特定の値との照合に必要なフィールドにスクリプトを入力して、クロスサイトスクリプティング攻撃を実行することはできますか?
アプリケーションの脆弱性をスキャンしていますが、スキャンツール(OWASP ZAP)がクロスサイトスクリプティングの脆弱性をいくつか返しています。返される結果には、RESTリクエストのパス、関連するメソッド(GETまたはPOST)、およびスクリプトを含めるために使用されるパラメーターが含まれます。
問題は、脆弱性ごとに、使用されるパラメーターが一意の値のIDであることです。たとえば、getUserPrivileges
GETリクエストは、パラメーター 'userId'を使用して脆弱性を示しています。無効なuserIdを使用してこのリクエストをSoapUIで作成しようとすると、「Bad Request」応答が返されます。また、UIには、このパラメーターに独自の値を入力できる場所もありません。
私の仮定では、これらのような問題はすべて誤検知であると考えていますが、このトピックについてはあまり詳しくないので、私の仮定を確認したいと思いました。
この仮定が正しい場合、そのような誤検知が発生する理由はありますか?スキャンツールがこれを問題と間違える原因となるものはありますか?
編集:2つのリクエストの例を次に示します。実際に問題があると思うのは例2です。その例の「」テキストは未加工の応答には存在しますが、html応答には存在しません。
(htmlコンテンツが受け入れられないと言うとき、私はリクエストレスポンスのコンテンツを参照しています。これの設定はサーバー側にあります。Springでは、これは「produces = MediaTypeメソッド宣言の.TEXT_HTML_VALUE "と、" produces = MediaType.APPLICATION_JSON_VALUE "のようなものでの置換)
例1:
Request:
GET http://###.##.##.###:####/AAAAAAAA/BBBBBBBB/CCCCCCCC? requestId=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E&comments=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E HTTP/1.1
Accept-Encoding: gzip,deflate
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Response (Raw):
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Content-Type: application/json;charset=UTF-8
Content-Length: 167
Date: Wed, 22 Aug 2018 ##:##:## GMT
Connection: close
{"timestamp":#############,"status":400,"error":"Bad Request","exception":"Java.lang.NumberFormatException","message":"For input string: '<script>alert(1);</script>'"}
Response (HTML):
unsupported content-type [application/json;charset=UTF-8]
例2:
Request:
GET http://###.##.#.###:####/AAAAAAAA/BBBBBBBB/CCCCCCCC?requestId=%3Cscript%3Ealert%28%22hello%22%29%3B%3C%2Fscript%3E HTTP/1.1
Accept-Encoding: gzip,deflate
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Host: ###.##.#.###:####
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (Java 1.5)
Response (raw):
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Content-Type: text/html;charset=UTF-8
Content-Length: 173
Date: Wed, 22 Aug 2018 ##:##:## GMT
Connection: close
{"timestamp":#############,
"status":400,
"error":"BadRequest",
"exception":"Java.lang.NumberFormatException",
"message":"For input string: '<script>alert('hello');</script>'"}
Response (HTML):
{"timestamp":#############,
"status":400,
"error":"Bad Request",
"exception":"Java.lang.NumberFormatException",
"message":"For input string: ''"}
自動スキャナーを使用するときはいつものように、この脆弱性を確認するか、誤検知として拒否するために、いくつかの手動テストを行う必要があります。
ZAPドキュメント から(@SimonBennettsに感謝):
クロスサイトスクリプティング(反映)
このルールは、「安全な」値を送信し、この値が応答で発生するすべての場所(存在する場合)を分析することから始まります。次に、タグ属性、URL属性、src属性をサポートするタグ内の属性、htmlコメントなど、各インスタンスが発生する場所をターゲットにした一連の攻撃を実行します。
つまり、反映されたXSSに対するZAPの誤検出率はおそらくかなり低く、つまり、レポートされているもののほとんどは実際のものです。標準のXSSメカニズム。
それが報告するものはすべて、さらに手動で調査する価値があります。
関係ありません。
最も危険な種類のXSSは、悪意のあるペイロードがGET URLパラメータにあるものです。次に例を示します。
_http://server/cgi-bin/testcgi.exe?usedid=<script>alert("Hello!")</script>
_
それで、そのリンクをフィッシングメールに入れて、クリックすると、私のコードが実行されます。
そのため、UI要素はありませんが、ZAPはコードを挿入できるパラメーターをいくつか検出し、サーバーはそれをHTMLページの一部としてエコーバックします。
これは、アラートのポップアップが生成されるか、開発者が適切な出力エスケープを行ったと確信するまで、ページソースを調べて/ページの再生を開始する必要がある場所です。
はじめに、OWASPには優れたXSSテストガイドがあります。
https://www.owasp.org/index.php/Testing_for_Cross_site_scripting
@AndrolGenhaldが指摘するように、「Bad Request」ページは、適切にエスケープせずに入力をエコーバックする可能性があります。私がusedid=<script>alert("Hello!")</script>
を使用してサーバーをヒットした場合、それは私にエラーページを返すのに役立つと思います
_Bad Request: "<script>alert("Hello!")</script>" is not a valid user.
_
ページのソースを見ると、これが適切にエスケープされているのがわかると思います。
_Bad Request: "<script>alert("Hello!")</script>" is not a valid user.
_
これは、HTMLコードの一部として扱うのではなく、これをテキストとしてレンダリングするようにブラウザに指示します。ページのソースでエスケープされていないように見える場合は、少し遊んでみると、おそらく次のようにレンダリングできます。
_Bad Request: "
_
これは、テキストとしてレンダリングするのではなく、実際にスクリプトを実行したことを意味します(それに伴って、おそらく素敵なポップアップが表示されます)。こんにちは反射XSS攻撃ベクトル!! (あなたは脆弱性を見つけた、バグチケットを開いてビールを飲みに行く)