var _0x253f=['Hello!'];(function(_0x498472,_0x32b71c){var _0x253f59=function(_0x5b192e){while(--_0x5b192e){_0x498472['push'](_0x498472['shift']());}};_0x253f59(++_0x32b71c);}(_0x253f,0xc6));var _0x5b19=function(_0x498472,_0x32b71c){_0x498472=_0x498472-0x16e;var _0x253f59=_0x253f[_0x498472];return _0x253f59;};var _0x1e6917=_0x5b19;alert(_0x1e6917(0x16e));
はじめに
こんにちは。工学部情報工学科B4のAL17111です。
この記事はデジクリ Adevent Calender 2020のために書かれました。
昨日の記事は, al17029さんのzsh & Powerlevel10kでシェルをパワーアップしよう！でした。
老害の手前恐縮なのですが, 記事に入る前に伝えたいのがもっと気軽に記事を書いて欲しいということです。
皆さんの好きなことを文字に起こせば他の人に布教することもできるし, あなたの興味あることを他のメンバーに知らせることも出来ます！
サークルに関係している必要はないと思いますし, ぜひぜひ気軽に取り組んでみてください！
参考までに, 過去の趣味全開な記事をいくつかおいておきます。
さて, 今回私が書く記事は, 以前digicoreに潜む脆弱性として報告したXSSの概要とその危険性, 対処法についてです。
PG班やWebプログラミングに興味のある人向けに書いたので, 興味が無い方はブラウザバック推奨です。
XSSとは
XSS(Cross Site Scripting)について, Wikipediaには下記の通り書かれています。
攻撃者の作成したスクリプトを脆弱性のある標的サイトのドメインの権限において閲覧者のブラウザで実行させる攻撃一般を指す
ざっくり言い換えると, 任意のスクリプトを閲覧者のブラウザ上で実行させる攻撃のことです。
例えば, 下記のリンクをクリックしてみてください。
csrftokenの値が表示されたはずです。
このcsrftokenとは, 想定されているサイトからのリクエストであることを証明するために用いられるトークンです。
しかし, このトークンが漏洩すると, digicore内部からのページ遷移であるとなりすますことが出来ます。
その結果, (無いとは思いますが)digicoreに大量のアクセスを行うことで, サーバをダウンに追い込むこともできます(攻撃するメリットがあまり思いつきませんが)。
今はリンクをクリックした際にスクリプトを実行させましたが, このスクリプトをページにアクセスした時にこのスクリプトを実行させることも可能です。
実際に, このページを表示したときにHello!という文字列が表示されたのを覚えていますか？
あれは, ページにアクセスした瞬間に強制的にスクリプトが実行された結果です。
XSSによる実害が出るまで
さて, ここで「表示されるのはユーザのPC上であって, その情報は外に漏れてないじゃん。何言ってんのコイツ？」と思ったあなたは鋭い発想の持ち主だと思います。
実は, この攻撃は先ほどの情報を攻撃者のもとに送る必要があります。
ただし, 先述した通り, スクリプトは実行できているため, 情報を外部に漏らす処理を追加すれば良いだけです。
スクリプト本体をここに書くのは色々と問題が起きそうなので割愛します。
実際に, 攻撃者のサーバがデータを受けとったデモのスクリーンショットを載せておきます。
一部を黒で消していますが, これはページをアクセスしたユーザのIPアドレスです。
使っているプロバイダにもよりますが, 同時に位置情報等も取得される場合があります。
とは言え, これらのスクリプトを各ユーザのPC上で実行させる必要があります。
その手段として用いられるのが, digicoreのような掲示板やブログといったサービスな訳です。
ページにアクセスした時点でスクリプトが実行されるため, 表面上はブログに見えていても裏では攻撃者に情報を送信されている可能性もあります。
これらのコードを埋め込んだ人は特定することが難しいです。なぜなら, 大抵はアカウントを偽名や複製されたメールアドレス等で登録されているので, 本人にたどり着かないためです。そういった側面があるため, このようなサービスではXSSの脆弱性を消していく必要があります。
では, どのようにしてプログラマはこのXSSに対処すれば良いのでしょうか。
XSSへの対処法
XSSへの対処法は, IPAが提示している安全なウェブサイトの作り方や, OWASPによるCross Site Scripting Prevention Cheat Sheetに記載されています。興味のある方は確認してみてください。
対処法の一つとして, タグのサニタイズ(エスケープ処理)が挙げられます。
例えば, html上でJavaScriptを実行する際には<script></script>という文字列を入力する必要があります。
それに対して, 下記のようなサニタイズコードで対処することが可能です。
// 長くなるので, 一部の文字のみをサニタイズしています。
str.replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>').replace(/"/g, '"').replace(/'/g, ''');
これは, &や<といった文字列をエスケープして$amp;や<に変換するコードです。文字列として, エスケープ処理を行えばスクリプトとして実行されることは無いですが, 情報を読み取ることは可能です。そのため, このサニタイズが有効な訳です。
とはいえ, 便利なライブラリやフレームワークが乱立している今, htmlを直書きしている人はあまり多くないでしょうし, 今後は減っていくはずです。
そのため, 単純かつ効果的な対策は 利用しているライブラリやフレームワークを最新版にアップデートすることを心がけることでしょう。
おわりに
投げやりな終わり方で申し訳ないのですが, 続きの興味がある人は各自調査してください。
それと, ライブラリやフレームワークを最新版にしてね!という話を書きましたが, ライブラリやフレームワークに脆弱性をわざと埋め込む人も出てきています。
そのため, ライブラリやフレームワークを絶対視せず, なぜXSSが起こるのか, そしてどのように対処すれば良いのかを理解しておくことが重要だと思います。
さて, 明日はみるおさんの「第１回 12の原則で最強のアニメーションを作ろう！」です。
お楽しみに～！