どーも。ばぁどです。
もうすぐ7年目になるWebアプリエンジニア上がりの情報処理安全確保支援士です。(情報処理安全確保支援士歴は2020年度で3年目になります)
現在はセキュリティ関連の仕事をやったり、社内内部システムの開発などをしたりしています。
最近、社内で色々と若手に教える立場になっています。 一時期、講師業務もやっていたので、教えるということには少しはなれたのですが、いかんせんまとまった資料が手持ちでありません。
ネットを探せば、良い資料は沢山あって、筆者自身ブックマークは大量につけているのですが、自分自身で作った資料ほど扱いやすいものはありません。
そこで今回はブログ記事として資料を作ってみて、いつでも使えるようにしてみました。 あくまで本ブログ記事は筆者の自己満足ですが、読者の対象としては「IT未経験の新人、セキュリティ入門者」としております。
脆弱性とは？
システム上のバグ、ソフトウェアの設計、実装不備などを用いて、攻撃者に攻撃の侵入経路を与えてしまうようなセキュリティ上の欠陥のことを言います。 攻撃者はこれらの脆弱性を用いて、システム内部への攻撃(エクスプロイト)を仕掛けてきます。
脆弱性は様々な層で紛れ込む可能性があります。
ソフトウェアがのるサーバーに脆弱性が紛れ込んでいる場合もあれば、 人員的な配置や組織的な人に対する脆弱性というものもあります。
そして、ソフトウェア開発者であれば、セキュアコーディングを意識しないと、今回学ぶWebの脆弱性が紛れ込む可能性は大いにあります。
XSS (クロスサイトスクリプティング)
概要
Google Chrome や FireFox などの Web ブラウザ側で実行されるプログラム言語である JavaScript を悪用し、開発者が意図しないシステム的な動作をWebブラウザ側で起こす脆弱性です。
例えば下記のようなスクリプトが Web ブラウザで JavaScript として読み込まれるとダイヤログで "XSS の脆弱性が存在します。" と表示されます。
<script>
alert("XSS の脆弱性が存在します。");
</script>
実行例
これは Web ブラウザが というタグを認識し、タグで囲まれた内部の文字列を JavaScript として処理してしまうことによって起きてしまいます。
ちなみに、本来のクロスの綴りは(Cross)でCが大文字なのですが、Webでは html, JavaScript と並んでデザインを行う CSS( Cascading Style Sheet )が存在し、それと区別するために X が用いられているようです。
XSSの具体例としては下記のようなものが挙げられます。
1. Cookieの中身が操作、覗き見られてしまう
クライアント、サーバー間で一意の存在として判断するために、よく Cookie というものが使われます。この Cookie の中にはサーバーから与えられた一意のIDなどの情報が含まれている場合があります。
例えば、下記のようなスクリプトを流し込まれてしまうと Cookie の中身が閲覧されてしまいます。
<script>
alert(document.cookie);
</script>
今回は例として Cookie の中身の閲覧を行いましたが、Cookieの閲覧ができるので Cookie の中身の書き換え(改ざん)なども行うことが可能であり、セッションIDなどが書き換えや奪取されてしまうとセッションハイジャックが行われる場合もあります。
2. 悪意のあるWebページへ強制的にリダイレクトされてしまう
JavaScript はブラウザ側で実行される言語なので、ブラウザ側の操作を行うことが可能です。 操作可能な挙動としては、画面の遷移を行うものも存在し、攻撃者が用意した悪意のあるWebページなどへ強制的に移動(リダイレクト)させられてしまう場合があります。
<script>
location.href=’http://example.com’;
</script>
3つの種類のXSS
1. 格納型 XSS
格納型のXSSとは、サーバー側に格納された悪意のある JavaScript をブラウザでアクセスするたびに読み込んでしまうパターンのXSSです。 Webアプリで扱うデータはサーバー側でDBなどに格納する場合がほとんでです。
例えばブログサイトを一つ取ったとしても、ブログのタイトルや内容、閲覧者からのコメントなどを記事のデータとしてサーバー側に格納する必要があります。
外部から訪れた人でも入力できる閲覧者からのコメント部分に、上記のような XSS を引き起こすスクリプトを入れ込まれてしまうと、サーバーからデータを取得するたびに、JavaScript が読み込まれて実行されてしまいます。
格納型の怖いところは、一度サーバー側に悪意のあるデータが格納できてしまえば脆弱性が存在している間サイトを訪れた人全員がXSSに引っかかってしまうことです。
2. 反射型 XSS
反射型XSSとは、利用者が入力した入力値をブラウザ側で読み込んでしまうパターンのXSSです。 検索画面などに多いのですが、前の画面で入力した値を表示する場合が多いです。 この前の画面で入力した値を表示する部分に脆弱性が存在すると反射型XSSが成功してしまいます。
赤枠で囲まれているところにXSSの脆弱性が存在すると、キーワードに入力した JavaScript が発火してしまう。
3. DOMベースXSS
DOMべースのXSSとは、XSSによりDOMを書き換えられてしまう攻撃です。 WebのHTMLはDOMという構造で管理されています。 そのDOMをXSSで書き換えて、Web利用者が意図しない動きを与えるのがDOMベースのXSSです。
対策
対策はいくつかあるのですが、基本的には入力された JavaScript をブラウザ側で JavaScript として認識させないことです。
1. 出力時の特殊文字のエスケープ
XSS 対策は基本的に出力時の特殊文字エスケープがされていれば防ぐことができます。
上記Mozillaのページより転載
| 文字 | エンティティ | 注記 |
|---|---|---|
| < | < |
タグの開始として解釈 |
| > | > |
タグの終了として解釈 |
XSS の原因とは、ブラウザ側で <script>という表記がHTMLのタグとして認識されていることが問題です。
ブラウザ側にサーバーで取得した値、または入力された値を表示する時に、これらのエスケープ処理をすることによってXSSは防ぐことができます。
システム的には<や>と解釈されていても、我々がブラウザで見るときは<や>としてブラウザは表示してくれます。
<script>
alert("エスケープ処理されているためXSSの脆弱性は存在しません。");
</script>
2. データ格納時の特殊文字のエスケープ
こちらは、格納型のXSSにのみの対策になりますが、サーバー側へのデータ格納時にエスケープする処理を入れ込む方式です。
また、システムの仕様によってはサーバー側の言語で<script>という単語を取り除く仕様もたまに見かけます。
WordPress なんかは <script>という文字列を取り除く処理が、いくつかのXSS対策の一つとして採用されていました。
<script>という単語を取り除いてしまっても良いシステム要件であれば一考しても良いかもしれません。
