この本は今年のPHPカンファレンスで景品として頂いた本です。
CakePHPと言えば「CakeMatsuriTokyo2009」が10/30, 10/31に開催されます。興味がある方、CakePHPによるWeb開発にさらに磨きをかけたい方は参加されてはどうでしょうか?
この本は今年のPHPカンファレンスで景品として頂いた本です。
CakePHPと言えば「CakeMatsuriTokyo2009」が10/30, 10/31に開催されます。興味がある方、CakePHPによるWeb開発にさらに磨きをかけたい方は参加されてはどうでしょうか?
本格的にSubversionからGitへの移行を行った際に作ったGit+SSHサーバの手順をWikiに書きました。この手順を実行すると
ができるようになります。
詳しくはWikiのgit sshサーバの構築をご覧下さい。
Subversionの頃はWebDAV+SSL+Basic認証だったので以前と比べればかなり認証の安全性は増したと言えます。
PHP 5.2.11用のStrict Session Patchを公開しました。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
これが無いとセッション管理が面倒です。 どう面倒なのかは既に何度も書いているので省略します。(本当は面倒なだけではないのですが.. )最新リリースの追随がいつも遅れているので、もし作った方は送って頂けると助かります。
もし問題を発見した場合は教えて下さい。直します。
このパッチを使っているサイト例はこのブログです :)
PHPが文字エンコーディング攻撃に比較的強い理由は入出力の文字エンコーディングのバリデーション(サニタイズ)が行えるだけではありません。PHPが提供するHTMLエスケープ関数が文字エンコーディング攻撃に対して強い事も理由の一つです。
PerlでHTMLエスケープと言えば、<,>,&,”,’をエンティティ変換するコードが一番に見つかります。
「perl html escape」でググると一番に見つかったページは次のページです。このページではまだ3バイトEUCの場合の例、CGIモジュールを使った例も載っているので良い方でしょう。
http://saboten009.blogspot.com/2008/04/perlhtml-xss.html
少し前にPerl, Ruby,Pythonユーザは検索で有用なセキュリティ情報を得られるのか?と疑問に思い調べました。これだけ知っていれば取り合えず十分というページはそう簡単には見つかりませんでした。
いつも問題になるのは PHP だけど Perl は問題ないのか、すでに議論し尽くされた問題なのか、PHPer のモラルが低いせいか。
Perl,Ruby, Pythonで議論し尽くされ対策が浸透している、とは到底思えません。Railsで文字エンコーディングを利用したXSS脆弱性が話題になっていることからも明らかです。PHPがいつも問題になるのはよく使われていて、初心者も多く、公開されているWebアプリも圧倒的に多いからです。モラルの問題ではありませんし、このページで紹介されているPerlのエスケープ方法だけではPHPのhtmlentities()やhtmlspecialchars()よりも脆弱です。文字エンコーディングを考慮するようになっていないからです。 (さらに…)
恒例の「オープンセミナー2009@徳島」が10/3(土曜)に開催されます。毎年パワーアップしている無料セミナーです。徳島近郊の方は是非ご参加ください。転載自由です。興味がある方へお知らせ、転送頂けると助かります。
追記:懇親会費が変更されました!4000円→4500円です。ご注意ください。
Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリをまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは?と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 (さらに…)
Twitterで書いた方が良いようなエントリですが、たまには良いでしょう。
#perl – utf8::decode()ではなくEncode::decode_utf8()を使うべき理由
という記事がありました。PHPにも似た関数、utf8_decodeがあります。PHPでも使ってはなりません。日本人というよりマルチバイト圏で使っている人はほとんどいないはずです。理由はコードを見れば一目瞭然です。 (さらに…)
最近この種のエントリがありませんでしたが、個人的に面白いとセキュリティ系の話題はできるだけ書いていきたいと思っています。
glibcのstrfmon関数の実装に脆弱性があり、簡単なスクリプトで大量のメモリが割り当てられる脆弱性があるようです。影響するglibcは2.10.1以下なので影響範囲は非常に大きいです。
最初はBSDのlibcで脆弱性が発見され、glibcでも影響があることは脆弱性の発見者には分かっていたようです。詳細はアドバイザリに記載されています。
http://packetstormsecurity.org/0909-advisories/glibc-format.txt
お願い: 特定のページが文字化けする問題があります。一応確認したのですが残っていた場合、教えてください。(追記:恐らく「ツール」-「いろいろ」-「Delete pre-renderered item cache.」でキャッシュを削除すると文字化けしなくなると思います。これからアップグレードする人は試してみて下さい)
b2evolutionというマイナー(?)なブログアプリを使っています。しばらく、アップグレードを怠っている間にサポート対象のバージョンでは無くなっていたので連休を機会にアップグレードしました。b2evolutionを選択したのは当時入力のバリデーションをしていたブログアプリはこれしか無かった事が理由です。
2.4.xの最終版から3.3.1にバージョンアップしました。非常に簡単でいつもの通り、新しいバージョンのファイルを上書きしてインストールスクリプトを動かしアップグレードを選択するだけです。データが多いと変換に長い時間がかかります。気長に待ちましょう。念のためにphp.iniのmax_execution_timeの設定を確認しておいた方が良いでしょう。変更不可能に設定されている場合、アップグレードに失敗する可能性があります。
このバージョンでは気になっていた部分が改善されているようです。ユーザビリティもWYSIWYGエディがが付いたり最近のブログらしくなっています。細かい機能アップは非常に便利です。画像の場所がエントリの先頭に固定であることを除けば、画像サイズの自動調整も入ったようで、写真や画像を貼る人には便利になっています。添付ファイルも同じようにエントリに添付として付けると先頭にリンクを表示してくれるのではないかと思います。
日本語周りはそのまま利用するには問題が多かったのですが、動作をみる限りでは随分よくなったようです。現状のステイブル版(3.3.1)をインストールして基本の設定ファイル(conf/_basic_config.php)を通常通りに設定すると同時に、ロケールファイル(conf/_locale.php)を少しだけ修正して使っています。ロケールファイルの修正は文字エンコーディング設定を全て”utf-8″に設定しただけです。
この為、もしかすると問題が発生するかも知れません。もし、文字化けなどの問題に気がついた方がいらしたら教えていただけると助かります。
余裕がなくて日本語化を全くしないで使っていましたが、今回は日本語ファイルも入れました。
http://blogs.da-cha.jp/momokuri.php/2008/10/13/b2evolution_2-4-5_japanese_message_trans
en-USロケールがデフォルトにしていますが、ja-JPロケールファイルを見てくれるようです。三浦さん日本語ファイルありがとうございます。
b2evolution 3.3は編集が便利になっているので日本語さえキチンと使えればアップグレードする価値はあります。問題は日本語が問題なく使えるか?ですが、まだテストできていません…
追記:
ブラウザの言語設定によってはいつもの、おかしな文字化けが発生するようです。言語設定を色々替えて試してみました。特に問題はないようです。文字化けしている、と勘違いしたのはバリデーションサービスの方の問題でした。コメントからメールを送信してみましたがコンタクトやフィードバックはutf-8で送信しThunderbirdでは読める形で送ってくれました。一応、日本語環境で使う為に大きな不自由はない状態にはなっているようです。
随分長い間放置していた、Linux版Firefoxではテキストボックスとテキストエリアが大きくなる理由を調べてみましたが、Linux版では一文字の幅を全角で計算しているようです。この為、テキストボックスとテキストエリアのcols等の文字数で指定すると横幅が倍になるようです。これ、FAQだったような… Googleの検索ボックスはスキンのCSSで強制的に横幅を設定してしまいましたが、テキストエリアの出力はスキンではないので修正するかどうか迷っています。プログラムの出力を修正するとバージョンアップの度に修正が必用となるからです。
フラッシュのバージョンチェックがFirefoxに追加されました。ようやくと言う感じです。MozillaプロジェクトよりAdobeがもっと頻繁にバージョンアップのチェックを行うようにすべきだと思います。 脆弱なWindowsXP, Flash, PDFは攻撃対象の三種の神器と言っても良い(?)くらい攻撃対象になっています。 久しぶりにこのブログの読者がどれくらい新しいFlashを使っているのか、Google Analyticsで見てみました。
半分くらいは脆弱です… 皆さん、FlashとPDF(PDFも忘れずに!)のバージョンアップをしましょう。 Firefoxを使っている方、IEの方のFlashのアップデートもお忘れなく。一緒にアップグレードされません。過去にFirefoxからIEの脆弱なFlashを悪用する攻撃もありました。使っていないからと言って安心出来ません。
フラッシュのバージョンチェック
http://www.adobe.com/jp/support/flashplayer/ts/documents/tn_15507.htm
フラッシュのアップグレード
http://get.adobe.com/jp/flashplayer/
アプリケーション開発者がセキュリティ対策を行うべき部分とはどこか?当たり前ですがアプリケーションです。アプリケーションとは広い意味でのアプリケーションです。Webアプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。
すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。
例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。
何故、セキュリティが分かり辛いのか?その一つ理由が「セキュリティ対策を行うべき部分 – 自分が作っている部分」と言う意識が足りないからだと考えています。
(さらに…)
9/12はオープンラボ岡山の日です。オープンラボとは勉強会の名前です。
今回のフマートフォン特集で私は「知っててあたり前 – モバイルセキュリティ」をテーマに話します。携帯開発をしている人にはあたり前の話が多いと思いますが、それ以外の小ネタも混ぜるつもりです。
参加登録
http://openlab.okaya.ma/wiki.cgi?page=%CA%D9%B6%AF%B2%F1%2F%C2%E8003%B2%F3
勉強会
http://openlab.okaya.ma/
Twitter ハッシュタグ #OLO
Androidの開発環境を作っとかないと…
私が4年前(2005年)に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは?とヒヤヒヤしたので良く覚えています。
不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。
参考:エンジニア向けにもう少し解りやすいブログを最近書いています。
https://blog.ohgaki.net/reason-why-char-encoding-validation-is-mandatory