フロントエンドセキュリティ - XSS攻撃、CSRF攻撃

まずは小さなゲームをプレイして、特定の値を入力してXSS攻撃を成功させ、alert(1)のコードを実行してみましょう。

https://alf.nu/alert1

1. ウォームアップ、最初の質問は非常に簡単なので、直接");alert(1);("渡すことができます
2. Adobe、2 番目の質問は「エスケープ」ですが、\コマンドを使用して\エスケープ文字を無効にし、alert(1) を追加して渡すことができます。参考回答\");alert(1);//
3. <json、3 番目の質問は入力データを JSON に変換しようとしますが、特別な処理は行いません。alert </script><script>alert(1)//(1) を入力して実行します。
4. markdown では、4 番目の質問の後、答えを考えずに各質問について長い時間考えました。ここではと の両方がエスケープされて<おり"、URL の href も http の先頭を制限しているため、javascript:コード インジェクションは使用できません。次の画像リンクも\w修飾文字を使用しているため、使用できませjavascript:ん。"他のブログを読んでいると、 img クラック用の文字を与えるために href エスケープを使用できることがわかり[[a|http://onload='alert(1);']]、これを使うと文字http://が与えられ"、後続の記号が混同されてスクリプト実行エラーが発生するため、onerror関数が実行されて実行されますalert(1)それが欠落しているので"、それを見つける必要があります。それを見つける方法を見つけたい場合は、前のコードでそれが提供されるかどうかを確認できます。たとえば、この質問では、http://キーワードが提供されています。"
5. dom、
   createElement と createTextNode を試してみましたが、可能性がないことがわかりました。そこでもう一度答えを確認したところ、createComment API もあることを知り、コメントはエスケープされないので非常に簡単です。Comment#><script>alert(1)</script>
6. コールバック、続きます

---

XSS クロスサイト スクリプト 悪意のあるユーザーが Web ページにコードを挿入し、他のユーザーが Web ページを表示しているときにクロスサイト リクエストを開始させます。

CSRF クロスサイト リクエスト フォージェリ ユーザーになりすましてリクエストを開始する
リファレンス

https://tech.meituan.com/2018/10/11/fe-security-csrf.html
https://tech.meituan.com/2018/09/27/fe-security.html

---

XSS

3つのカテゴリーに分けられる

1. 反射型。URL パラメーターまたは投稿フォームに悪意のあるコードがあり、サーバーはそれを処理せず、フロントエンドの実行スクリプトに返します。
2. フォーラムへの投稿などのストレージ タイプ。悪意のあるコードは処理されず、データベースに保存され、スクリプトを実行するために他のユーザーに表示されます。
3. DOM タイプ、これはバックエンドとは関係ありません。たとえば、フロントエンド DOM は url パラメーターからデータを取得する必要がありますが、データは適切に処理されず、スクリプトが実行されます。

CSRF

クロスサイト リクエスト フォージェリは、被害者がサードパーティの Web サイトにアクセスし、攻撃対象の Web サイトにクロスサイト リクエストを送信するように誘導します。被害者は攻撃対象の Web サイトで登録資格情報を取得しているため、ユーザーになりすまして操作を実行できます。攻撃された Web サイトの目的。

1. GET タイプ、取得リクエストを自動的に発行します
2. POST タイプ、非表示の自動送信フォーム
3. ユーザーがクリックした場合にのみトリガーされるリンク タイプ。たとえば、フォーラムに投稿された画像に悪意のあるリンクが埋め込まれています。これは
   サードパーティの Web サイトから開始されるため、攻撃された Web サイトはそれを防ぐことができません。

次のように保護できます。

1. 外部ドメインへのアクセスを禁止する
   サーバーは、リクエストヘッダーの Origin Header と Referer Header からソースドメイン名を取得できます。これら 2 つの値が取得できない場合があります。
2. 送信時にこのドメインでのみ取得できる情報を添付してください
   1. ユーザーがページを開くと、サーバーが生成したトークンが (Cookie の代わりに) ページに生成され、非表示になります。リクエストを送信するときにこのトークンを持参すると、サーバーはトークンが有効かどうかを検証します。大規模な Web サイトでは、複数のサーバーが存在し、異なるリクエストが異なるサーバーに送信される可能性があるため、サーバーがトークンを保存することが複雑になる場合があります。このとき、トークンはUserIDやタイムスタンプなどの計算に基づいて生成され、暗号化されたものとすることができるため、トークンを保存する必要はなく、毎回計算するだけでよい。
   2. 認証コードやパスワードも使用可能
3. 二重 Cookie 検証
   2 番目の方法はより面倒であり、すべてのリクエストでトークンを取得する必要があるため、非常に面倒です。
   CSRF が Cookie を取得できない場合、Cookie を 2 番目のメソッドのトークンとして使用し、リクエスト パラメーターに含めることができます。サーバーは、Cookie がリクエスト内のパラメータと一致しているかどうかを検証します。
   ただし、リスクもあります:
   1. ユーザーがa.comバックエンド API ドメイン名にアクセスすると、api.a.com Cookie を取得できません 2. あらゆる自己娯楽によってCookie を読み取ったり、変更したりすることができます サブドメイン名に脆弱性があり、XSS によって攻撃された場合、Cookie は変更する必要がある場合、攻撃者はリクエスト パラメータに独自の Cookie を追加する可能性があります。a.comapi.a.com
a.com
4. Samesite Cookie は、
   Cookie がサードパーティ Cookie として使用できないことをブラウザ レベルで保証します。たとえば、Baidu から Taobao にアクセスする場合、Taobao は Cookie を受け取りません。