Tag: PHP

Posted on

PHPで数式画像が作れるライブラリ

これは綺麗な数式ですね。学生なら使い道あるかな？論文はLaTeXでそれ以外ならWordの数式エディタで作っていましたがウェブ公開用というのは今までなかったかも。多分現状の数式が載っている学校系のサイトはWordの数式エディタで作った数式を画像として出力してアップロードしているのような気がします。使い方もLaTeXで数式書いていた人には難なく使えそうですね。（細かいところは忘れますたが同じような書き方だったような気がします）。これの一番嬉しいことは数式をソースコードで定義できるから左記のWordで画像作ってアップロードみたいな面倒がなくなる事ですね。

PHPで複雑な数学式の画像が作れる「PhpMathPublisher」:phpspot開発日誌
http://phpspot.org/blog/archives/2009/01/phpphpmathpubli.html

PhpMathPublisher
http://www.xm1math.net/phpmathpublisher/

Posted on

Cookieを使ったSQLインジェクション

最近Cookieを使ったSQLインジェクションが発見されたということでその手法の詳細記事がありました。前置きが長すぎてもっと簡潔にして欲しかったのですが問題点は以下のようになります。

  • メジャーな侵入検知システムはPOST/GETの検査を行うがCookieを見逃していた。
  • スクリプト側でPOST/GET等メソッドを明示的に区別してデータ取得していない。
  • スクリプト側で入力データの検査が出来ていない。

元記事には

ここまで聞くと、「うちのサイトではクッキーにデータベースに関連するような情報は格納していないから関係ない」と、早合点する人もいるかもしれない。それは間違いなので、もう少しお付き合いいただきたい。

なんて書いてるからよくよく読んでみましたがCookie使う以前の問題で仕事でウェブプログラミングしているならその会社のスキルを疑って良いレベルです。PGのスキル不足は常にあると仮定してもレビューせずに素通りかPLが無能。PMが放置主義って言ってる様なもので会社でレベルで恥かいてるぞ。私ならこんな杜撰なコード組む会社に2度目の外注はしない。

まずコードの品質を上げる前に侵入検知システム等に頼るのは気が進まないし費用のムダ。これの方法の恐いのは侵入検知システム自体に穴がある場合だけでなく、サーバー移設等環境が変わった場合にミスが起きやすい。ニュースで「サーバーの設定ミスで情報漏えい」というケースがこれ。

次にデータ取得においてメソッドを区別していないのはCookie以前の問題でGETしか想定していないスクリプトでPOSTで渡されてもスクリプトのみでは同じ問題が起きるので注意すること。昔Perlで外部ライブラリなしでコーディングしているときは非常に面倒だと思いつつもどうやってデータがウェブサーバに送られてくるのか勉強になりました。今時よく利用されるASPやPHPはその辺の面倒な処理を自動的にやってくれて組込関数グローバル変数から読み込めますがRequest系の実装は気持ち悪くて使えない。未だにRequestについてGET/POSTを気にせずどっちでも使えるから便利とか発言するPGを見かけるが変数名が重複したときの対処方法を考えていないのが大半。セキュリティはともかくバグの元になる事を想定できていない。そういう人に限ってデバッガ未経験だったりする。

あとニュース記事には書かれていませんがPHPの場合、Requestでなくても$_POSTや$_GETのみで変数を上書きできるから注意ですね。通常リスト構造のデータを受け取るときは配列型にしたほうが便利ですが、それをせず同じ変数名で並べて送ってくるフォームがありそれにも$_POSTや$_GETは対応できないのでPerlの時のように素の入力データから抽出しています。それと同じ方法で本来の変数を上書きされても発見できない場合がありますので注意です。

最後に入力されたデータを検査していないのは論外、今回のセキュリティホールもPOST/GETを想定した変数だとしてもスクリプト側で検査していれば問題になっていない。メソッドを明示していればCookie経由で上書きしようとした変数はその場でイジェクトできるし、Request受けていてもそのデータを検査できていれば良いのである。とは言っても現実はApacheエラーログを見ずに組む人が多い、サニタイズどころかValidateやisset検査すらせずにエラーログを汚しまくる奴もいる。指摘するとErrorじゃなくてWarningだから大丈夫だろうとか言葉を理解できていない人やErrorじゃ無いんだからサーバー側でログ出力止めろよ！と逆ギレする民度の低いPGも少なからず存在する。そういうのに限ってこれまたPHPはPerlと違ってセッション実装できているから凄いとか内部処理を知らずに自慢(それもPHP作った本人じゃないのに)していたことがあって呆れたこともあります。

以上で愚痴込みのまとめは終わりますが、元記事を見てハッと気付いた脅威が一つありました。
最低限の作業として送られてくるデータは特定して検査するように書いているつもりですが、セッション変数はサーバーに保存されているデータなのでそこまでは強制的に検査していませんでした。(ヒマがあればするけれど他人にまで強制していない)

これの何が原因かというと、一度送られたフォームデータ(特にショッピングカート等)は途中ページでの改ざんを防ぐ為にセッション変数として保持することがありますが、保存したセッション変数からデータを再取得するときに検査をしていない場合がありました。近年はCookieに値セットして使うことが無いので完全な見逃しですが、Cookieを改ざんされた時に$_SESSIONが自動的に汚染されないか確認したことが無かった・・・。これは週明け直ぐにでもチェックしてみます。

他にDBとの入出力に対しての検査も、最初はそこまでする必要あるのかな？と思っていましたが仕事で使う内に必須だと思うようになりました。セキュリティ的には外部と接触する部分で一斉検査すれば大体良いのですが、開発途中でDBのデータがいい加減に入力されているとか仕様外の構成になっていたりするとが多く、というかほぼ100%でデバッグの障害になってたりもします。これでPGとDBエンジニアが鶏が先か卵が先かみたいなケンカもします。そこでスクリプト側としてはDBとの入出力にも開発効率を上げるために検査を入れておいたほうが良いと思います。あとApache管理者の意見として、大量のUndefined indexでログを汚すなというのもあります。

またまた進化したＳＱＬインジェクションの脅威　クッキーを悪用 セキュリティー-最新ニュース:IT-PLUS
http://it.nikkei.co.jp/security/news/index.aspx?n=MMIT2g000028102008&cp=1

Posted on

PHPにPDOを実装

最近PHPの開発でDB接続にPDOを使用する機会が増えてきました。PDOとはPHP5.1以降に登場したPHP Extensionで従来のmysql等の代わりに使えるライブラリらしいです。ということは従来のmysql関数群は無くても良いということかな？それは余ったサーバでも捜して試してみるかな。またPEAR::DBのようなスクリプトのラッパーではなくネイティブコードなのでパフォーマンスの低下も少ないというメリットもあるそうです。その他既存のデータベース関数と比較すると抽象化しているのでなんたら…とPDOの中身はまだ勉強してませんがｗ

ソースからのインストール方法は./configureで–with-pdo-mysql=/usr/local/mysqlという風に追加すれば大丈夫のようです。 ググっても–with-pdoは省略されているので無くて大丈夫っぽい。

因みに、既存環境でPDOを追加インストールするのは過去にやってエントリー書いてますのでそちらを参照ください。

PHPにモジュールを追加　(ここでPDOを追加インストールしています)

そういえばmbstringやmysqlもExtensionでしたね。そうすると全くExtensionなしのPHP関数の一覧ってどんなものなんだろう？今後は使う関数がどのライブラリに属しているか気にしたほうがよさげですね。PHPリファレンスもライブラリを調査して明記してくれると大変ありがたい。PHPがdisられているときに関数の銘々規則がめちゃくちゃなんて書かれていましたがExtensionの開発者のクセがそのまま乗っかってるとかそんな気がしてきた…。

参考：PDOでサクサクDB開発：CodeZine
http://codezine.jp/a/article/aid/433.aspx

参考：PHP 5.1インストール
http://w-d-l.net/memo/vinelinux_ppc/12_php/