cross site scripting attack tutorial with examples
クロスサイトスクリプティング（XSS）攻撃の完全ガイド、それを防ぐ方法、およびXSSテスト。
クロスサイトスクリプティング（XSS）は、すべての高度なテスターに知られている最も一般的で脆弱な攻撃の1つです。これは、Webアプリケーションにとって最も危険な攻撃の1つと見なされており、有害な結果をもたらす可能性もあります。
XSSは、クライアント側の言語が主にこの攻撃中に使用されているため、同様のクライアント側の攻撃と比較されることがよくあります。ただし、XSS攻撃は、脆弱性の低いテクノロジにさらに損害を与える可能性があるため、リスクが高いと見なされます。
このXSS攻撃チュートリアルでは、そのタイプ、ツール、および予防策の完全な概要と、わかりやすい簡単な用語での完璧な例を紹介します。
学習内容：
- XSS攻撃の概要
- XSSはどのように実行されていますか？
- クロスサイトスクリプティング攻撃の種類
- XSSに対してテストする方法は？
- XSSテストツール
- 他の攻撃との比較
- XSSを防ぐ方法
- 技術による予防
- XSSチートシート
- 結論
- 推奨読書
XSS攻撃の概要
クロスサイトスクリプティング攻撃は悪意のあるコードインジェクションであり、被害者のブラウザで実行されます。悪意のあるスクリプトはWebサーバーに保存され、ユーザーが適切な機能を呼び出すたびに実行される可能性があります。 Webサーバーにスクリプトを保存せずに、他の方法で実行することもできます。
この攻撃の主な目的は、他のユーザーのIDデータ（Cookie、セッショントークン、その他の情報）を盗むことです。ほとんどの場合、この攻撃は他の人のCookieを盗むために使用されています。ご存知のように、Cookieは自動的にログインするのに役立ちます。したがって、盗まれたCookieを使用して、他のIDでログインできます。そして、これが理由の1つであり、この攻撃が最も危険な攻撃の1つと見なされる理由です。
XSS攻撃はクライアント側で実行されています。さまざまなクライアント側プログラミング言語で実行できます。ただし、ほとんどの場合、この攻撃はJavascriptとHTMLを使用して実行されます。
おすすめの読み物=> HTMLインジェクションチュートリアル
XSSはどのように実行されていますか？
クロスサイトスクリプティング攻撃とは、悪意のあるコードまたはスクリプトを送信および挿入することを意味します。悪意のあるコードは通常、Javascript、HTMLなどのクライアント側プログラミング言語で記述されています。 VBScript 、Flashなど。ただし、この攻撃を実行するために主にJavascriptとHTMLが使用されます。
この攻撃はさまざまな方法で実行できます。 XSS攻撃の種類によっては、悪意のあるスクリプトが被害者のブラウザに反映されるか、データベースに保存され、ユーザーが適切な関数を呼び出すたびに実行される可能性があります。
この攻撃の主な理由は、悪意のある入力が出力に侵入する可能性がある不適切なユーザーの入力検証です。悪意のあるユーザーがスクリプトを入力して、Webサイトのコードに挿入する可能性があります。そうすると、ブラウザは実行されたコードが悪意のあるものかどうかを知ることができません。
そのため、被害者のブラウザで悪意のあるスクリプトが実行されているか、偽のフォームがユーザーに表示されています。 XSS攻撃が発生する可能性のあるいくつかの形式があります。
クロスサイトスクリプティングの主な形式は次のとおりです。
- クロスサイトスクリプティングは、クライアント側で実行される悪意のあるスクリプトで発生する可能性があります。
- ユーザーに表示される偽のページまたはフォーム（被害者が資格情報を入力するか、悪意のあるリンクをクリックする場所）。
- 広告が表示されているウェブサイト。
- 被害者に送信された悪意のある電子メール。
この攻撃は、悪意のあるユーザーがWebサイトの脆弱な部分を見つけて、適切な悪意のある入力として送信したときに発生します。悪意のあるスクリプトがコードに挿入され、最終ユーザーに出力として送信されています。
簡単な例を分析してみましょう。 検索フィールドのあるウェブサイトがあるとします。
検索フィールドが脆弱な場合、ユーザーがスクリプトを入力すると、そのスクリプトが実行されます。
以下に示すように、ユーザーが非常に単純なスクリプトを入力するとします。
alert(‘XSS’) 
次に、をクリックした後 '探す' ボタンをクリックすると、入力したスクリプトが実行されます。
私たちが見るように 例 、検索フィールドに入力されたスクリプトが実行されます。これは、XSS攻撃の脆弱性を示しているにすぎません。ただし、より有害なスクリプトも入力される可能性があります。
多くのテスターは、クロスサイトスクリプティング攻撃と Javascriptインジェクション 、これもクライアント側で実行されています。どちらの場合も、攻撃の悪意のあるスクリプトが挿入されています。ただし、XSS攻撃の場合、スクリプトを実行するためにタグは必要ありません。
例えば ：
;また、他のイベントで実行されるスクリプトにすることもできます。
例えば：マウスをホバーします。
別の例を分析してみましょう：最新の書評がウェブサイトに表示されているページがあるとします。
このページのコードは次のようになります。
print '' print '. If this vulnerability is present in the web application, an indicated text will be inserted intags. Trying to pass some code through HTTP request as this is also a method to check if this attack is possible.
Generally, while testing for possible XSS attack, input validation should be checked and the tester should be conscious while checking the website’s output. Also if a code review is being performed, it is important to find how input can get into the output.
XSS Testing Tools
As Cross Site Scripting attack is one of the most popular risky attacks, there are a plenty of tools to test it automatically. We can find various scanners to check for possible XSS attack vulnerabilities – like, Nesus and Nikto. Both of which are considered as quite reliable.
From my software testing career, I would like to mention SOAP UI tool. SOAP UI can be considered as a quite strong tool for checking against the possible XSS attacks. It contains ready templates for checking against this attack. It really simplifies the testing process.
However, in order to test for this vulnerability with SOAP UI tool, API level testing should already be automated with that tool. Another solution to test against XSS can be browser plugins. However, plugins are considered as quite a weak tool to check against this type of attack.
Even while testing automatically, the tester should have good knowledge of this attack type and should be able to analyze the results appropriately.
Good knowledge is also helpful while selecting the testing tool. Also, it is important to know, that while performing scanning for security vulnerabilities with an automatic tool, testing manually is also a good practice and this way the tester will be able to see the results and analyze them.
Recommended Tool:
#1) Kiuwan
Find and fix vulnerabilities in your code at every stage of the SDLC.
Kiuwan is compliant with the most stringent security standards including OWASP, CWE, SANS 25, HIPPA, and more. Integrate Kiuwan in your IDE for instant feedback during development.
Kiuwan supports all major programming languages and integrates with leading DevOps tools.
=> Scan your code for free
Comparison with Other Attacks
XSS is considered to be one of the riskiest attacks, as its main purpose is to steal the website’s or system’s user identities. Also, XSS attack can be performed with different client-side languages like Javascript, HTML, VBScript, Flash, etc. And this makes it more harmful and widespread than the other possible attacks.
Testing for XSS attack is quite similar to testing for the other possible client-side attacks. However, it is important to remember what additional cases should be checked while testing for XSS.
Another thing, that makes this attack riskier is the possibility to be stored in the web service – this way it can affect many users for a longer period of time. XSS sometimes can be performed to even less vulnerable systems and its vulnerabilities are sometimes difficult to be found.
Also, while comparing with the other attacks, XSS has many ways to be performed and affect the website as well.
Ways to Prevent XSS
Though this type of attack is considered to be one of the most dangerous and risky one, still a preventing plan should be prepared. Because of the popularity of this attack, there are quite many ways to prevent it.
Commonly used main prevention methods include:
- Data validation
- Filtering
- Escaping
The first step in the prevention of this attack is Input validation . Everything, that is entered by the user should be precisely validated, because the user’s input may find its way to the output. Data validation can be named as the basis for ensuring the system’s security. I would remind, that the idea of validation is not to allow inappropriate input.
Therefore it just helps to reduce the risks, but may not be enough to prevent the possible XSS vulnerability.
Another good prevention method is user’s input filtering. The idea of the filtering is to search for risky keywords in the user’s input and remove them or replace them by empty strings.
Those keywords may be:
- tags
- Javascript commands
- HTML markup
Input filtering is quite easy to practice. It can be performed in different ways too.
Like:
- By developers who have written server-side code.
- Appropriate programming language’s library is being used.
In this case, some developers write their own code to search for appropriate keywords and remove them. However, the easier way would be to select appropriate programming languages library to filter the user’s input. I would like to comment, that using libraries is a more reliable way, as those libraries were used and tested by many developers.
Another possible prevention method is characters escaping . In this practice, appropriate characters are being changed by special codes. For Example, Meanwhile, good testing should not be forgotten as well. It should be invested in good software testers knowledge and reliable software testing tools. This way good software quality will be better assured.
Prevention According to Technologies
As already discussed, filtering and characters escaping are the main prevention methods. However, it can be performed differently in different programming languages. Some programming languages have appropriate filtering libraries and some do not.
It should be mentioned, that filtering can be performed quite easily in Java and PHP programming languages, as they have appropriate libraries for it.
Java technology is quite widely used, therefore there are many solutions to it. If you are using Spring technology and if you would like to escape HTML for the whole application, then you have to write the appropriate code in the project’s web.xml file.
defaultHtmlEscape true このコードは、アプリケーション全体のHTMLエスケープを切り替えます。
適切なページのフォームのHTMLエスケープを切り替えたい場合は、コードを次のように記述する必要があります。
.jarファイルの形式ですぐに使えるXSSフィルターがたくさんあります。 .jarファイルをプロジェクトに追加する必要があり、そうして初めてそのライブラリを使用できることを思い出してください。そのようなXSSフィルターの1つは、サーブレットフィルターであるxssflt.jarです。この.jarファイルは、インターネットから簡単にダウンロードして、プロジェクトに追加できます。
このフィルターは、アプリケーションに送信されるすべての要求をチェックし、潜在的な注入からアプリケーションをクリーンアップします。
Wordでxmlファイルを表示する方法
external.jarファイルをプロジェクトに追加するときは、web.xmlファイルにも記述する必要があります。
XSSFilter com.cj.xss.XSSFilter 別の可能な解決策はESAPIライブラリです。 ESAPIライブラリは多くのプログラミング言語と互換性があります。 JavaおよびPHPプログラミング言語用のESAPIライブラリを見つけることができます。これはオープンソースで無料のライブラリであり、アプリケーションのセキュリティを制御するのに役立ちます。
XSSチートシート
XSSチートシートは、クロスサイトスクリプティングの防止に非常に役立ちます。これは、XSS攻撃を防ぐ方法に関する開発者向けのガイドラインです。ルールは非常に役立ち、開発中に忘れてはなりません。 XSSチートシートは、OWASP（The Open Web Application Security Project）などのインターネットコミュニティで見つけることができます。
さまざまな種類のチートシート：
- XSS防止に関するチートシート
- DOMXSSチートシート
- XSSフィルター回避チートシート
XSS攻撃防止の一般的なルールを提供するため、主なガイドラインはXSS防止に関するチートシートです。 DOM XSSチートシートとXSSフィルター回避チートシートのルールに従う場合でも、XSS防止チートシートに従う必要があります。
前述のように、XSS防止に関するチートシートはOWASPコミュニティにあります。このチートシートには、XSS攻撃の可能性のリスクを軽減するのに役立つルールのリストが記載されています。これは、コーディング規則だけでなく、予防ベースのセキュリティの脆弱性でもあります。
いくつかのルールが含まれます：
- 信頼できないデータは挿入しないでください。
- 信頼できないデータを挿入する前に、HTMLをエスケープする必要があります。
- 信頼できないデータなどを挿入する前に、属性をエスケープする必要があります。
したがって、チートシートは、このタイプの攻撃を防ぐのに非常に役立つ場合があります。
結論
テスト中に、XSS攻撃の可能性をもたらすリスクを評価することを強くお勧めします。 XSS攻撃は、安全と思われるWebアプリケーションに影響を与える可能性があります。
これは、最も有害で危険な攻撃の1つと見なされています。したがって、このタイプのテストを忘れてはなりません。 XSSに対してテストを実行するときは、この攻撃について十分な知識を持っていることが重要です。そしてこれは、テスト結果を正しく分析し、適切なテストツールを選択するための基礎です。
あなたはクロスサイトスクリプティングXSS攻撃に対処したテスターですか？ XSS攻撃について、読者にも役立つ興味深い事実はありますか？以下のコメントセクションで私たちとあなたの経験を共有してください！
推奨読書
