Programming/セキュアWebプログラミングの手引き の履歴(No.2)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Programming/セキュアWebプログラミングの手引き へ行く。
  • 1 (2007-10-22 (月) 00:14:03)
  • 2 (2011-12-23 (金) 01:30:06)
  • 3 (2014-11-10 (月) 02:44:55)

GET,POST†

GETで渡す情報にユーザーの身元が特定できるものを不必要につけてはいけない。同じ情報をPOSTにしてもHTTPヘッダーモニターツール(LiveHttpHeaders)などでいくらでも改ざんできるのでログイン以後はセッションを利用すべきである。

Cookie†

CookieもHTTPヘッダーにて送られるので改竄は容易。Cookieを使うのであれば、平分で保存するのではなく、サーバ側が保持しているIDをCookieに持たせ、さらにそのIDを可逆暗号化して、毎回サーバ側で照合すべき。もちろんニックネームなどの流出しても個人情報特定につながらないものであれば対策は不要。

セッションの受け渡し†

言語標準でセッション管理が備わっている場合はあまり意識しなくていい。ただし携帯開発などではCOOKIEが使えないので、GETパラメータに加えるように変更する必要がある。スタティックなページでもセッションを維持できる方法がある。それは上位ディレクトリにセッションＩＤを埋め込んでおいて、mod_rewriteで書き換えるのである。

http://rutake.com/9803/index.php →index.php?session=9803

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

セッションＩＤを盗んで他人のログイン後の画面に侵入するものである。漏洩パターン配下のとおり

1. 単純なセッションＩＤ付与による類推（単なる連番とか）
2. REFERERによるセッションＩＤの取得
3. XSSなどによるCOOKIE情報の取得

perlの汚染検出オプション†

汚染文字列の危険性のチェックをしてくれるモード

perl -T

攻撃手法と防御策†

Script Insertion†

HTMLタグをそのまま表示するというもの。攻撃手法としてはもっとも単純だが、これの防御ができていないサイトだと、他の脆弱性も間違いなく存在する。JavaScriptを仕込んで任意のページに飛ばしたりできてしまうので、他のユーザにも影響がある。対策としてはHTMLタグを無効化することであり、各言語にはその関数が用意されているはず。ユーザの入力値、データベースの値、現在のアクセスURL($_SERVER['self'])などがタグ無効化対象となる。

SQL Injection†

入力値に不正なSQLを入れる攻撃。PreparedStatementなどを使っていれば防げる。その場合でも入力値を使ってSQLを組み立てるときは必ず入力チェックを行うこと。

CSRF†

正規なログイン認証を経たユーザーに対して、意図せずして更新などを行わせてしまう脆弱性。対策としてはリファラーチェックやトークンが考えられる。

ヌルバイト攻撃†

\0を間に挟むことによりファイルの拡張子チェックなどをすり抜ける攻撃。たとえばdatファイルのみを読み込ませるコードでindex.php\0datとすれば、拡張子チェックは抜けることができる。リクエストパラメータで不正文字は除去する関数を作成しておけば次のディレクトリトラバーサル攻撃も防げる。