jump to navigation

WEBセキュアプログラミング 11月 2, 2009

Posted by hyhy in 技術情報.
Tags:
trackback

WEBセキュリティー

SecurityFocus

セキュアWebプログラミング入門1

HTTP通信の基礎

【クライアント側の入力制限とセキュリティ】

GET送信、POST送信のどちらが安全ということではない。
HTML上のSELECTボックスやラジオボタンの入力制限の意味はない。
なぜなら、不正行為者はWebブラウザが送信したHTTPリクエスト・メッセージ自体
を任意に改変して攻撃を仕掛けてくる。

【CGIプログラムから見たGETとPOSTの違い】

クエリ文字列もPOSTされるデータもRequestオブジェクトとして提供される

【クエリ文字列とReferer情報による漏洩】

Referer情報はリンク元のURL情報+クエリ文字列が含まれる
そのため、クエリ文字列は自分のWEBサイトのリンクによって他のWEBサイト
に漏れてしまう情報である。
よってURLに機密情報は埋め込まないWebアプリケーションとすること。

しかしユーザ認証が必要な携帯端末向けコンテンツではURLに認証情報やセッションIDを埋め込む必要がある。
利用者に便宜を図るため、携帯端末向けコンテンツではサイトへのアクセスが簡単にできるようになっている。
利用者IDと他社には推測困難なURLを紐付け、そのURLにアクセスしたら利用者であると判断する。

機密性の高いURLのWEBページには外部リンクを用意しない。

外部リンクが必要な場合の対策として、
利用者を一度、URLを洗浄するWebページに遷移させて、そのリダイレクト専用のWebページから外部Webサイトへ
ジャンプさせる。

HTTPセッション管理となりすまし

【HTTPセッション管理機能】

1.REMOTE_ADDRを使うなどして、IPアドレスとユーザー認証情報を紐付けることはセキュリティ上やってはいけない。

理由として、REMOTE_ADDRはWebブラウザのIPアドレスとは限らず、ProxyサーバのIPアドレスの場合もある。
NAT/NAPTで複数ユーザが一つのグローバルアドレスを共有してある場合も同様。
逆に複数のProxyサーバを負荷分散として使っている場合、認証後に異なるIPでアクセスする場合もある。

2.HTTP_Refererを使った認証機能はセキュリティ上やってはいけない。

Referer(リンク元ページのURL)はHTTPリクエストメッセージのヘッダ情報としてWebブラウザがWebサーバへ
提示するという仕組みになっているが、CGIプログラムが参照するReferer情報を改変することができてしまう。

3.Hidden、クエリやCookie情報にデータを保持させる(非推奨)

ページ間の情報の保持について
Webブラウザ上のデータ格納領域(Hidden、クエリ文字列、Cookie情報)はWebブラウザを操作できる人であれば
データを改変することができる。
よって改変されては困る情報をWebブラウザ上のデータ格納領域に保存することはセキュリティ上、問題がある。

■【セッションIDによるセッション管理】

セッションIDによるセッション管理が現在の主流

Webブラウザ側の格納領域にはセッションIDだけを保存し、Webサーバ側にセッションIDと紐付いた形で、セッションID
ごとにメモリを用意し、そこに保存する。
Webサーバ側で保持できる領域は「セッション変数」または「セッションオブジェクト」という。

セキュリティ上、セッションIDは推測困難性という性質が必要不可欠

【既存のセッション管理機能】

IIS+ASP, ASP.NET, JavaServlet, PHPなどのWebアプリケーションサーバには
セッションオブジェクトがあらかじめ組み込まれている。
perlの場合はCPANから「Apache::Session」モジュールをインストールして利用すればいい。

セッション管理機能ではタイムアウト機能が実装されている。
タイムアウト機能とは最後にアクセスしてからタイムアウトで指定した時間が経過しても再度アクセスがこなければ
別のページに遷移したかブラウザを閉じたと判断する。
タイムアウトした場合は、セッションオブジェクトを破棄し、メモリを開放する。

注意点として
1.タイムアウト時の明示的なセッション破棄ページを用意すること
2.ログアウト機能(明示的にセッションを破棄する)を実装すること

【Session Fixation(セッション固定化攻撃)】

不正行為者が決めた任意のセッションIDを犠牲者に使わせるというもの。
手順として、
1.あらかじめ決められたURL(セッションIDがクエリ文字列として付加)を相手に渡す
2.そのURLでログインする。
3.相手がログイン後にアクセスする。

こうならない為に、必ずWebアプリケーション側でセッションIDを生成する。ブラウザが提示したセッションID
をそのまま採用するのはセキュリティ上、問題がある。

ほとんどのWebアプリケーションサーバにとって「セッションIDの自動発行」機能が有効

可能であれば自動発行ではなく、ログインによるユーザ認証処理後にセッションIDを発行(再発行)
することがのぞましい。

【Cookie Monster (CrossDomain Cookie Injection)】

CSRFとアクセス制御

【CSRF(Cross-Site Request Forgeries)】

Cookie情報がWebブラウザ全体で共有されるという性質を利用した攻撃がCSRF攻撃
偽ページから自サイトの重要なページを表示または行動をするという攻撃

セキュリティ対策のため、
自動ログイン後でも個人情報閲覧や購入の際にはパスワードを求める仕様にする。
重要な処理ページでは、Webページ側で確認ページを設け、その確認ページのHiddenフィールド
に推測困難な値(トークン)を埋め込み、その値が正しく返ってきた場合が正常処理であるという
チェックルーチンを用意する。

メモリ破壊バグとその対策

【メモリ破壊バグ】

メモリ上のマシン語コードを直接書き換えられてしまうセキュリティ・ホール
「バッファ・オーバーフロー」

インジェクション系セキュリティ・ホールとその対策

特殊文字を普通のデータのように扱うルールをエスケープ処理という。

インジェクション系セキュリティ・ホールのほとんどがエスケープ処理忘れ。

不正行為者はこのエスケープ処理忘れの入力箇所を探し出し、入力データ中にメタキャラクタを含ませて、
インジェクション系セキュリティ・ホールを悪用し、システムに対し不正アクセスを行う。

基本対策として、
1.テキストインターフェイスを使う場合、データ類は全てその機能ごとにエスケープを実施すること
2.入力データに特定の書式が期待される場合は、入力値チェックもあわせて実施すること

セキュアWebプログラミング入門2

Webシステムに対する攻撃の内訳

1.クロスサイト・スクリプティング(Javascriptインジェクション)
2.SQLインジェクション
3.情報漏えい
4.任意プログラム/コマンドの実行
5.不十分な認証

Webアプリケーション構築時に必要なセキュリティ対策

【重要な要素】

入力と出力

設計

コーディングの指針

【エラーを厳格に処理する】

通常の処理を行っている場合にはエラーや例外が一切発生しないようなコーディングが必要。

例外やエラーが発生した場合には必ず実行を停止するようにコーディングする。その為には
適切エラーページを送信できれば処理を打ち切っても問題はない。
    

エラーが発生した場合、その内容を記録すべき(バグ発見の為)。

【入力を完全にチェックする】

入力が明示的に許可されている文字種、形式、長さ、範囲に収まっているかをチェックする。

セキュリティ対策として入力の「サニタイズ」という処理があるがお勧めできない。
サニタイズとは入力をチェックし、不正な文字や文字列を取り除いてプログラムで安全に処理できるようにすること。

サニタイズ処理の多くは入力に問題があった場合に、問題を起こさないようなデータに変換して処理を続けるコードになっている
ため、「エラーを厳格に処理する」に反する。

入力をチェックする際には正規表現を利用することが多いが、間違った正規表現を使うとチェック漏れが起こる。

【可能な限り出力をエスケープする】

外部システム(XML,HTMLの出力、DBへのクエリー)への出力はエスケープ処理してはならない値を除き、すべてエスケープすべき。
エスケープ処理とは、特殊な意味を持つ文字を意味を持たない単なる文字として出力するために行う変換処理のこと

【対策を多重化する】

JavaScriptインジェクション

ユーザーがWebアプリケーションの出力に任意のJavaScriptを挿入できてしまうという脆弱性。
この脆弱性を悪用した攻撃手法である「クロスサイト・スクリプティング」

SQLインジェクション

攻撃者が送ってくる不正なデータによってサーバーが意図しないSQL文を実行させられてしまう脆弱性

対策として、「プリペアード・クエリー」を利用する。これは、実行したいSQL文をDBサーバに登録
しておき、実行時に必要なパラメータのみを渡すクエリー方法。
プリペアード・クエリーに与えられるパラメータはすべてSQL文への変数として処理される。

認証について

【Refererを認証に利用するケース】

Referer情報はブラウザから送信される情報であり、簡単に改ざんできるので危険

【認証にSQLDBを利用し、ユーザー名、パスワード文字列をエスケープしないケース】

select文で入力したユーザー名、パスワードで1件ヒットした場合にログインOKとするロジックは、
$_POST[‘username’] に”’OR1=1;–”を送信することで認証をバイパス可能。

【ログアウト機能を実装していないケース】

認証をサポートするWebサイトは必ずログアウト機能を実装しなくてはならない

自動ログイン機能について

セッション管理機能について

【セッション管理用のIDに意味のある値、予測可能な値、固定の値を使用していた】

セッションIDの値は、予測不可能なランダムな値の必要がある

【セッションIDの有効期限が極端に長い設定だった】

セッションIDは最長でも1日に1度は更新すべき

【セッションIDの管理にセッションCookieでないCookieを利用していた】

セッションCookieとは有効期限が0の特別なCookieで、通常メモリー上にのみ保存され、
ブラウザを終了すると削除される。
通常のCookieでセッションを管理するとブラウザを終了してもセッションIDが残ってしまう。

排他制御について

排他制御とは:ファイルやデータベースに書き込み処理を行なう際に、
データの整合性を保つためにデータの読み書きを一時的に制限すること。

【一時ファイル名の重複で情報が漏えいしたケース】

【データベースのデータが不整合を起こした】

トランザクションを利用すべき場所を把握する

【フォームの2重送信】

フォームの2重送信のチェック処理が必要

広告
%d人のブロガーが「いいね」をつけました。