ウェブフロントエンドに対する一般的な攻撃とその防止方法

ウェブサイトのフロントエンド開発で発生するセキュリティ問題は、クライアントブラウザで実行されるコードがサーバー側でセキュリティリスクを引き起こすことはないと多くの人が信じているため、簡単に見過ごされてしまいます。この記事では、ウェブサイトのフロントエンドでよく発生するセキュリティ問題と、その対処方法について簡単に説明します。

フロントエンド技術の発展に伴い、セキュリティの問題はサーバーから各ユーザーへと静かに移行し、ユーザーデータを盗んだり、悪意のある自己複製ワームコードを作成したり、ユーザー間でウイルスを拡散させたり、サーバーをクラッシュさせたりしています。さらに、ユーザーが知らないうちに攻撃者になる可能性もありますが、これは決して驚くべきことではありません。リッチクライアントの利用が増えるにつれて、フロントエンドのセキュリティ問題も増加しています。今日は、一般的な攻撃方法とその防止方法を簡単に紹介します。

一般的な攻撃

XSS (クロスサイトスクリプト)、クロスサイトスクリプティング攻撃。これは、悪意のある攻撃者が Web ページに悪意のある HTML コードを挿入することを指します。ユーザーがページを閲覧すると、埋め込まれた悪意のある HTML コードが実行され、悪意のあるユーザーの特別な目的が達成されます。 XSS は受動的な攻撃です。受動的で使いにくいため、その有害性を無視する人が多くいます。しかし、フロントエンド技術の継続的な進歩とリッチクライアントアプリケーションの数の増加に伴い、この分野の問題はますます注目を集めています。簡単な例を挙げてみましょう。あなたがSNSサイトのユーザーで、情報公開機能にJS実行を許す脆弱性があったとします。この瞬間に悪意のあるスクリプトを入力すると、現在あなたの新しい情報を見ているすべての人のブラウザでこのスクリプトが実行され、プロンプトボックスがポップアップします（ポップアップ広告はクールですよね？ :)）。さらに過激なことをすると、結果は想像を絶するでしょう。

CSRF (クロスサイトリクエストフォージェリ)、クロスサイト偽造リクエスト。名前が示すように、これはユーザーに知られることなく接続リクエストを偽造し、ユーザーが自分の ID を使用して、攻撃者が達成する必要のある目的の一部を達成できるようにすることです。 CSRF 攻撃は、攻撃者のアクティブな動作によってトリガーされる必要があるという点で、XSS 攻撃とは異なります。これはフィッシング詐欺のようですね、ハハ。
マルチウィンドウ ブラウザは、新しいウィンドウが開かれると現在のセッションがすべて含まれるため、この点で助長しているように思われます。IE6 のような単一のブラウザ ウィンドウの場合は、各ウィンドウが独立したプロセスであるため、このような問題は発生しません。簡単な例を挙げてみましょう。Baishehui をプレイしていて、誰かがリンクを送信したのに気づきました。それをクリックすると、リンクに偽のギフト送信フォームが表示されます。これは単なる簡単な例であり、問​​題は明らかです。

Cookie ハイジャックは、ページの権限を取得して、ページ内に悪意のあるサイトへの簡単なリクエストを書き込み、ユーザーの Cookie を運びます。Cookie を取得した後、Cookie を通じて盗まれたユーザーとしてサイトに直接ログインできます。これはクッキーハイジャックです。簡単な例を挙げてみましょう。誰かが興味深いブログ記事を書いて、みんなにシェアしました。多くの人がクリックして閲覧し、シェアしました。すべて正常に見えました。しかし、ブログ記事を書いた人は別の意図を持っていて、ブログ記事に外部サイトへのリクエストを密かに隠していました。すると、ブログ記事を読んだ人は全員、知らないうちに自分の Cookie を他の人に送信し、その人の Cookie を通じて誰かのアカウントにログインできるようになります。

私たちは何をすべきでしょうか?

大まかに分けると、1. 一般ユーザー 2. ウェブサイト開発者の 2 つのカテゴリに分けられます。

まず最初に、Web 製品の一般ユーザーとして、私たちはしばしば受動的になり、知らないうちに搾取されているという点についてお話ししましょう。そうすると次のことが可能になります。
1 セキュリティ レベルの高い Web アプリケーションにアクセスするには、別のブラウザ ウィンドウを開く必要があります。
2 見知らぬ人が投稿したリンクについては、コピーして新しいウィンドウで開くのが最善です。もちろん、無視するのが最善の方法です。

開発者の場合は、比較的詳細な観点から分析する必要があります。
XSS 攻撃の特徴は、攻撃者のコードがユーザーのブラウザで実行権限を取得できることです。では、コードはどこから来るのでしょうか。このような攻撃を防ぐために、実際には入口と出口で厳格なフィルタリングを行うことができます。この二重の保険により、同様の問題の 99% は解決されているはずです。残りの 1% は、それらのひどいブラウザによってもたらされた後遺症です。今後、このような問題はますます少なくなると信じています。

ここでは、XSS脆弱性の形式を整理しました。

悪意のあるコードの値は、特定のタグの内容として表示されます（入力がHTMLの場合は、HTMLが解析されます）。たとえば、ユーザー名を入力すると、更新後のページの特定のタグにユーザー名が表示されます。

popper.w<script src="hack.js" type="text/javajscript"></script>

フィルタリングせずにページに直接表示すると、サードパーティの js コードが導入され、実行されます。

戦略: HTML 入力が不要な HTML タグと一部の特殊文字 (" < > & など) をフィルターし、ブラウザーによって解釈および実行されない文字に変換します。

悪意のあるコードは、タグの属性として表示されます（「」を使用して属性を切り捨てて新しい属性または悪意のあるメソッドを作成します）。開発者が機能を実装するために、特定のDOMタグにユーザー入力情報を記録する可能性があるため、このような状況になることがよくあります。たとえば、入力したユーザー名は、ページ上のタグのタイトルとして表示されます。このとき、慎重に設計されたコンテンツを入力すると、

<a title="popper.w" onclick="アラート(1)">popper.w" onclick="アラート(1)</a>

実際にここで入力したのは「popper.w」onclick="alert(1)ですが、もちろん上にさらに内容を記述することもできます。

戦略: 属性内で切り捨てられる可能性のある一部の文字を除外します。属性自体内の一重引用符と二重引用符の両方をトランスコードする必要があります。

悪意のあるコードが HTML コードそのものとして表示されます (一般的な HTML エディタ)。この状況は最も問題が多いため、ここでは例を挙げません。

戦略: ユーザーが入力した HTML タグとタグ属性をホワイトリストに登録するか、脆弱性のある一部のタグと属性を具体的にフィルタリングするのが最適です。

悪意のあるコードは、JSON 文字列として表示されます (変数の切り捨てによって、新しい悪意のある js 変数や実行可能コードが作成されます)。この問題の鍵となるのは、ユーザーが入力した情報がページ内の js コードの一部になる可能性があることです。

戦略: 属性内で切り捨てられる可能性のある一部の文字を除外します。属性自体内の一重引用符と二重引用符の両方をトランスコードする必要があります。

crsfとcookieハイジャックについて

特徴: 高度に隠蔽されています。場合によっては、最初に XSS 脆弱性が悪用され、その後に欺瞞が行われます。

この戦略では、リファラー、トークン、または検証コードを介してユーザーの送信をチェックします。
ページ上のリンクに、ユーザーの固有番号 (ユーザー ID) に関連する情報を公開しないようにしてください。
ユーザーの変更、削除、送信操作には、投稿操作を使用するのが最適です。
サイト全体の Cookie は避けてください。Cookie を設定するドメインについては厳密にしてください。

はい、ここまでにします〜

上記は、主に js ハッキングの観点から見た一般的なセキュリティ問題です。フロントエンド技術の継続的な開発と進歩に伴い、より多くのセキュリティ問題が私たちの前に現れる可能性があります。開発者にとって、ほとんどの問題は開発段階で回避できるため、恐ろしいのはハッキングではなく、自社製品のセキュリティに対する私たちの怠慢です。