_ アプリケーションの先頭で行う入力値検証は業務要件により行うべし 前回のエントリ徳丸浩の日記 - そろそろ入力値検証に関して一言いっとくか - Webアプリケーション脆弱性対策としての入力値検証についての内容をもう少し突っ込んでみたい。 このエントリは、幸いにも何人かの人たちの建設的なコメントをいただくことができた。それにより、私自身の考えを整理し、深めることができたように思う。 T.Teradaの日記 - 2007-09-08 "週"記(2007-09-07) 今回は、入力値検証の中でも、特にアプリケーションの先頭で行う入力値検証として何をすべきかということに焦点を絞って議論を進めたいと思う。 その前に、まずHTTPの復習から。 HTTPリクエストは申請書にたとえると理解しやすい この日記の読者の多くは先刻ご存知だと思うが、HTTPは非常にシンプルなプロトコルである。WebサーバはHT
Webアプリケーションのセキュリティ対策としての入力値検証について議論されています。 そろそろ入力値検証に関して一言いっとくか: Webアプリケーション脆弱性対策としての入力値検証について - 徳丸浩の日記(2007-09-05) 思ったことをいくつか書きます。 徳丸さんの日記は、ユーザがテキストボックスなどで自由に値を入力できる住所などのデータを主に対象としたものだと思う。 ただ、ユーザの自由な入力を起源としないデータも存在する(ここでは「システム起源のデータ」と呼ぶ)。 hidden、リンクURLに埋め込まれているGETパラメータ、Cookieなどには、この手のデータが入ることが多い。 システム起源のデータの多くは、ある型に従うことが期待されるもので、原則的に入力値検証をすべきもの(BMPの「ピクセルあたりビット数」と同じような感覚)。 システム起源のデータも、エスケープさえすればイン
_ Webアプリケーション脆弱性対策としての入力値検証について Webアプリケーションのセキュリティ対策としての「入力値検証」について色々言われている。セキュアコーディングの基本は入力値検証だといわれたり、さほど重要でないと言われたりしている。本当のところはどうなのだろうか。以下、バイナリデータを扱う場合の多いミドルウェア(Webサーバーなど)と対比しながら、この問題を掘り下げたい。 バイナリデータの場合(≒ミドルウェアの場合) バイナリデータでは、入力検証が重要である。少し前にmod_imagefightを取り上げた(画像版サニタイズ言うな(2))ので、ビットマップ画像を例に説明しよう。 その際に使用したBMP形式の説明を再掲する。 0000:MARK(2) ='BM' 0002:ファイルサイズ(4) * 0006:予約1(2) =0 0008:予約2(2) =0 000A:ビットマップ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く