セキュリティ攻撃について(JavaScript)
お疲れ様です！
IHです！
今日は、JavaScriptによるセキュリティ攻撃について学んだので、アウトプットを行いたいと思います！
ーーーーーーーーーーーーーーーー
Webアプリケーションに脆弱性があると、ユーザーと開発者の双方が被害を受けます。
脆弱性とは、ソフトウェアに欠陥や使用上の問題点のことをいいます。いわば、そのWebアプリケーションの抱える弱点です。
そして、悪意を持ったユーザー(攻撃者)が、この脆弱性につけ込んで、アプリケーション上で攻撃を仕掛けることがあります。
本日学んだ、その攻撃の種類は
順番に説明していきます。
クロスサイトスクリプティング(以下XSS)とは、攻撃者が脆弱性を持っているサイトを利用して、そのサイトの利用者を攻撃する手法のこと。
具体的な攻撃の流れは以下の通りです。
①XSSの脆弱性があるサイトに悪意のあるJavaScriptを埋め込む
②JavaScriptを埋め込んだサイトをリンクに指定する罠サイトを用意する
③罠サイトへ誘導するようなメールを送信する
④ユーザーは、メールに添付された罠サイトにアクセスし、JavaScriptを埋め込んだサイトにアクセスする
⑤ブラウザ上で埋め込まれたJavaScriptが実行される
⑥クッキーの盗聴やマルウェア感染が起きてしまう！
※罠サイトとは、JavaScriptを埋め込んだXSSの脆弱性のあるサイトへのリンクを含んでいるページのこと。
※スクリプトとは「ソースコードを書く→実行する」ということができる、簡易的なプログラムのこと。
TwitterやYoutubeも、過去にXSSによる被害を被ったそうです。
Twitterでは
「特定のツイートをマウスオーバー(マウスカーソルを対象に重ねること)するだけで、埋め込まれたJavaScriptが実行され、勝手にリツイートされる」
という被害が出て、
YouTubeではコメント欄に存在した脆弱性を狙って、コメント欄にJavaScriptが仕掛けられ、
「コメントが表示されなくなる」
「偽のニュースが表示される」
「不適切なウェブサイトへリダイレクトされる」
といった被害が出たそうです。
XSSが発生する主な原因として、フォームから入力されたHTMLタグがそのままページに反映されてしまっていることがあげられます。
したがって、HTMLを生成する際に意味を持つ「"」や「<」、「>」といった表記を違う文字列に変換することで、XSSを防ぐことができます。このように、HTML上で直接記述できない特殊文字を表記する際に用いられる記法を「文字参照」といいます。
文字参照を利用することで、たとえば
「<」は「& It;」
「>」は「& gt;」
「"」は「& quot;」
「'」は「& #39;」
「&」は「& amp;」
に変換することができます。(上記は、XSSの対策をする際に変換すべき特殊文字の一覧です)
以上のような特殊文字を文字列参照に変換して保存すれば、外部から埋め込まれたスクリプトが実行されることはなくなります。
「Webページのテキスト入力欄」
「URL」
などにSQL分の断片を埋め込むことで、データベースの改竄や、情報の不正入手を行う攻撃方法がSQLインジェクションです。
つまり、入力フォームから送信した値によりアプリケーションが想定しないSQL文を実行させることで、
「認証を突破する」
「情報を盗む」
といったことを可能にします。
SQLインジェクションの脆弱性を解消するには、SQL文の変更を防ぐ必要があります。
対策方法としては、以下があるそうです。
・事前にSQL文の構造を確定する
このSQLインジェクションについては理解が浅く、データベース言語の一つであるSQLも学習していないので、今後学習をしていきたいと考えています。
まず、セッションとは、Webサービスにおいて情報を一時的に記憶しておく仕組みのことです。
ショッピングサイトにも利用されています。
(たとえば、Amazonで買い物カゴに商品を入れた時、「買い物カゴには○○という商品が入っている」という状態が維持されているのは、このセッションのおかげです)
セッションハイジャックとは、何らかの方法を用いて、正規利用者ではない者が他人のセッションIDを乗っ取る攻撃方法です。
このセッションハイジャック、非常に恐ろしいです。
これが成功してしまうと、正規利用者ができることがほとんど実行できてしまいます。
具体的には、以下の通りです。
・正規利用者の個人情報閲覧
・送金
・物品購入
・なりすましメール etc……
とにかく、正規利用者はとんでもない被害を被る可能性があります。ヒエーッ！
そして、セッションハイジャックの具体的な攻撃方法としては、以下の3つがあります。
・セッションIDの推測
・セッションIDの盗み出し
・セッションIDの強制
セッションIDは、利用者の状態を保持するために使われます。
順番に説明します。
☑️セッションIDの推測
Webアプリケーションに用いられるセッションの生成規則に問題があると、第三者に用意にセッションIDを予測され、悪用されてします恐れがあります。
たとえば、
・ユーザーIDやメールアドレス
・リモートIPアドレス
・日時
・乱数
などを生成規則の元にしてセッションIDを生成すると、第三者に予測されてしまいます。
対策としては、Webアプリケーション開発ツールが持つセッション管理機構を利用することが安全とされています。主要なアプリケーション開発ツールのセッション管理機構に脆弱性が発見された場合、セキュリティ研究者によって指摘されすぐに改善されることが見込まれます。
そのため、セッションIDの生成は開発ツールに夜ものにすると、セッションIDを予測されることはほとんどなくなるそうです(反対に、独自の機構で生成したセッションIDは、予測されやすいのでやめておくこと)。
☑️セッションIDの盗み出し
セキュリティ対策が不十分なインターネット上の通信では、Webアプリケーションとサーバー間でのデータ通信の際に、値(ここではセッションID)を用意に取得できます(例：暗号化されていない無線LAN)。
この攻撃方法に対しては、SSL(Secure Socket Layer)という
「インターネット上の通信を暗号化する技術」
を利用することが対策となります。
☑️セッションIDの強制
セッションIDを悪意ある第三者が、外部から強制させる方法です。「セッションの固定化」とも呼ぶそうです。
セッションの固定化の手順は、以下の通りです。
①悪意のある第三者(以下攻撃者と呼ぶ)は、まず普通の利用者としてセッションID(例：id1)を取得する。
②攻撃者は、被害者に対して①で取得したセッションIDを強制する。たとえば、"http://example.jp?PHPSESSID=id1"のリンクを含んだメールを被害者へ送信する。
③被害者は届いたメールから"http://example.jp?PHPSESSID=id1"へアクセスし、標的となるアプリケーションにログインをする。
④攻撃者は、被害者に強制したセッションID(id1)を使って標的アプリケーションにアクセスする。
セッションIDの固定化への対策として、認証が完了した時点でセッションIDを変更するという方法があります。
具体的には、③で被害者が
"http://example.jp?PHPSESSID=id1"へアクセスし、標的となるアプリケーションにログインをして認証が終わった後、新たに別のセッションID(例：id1 → id2)を再発行します。
こうすることで、攻撃者は、
「"http://example.jp?PHPSESSID=id1"にアクセスしても、セッションIDが変更されているのでアクセスできない」
という状況になります。
ーーーーーーーーーーーーーーーー
いかがでしたか？
正直申し上げますと、僕自身
「難しい！ わからん！」
と思った内容がたくさんありました😅
でも、Webアプリケーションとは切っても切り離せない分野ですから、今後少しずつ理解を深めていきたいと思います！
データベース言語のSQLも勉強した方が良さそうですね。
プログラミングはやはり奥が深いですね😌
それでは、ここまで読んでくださってありがとうございました！
