サイバー攻撃 - Shinichi0713/security_specialist GitHub Wiki

目的

サイバー攻撃についてまとめる。

OWASP TOP10 →webアプリケーションのセキュリティリスクのリストが存在。 メジャーどころがまとめられている。

https://owasp.org/Top10/

CSRF

概要

クロスサイトリクエストフォージェリ（以下、CSRF（シーサーフ）と呼称します）は、Webサイトの利用者が意図せずWebサイト上の処理を実行させられてしまう脆弱性です。
攻撃者は、攻撃者が用意したWebサイトに何らかの方法（メール、SNSでURLを送信するなど）で利用者を誘導します。

攻撃イメージ：
a. CSRFの脆弱性があるWebサイトの利用者が、攻撃者によって用意されたサイトを訪れる
b. 攻撃者が指定した処理を実行するリクエストが、利用者のブラウザから意図せず正規のWebサイトに向けて送信される
c. 攻撃者が指定した処理は、利用者からの要求として実行される

攻撃の仕組み

利用者が正規サイトにログインのセッションを維持しているとする。

この状態で、攻撃者が用意したサイトにアクセスし、正規サイトに対するリクエストが発生するようなスクリプトを保持・利用者に実行させる。

正規サイトに対して、利用者のふりをして、攻撃者が準備したスクリプトに沿った処理がされる。

こんな感じで本人に成りすまして、不正な攻撃を行う攻撃。

脆弱性の原因

  • セッションのみで、本人確認が不足していると、なりすましを見抜けない
  • ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のあるリクエストを受け入れてしまう

対策

Webサーバが受信したリクエストがどこから来たものが確認する。

  1. トークンを用いてリクエストの正当性を検証する

フォームを実装しているページに、攻撃者が推測できない値（以下、CSRFトークンと呼びます）※3を埋め込む対策方法です。

Webサーバで生成したCSRFトークンをWebサイト利用者にあらかじめ渡しておき、重要な処理を実行する際には、セッション管理用のCookieと併せてCSRFトークンを送信します。Webサーバは、受信したリクエストに含まれるCSRFトークンがWebサーバで生成したものと一致することを確認します。

CSRFトークンはWebサイトとその利用者しか知りえない値であるため、CSRFトークンが一致しないリクエストを「不正なリクエスト」として拒否できるようになります。

  1. Originリクエストヘッダを検証

WebサーバでOriginリクエストヘッダを検証し、許可したオリジン以外からのリクエストを拒否する対策方法。

Originリクエストヘッダは、リクエストの発生したオリジン（スキーム、ホスト名、ポート番号）が記録されたリクエストヘッダ。 オリジンをまたぐリクエストはもちろん、同一オリジン内のリクエストであってもOriginリクエストヘッダは付与される。

アプリケーションが意図しないオリジンからのリクエストを拒否するように実装・またはミドルウェアを構成することで、CSRF攻撃を見抜ける。

  1. カスタムリクエストヘッダが付与されていることを検証

正当なリクエストにはカスタムリクエストヘッダを付与し、Webサーバが受信したリクエストにカスタムリクエストヘッダが付与されていることを検証する対策方法。

HTML formによるリクエストではなく、JavaScriptを用いたリクエストを実装していることが前提の対策となります。

avaScriptを用いてブラウザからWebサーバに向けてリクエストする場合、正当なリクエストには必ずカスタムヘッダを付与するように実装します。このとき、ヘッダの値は重要ではありません。

例えば、次のようなX-Custom-Headerが付与。

→Webサーバで受信したリクエストにX-Custom-Headerが付与されていることを確認します。付与されていない場合、不正なリクエストとして拒否するように実装します。

POST /transfer HTTP/1.1
Host: api.bank.example
Content-Type: application/x-www-form-urlencoded
X-Custom-Header: <任意の値>

<params>
  1. CookieのSameSite属性を適切に設定 セッション管理用のCookieを利用者のブラウザに記録する際、SameSite属性をLaxまたはStrictに設定することで、CSRF攻撃の緩和策となります。

SameSite属性にLax、Strictが指定されたCookieは、サイトをまたぐリクエストにおいて次のようにCookieの自動送信が制限されます。 Lax: GET以外のサイトをまたぐリクエストにおいてCookieを自動で付与しない Strict: サイトをまたぐあらゆるリクエストにおいてCookieを自動で付与しない

→脆弱性の原因となるセッション情報を保持したCookieがむやみに、悪用されなくなる。

SSRF

概要

攻撃者がWebアプリケーションやAPIを改ざんして内部リソースにリクエストを送信させることで発生するセキュリティ欠陥の一種であり、不正アクセス、データ漏洩、システム侵害、リモート コード実行などにつながる可能性がある。

攻撃の仕組み

攻撃者は一般に、サーバ側HTTPリクエストのターゲットURLを指定するために使用される入力を改ざん。

これは、アプリケーションがリモート リソースからデータを取得する前に、ユーザーが入力したURLを検証またはサニタイズしない場合に発生する可能性がある。

例. 標的となるリソースが、クラウドのメタデータ サービスやバックエンドのAPIなど、他のシステムと信頼関係を構築している場合にも発生し、攻撃者はこれらの信頼されたサービスにリクエストを行って機密情報を引き出したり、不正なアクションを実行したりすることができます。

a. APPで、ユーザー入力により、サーバリクエストのターゲットURLを指定できるフォーマットがある

b. 攻撃者は、リクエストに加工を施して、アクセスしたいターゲットURLを指定するように入力する→リクエスト

c. サーバーが、悪意ある入力を処理して、ターゲットURLへのリクエストを作成→サーバーからのリクエストとなる

d. ターゲットとなったサーバーから内部の機密情報を盗み出したりと、攻撃に悪用される。

ディレクトリ・トラバーサル

概要

ウェブアプリケーションには、外部からパラメータを直接指定するものがある。
このようなウェブアプリケーションでは、ファイル名指定の実装に問題がある場合、攻撃者に任意のファイルを指定され、ウェブアプリケーションが意図しない処理を行う可能性がある。

脅威

  • サーバー内のファイル参照、改ざん、削除
  • 重要情報の漏洩

脆弱性の原因

外部からのパラメータでサーバー内のファイル名を指定している場合に起こる問題

根本解決

  1. 外部からのパラメータによるファイル直接指定の実装を避ける
    外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装では、そのパラメータが改 変され、任意のファイル名を指定されることにより公開を想定しないファイルが外部から閲覧される可 能性があります。
  2. ファイルを開く際は固定のディレクトリを指定し、ファイル名にディレクトリ名が含まれないようにする
    カレントディレクトリ上のファイル「filename」を開くつもりで、open(filename) の形式でコ ーディングしている場合、open(filename) のfilenameに絶対パス名が渡されることにより、任意ディ レクトリのファイルが開いてしまう可能性があります。
  3. ウェブサーバー内のアクセス権限を正しく管理する
    ウェブサーバ内に保管しているファイルへのアクセス権限が正しく管理されていれば、ウェブアプリケーションが任意ディレクトリのファイルを開く処理を実行しようとしても、ウェブサーバ側の機能でその アクセスを拒否できる場合があります。
  4. ファイル名のチェックを行う
    ファイル名を指定した入力パラメータの値から、「/」、「../」、「..\」等、OS のパス名解釈でディレク トリを指定できる文字列を検出した場合は、処理を中止します

セッション・ハイジャック

ウェブアプリケーションには、セッションIDを発行し、セッション管理を行うものがある。
セッションIDの発行や管理に不備がある場合、悪意ある人にセッションIDを不正に取得され、正規利用者になりすましてアクセスされる可能性がある。

以下例の場合攻撃者はセッションIDが連番であることを予測して、利用者のセッションIDを予測してなりすましている
image

攻撃者が、ウェブサイトに罠をしかけて、利用者がアクセスした際に、セッションIDを盗む→利用者になりすます
image

攻撃者がウェブサイトよりセッションIDを取得→別の利用者のアクセス時に、攻撃者のセッションIDでログインさせる→利用者がログインすると、攻撃者がログイン状態となる
image

脅威

セッション管理の不備を狙った攻撃が成功した場合、攻撃者は利用者になりすまし、その利用者本人に許可されている操作を不正に行う可能性がある。
具体例

  • ログイン後の利用者のみが利用可能なサービス悪用
  • ログイン後の利用者のみが編集可能な情報の改ざん、新規登録
  • ログイン後の利用者のみが閲覧可能な情報の閲覧

XSS

webアプリケーションの脆弱性を利用して悪意あるスクリプトをユーザーのブラウザで実行させる攻撃方法。

発生しうる脅威

XSS攻撃により発生しうる脅威は次の通り。

  • 本物サイト上の偽ページに表示される
  • ブラウザが保存しているCookieを取得される
  • 任意のCookieをブラウザに保存させられる

反射型XSS（非持続型XSS）

特徴：攻撃者が用意したURLにアクセスすると、悪意のあるスクリプトが即座に実行されます。 例：検索結果ページにスクリプトを含むURLを入力し、ユーザーがそのURLにアクセスすると、スクリプトが実行されます

蓄積型XSS（持続型XSS）

特徴：悪意のあるスクリプトがウェブサイトのデータベースに保存され、他のユーザーがそのデータにアクセスするたびにスクリプトが実行されます。 例：掲示板やコメント欄にスクリプトを投稿し、他のユーザーがそのページを閲覧するとスクリプトが実行されます

DOM-based XSS

特徴；クライアントサイドのJSが不適切に処理されることで発生する。
サーバーを経由せずに、ブラウザ内で直接スクリプトが実行される。 例: ユーザー入力を直接DOMに反映する際にエスケープ処理が不十分な場合、スクリプトが実行されます

対策

  1. webページに出力するすべての要素に対してエスケープ処理 ウェブページを構成する要素として、本文やHTMLタグの属性値に相当する要素にエスケープ処理を行う。
    エスケープ処理には、ページに表示する特別な文字(<>&)を、ＨＴＭＬエンティティ"&lt"、"&gt"、"&amp"に置換する。
  2. URLを出力するときは"http://"や"https://"で始まるURLのみを許可する。
    URLには"javascript"で始まるようなサイトもある。
    URLにスクリプトが含まれていると、XSSが可能となる場合がある。 例. 利用者から入力されたリンク先のURL を「」の形式でウェブページに出力するウェブアプリケーション リンク先のURL に「javascript:」 等から始まる文字列を指定された場合に、スクリプトを埋め込まれてしまう可能性

リンク先のURLには"http://"か"https://"から始まる文字列のみを許可する。

OSコマンドインジェクション

OSコマンドインジェクションの脆弱性。

発生しうる脅威

OSコマンドインジェクション攻撃により発生する脅威。

サーバ内ファイルの閲覧、改ざん、削除

重要情報の漏えい、設定ファイルの改ざん 等

不正なシステム操作

意図しないOS のシャットダウン、ユーザアカウントの追加、変更 等

不正なプログラムのダウンロード、実行

ウイルス、ワーム、ボット等への感染、バックドアの設置 等

HTTP ヘッダ・インジェクション

ウェブアプリケーションの中には、リクエストに対して出力するHTTP レスポンスヘッダのフィールド値を、外部から渡されるパラメータの値等を利用して動的に生成するものがあります。
たとえば、HTTP リダイレクションの実装として、パラメータから取得したジャンプ先のURL 情報を、Location ヘッダのフィールド値に使用する場合や、掲示板等において入力された名前等をSet-Cookie ヘッダのフィールド値に使用する場合等が挙げられます。
このようなウェブアプリケーションで、HTTP レスポンスヘッダの出力処理に問題がある場合、攻撃者は、レスポンス内容に任意のヘッダフィールドを追加したり、任意のボディを作成したり、複数のレスポンスを作り出すような攻撃を仕掛ける場合があります。
image

⚠️ **GitHub.com Fallback** ⚠️