Webのフロントエンドでよくある攻撃とその防止方法

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

フロントエンド技術の発展により、セキュリティ問題はサーバーから各ユーザーの前に静かに現れ、ユーザーデータを盗み、悪意のある自己複製ワームコードを作り、ウイルスをユーザーの間で蔓延させ、サーバーを手先にするようになりました。しかも、ユーザーが気づかないうちに、ユーザーが攻撃者になることもあり、絶対に呆れることはない。リッチクライアントの普及に伴い、フロントエンドのセキュリティ問題も増えてきていますので、今日はよくある攻撃とその対策について簡単に紹介します。

<フォント 一般的な攻撃

XSS（Cross Site Script）、クロスサイトスクリプティング攻撃。 XSSは受動的な攻撃であり、簡単に使えるものではないので、多くの人がその弊害を訴えることが多い。しかし、フロントエンド技術リッチクライアントアプリケーションの継続的な進展に伴い、この問題の側面はますます懸念されている。簡単な例です。あなたは今、snsのサイト上のユーザーである場合は、脆弱性がある情報を投稿する機能は、jsを実行することができますあなたはこの時点で悪意のあるスクリプトを入力し、あなたの新しいメッセージを見るすべての人の現在のブラウザは、このスクリプトのポップアップ警告ボックス（非常にクールそれはポップアップ広告：）、あなたがいくつかのより積極的な行動をすればそれを実行します結果は想像を絶するものである。

CSRF（Cross Site Request Forgery）、クロスサイトフォージェリーの略。 その名称は、ユーザーが知らないうちに接続要求を偽造することで、ユーザーが自分自身になりすまし、攻撃者が達成したいことを達成することを意味しています。csrf攻撃は、攻撃者の積極的な行動によって引き起こされる必要があるxss csrfとは異なるものです。これはまるでフィッシングのようですね。
マルチウィンドウブラウザのこの側面は、新しく開いたウィンドウが現在のセッションをすべて持っているため、実現されているようです。一方、ie6のような単一のブラウザウィンドウであれば、各ウィンドウが個別の処理であるため、このような問題は発生しません。単純な例ですが、ホワイトソサエティで遊んでいて、誰かがリンクを貼っているのを見て、それをクリックすると、そのリンクがギフトフォームを偽造してしまうのです。

ページへのアクセス権を取得し、クッキーをハイジャックする。 ユーザーのクッキーがあるページに、悪意のあるサイトへの簡単なリクエストを書けば、クッキーを取得し、それを使って盗んだユーザーとしてサイトにログインすることができます。これがクッキーのハイジャックです。例えば、ある人がとても面白いログを書いてみんなと共有し、多くの人がそれをクリックして共有し、すべてが正常に見えるが、ログを書いた人は別の意図を持って、こっそりログにオフサイトへのリクエストを隠し、そうするとこのログを読んだ人全員が自分のクッキーを知らないうちに誰かに送り、その人は誰のクッキーでも使ってその人のアカウントにログインできるのだ。

私たちは何をするのか？

大きく分けて、1一般ユーザー 2Web開発者の2つに分かれます。

まず、一般的なWeb製品のユーザーとして、受動的になってしまい、知らず知らずのうちに搾取されているケースが多いとします。すると、こうなります。
1 セキュリティレベルの高いWebアプリケーションにアクセスする場合 ブラウザーを別ウィンドウで開く必要があります。
2 知らない人が貼ったリンクは、コピーしてから新しい開いたウィンドウで開くのも良いですが、もちろん無視するのが一番です - - 。

開発者向けには、もう少し詳しく見ていく必要があります。

xssの攻撃は、攻撃者のコードがユーザーのブラウザの実行権限を取得することができなければならないことを特徴とし、それがどこから来るのコードは、実際にはこのような攻撃を排除したい入り口と出口厳格なフィルタリングにすることができます、このような二重保険は、同様の問題の99％が私たちによって解決されると言うべきである、他の1％がそれらのくずブラウザの余波ですが、私は将来的にはこの問題は少なくなると考えています。将来的には、このような問題は少なくなっていくと思います。

xssの脆弱性の形式を簡単に説明すると、以下のようになります。

悪意のあるコードの値がタグの内容として表示される（htmlを入力すると、htmlが解析される） 例：ユーザー名を入力すると、更新後のページでユーザー名がタグの1つに表示される 例：ユーザー名を入力すると、更新後のページでユーザー名がタグの1つに表示される

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

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

戦略 htmlタグやhtml入力が不要な特殊文字（" < > &など）をフィルタリングし、ブラウザで解釈・実行されない文字に変換する。

悪意のあるコードがタグの属性として表示される（属性を " で切り捨てて新しい属性や悪意のあるメソッドを開く） これは、開発者が機能を実現するために、ある dom タグにユーザーの入力を記録する場合がよくあります。 が慎重に設計されているなら、これを見ましょう。

<a title="popper.w" onclick="alert(1)">popper.w" onclick="alert(1)</a>。

ここで実際に入力したのは "popper.w" onclick="alert(1)" ですが、もちろんその上にさらに書き込むこともできます。

ポリシー 属性内で切り捨てられる可能性のある一部の文字に対するフィルタリング 属性自体のシングルクォートとダブルクォートの両方をトランスコードする必要があります。

悪意のあるコードがhtmlコードそのものとして表示されている（一般的なhtmlエディター） これは最も問題のあるケースなので、ここでは例をあげない。

戦略 ユーザが入力したhtmlタグやタグの属性に対してホワイトリストフィルタリングを行い、さらに脆弱性のある一部のタグや属性に対して特別なフィルタリングを行うことがベストです。

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

攻略法 属性内で切り捨てられる可能性のある一部の文字にフィルターをかける 属性自体に存在するシングルクォートとダブルクォートの両方をトランスコードする必要がある。

<フォント crsfとCookieのハイジャックについて

特徴 よりステルス性が高い xssの脆弱性を先に突いてからスプーフィングを行うこともある。

戦術
referer、token、captchaによってユーザー投稿を検出する。
ページ内のリンクに、ユーザー固有の番号（ユーザーID）に関連する情報を露出させないようにする。
ユーザーの変更、削除、コミットには、post操作を使用するのが最善です。
サイトワイドなクッキーを避ける クッキーのドメインを厳密に設定する。

とりあえず、これで終了〜。

以上、主にjsハック側のセキュリティ問題を紹介しましたが、フロントエンド技術が発展・進歩すれば、もっと多くのセキュリティ問題が目の前に現れるかもしれません、開発者側の問題のほとんどは開発段階で回避できるので、怖いのはハックではなく、自社製品のセキュリティの甘さです〜。