変数はHTTP GETを介して送信される変数よりもHTTP POSTを介して送信されるため、セキュリティは向上しません。
HTTP / 1.1は、リクエストを送信するための一連のメソッドを提供します。
- オプション
- 取得する
- 頭
- 役職
- 置く
- 削除
- 痕跡
- 接続する
GETを使用した次のHTMLドキュメントがあるとします。
<html>
<body>
<form action="http://example.com" method="get">
User: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="hidden" name="extra" value="lolcatz" />
<input type="submit"/>
</form>
</body>
</html>
あなたのブラウザは何を尋ねますか？それはこれを尋ねます：
GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
Host: example.com
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
ここで、リクエストメソッドをPOSTに変更したとしましょう。
POST / HTTP/1.1
Host: example.com
Connection: keep-alive
Content-Length: 49
Cache-Control: max-age=0
Origin: null
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
username=swordfish&password=hunter2&extra=lolcatz
これらのHTTPリクエストは両方とも次のとおりです。
- 暗号化されていません
- 両方の例に含まれています
- 盗聴される可能性があり、MITM攻撃の対象となります。
- サードパーティやスクリプトボットで簡単に複製できます。
多くのブラウザは、POST / GET以外のHTTPメソッドをサポートしていません。
多くのブラウザビヘイビアはページアドレスを保存しますが、これはこれらの他の問題を無視できるという意味ではありません。
具体的には：
1つは本質的により安全ですか？POSTはURLの情報を公開しないことに気づきましたが、その中に本当の価値はありますか、それともあいまいなことによる単なるセキュリティですか？ここでのベストプラクティスは何ですか？
これは正解です。HTTPを話すために使用しているソフトウェアは、1つの方法で要求変数を保存する傾向がありますが、別の方法では、ブラウザーの履歴や、h4x0r1ngを理解していると考えている10歳の人からの単純な攻撃を防ぐだけではありません。 、または履歴ストアをチェックするスクリプト。履歴ストアをチェックできるスクリプトがあれば、ネットワークトラフィックをチェックするスクリプトも簡単に作成できます。そのため、このあいまいさによるセキュリティ全体は、スクリプトキディや嫉妬深いガールフレンドにあいまいさを与えるだけです。
httpsではPOSTデータがエンコードされますが、URLがサードパーティによって盗聴される可能性はありますか？
SSLの仕組みは次のとおりです。上記で送信した2つのリクエストを覚えていますか？SSLでの表示は次のとおりです（example.comがSSLで応答しないため、ページをhttps://encrypted.google.com/に変更しました）。
SSL経由のPOST
q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r
SSL経由で取得
rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv
（注：HEXをASCIIに変換しましたが、一部は表示できないはずです）
HTTP会話全体が暗号化され、通信の可視部分のみがTCP / IP層（IPアドレスと接続ポート情報を意味する）上にあります。
ここで、大胆な発言をします。あなたのウェブサイトは、あるHTTPメソッドよりも他のHTTPメソッドよりも優れたセキュリティを提供されていません。世界中のハッカーや初心者は、ここで説明したことを実行する方法を正確に知っています。セキュリティが必要な場合は、SSLを使用します。ブラウザは履歴を保存する傾向があります。アクションを実行するためにGETを使用しないことをRFC2616 9.1.1で推奨していますが、POSTがセキュリティを提供すると考えるのは間違いなく間違っています。
POSTがセキュリティ対策である唯一のことは何ですか？ブラウザーの履歴をめくる嫉妬の元に対する保護。それでおしまい。残りの世界はあなたに笑いながらあなたのアカウントにログインしています。
POSTが安全でない理由をさらに実証するために、FacebookはPOSTリクエストをいたるところに使用しているので、FireSheepなどのソフトウェアはどのようにして存在できるのでしょうか。
HTTPSを使用していて、サイトにXSSの脆弱性が含まれていない場合でも、CSRFで攻撃される可能性があることに注意してください。つまり、この攻撃シナリオでは、被害者（サイトまたはサービスのユーザー）がすでにログインしており、適切なCookieを持っていることを想定しており、被害者のブラウザが（おそらく安全な）サイトで何かをするように要求されます。CSRFに対する保護がない場合でも、攻撃者は被害者の資格情報を使用してアクションを実行できます。サーバーの応答は被害者のブラウザに転送されるため、攻撃者はサーバーの応答を見ることができませんが、被害は通常その時点ですでに行われています。