HTTPの仕様による脆弱性と対策 [情報セキュリティ]
HTTP(プロトコル)の仕様による脆弱性
ベーシック認証では、Webサーバで認証情報を管理する必要があるため、漏えいなどの危険性が高まる
HTTP(プロトコル)の仕様による脆弱性への対策
- HTTPでは通信データが平文でネットワーク中を流れるため、パケット盗聴によって重要な情報が盗まれたり、改ざんされる可能性がある
- ベーシック認証の脆弱性により、パケット盗聴によって認証情報が盗まれる危険性が高い
- HTTPの基本機能であるベーシック認証では、入力された認証情報(ユーザIDとパスワード)がBASE64エンコードされ、ネットワーク中を流れる
- BASE64はバイナリデータをテキストデータに変換する方式であり、エンコードされたデータを復元(デコード)することは容易である
- ベーシック認証では、HTTPリクエストのたびに認証情報が送信される
- 上記の理由から、HTTPでベーシック認証を行っている場合には、パケット盗聴によって認証情報を盗むことは容易である
- 認証情報の一元管理ができず、管理が煩雑になる
- 上記により、漏えいの危険性も高まる
HTTP(プロトコル)の仕様による脆弱性への対策
- 重要な情報を取り扱うWebページではHTTPS(SSL/TLS)によって通信する
- HTTPのベーシック認証は極力使用せず、認証用の入力フォームを用いる(フォーム認証)か、チャレンジレスポンス方式とMD5の採用によって認証情報が秘匿化されるHTTPダイジェスト認証を用いる
- 認証を行う画面では必ずHTTPSを使用する
- ベーシック認証では、認証後もHTTPリクエストのたびに認証情報が送信されるため、全てHTTPSを使用する必要がある
- フォーム認証では認証情報はWebサーバで管理せず、データベースなどを用いて管理する
情報処理教科書 情報セキュリティスペシャリスト 2014年版 (EXAMPRESS)
- 作者: 上原 孝之
- 出版社/メーカー: 翔泳社
- 発売日: 2013/09/13
- メディア: 単行本（ソフトカバー）
CSRF(クロスサイトリクエストフォージェリ) [情報セキュリティ]
CSRF(クロスサイトリクエストフォージェリ)
Webアプリケーションのユーザ認証やセッション管理の不備を突いて、サイトの利用者に、Webアプリケーションに対する不正な処理要求を実行させる攻撃手法です。
例えば、上記のような手続きを踏み、商品を購入するWebサイトがあったとします、このWebサイトにCSRFの脆弱性があった場合に、当該サイトの利用者が、ログイン状態を保持したまま外部のWebサイトに設置された{注文確定}画面への不正なリンクをクリックすることによって、意図しない商品を注文させられてしまう可能性があります。
他にも、CSRFにより、パスワードを強制的に変更させられる、会員制サービスから強制的に退会させられる、ブログや掲示板に意図しないメッセージを書き込まれる、などの問題が発生する可能性もあります。
CSRFの対策
CSRFによる被害を防ぐためには、Webアプリケーションのユーザ認証機能やセッション管理機能を強化し、不正なリクエストを受け付けないようにする必要があります。具体的には後述のとおりです。
【hiddenフィールドを用いてセッション管理機能を強化する】
注文確定前の確認画面(前述の例で言うと{注文内容の確認}画面)をクライアントに送る際に、擬似乱数によって算出した秘密情報をhiddenフィールドにセットするようにして、クライアントからの注文確定のリクエストがあった場合には、リクエストに含まれるhiddenフィールドの値と秘密情報とを比較し、一致した場合にのみ処理を実行します。
これにより、正規の画面を経由しない注文確定のリクエストを排除することが可能になります。なお、Referrerログから秘密情報が漏えいしないように、一連の処理にはPOSTメソッドを使用する必要があります。
【確定処理の直前で再度パスワードを入力させる】
前述の例で言うと{注文内容の確認}画面で利用者に再度パスワードの入力を求め、{注文の確定}画面では入力されたパスワードが正しい場合のみ処理を実行するようにします。
これにより、パスワードの入力がない注文確定のリクエストを排除することが可能になります。なお、この対策は比較的実装が容易ですが、利用者の負担を増やすことになる問題があります。
【Referrerを用いてリンク元の正当性を確認する】
前述の例で言うと{注文の確定}画面でリクエストのReferrer情報を確認することで、不正なサイトから送られてきた注文各リクエストを排除することが可能になります。但し、クライアントの設定などでReferrer情報を送付しないようにしている場合には、正当なリクエストであっても排除されてしまうことになります。
Webアプリケーションのユーザ認証やセッション管理の不備を突いて、サイトの利用者に、Webアプリケーションに対する不正な処理要求を実行させる攻撃手法です。
- ユーザ認証
- 商品の選択
- 商品の注文
- 注文内容の確認
- 注文確定
例えば、上記のような手続きを踏み、商品を購入するWebサイトがあったとします、このWebサイトにCSRFの脆弱性があった場合に、当該サイトの利用者が、ログイン状態を保持したまま外部のWebサイトに設置された{注文確定}画面への不正なリンクをクリックすることによって、意図しない商品を注文させられてしまう可能性があります。
他にも、CSRFにより、パスワードを強制的に変更させられる、会員制サービスから強制的に退会させられる、ブログや掲示板に意図しないメッセージを書き込まれる、などの問題が発生する可能性もあります。
CSRFの対策
CSRFによる被害を防ぐためには、Webアプリケーションのユーザ認証機能やセッション管理機能を強化し、不正なリクエストを受け付けないようにする必要があります。具体的には後述のとおりです。
【hiddenフィールドを用いてセッション管理機能を強化する】
注文確定前の確認画面(前述の例で言うと{注文内容の確認}画面)をクライアントに送る際に、擬似乱数によって算出した秘密情報をhiddenフィールドにセットするようにして、クライアントからの注文確定のリクエストがあった場合には、リクエストに含まれるhiddenフィールドの値と秘密情報とを比較し、一致した場合にのみ処理を実行します。
これにより、正規の画面を経由しない注文確定のリクエストを排除することが可能になります。なお、Referrerログから秘密情報が漏えいしないように、一連の処理にはPOSTメソッドを使用する必要があります。
【確定処理の直前で再度パスワードを入力させる】
前述の例で言うと{注文内容の確認}画面で利用者に再度パスワードの入力を求め、{注文の確定}画面では入力されたパスワードが正しい場合のみ処理を実行するようにします。
これにより、パスワードの入力がない注文確定のリクエストを排除することが可能になります。なお、この対策は比較的実装が容易ですが、利用者の負担を増やすことになる問題があります。
【Referrerを用いてリンク元の正当性を確認する】
前述の例で言うと{注文の確定}画面でリクエストのReferrer情報を確認することで、不正なサイトから送られてきた注文各リクエストを排除することが可能になります。但し、クライアントの設定などでReferrer情報を送付しないようにしている場合には、正当なリクエストであっても排除されてしまうことになります。
情報処理教科書 情報セキュリティスペシャリスト 2014年版 (EXAMPRESS)
- 作者: 上原 孝之
- 出版社/メーカー: 翔泳社
- 発売日: 2013/09/13
- メディア: 単行本（ソフトカバー）
セッション管理の脆弱性と対策 [情報セキュリティ]
セッション管理の脆弱性
HTTPでは、URL指定によるWebページの閲覧や、リンクをクリックすることによる別ページへの遷移、ログイン処理の実行などの各リクエストが単発で完結するため、その連続性や状態を管理することができません。そのため、Webアプリケーション側で各セッションを管理するための識別情報(セッションIDなど)を生成し、クライアントとやり取りする必要があります。
セッション管理の脆弱性への対策
HTTPでは、URL指定によるWebページの閲覧や、リンクをクリックすることによる別ページへの遷移、ログイン処理の実行などの各リクエストが単発で完結するため、その連続性や状態を管理することができません。そのため、Webアプリケーション側で各セッションを管理するための識別情報(セッションIDなど)を生成し、クライアントとやり取りする必要があります。
- パケット盗聴によってセッション管理情報が盗まれる可能性がある(HTTPの場合)
クエリストリング、hiddenフィールド、クッキーのいずれの手段を用いていたとしても、HTTPで通信していれば盗聴される可能性がある - セッションIDが推測・改ざんされ、他者に情報などが漏洩する可能性がある
セッションIDに単純な文字列を使用していると、たとえHTTPSを使用している場合でも、セッションIDが推測・改ざんされてしまう可能性がある - 詳細なセッション管理情報をWebサーバとクライアント間でやり取りしていることにより、他者に情報などが漏洩する可能性がある
GETメソッドでクエリストリングを使用して詳細なセッション管理情報をやり取りしている場合には、特に危険である - Referrerのログが他のWebサイト管理者にセッション管理情報が漏洩する可能性がある
GETメソッドでクエリストリングを使用して詳細なセッション管理情報をやり取りしている場合には、特に危険である - hiddenフィールドの改ざんにより、不正な処理を実行される可能性がある
hiddenフィールドには計算に用いる定数などがセットされている場合があり、HTMLを保存することにより内容を改ざんすることは容易である。そのため、hiddenフィールドの値が改ざんされ、不正な処理が実行されてしまう可能性がある - XSSの脆弱性により、クッキーにセットされたセッション管理情報が盗まれ、悪用される可能性がある
- クッキーの属性設定の問題により、クッキーにセットされたセッション情報が盗まれ、悪用される可能性がある
- セキュア属性が設定されていないとHTTP通信でもクッキーが送出され、盗聴される危険性が高まる
- 有効期限が必要以上に長く設定されていると、クライアント側の問題によりクッキーが悪用される危険性が高まる
- 有効範囲の設定が適切でないと、関係のないサーバやディレクトリにアクセスする際にもクッキーが送出され、悪用される危険性が高まる
- WebサーバでURL Rewriting機能が有効になっていると、意図的なセッション管理情報をクエリストリングにセットして使用することができる可能性がある
- クッキーにセットされたセッション管理情報をクエリストリングとして送ることができる可能性がある
- この脆弱性により、セッションフィクセイションが行われる可能性がある
- セッション管理のバグにより、本来は認証を必要とするWebページに認証プロセスを経ることなくアクセスされる
セッション管理にバグがあると、URLの直接指定や、検索エンジンからの参照によって、本来は認証を必要とするページに直接アクセスされてしまう可能性がある
セッション管理の脆弱性への対策
- 重要な情報を取り扱うWebページではHTTPS(SSL/TLS)にって通信する
- 重要なセッション管理情報はすべてWebサーバ側で管理し、セッションの識別情報(ID)しか含めないようにする
- セッションIDには十分な長さをもった乱数やハッシュ値を用いる
- 重要な情報を取り扱うWebページでは、POSTメソッドを用いてセッション管理情報を隠蔽する
但し、POSTメソッドはWebサーバのアクセスログに入力データが記録されないため、SQLインジェクションやXSSなどが発生した場合に、原因究明や追跡が困難になる
そのため、POSTメソッドを使用する場合は、Webアプリケーション側で受け取ったデータの内容をロギングするようにするのが望ましい - クッキーの有効期限は可能な限り短く、有効範囲は可能な限り狭く設定する
- HTTPSでアクセスするWebページでは、必ずクッキーをセキュア属性ありに設定する
- HTTPでアクセスするWebページとHTTPSでアクセスするWebページをまたがってセッション管理を行う必要がある場合は、二つのクッキーを発行し、一方をセキュア属性なしにしてHTTPのページで使用する。もう一方をセキュア属性ありにしてHTTPSのページで使用する
- 入力データに含まれるメタキャラクタのエスケープ処理を確実に行い、XSSの脆弱性を残さない
- WebサーバのURL Rewriting機能を無効に設定する
- 認証を必要とするページが直接アクセスされることがないようセッション管理を確実に行うとともに、そうしたページが検索エンジンやキャッシュに登録されないよう設定する(タグを用いて設定する)
- セッション管理を自社で開発せず、アプリケーションサーバなどに実装されている機能を使用する(それらの機能にも脆弱性はあるため、十分な評価・検証が必要)
- ログイン後に新たなセッションIDを発行するようにする
- Webアプリケーションファイアウォール(WAF)を用いてセッション管理の脆弱性をついた攻撃を遮断する
→実際にはWAFでロジック系の攻撃を防ぐのは困難
情報処理教科書 情報セキュリティスペシャリスト 2014年版 (EXAMPRESS)
- 作者: 上原 孝之
- 出版社/メーカー: 翔泳社
- 発売日: 2013/09/13
- メディア: 単行本（ソフトカバー）
