質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
HTTP

HTTP(Hypertext Transfer Protocol)とはweb上でHTML等のコンテンツを交換するために使われるアプリケーション層の通信プロトコルです。

POST

POSTはHTTPプロトコルのリクエストメソッドです。ファイルをアップロードしたときや入力フォームが送信されたときなど、クライアントがデータをサーバに送る際に利用されます。

URL

URL(ユニフォームリソースロケータ)とは、インターネット上のリソース(Webページや電子メールの宛先等)を特定するための形式的な記号の並びの事を言う。

Q&A

解決済

2回答

76285閲覧

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

takenyaan

総合スコア119

HTTP

HTTP(Hypertext Transfer Protocol)とはweb上でHTML等のコンテンツを交換するために使われるアプリケーション層の通信プロトコルです。

POST

POSTはHTTPプロトコルのリクエストメソッドです。ファイルをアップロードしたときや入力フォームが送信されたときなど、クライアントがデータをサーバに送る際に利用されます。

URL

URL(ユニフォームリソースロケータ)とは、インターネット上のリソース(Webページや電子メールの宛先等)を特定するための形式的な記号の並びの事を言う。

1グッド

5クリップ

投稿2015/10/13 16:36

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

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

saitouakihiro👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

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

  • 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よりは高レベルのアプリケーション上の要求でとなります。

投稿2015/10/20 12:04

yuba

総合スコア5568

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

TetsujiMiwa

2015/10/21 10:29

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

0

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

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

投稿2015/10/13 18:34

TetsujiMiwa

総合スコア1124

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yuba

2015/10/13 22:57

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

2015/10/13 23:30

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

2015/10/20 06:51

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

2015/10/20 12:11

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

2015/10/20 12:23

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

2015/10/20 12:26

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

2015/10/21 01:08

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問