本格的に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アプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。
すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。
例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。
何故、セキュリティが分かり辛いのか?その一つ理由が「セキュリティ対策を行うべき部分 – 自分が作っている部分」と言う意識が足りないからだと考えています。
もっと読む
一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。
その間違いとは
です。(※0)
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サイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。
不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。
参考：エンジニア向けにもう少し解りやすいブログを最近書いています。
Linux Foundationは全面的にDrupalと呼ばれるCMSに移行したそうです。日本のLinux Foundationも当然、Drupalに移行しています。そこでLinux Foundationの小薗井さんから一度講師をして欲しい、と頼まれていました。PHPカンファレンスにいったので、その次の日の日曜日、9月6日の勉強会に参加してきました。
外国人の方が多い、と聞いていたのですが本当に外国人の方の割合が多かった。20名弱(?)ほどのうち4名くらい(?)は外国人の方、日本人の方(?)でも帰国したばかりで日本語がたどたどしいと言われている方もいました。とてもインターナショナルな感じで学生のころを思い出しました。
ユーザ会のURL: http://groups.drupal.org/japan
勉強会の様子は次のような感じです。
その時に使った資料を公開します。
テーマはPHPを使った安全なWebプログラミングの概要です。
クリックしてSecure-PHP-Programming.pdfにアクセス
かなり古い資料をリフレッシュさせたのですが、時代の流れを感じました。昔は「まあ、いいか」と判断していた部分も今でもは「絶対ダメ」になっていたりしました。とは言っても「Webアプリセキュリティ対策入門」はこれより新しく書いたもなので今でも十分通用します。ちょうど良い時期に出版したといえるのかも知れません。
資料にタイポや概要の説明であっても分かり辛い点と思える箇所などありましたら、ぜひ教えて下さい。
DrupalなどのCMSは興味の対象外だったのですが、NetCommonsといい個人的にはブーム(遅すぎ?)になっています。ToDoリストにやりたいことが山積みです…