Wordpressには404エラーで応答する「デフォルトの」アンチSQLインジェクションコードが含まれていますか？
私はこれで 「キャンディー杖の森の7つの層」 を通っています…:)
私たちのプラグインはPOSTリクエストを通してデータを受け取ります。私たちのプラグインがインストールされている特定のサイトで、私たちは奇妙な振る舞いを観察しました。 ある特定のシナリオでは、POST要求が誤って404（Not Found）エラーを生成していました。
私は次のような再現のシナリオが残るまで、私は非常に広く始めて少しずつ問題を絞り込んでいきました。不可解なエラーは以下の場合に発生します。
- 「POST」リクエスト
- 以下のURLにアクセスする http://example.com/wp-content/
- x-www-form-urlencodeされたデータを提供します
or（ "or"の後にスペース、大文字と小文字は区別されません）の直後に、送信されたデータ内の任意の場所（フィールド値だけでなく）が続きます（例：an ARM or 30-year fixed-rate mortgage）
他のインストール済みプラグインをチェックしました。何もない。テンプレートを確認しました。なだ。プラグインがインストールされている他のいくつかのサイトをチェックしましたが、それでもバグを再現することができませんでした。
私が言うことができるすべてから、これは問題となっている単一のサイトの信じられないほど特定の問題です。再現のシナリオのせいで、私はそれがいくつかの過剰な反SQLインジェクションコードによるものだと思います。
Wordpressにデフォルトでこの問題を引き起こしている可能性のあるコードはありますか？私の考えでは、この問題は他のもの（ファイアウォール、.htaccessルールなど）のせいです。 ）でも、専門家に相談したいと思いました！ :)
更新：
< having x、or having y、and having zなど、 "[operator] having [string]"の形式の投稿データでもこの問題は発生しています。HAVINGがSQLキーワードであることを考えると、これはさらに証拠であると考えられます。セキュリティツールが正しく設定されていません。これらのさまざまな観察は異なるサーバー上で行われたので、この単一サーバー上で単にファンキーなものではありません。私は、複数のサーバーが誤って設定されていたり、厳密なセキュリティプロトコルが設定されている可能性がありますが...
もう一つの更新：私はこの問題に再び遭遇した。今回は、問題のPOSTペイロードを単純に文字列<strong>に単純化しました。この文字列を含むPOSTされたデータ（上記の他の条件と一致）は404を生成します。
@ Jeff Mattsonによって示唆されているように、何時間もの調査とテストはこれがおそらくmod_securityが原因であることを示唆しています。私はそれがSuhosinによるものである可能性についても調査しました、しかしそれが非難であるとは思いません。
これが契約です。問題がmod_securityによるものであることを確認しても、実際には役に立ちません。プラグインを実行しているサーバーを制御していないため、.htaccessを介してmod_securityを無効にしようとしても失敗しました。
幸い、トンネルの終わりに光があります。問題の原因が何であれ、問題を解決するためのほぼ確実な解決策は、単にPOSTデータを変更することです。
私が実装しようとしている解決策は、私たちがプラグインに送っているデータをBase62でエンコードすることです。 Base64もおそらくうまくいくでしょうが、私はこの問題を一回限り解決したいと思います。そして、その限られた文字セットのために、mod_security.のような神経症の獣を扱うときはBase62が安全な方法です。
Mod_securityは送信されたデータの中で特定の "問題のある"文字列を探すので、これはうまくいくはずです。私はモジュールが送信されたデータにさまざまなエンコーディングの束を適用することを試みるのに十分に洗練されていることを疑います（そして、そうすることはパフォーマンスに悪い影響を与えるでしょう）.
わーい！