XSSとCSRFの浅い分析

XSSとCSRFの浅い分析

Webセキュリティの面では、XSSとCSRFは昔話といえるでしょう.

XSS

XSS、すなわちcross site script、クロススタンドスクリプト攻撃、略称はもともとCSSであったが、カスケードスタイルシート(Cascading Style Sheet)と区別するためにXSSに変更された.
XSS攻撃とは、攻撃者がウェブサイトに悪意のあるスクリプトを注入し、ユーザーがウェブページを閲覧して使用する際に悪意のある操作を行うことであり、注入スクリプトにはJavaScriptのほかにCSS、HTMLなどがある.
XSS攻撃は,反射型(非持続型),記憶型(持続型),DOM型の3種類に分けられる.

はんしゃがた

反射型のXSS攻撃方式は,攻撃者が悪意のあるリンクをクリックしたりフォームを提出したりする操作をユーザに誘導し,スクリプト注入の目的を達成するのが一般的である.
例えば、あるページが検索キーワードをHTMLページに直接接続して表示するとします.

        ：

ユーザが検索をクリックすると、このような要求http://example/search?keyword=xxxがサービス側に送信され、サービス側はkeywordの後ろの文字をHTML接合して戻る.
このとき、ユーザが悪意のあるリンクhttp://example/search?keyword=xss をクリックすると、返されるHTMLは次のようになります.

        ：xss    

ブラウザはscript内のxss攻撃スクリプトを実行し、攻撃者の攻撃目的を達成します.

きおくがた

ストレージ型のXSS攻撃は、攻撃者が悪意のあるコードを入力したデータとしてサービス側に提出し、サービス側がデータベース内に格納するのが一般的であり、ユーザーがこのデータを要求した後、サービス側が返したデータは悪意のあるコードであり、XSS攻撃が発生する.
よくあるのは、フォーラムに投稿したり、コメントしたりして、悪意のあるコードを注入したりして、ユーザーが投稿をクリックすると、攻撃を受けます.

DOMタイプ

DOM型のXSS攻撃は、攻撃者が悪意のあるスクリプトを注入した後、ページ要素を修正し、DOMのデータを取得して攻撃操作を実行するのが一般的です.例えば,ユーザのログインフォームの抽出を攻撃者のサービス側に交換し,ユーザのログイン情報を取得する.

防犯XSS

CSPコンテンツセキュリティポリシーは、主流ブラウザがCSPを実現しています.
コンテンツセキュリティポリシーの構成は、Content-security-Policy HTTPヘッダをページに追加し、ユーザーエージェント(ブラウザなど)がページに対してどのリソースを取得できるかを制御するために、適切な値を構成することに関連します.たとえば、ファイルをアップロードしたり、ピクチャページを表示したりすることができます.ピクチャはどこからでも許可されますが、フォームのactionプロパティを制限するには、指定したエンドポイントにのみ値を割り当てることができます.適切に設計されたコンテンツセキュリティポリシーは、クロスステーションスクリプトからページを効果的に保護することができるはずです.(MDN)

HttpOnlyを設定することによりCookieの読み取りが防止される.

フロントエンドはユーザーの入力をチェックしてエスケープし、ホワイトリストを確立し、安全な文字とHTMLラベルのみが存在することを許可する:

const HTML_DECODE = {
 '
': '
',
  '<'  : '', 
 '&' : '&',
  '"': '"',
 ' ': ' ', 
 '"': '\'
 // more code
};

フロントエンドロジックは比較的迂回されやすいので、バックエンドも受信したデータをチェックフィルタリングし、HTMLを出力またはパッチする際に符号化、エスケープを行う.

CSRF

CSRF、すなわちcross site request forgeryは、クロスステーション要求偽造であり、再生攻撃と理解できる.よくあるのは、攻撃者がユーザーに釣りサイトを開いて操作するように誘導することです.
一例を挙げて説明すると、あるユーザがwww.a.comサイトにログインし、ログインしていない場合に釣りサイトwww.b.comを開き、釣りサイトに悪意のあるスクリプトがあり、開かれたときにCookie情報を持ってwww.a.comにドメイン間リクエストを送信したとする.

CSRFの特徴

CSRF発起要求方式は、ピクチャURL、ハイパーリンク、フォーム提出などが多い.

はXSS攻撃とは異なり、CSRFは一般的にサードパーティのウェブサイトで攻撃を開始する.

CSRFはhttp要求を利用してユーザのCookie情報を自動的に携帯するだけで検証に合格し、Cookie情報を取得することはできない.

CSRF防犯

再生攻撃については,実はフロントエンドでは処理できないが,主にバックエンドに頼っている.

Referフィールドhttpのリクエストヘッダには、httpリクエストのソースアドレスが記録されたReferフィールドがあり、サービス側はこのフィールドをチェックすることで、リクエストが合法的なアドレスから来たかどうかを判断します.ただし、Referフィールドはブラウザによって追加されるため、改ざんされる可能性があることに注意してください.

認証メカニズムCSRFは、通常、ユーザが知らないうちに要求を送信して攻撃するので、認証メカニズムを利用してユーザにウェブサイトとのインタラクションを強制することができ、例えば、認証コードをユーザの携帯電話、メールボックスに送信したり、ユーザのパズルを必要としたり、認証コードを記入したりすることができる.しかし、検証メカニズムはユーザー体験にあまりよくなく、すべての操作に検証を加えることができるわけではありません.

tokenサービス側は、ユーザーがログインした後、ランダムなtokenを発行し、ページに埋め込むことも、sessionStorageに格納することもできます.その後、クライアントにブロッカーを設定し、すべてのリクエストにtokenを追加し、サービス側はブロッカーを設定し、リクエストがtokenを持っているかどうかを確認します.同源ポリシー(プロトコル、ドメイン名、ポートが同源)のため、CSRFはtokenを取得できません.

let xhr = new XMLHttpRequest();
let token = sessionStorage.getItem('csrfToken');
xhr.setRequestHeader('CSRF-Token', token);

ただし、tokenはサービス側に格納され、tokenの読み取り、検証が必要であることに注意してください.