HTTPのPOSTメソッドにおいてリクエストボディをURLエンコードする必要性はあるのでしょうか？

Question

HTTPのPOSTメソッドでリクエストを投げる際にURLエンコードする必要性はあるのでしょうか。
URLエンコードというのは、もともとヘッダ部のURL部分に2バイト文字や制御文字と紛らわしい文字が入るのを防止するためのものであり、
BODY部には不要ではないかと思いました。

例えばMIME TYPEにapplication/x-www-form-urlencodedが指定されている場合文字列はエンコードして送信されますが、
application/jsonを指定する場合などは、手動でURLエンコーディングするべきでしょうか？

Answer 1

まず結論から申し上げますと、

• URLエンコードは求められていません。
• ただしもちろん、JSONならばJSONとしての適切なエスケープ（例えば文字列フィールド中の引用符など）は別途必要です。

まず、URLエンコードの不必要な理由。HTTPは最初からバイナリデータを送受信できるように規格で決められています。HTTPの規格書 https://www.ietf.org/rfc/rfc2616.txt の4.4節

       message-body = entity-body
                    | <entity-body encoded as per Transfer-Encoding>

7.2節

entity-body    = *OCTET

に定義されているとおりメッセージボディは、Transfer-Encodingが指定されていない限り生のバイナリの配列であるとされています。

さてではコンテントタイプがapplication/x-www-form-urlencodedのときにURLエンコードが必要となる理由。これはkey=value形式のデータを&区切りで並べる以上、value部に'&'が入っているとvalueの一部なのか区切り文字なのか見分けがつかないからエスケープする必要があるという、HTTPよりは高レベルのアプリケーション上の要求でとなります。

Comments

[TetsujiMiwa]

takotakotさんのコメントでもしやと思いましたが、
yubaさんは、GETの話をごちゃ混ぜにして居ませんでしょうか？
質問は、「POSTでのリクエスト時にボディ（つまりフォームのパラメータ）にURLエンコードをする必要があるか？」なので、これから外れる内容であれば、それを明記してあげないと誤解をうむと思います。
セキュリティの検討説明についても、「SQLインジェクション」の話などをされていますが、質問文ではDBについて一切触れてないです。ご自身が質問する側の立場でしたら、このような注意を受けてどう感じますでしょうか？
少なくとも私でしたら「SQLインジェクションについて考えなきゃいけないと言われているけど、では具体的にどう検討したらいいのだろう？」と困ってしまうと思います。

Answer 2

エンコードの必要はないです。

URLエンコードとは、リクエストURLに対するエンコードです。
最近はあまり意識する必要は無いです。
実際問題が起こってから対処する形で良いと思います。

Comments

[yuba]

必要ないという結論は正しいのですが、URLエンコードは別にリクエストURLだけのためのものではなくボディに適用することは普通にありますし、また「問題が起こってから対処」という方針はことセキュリティに関わる分野では許容されません。

[TetsujiMiwa]

yubaさん
ボディに適用することは普通にあるのに、適用の必要が無いという結論が正しいというのは、矛盾を感じるところです。私のレスではなくご回答されてみてはいかがでしょう。
あと、ただのコード変換のURLエンコードがセキュリティとどのように関係するかもご回答いただけると、私の回答の稚拙さを明白にできるかと思います。

[takotakot]

yuba 様の回答が気になりますね。
TetsujiMiwa 様へ…「実際問題が起こってから」とは、どんな問題がありうるのでしょうか？こちらも伺いたいです。

[yuba]

詳細は回答の方をご覧頂くとして、「ただのコード変換のURLエンコードがセキュリティとどのように関係するか」についてこちらでお答えします。
URLエンコードは英数字以外のエスケープという性格を持つ文字列変換です。エスケープが必要な状況でエスケープをし忘れるというのがセキュリティ上どれだけ脅威であるか、経験豊富な技術者であるTesujiMiwa様ならご理解いただけると思います。
エスケープが必要な非リテラル文字が素通しされれば、XSS・SQLインジェクション・コマンドインジェクション、以上を総称して文字列インジェクション攻撃が可能になります。
「適切なエスケープが必要な状況でないか」を確認せずに問題が起きてから対処という行動の結果がどのくらいの破壊力になって帰ってくるかは「SQLインジェクション 被害額」あたりでぐぐっていただければと思います。

[TetsujiMiwa]

過去の経験からの話ですが、
・C#のMVCでRazorビューというのを採用した際、デフォルトでURLエンコードをしているのに気付かず自前でURLエンコードしてしまったためにおかしな挙動となった
・IE5あたりで、#をパラメータとする物があって、直前URLの保持に苦労した、
とかです。
大体、すぐに問題が発覚するものでしょうから、URLエンコードによる起こりうる問題を実装前に事前にあれやこれや検討する必要はない、ということです。

[TetsujiMiwa]

セキュリティ対策は、アプリケーションサーバ側で処置するものであって、
クライアント側で対処するものではないと思うのですが。。。

[takotakot]

お二方、ありがとうございます。
yuba 様の回答を読む限りでは、「エスケープが必要な状況でエスケープをし忘れるというのがセキュリティ上どれだけ脅威であるか」は、「フォーム送信データの URL エンコード」とは必ずしも関係しない気が致しました。
姿勢として「問題が起きてから対処」は困るとは思いますし、エスケープ処理を忘れることはセキュリティ上の問題に直結しますが、TetsujiMiwa 様の「問題が起きてから対処」は、URL エンコードに限定して仰っている気がしました。
URL エンコードされたデータは受け手(サーバ)でデコードする(しないと「欲しかった」データが得られない)、という仮定の下では、デコード後の挙動が問題になるので、もちろん、そのまま表示すれば、XSS 等に繋がります。もし違えば、ご回答に追記頂ければ幸いです。
「value部に'&'が入っているとvalueの一部なのか区切り文字なのか見分けがつかないからエスケープする必要がある」のが、エスケープ処理が必要な理由ですね。

TetsujiMiwa 様によれば、デフォルトの挙動や、# の有無 によって、「URLエンコードによる」問題が出ることがある(あった)ということですね。
送信側が生データをどう送るかという観点では、クライアント側のエンコード有無は(サーバがどちらか分かっていれば)不要で、セキュリティは別の話、ということですね。

takenyaan 様、横レスになってすみませんでしたが、非常に参考になりました。ありがとうございます。