がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

validateとescapeは違う概念だと思うのだが…

プログラミング セキュリティ

先に。sanitizeについてはなんか定義が色々と怪しいので使いませんｗ
…とかいいつつ少しだけ書くと。


sanitizeって、基本的に「antidote(解毒)」って概念だと思うのですが。
問題は。現実の毒でもそうなのですが「実際の解毒法は毒の種類によって変わる」です。ゲームアイテムにあるような「毒消し草」は存在しないです。
ついでに「何を以て毒とするか」って定義も曖昧ですしね。人間に作用する毒が同じように鳥類に作用するとは限りません。
なので。
sanitizeという言葉は「概念」として用いる可能性はあったとしても「実装周り」に使える単語では、結局ないんじゃないかと思うです。
ついでに。sanitizeって単語、もう一つ「防毒*1」なのか「解毒*2」なのかも微妙ですしね。使われ方的に。


で、本題。


んと…セキュリティ系の文脈でよく出てくるのですが…もう一つ混ざってる気がしてならないvalidateとescape。
ちとこの概念をいい加減きちんと整理して使い分けたいなぁと思うです。


validateは「有効であるかどうかを検証する」という意味合いがあります。
例えば日本の郵便番号は、2008年現在とりあえず「アラビア数字で３桁と４桁」ってのが有効範囲なので。ここでアラビア数字以外の、例えばローマ数字を持ち込んだり英字をぶち込んだりすると、それは「無効(invalid)なデータ」って事になります。
誕生日であれば「日付が存在しうる月日」ですし。…これが年になると微妙なんですがね(苦笑
ここらあたり、いわゆる「valid(正統)な」データが判断しやすいところになります。


つぎに。
メールアドレス…の正当性(valid)を論じるのは大変に厄介である事は以前に何度か書いたのですが。
今回はまたちぃと別の切り口から。
んと。例えば hoge@foo.com ってのは、存在するかはともかくとして、とりあえずvalidなメアドです。
んで。
小美人＜hoge@foo.com＞(本当は半角)というアドレスもまた、これはちゃんとvalidなメアドになります。有効部分はhoge@foo.comだけですが。


さらに。
例えば「プログラムを語る掲示板」なんかだったりすると、当然ながら様々な文字が出てくるわけです。
とりあえず

string s = 'INSERT INTO bar(hogera,mugera) VALUES(?,?);';

なんて文字列を想定。
当然ながら掲示板ですし、データとしてはvalid。


ただ。
当然ながら。
HTMLに出力するときに、メールの＜＞はエスケープせにゃあきませんし、DBにぶち込む時に掲示板の’だの；だのはエスケープしなきゃ酷い事が起きます。
つまり、例題のデータのいくつかは「validではある」けれども「escape対象の文字を含みます」。


ここまでOKでしょうか？


さて。
まぁ結局のところ、発端は「“入力時のサニタイズ”やめれ」いう話からなのですが。
入力時のサニタイズ推奨派の皆様がいう単語の一つに「ちゃんとホワイトリストで云々間ぬん」とかいう発言があります。


ホワイトリストにせよブラックリストにせよ、基本的にこれらは「validate」というチェックに属するものになります。
つまり「ホワイトリストにあるもの以外をinvalidにするのか、ブラックリストに載っているものをinvalidにするのか」という感じですね。
一方で。セキュリティの文脈でXSSとかSQL-Injectionとかの文脈で語られるのは「エスケープ処理が出来ているか否か」という部分であります。


つまりですね。
エスケープ処理を論じるべきところで「ホワイトリスト云々」言われても「駄目だなぁ」と思ってしまうわけですよ。


validateは、もちろん「入力のタイミングで」チェックする事が可能です。なぜなら、validateは「そのデータ項目に紐付いた」属性だから。
でもescapeはそうじゃなくて。escapeは「出力先に紐付いた」属性を持っているので、だからこそ「出力先にあったescape方法が各種とりそろえられている」はず、なのです。


一番肝心なのは「validateとescapeは、意味も趣旨も全然違うんだ」ってところ。
この二つをまぜまぜすると…ちょっと危険な香りが漂います。
あなたは、ちゃんと使い分けて話ができますか？

*1:体内に入る前に防ぐ

*2:体内の毒を無毒化する

「おまえが悪い」ネタ第二弾 orz

MySQL

んと。ちと色々ありまして

  • 現行本番のDBを色々したいってかとりあえず「ちと細工などしつつ」吸い上げたい
  • 本番DBくん、ぶっちゃけ「uptimeとかすごい事になってる orz」
  • 幸い、いくつか別マシンがある

って状況がお膳立てとしてありまして。
まぁ

  • 一瞬だけMySQL君に止まってもらう
  • データディレクトリを丸ごとcp -pR
  • cpしたファイル一式を、MySQLが入ってる別マシンに移動 ＆ 起動

って処理して、別マシンで安心して吸い上げを開始したです。


さて………日本語が全然吸い上がらない orz


具体的には。0x3fからなります、いわゆる？か連打されております。
実際に？であることは、

head 対象ファイル.sql | od -x | less

で確認してございます orz


で、調査。
んと…my.cnfが違う orz


コンソールに入りまして。statusっちゅ〜コマンドを叩くです。
で、一部抜き出し。
元DB

Server characterset: sjis
Db characterset: sjis
Client characterset: sjis
Conn. characterset: sjis

ぶち込んだ吸い上げ用DB

Server characterset: latin1
Db characterset: sjis
Client characterset: latin1
Conn. characterset: latin1

orz orz orz
いいぢゃん所詮バイナリデータなんだしなにもしねぇで素直にはき出してくれよ ；；


中でなにをどのように処理してるのかかなり不明ですが。
とりあえず「copyするならmy.cnfまで全部コピらないと駄目」というノウハウを「げっとだぜ〜」(号泣

えと…まぢ？

セキュリティ

Google Android携帯にすごいバグ、すべてのテキスト入力をコマンド扱いで実行
http://japanese.engadget.com/2008/11/09/google-android/

Google CodeのAndroidプロジェクトに寄せられたバグリポート Issue 1207によると、G1のファームウェア RC29以下にはすべてのテキストエリアへの入力をコマンドとして、しかもスーパーユーザー権限で実行してしまう(！)バグがあるとのこと。

………まぢっすか？

アクセルとブレーキがそろってこその車なんだなぁと思うのですが

親方 その他技術

「あれやるなこれ危険」なブレーキだけでは車は1mmたりとも前に進まない。
イケイケどんどんでアクセル床まで踏みっぱなしだと、多分いろは坂あたりでどえりゃぁ事になる。


急がなきゃいけない時にはそれなりにアクセルも床まで踏み込めて。
でもちゃんと必要な時には、場合によってはフルブレーキかけることが出来て。
別に「ヒール・アンド・トウ」しろたぁ言わないけど。せめて「スロウインファストアウト」くらいは把握してようよ。
うちら、それで飯喰ってるんでしょ？ それでお金貰ってるんでしょ？


腕が知識が判断力がないのは。
無い事を理由に「ブレーキしかない」「アクセルしかない」車になるということは。
努力を成長を教育を学習を放棄しちゃうのは。
もちろん全てが十全に出来るわけではないけれども、「出来ないのが当たり前」って開き直っちゃうのは。
それらを肯定しちゃったらもはや詐欺と変わらないんじゃないかなぁと思うのですが。


どんなもんなんですかねぇ？
などとつらつら…かなりの猛毒を雑感ｗ

やっぱり怖いよ orz

携帯

元ネタはこちら。
IP制限は必要悪。
http://d.hatena.ne.jp/m_norii/20081106/1225981496


うんid:m_noriiさんが言っている事はすべてtrueだと思う。
つまり

  • 本質的にはIP制限なんて無意味な「はず」なんだけど
  • いわゆる簡単ログイン(契約者識別ID)が、特にPCブラウザとかだと極めて容易に偽装出来る
  • から結果としてIP帯域を制限せざるを得ない


ただ。じゃぁ「IP制限によってとりあえずどうにかなるのか」といえば…

  • そもIP制限そのものが「キャリアが明示的に未保証である」と明記している
  • っつかその「IPを取得できるPage」がDNSポイゾニングとかであっというまにアタックNo1
  • っつかrawパケットのfrom IPを書き換うわなにをするやめくぁｗせｄｒｆｔｇｙふじこｌｐ


わ〜いヽ（￣￣∇￣￣）ノ
なんていうか…相変わらずの八方ふさがり orz


かくして。
おまんま喰わにゃならんうちらとしては…

それらを必要悪と認識した上で、それが何故必要悪なのか、本来はどうあるべきなのか、それが何故今出来ないのかを理解すること。
また、そういうリスクのあるサービスを提供してるんだ、ということを経営層にもきちんと認識してもらうこと。
そして、大本である携帯キャリアにはもっと声をあげて、しかるべき機能をきちんと実装することを訴え続けること。
・・・が、良識ある携帯技術屋としては必要かなぁ。。。と考えた次第。

というあたりに帰結するわけですね。


っつか。
とりあえず書籍とかで胸はって「IP制限がセキュリティのためには必要」とか一言で片付けるのいい加減やめようよ orz
まぁまっすぐにぶっちゃけまして。この本とかなんですがね。…ネットで無駄に風評いいだけに*1、めっさ気になります orz

PHP×携帯サイト デベロッパーズバイブル

PHP×携帯サイト デベロッパーズバイブル

注：
一応念のため。絵文字その他、いわゆる携帯サイトを作る上でのノウハウ自体は色々ときちんとまとまってる…らしい。いくつかのサイトの記述を信用するのであれば。
おいちゃん的にはいくつかのソースコードとIP制限周りの話を立ち読みで斜めに見た瞬間にぶっちゃけ買う気が失せたので詳細は不明ですが orz


追記
んと…著者のBlogとかいうのがありまして。
http://ideaup.seesaa.net/article/108141154.html

7章にかいてある「かんたんログイン」に関する方法は、リクエストヘッダーなどを書き換えることにより、第三者がなりすましてログインされてしまう可能性があります。
そのため「かんたんログイン」を実装する際は、携帯キャリアゲートウェイのIPアドレスから来るアクセスのみに限定するように留意して実装してください。
ユーザーエージェントではなくIPアドレスで制限することで携帯電話本体からサイトにアクセスされていることを確認する事が出来ます。
IPアドレスからのアクセス制限の方法については、第3章に詳しく書かれておりますので、そちらをご参考にIPによる制限を実施して頂ければと思います。
携帯における「かんたんログイン」はそのままの使用ではセキュリティ上問題がありますので、対策をご理解の上ご使用くださいますようお願いします。

えと…だから「IP絞りゃいいってもんじゃなかんべ？」と思うのですが…
どうしてこう「バッドノウハウ」って速やかに広がるんですかねぇ？

*1:一部ではさんざこき下ろされてますが

戦略考察の基礎…っていうか用語確定

FFXI

ざっくりとしたmemo。近日なんか考察…しようかなぁｗ

  • アタッカー

ダメージ源。さらに以下の二種類に分かれる。

    • メレー

恒常的にダメージを出せる人。瞬発力はないがトータルダメージ量がたっぷり。

    • ヌーカー

瞬間最大風速(ダメージ)が鬼のような人。短い単位時間において強力なダメージ源となる。

  • タンク

敵の攻撃を一手に担う人。
防御力が高いのは最低限Must。

  • ヒーラ

治療をする人。できれば「メインヒーラ」のほかに「サブヒーラ」がいると色々安心。

  • バフ/デバフ(味方補助/敵弱体)

いなきゃいけないわけじゃないがいた方が楽な人たち。

  • テイマー

区分としては大抵メレーなのですが。「ヘイト値をペットが受け持ってくれるのでダメージ管理しやすい」ってのが一つ利点。

微妙過ぎるorz

PHP

えと。
おいちゃんは日本人だとのもっぱらの噂で、実際問題母国語が日本語っぽいので。
必然的に「日本語を扱う」Webあぷりけぇしょんってのを作るです。


で。


まぁとりあえず「日本語の文字コードを推測する」、いわゆる一つの「guess」系ルーチンってのが欲しいわけでして、まぁ必要ですしPHPにもあるわけですし重宝しなきゃいかんのであります。
PHPにおいては、おいちゃんのお勉強不足＆知識不足＆以下略でなければ、おそらく、mb_detect_encoding ( http://www.php.net/manual/ja/function.mb-detect-encoding.php ) という関数が、その手の処理を担ってくれているはずなのであります。

mb_detect_encoding ― 文字エンコーディングを検出する

って書いてあるしね。


ただ。


経験則上、極々希にではあるのですが「もしかしたら もしかしたら そうなのかしら〜？」と首をかしげたくなる挙動が、必ずしも０ではなかったような…記憶が、反逆的記録が、かすかにあるです。
そのような「用意された関数に対する反逆的感情」などという不届きなものを抹消するために、以下のプログラムをまず用意したです。

<?php

function dump_string(&$s, $flg = true)
{
//var_dump($s);
  $len = strlen($s);
  if (true === $flg) {
    $ret = $s . '(';
  } else {
    $ret = '(';
  }
  for($i = 0; $i < $len; $i ++) {
    $ret .= sprintf("(%02x)", ord($s[$i]) );
  }
  $ret .= ')';
  return $ret;
}

$s = 'あいうえお';
print dump_string($s, false) . "\n\n";

$ec = mb_detect_encoding($s, 'sjis-win,eucjp-win,JIS,UTF-8,ASCII');
var_dump($ec);

$ec = mb_detect_encoding($s, 'UTF-8,sjis-win,eucjp-win,JIS,ASCII');
var_dump($ec);

$ec = mb_detect_encoding($s, 'eucjp-win,UTF-8,sjis-win,JIS,ASCII');
var_dump($ec);

$ec = mb_detect_encoding($s, 'JIS,eucjp-win,UTF-8,sjis-win,ASCII');
var_dump($ec);

で、このファイルをsjis、euc、jis、utf-8のそれぞれに変換して走らせてみたのですが………結果がもう一つ微妙だったりするわけです orz

( (82)(a0)(82)(a2)(82)(a4)(82)(a6)(82)(a8) )
string(8) "SJIS-win"
string(8) "SJIS-win"
string(8) "SJIS-win"
string(8) "SJIS-win"


( (a4)(a2)(a4)(a4)(a4)(a6)(a4)(a8)(a4)(aa) )
string(8) "SJIS-win"
string(8) "SJIS-win"
string(9) "eucJP-win"
string(9) "eucJP-win"


( (1b)(24)(42)(24)(22)(24)(24)(24)(26)(24)(28)(24)(2a)(1b)(28)(42) )
string(8) "SJIS-win"
string(5) "UTF-8"
string(9) "eucJP-win"
string(3) "JIS"


( (e3)(81)(82)(e3)(81)(84)(e3)(81)(86)(e3)(81)(88)(e3)(81)(8a) )
string(5) "UTF-8"
string(5) "UTF-8"
string(5) "UTF-8"
string(5) "UTF-8"

EUCとsjisの判定がおかしい部分があり、かつ、jisについては概ね全滅 orz


ここでひるんではいけません。
世間には、一般的に「美乳テーブル」と呼ばれる特殊な文字列があります。ググるとそのまま出てきますのでどうぞ適宜お調べくださいｗ
で。
いきなり全てのHTMLに「美乳」とか書くと、0.25歩ほど間違えれば「せくはら〜」とか言われかねませんので。
ここは節度を以て$s を 「雀の往来美乳」という文字列にしてみました(「雀の往来」もまたよく使われる文字列の一つです)。


結果。

( (90)(9d)(82)(cc)(89)(9d)(97)(88)(94)(fc)(93)(fb) )
string(8) "SJIS-win"
string(8) "SJIS-win"
string(8) "SJIS-win"
string(8) "SJIS-win"


( (bf)(fd)(a4)(ce)(b1)(fd)(cd)(e8)(c8)(fe)(c6)(fd) )
string(9) "eucJP-win"
string(9) "eucJP-win"
string(9) "eucJP-win"
string(9) "eucJP-win"


( (1b)(24)(42)(3f)(7d)(24)(4e)(31)(7d)(4d)(68)(48)(7e)(46)(7d)(1b)(28)(42) )
string(8) "SJIS-win"
string(5) "UTF-8"
string(9) "eucJP-win"
string(3) "JIS"


( (e9)(9b)(80)(e3)(81)(ae)(e5)(be)(80)(e6)(9d)(a5)(e7)(be)(8e)(e4)(b9)(b3) )
string(5) "UTF-8"
string(5) "UTF-8"
string(5) "UTF-8"
string(5) "UTF-8"

jis以外は良い感じでございます。
んと…個人的には「jisはシフトアウト/シフトインがあるんだからもっと素直に判別しようや」とか思わんでもないのですが。
とりあえず「'JIS, eucjp-win, UTF-8, sjis-win, ASCII'」という文字列が、現状においては比較的「誤作動しにくい順番なのではなかろうか」と予想されるに至った訳であります。…多分ね。
というわけで、もしお悩みの方がいらっしゃいましたら適宜この順番をご利用いただけると、或いは、もしかすると、偶然、良い感じになるかもしれないわけでございます。


ここで「…やっぱりguessルーチン自作した方が確実だし早いよなぁ」とか思ってはいけないわけであります…多分。