クロスサイト スクリプティング (XSS)

This page is a translated version of the page Cross-site scripting and the translation is 65% complete.

クロスサイト スクリプティング (cross-site scripting)、XSS任意の JavaScript 注入 (arbitrary JavaScript injection) とは、ウェブ アプリケーションに典型的に見られるコンピューター セキュリティの脆弱性の一種であり、攻撃者が他の利用者が閲覧するウェブ ページにクライアント側スクリプトを注入できるものです。

クライアント側でのクロスサイト スクリプティングとその防止策については、DOM-based XSS を参照してください。

クロスサイト スクリプティングの例:

  • 攻撃者は、認証済みの利用者を騙して、特別に細工された URL や、攻撃者が制御するウェブサイトにアクセスさせ、細工された URL にリダイレクトさせることができます。
  • URL はウェブ アプリを指しており、クエリ文字列には JavaScript が含まれています。ウェブ アプリは、エスケープが不十分なため、利用者に表示するページに任意の JavaScript を注入します。
  • The JavaScript runs with full access to the user's cookies. It can modify the page in any way, and it can submit forms on behalf of the user. The risks are especially severe if the victim is an administrator with special privileges.

その他の例についてはウィキペディアの記事 Exploit の例を参照してください。

例:

function getTableCell( $out, $value ) {
    $request = $out->getRequest();
    $class = $request->getVal( 'class' );
    return "<td class='$class'>" . htmlspecialchars( $value ) . '</td>';
}

The attacker sends the victim to a URL such as:

http://example.com/wiki/SomePage?class='%20><script>hack();</script></td><td%20class='

POST requests are also vulnerable, using offsite JavaScript.

Victims do not even have to directly visit the page to be affected. Malicious 3rd party websites can embed hidden iframes to crafted URLs to attack a user while visiting a website of theirs. As well they may be tricked into visiting a malicious or crafted URL using short URL services or disguising the URL as another.

クロスサイトスクリプティングの停止

クロスサイト スクリプティングを回避するため、以下を行なってください:

  • 入力内容を検証
  • 出力内容をエスケープ

You can skip validation, but you can never skip escaping. Escape everything.

It does not matter if the escaping is redundant with the validation, the performance cost is a small price to pay in exchange for a demonstrably secure web app. It does not matter if the input comes from a trusted source, escaping is necessary even then, because escaping gives you correctness as well as security.

Escape as close to the output as possible, so that the reviewer can easily verify that it was done. It helps you to verify your own code as well.

Output encoding (escaping) is context sensitive. So be aware of the intended output context and encode appropriately (e.g. HTML entity, URL, JavaScript, etc.)

The OWASP Abridged XSS Prevention Cheat Sheet is a useful and up to date quick reference guide for mitigating XSS issues.

All this is true of any text-based interchange format. We concentrate on HTML because web apps tend to generate a lot of it, and because the security issues are particularly severe. Every text format should have a well-studied escaping function.

Here are some convenience functions which do HTML escaping for your site.

書式 エスケープ関数 注記
HTML htmlspecialchars( $string, ENT_QUOTES ) Always use the ENT_QUOTES flag which converts both double and single quotes. PHP has unfortunately "escape only single quotes" as default.[1]
XML ID Sanitizer::escapeId() HTML の id 属性用
CSS Sanitizer::checkCss() HTML の style 属性用
JavaScript FormatJson::encode(), Xml::encodeJsVar()
URL パラメーター wfArrayToCgi(), urlencode()
SQL $db->addQuotes()

MediaWikiエスケープ出力

MediaWiki also has some elegant built-in interfaces which implicitly escape your output. For SQL using the 'key' => 'value' syntax of conditions implicitly escapes values. And the Html:: and Xml:: interface methods escape attributes, and depending on the method used may escape a text value as well.

外部リンク

  • Escaping, w3.org. Very well written definition of escaping.

脚注