何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
鬼車+Unicodeの\[\[:print:\]\]はPOSIX流じゃないらしい - moriyoshiの日記
追記: どっちが正しいとかそういう話ではないので念のため...。 追記2: Technical ReportがAnnexとなっていたのを修正。 追記3: 微妙に誤解があった部分を修正。結論としては同じ。 id:ockeghem さんの、 「POSIX正規表現の[:print:]は改行やタブがマッチするかどうかがPerlとPHPで異なりますね。Perlはマッチしない、PHPはマッチする。どっちが正しいんだ? 」というつぶやきを見て、いろいろ調べてみたんですが、 今回はPHPのせいじゃなかった みたいなのでいろいろほっとしました。 さて、まずは試してみる PHP: <?php foreach (str_split("\x09\x0a\x0d a") as $c) { var_dump(ord($c)); echo "preg_match(): "; var_dump(preg_match("(
![鬼車+Unicodeの\[\[:print:\]\]はPOSIX流じゃないらしい - moriyoshiの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfbe387b8f7f34f3258b15383d14f7bbfd21a773/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704591929891451528%2F12704591929891452254%2F1365590825)
正規表現で「制御文字以外」のチェック - ockeghem's blog
一般に、セキュアコーディングの基本として入力値の検証（Validation）をせよということになっていますが、これが変な方向に行くといわゆる「サニタイズ」のような手法になってしまいます。以前も指摘したように、アプリケーションとしてのValidationは仕様に従って行うべきものです。 ですが、概ねどの場合でも行うべき検証として以下があると思います。 文字エンコーディングの妥当姓 制御文字(\x00〜\x1f, \x7f)のチェック 文字列長のチェック このうち後ろ二つを正規表現として書くにはどうすればいいかを考えていました。つまり、「制御文字以外の文字でm文字以上n文字以下」というようなチェックです。m文字以上、n文字以下は、{m,n}で書けるので、問題は「制御文字以外の文字」です。これはtextタイプのinput要素で、かつアプリケーション仕様としては文字種の制限をしない場合を想定してい
入力値検証について(2): アプリケーションの先頭で行う入力値検証は業務要件により行うべし - 徳丸浩の日記(2007-09-09)
_ アプリケーションの先頭で行う入力値検証は業務要件により行うべし 前回のエントリ徳丸浩の日記 - そろそろ入力値検証に関して一言いっとくか - Webアプリケーション脆弱性対策としての入力値検証についての内容をもう少し突っ込んでみたい。 このエントリは、幸いにも何人かの人たちの建設的なコメントをいただくことができた。それにより、私自身の考えを整理し、深めることができたように思う。 T.Teradaの日記 - 2007-09-08 "週"記(2007-09-07) 今回は、入力値検証の中でも、特にアプリケーションの先頭で行う入力値検証として何をすべきかということに焦点を絞って議論を進めたいと思う。 その前に、まずHTTPの復習から。 HTTPリクエストは申請書にたとえると理解しやすい この日記の読者の多くは先刻ご存知だと思うが、HTTPは非常にシンプルなプロトコルである。WebサーバはHT
入力値検証の話 - T.Teradaの日記 - 2007-09-08
Webアプリケーションのセキュリティ対策としての入力値検証について議論されています。 そろそろ入力値検証に関して一言いっとくか: Webアプリケーション脆弱性対策としての入力値検証について - 徳丸浩の日記(2007-09-05) 思ったことをいくつか書きます。 徳丸さんの日記は、ユーザがテキストボックスなどで自由に値を入力できる住所などのデータを主に対象としたものだと思う。 ただ、ユーザの自由な入力を起源としないデータも存在する（ここでは「システム起源のデータ」と呼ぶ）。 hidden、リンクURLに埋め込まれているGETパラメータ、Cookieなどには、この手のデータが入ることが多い。 システム起源のデータの多くは、ある型に従うことが期待されるもので、原則的に入力値検証をすべきもの（BMPの「ピクセルあたりビット数」と同じような感覚）。 システム起源のデータも、エスケープさえすればイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
