2つのWebアプリケーション間でデータを送信する方法は2つあります。
データをBase64でエンコードしてURLに追加し、宛先アプリケーションでこれらのパラメーターを取得して、パラメーターをデコードします。
たとえば、http:/myDomain/someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ
パラメータを非表示の値としてapplication1からapplication2に送信します。
文字列res =(String)request.getAttribute( "paramValue"); document.myForm.action = 'myDestinationURL'; document.myForm.method = "POST"; document.myForm.submit(); <form name = "myForm" method = "post"> <input type = "hidden" name = "paramValue" value = "<%= res%>" />
選択肢1では、送信しているパラメーターと私のエンコード手法を知ることができます。選択肢2では、ソースの表示を簡単に行うことにより、送信しているデータを表示できます。
上記のものとは別に、侵入者が私のシステムをよりよく知るために可能な方法は何ですか?そして、開発者にとって一般的に適しているのはどのオプションですか?選択肢1または選択肢2?
いずれにしても、オプション1では、セキュリティに関連しない多くの問題が発生する可能性があります。
しかし、これはセキュリティに関するものであり、オプション2にはないいくつかのリスクをもたらします。
とはいえ、それらは他の点ではそれらが提供するセキュリティにおいてほぼ同等です。どちらもHTTPヘッダーでプレーンテキストデータを送信します。base64は正確なロケットサイエンスではありません(POSTバージョン)をbase64エンコードできます)。
どちらも、データに意味のある保護を提供しません。
ユーザーに見せたくない情報の場合。はじめにそれをユーザーに送信するのはなぜですか?使用しているアーキテクチャを検討し、クライアント側でその情報を処理しないことによってリスクを完全に取り除く方法があるかどうかを確認してください。
したがって、質問に答えるために:データの送信に関して-both同じ情報を攻撃者に明らかにします。状況に適したオプションを選択します( このTreehouseブログ投稿がそれを助けるかもしれません )が、すべきではありませんいずれかの方法で実際に何かを保護します。
Webページに単純な<img>
タグを含めることで、クロスサイトGET
リクエストを簡単に作成できます。たとえば、www.evilhacker.com
のページでは、一部のJavascriptが攻撃者が選択したパスを含む<img>
タグの長いストリームを生成し、すべてがwww.targetbank.com
-およびを指します。 yourブラウザは、すべてのリクエストに銀行のCookieを含めます。
これだけでも、ターゲットサイトでのすべての変更を意味するGET
リクエストのサポートがない方がよい。一般的なルールとして、GET
リクエストは リプレイ攻撃 が問題ではない操作に予約する必要があります-つまり、実際には、静的データへの読み取りアクセス )のみ。
POSTを使用して、サーバーでデータを変更するリクエストを送信します。
HTTP仕様 により、GETリクエスト(URL内のパラメーターなど)は、データを変更せずに取得する(したがって、GETという名前の)リクエストにのみ使用する必要があります。 POSTリクエスト(非表示のパラメーターですが、HTTPリクエストではまだ暗号化されていません)は、リクエストがデータベースに保存されるデータ(標準ログ以外)を作成/更新/変更するときは常に使用する必要があります。これにより、攻撃者がクロスサイトリクエストフォージェリを実行することが やや難しく され、Webページの履歴やWebサーバーのログに秘密情報が誤って二重送信または保存される可能性が低くなります。
ピン変数は秘密ですか?
pin
変数の意味によっては、現在行っていることは安全ではないようです。これは潜在的な盗聴者から秘密にしておく必要がありますか、それともピンを傍受している人々がそれを使って何らかの攻撃を行うことができますか?その場合、このシークレットデータを使用するすべての要求に対してHTTPS(トランスポート層でのエンドツーエンドの暗号化)のみを使用してください。使用したbase-64値は_3000670269
_のようです(適切なb64エンコーディングにするために2つの等号を追加する必要があったことを認めています)。
攻撃者が他のピンを使用しようとするとどうなりますか?
私の_pin='300670269'
_としましょう。ただし、システムをテストするために_MzAwMDY3MDI1OQ
_を送信しました(_pin='3000670259'
_の場合)。それにより、別のユーザーアカウントに効果的に侵入できますか?もしそうなら、少なくとも、checksum=SHA256(pin+secret_server_side_string)
のような追加のPOST変数のようなものを実行する必要があります。ここで_secret_server_side_string
_は、長いランダムな文字列です(たとえば、何か_de10RRORX50UAUhx0dDIxJnzXKBAs68yjdWVz8QQ
_- 40 random upper + lower + numbers文字はlg(62)* 40 = 238ビットのエントロピーを持つ)のようになり、アプリケーションはピンにチェックサムが一致する場合にのみピンに作用します。アプリケーションはチェックサムを生成する必要があります(secret_server_side_stringをクライアントに公開せずに)。ピンでチェックサムをチェックするとき、アプリケーションが一定時間の文字列比較を行うように注意する必要があります。これにより、アプリケーションがタイミング攻撃に対して脆弱になりません。 。
Bobの回答に加えて、機密パラメータを指定したGETリクエストを使用する場合、セキュリティ上の別の欠点があります。
機密情報を含むURLは、結果のHTMLページによって参照されるリソースをホストしているサードパーティのWebサーバーに送信されます。
例:
最初のリクエスト:
GET /someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ HTTP/1.0
Host: domain
その要求への応答:
HTTP/1.0 OK
Content-type: text/html
<img src="http://thirdparty/hello.jpg" />
WebブラウザーはHTMLをレンダリングし、次のように画像を取得しようとします。
GET /hello.jpg HTTP/1.0
Host: thirdparty
Referer: http://domain/someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ
これは、ページにレンダリングされたHTMLが攻撃者によって制御されている場合(ある程度、ホワイトリストにhtmlがある場合)に特に問題になります。たとえば、セッションをURLに配置するWebメールサービスにより、攻撃者は、メールのHTML本文で、攻撃者のWebサーバー/スクリプトを指す画像を送信することができます。次に、攻撃者は、画像をレンダリングするときに、被害者のWebブラウザーから送信されたReferer
ヘッダーのURLをたどる必要があります。この種の脆弱性は、実際にはExciteメール(ここでは履歴を話します:))や過去の他のいくつかのWebメールサービスに影響を及ぼしました。
Webアプリケーションファイアウォールルールを回避するために悪用された最近の興味深い攻撃は、「 HTTPパラメータ汚染攻撃 」として知られています。のような例で説明します
POST /index.aspx?par=1&par=2 HTTP/1.1
User-Agent: Mozilla/5.0
Host: Host
Cookie: par=5; par=6
Content-Length: 19
par=3&par=4
このPost Requestアプリケーションの動作は、Javaの開発者などに依存します。
考慮すべきもう1つのセキュリティ要素は、Webサーバーのアクセスログは通常、クエリ文字列パラメーターを含め、要求されたURLをキャプチャすることです。クエリ文字列をログに記録したくない場合は、POSTリクエストに頼る必要があります。
もちろん、ページをリロードするときのブラウザの動作や、ブラウザの[戻る]ボタンを使用してページが呼び出されるときなど、GETリクエストとPOSTリクエストのどちらを決定するかを検討するときに、セキュリティに関連しない要素があります。