はじめに
IPAが出している『安全なウェブサイトの作り方』全115ページについて、まとめたものです。
以下はIPAのサイト
https://www.ipa.go.jp/security/vuln/websecurity.html
内容
1.SQLインジェクション
2.OSコマンド・インジェクション
3.パス名パラメータの未チェック/ディレクトリ・トラバーサル
4.セッション管理の不備
5.クロスサイト・スクリプティング
6.CSRF(クロスサイト・リクエスト・フォージェリ)
7.HTTPヘッダ・インジェクション
8.メールヘッダ・インジェクション
9.クリックジャッキング
10.バッファオーバーフロー
11.アクセス制御や認可制御の欠落
1. SQLインジェクション
悪意のあるリクエストにより、データベースの不正利用を招く可能性があります。
例えば、入力フォームにSQL文を含んだ文字列を入力した場合、データ漏洩や改ざんが起る場合があります。
解決策１
SQL文の組み立ては全てプレースホルダで実装する。
解決策2
SQL文の組み立てを文字列連結により行う場合は、エスケープ処理等を行うデータベースエンジンのAPIを用いて、SQL文のリテラルを正しく構成する。
解決策3
ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない。
2. OSコマンド・インジェクション
悪意のあるリクエストにより、ウェブサーバ側で意図しないOSコマンドを実行させられ、重要情報が盗まれたり、攻撃の踏み台に悪用される可能性があります。
例えば、入力フォームにSQL文を含んだ文字列を入力した場合、データ漏洩や改ざんが起る場合があります。
解決策１
シェルを起動できる言語機能の利用を避ける。(Perlのopen関数など）
3. パス名パラメータの未チェック/ディレクトリ・トラバーサル
パラメータにファイル名を指定しているウェブアプリケーションでは、ファイル名指定の実装に問題がある場合、公開を想定していないファイルを参照されてしまう可能性があります。
解決策１
外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける。
解決策2
ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする。
4. セッション管理の不備
悪意のある人は、セッションIDの生成規則を割り出し、有効なセッションIDを推測します。
悪意のある人は、罠を仕掛けたり、ネットワークを盗聴したりし、利用者のセッションIDを盗みます。
悪意のある人は、何らかの方法で自分が取得したセッションIDを利用者に送り込み、利用者のログインを狙って、その利用者になりすまします。
解決策１
セッションIDを推測が困難なものにする。
解決策2
セッションIDをURLパラメータに格納しない。
解決策3
HTTPS通信で利用するCookieにはsecure属性を加える。
(HTTPS通信で発行されたCookieがHTTP通信で利用できなくなる）
解決策4
ログイン成功後に、新しくセッションを開始する。
解決策5
ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページ遷移ごとにその値を確認する。
5. クロスサイト・スクリプティング
ウェブアプリケーションにスクリプトを埋め込むことが可能な脆弱性がある場合、これを悪用した攻撃により、
利用者のブラウザ上で不正なスクリプトが実行されてしまう可能性があります。
解決策１(HTMLテキストの入力を許可しない場合)
ウェブページに出力する全ての要素に対して、エスケープ処理を施す。
解決策２(HTMLテキストの入力を許可しない場合)
URLを出力するときは、「Http://」や「https://」で始まるURLのみを許可する。
解決策3(HTMLテキストの入力を許可しない場合)
要素の内容を動的に作成しない解決策4(HTMLテキストの入力を許可しない場合)
スタイルシートを任意のサイトから取り込めるようにしない。
解決策5(HTMLテキストの入力を許可しない場合)
入力値の内容チェックを行う。
解決策6(HTMLテキストの入力を許可する場合)
入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する、
6.CSRF(クロスサイト・リクエスト・フォージェリ)
ウェブサイトの中には、ログイン機能を設けているのものあります。
外部サイトを経由した悪意あるリクエストを受け入れてしまう場合、ウェブサイトにログインした利用者は、
悪意ある人が用意した罠により、利用者が予期しない処理を実行させられてしまう可能性があります。
解決策1
処理を実行するページをPOSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。
解決策2
処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理する。
解決策3
Refereが正しいリンク元かを確認し、正しい場合のみ処理を実行する。
7. HTTPヘッダ・インジェクション
任意のレスポンスヘッダフィールドやレスポンスボディを作成する罠が仕掛けられ、この罠を踏んだ利用者のブラウザで偽のページが表示されたり、スクリプトが実行したり、任意のCookieを保存させられたりする可能性があります。
解決策1
ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用する。
解決策2
開業コードを適切に処理するヘッダ出力ようAPIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する。
9. クリックジャッキング
ウェブサイトの中には、ログイン機能を設け、ログインしている利用者のみが使用可能な機能を提供しているものがあります。該当する機能がマウス操作のみで使用可能な場合、細工された外部サイトを閲覧し操作することにより、利用者が誤操作し、意図しない機能を実行させられる可能性があります。
解決策1
HTTPレスポンスヘッダに、X-Frame-Optionヘッダーフィールドを出力し、他ドメインのさいとからのframe要素やiframe要素による読み込みを制限する。
解決策2
処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
10.バッファオーバーフロー
悪意あるリクエストにより、ウェブサーバー側で任意のコードを実行させられたり、ウェブアプリケーションが異常終了する可能性があります。
解決策1
直接メモリにアクセスできない言語で記述する。
解決策2
直接メモリにアクセスできる言語で記述する部分を最小限にする。
解決策3
脆弱性が修正されたバージョンのライブラリを使用する。
11. アクセス制御や認可制御の欠落
ウェブサイトの中には、運営者のセキュリティ意識のなさから、不適切な設計で作成されたウェブサイトが運用されていることがあります。
アクセス制御の欠落の解決策
アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワードなどの秘密情報の入輿r区を必要とする認証機能を設ける。
認可制御の欠落の解決策
認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする。
最後に
IPAではセキュリティに関するチェックシートも提供している。
うまく活用して、ユーザーが安心して使えるサービスを提供しましょう。