カテゴリー: Security

出力文字エンコーディングのバリデーション

前のエントリで「書かない日記」の名前通り、出力文字エンコーディングのバリデーションについてあまりに書かなさすぎで何の事やら分からない方も居たと思います。もう少し詳しく書きます。出力バッファとエラーハンドラで出力文字エンコーディングを簡単にバリデーションできます。 もっと読む

Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由

Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは?と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 もっと読む

glibcの脆弱性で大量のメモリが割り当てられる – セキュリティ専門家は基盤ソフトウェアに期待させてはならない

最近この種のエントリがありませんでしたが、個人的に面白いとセキュリティ系の話題はできるだけ書いていきたいと思っています。

glibcのstrfmon関数の実装に脆弱性があり、簡単なスクリプトで大量のメモリが割り当てられる脆弱性があるようです。影響するglibcは2.10.1以下なので影響範囲は非常に大きいです。

最初はBSDのlibcで脆弱性が発見され、glibcでも影響があることは脆弱性の発見者には分かっていたようです。詳細はアドバイザリに記載されています。

http://packetstormsecurity.org/0909-advisories/glibc-format.txt

参考:セキュアプログラミングの7つ習慣

もっと読む

Flashのバージョン – このブログの閲覧者の半分は脆弱…

フラッシュのバージョンチェックが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アプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。

すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。

例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。

何故、セキュリティが分かり辛いのか?その一つ理由が「セキュリティ対策を行うべき部分 – 自分が作っている部分」と言う意識が足りないからだと考えています。
もっと読む

PHP6移行で増える脆弱なWebアプリ

PHP6のリリースはまだまだ先の話なのですが、PHP6への移行で脆弱なWebアプリが大量に発生する可能性があります。

理由は2つ

– mb_check_encodingで全ての入力文字エンコーディングが正しいかチェックしていない
– PHP6のhtmlentities/htmlspecialcharにはマルチバイト文字チェックコードが削除される

PHPのコードを書いている人も自覚していないと思いますが、この影響はかなりあると考えられます。

近日中にgihyo.jpのセキュリティブログに詳しい情報を記述します。

追記:PHP5.3のコードを見てみたら、バックポートすべきではないのにバックポートされてました。つまり、PHP6がリリースされたらと言う問題ではなく、今ある問題になっています。一応、改修を提案するつもりですがどうなるか判りません。

追記2:結構、ページビューが多いですね。心配される方もいるかと思いますが、「Webアプリセキュリティ対策入門」やgihyo.jp等で書いているように、mb_check_encodingで文字エンコーディングチェックしていれば影響は受けません。

追記3: 前に読んだ時は斜め読みだったので、もう一度コードをよく見てみると一応必要そうなチェックは入っています。決めうちしているのは別の部分だったので対丈夫でしょう。

デブサミ200 優秀スピーカー賞

今年のデブサミにはパネルディスカッションのパネラーの一人として参加していたのですが、そのセッションが優秀スピーカー賞に選ばれました。

デブサミらしく(?)表彰状はGoogle Docsで送られてきました。

優秀スピーカー賞

パネルディスカッションを仕切った竹迫さんの戦略勝ち、という方が良いと思います。何はともあれ表彰して頂けてありがたいです。パネラの皆さん、またどこかでご一緒しましょう。

第01回 STLUG & セキュリティうどん勉強会 (5/17)

ブログ更新を随分していませんでした。リハビリに軽い物から再開したいと思います。

第01回 STLUG & セキュリティうどん勉強会が今月17日に香川県高松市で行われるそうです。

http://atnd.org/events/556

私も参加します(と、いうよりしたい)

OpenIDプロバイダー対応のアカウントを持っていれば何方でも登録できるようです。まだ、セミナー/懇親会共に空きが十分あるので、都合が良い方は是非どうぞ。

Flashのセキュリティ設定 – Flash Cookie

Flash Playerの設定はAdobe(Macromedia)のページで行う事は、Web開発者には常識だと思います。このブログをあまり一般的なユーザが見ている、とは思えませんが一般ユーザ向けに書いています。

Flashの設定は以下のWebページから行います。

Flashセキュリティ設定のページ(MomongaLinux x86_64+Flash10 Alpha)
Disable Flash Cookie
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html

デフォルトで「サードパーティ製のFlashコンテンツにコンピュータ上のデータを格納する事を許可します」にはチェックが入っています。

これはFlash Cookie(ローカル共有オブジェクト – SharedObject)とも呼ばれているFlash用のローカル(ブラウザを実行しているPC)ストレージです。ブラウザのクッキーはたったのサイトあたり4KBしか利用できませんが、Flashはデフォルトで100KBまで使えます。
もっと読む

「ハッカー」に逆襲、パスワード盗み返す 中3書類送検

今年、流行するだろうと予測していることに、素人によるWebアカウントのクラックが増える、があります。

少年はゲームの動きが悪くなったことからキーロガーに気づき、ソフトを解析。操作の履歴の送付先になっていた男性のメールアドレスやID、パスワードを割り出したという。

http://www.asahi.com/national/update/0205/NGY200902050001.html

キーロガーを送りつけられ、それに気づいた中学生が犯人を割り出して、逆にクラックした事件だそうです。加害者でもあり、被害者でもあるクラッカーは気が付かなかったようなのでスクリプトキディーだとしてもなかなかのものです。

Webアカウントのクラックはもっと簡単です。パスワードが盗めたり、セッションが盗めるサイトは多数あります。パスワードは結構簡単にクラックできます。例えば、md5でハッシュ化しているパスワードで小文字アルファベットと数字だけ(1-8文字)

abcdefghijklmnopqrstuvwxyz0123456789

の辞書サイズはたったの36GBです。(単純にハッシュ化したデータを保存している訳ではないので解析できる可能性は99.904%) オンラインで巨大な辞書(レインボーテーブル)を公開しているサイトもあるので自分で辞書を作る必要もありません。

この少年がWebアカウントでなくWindowsアカウントですが、関連事例として書いておきます。

関連: http://blog.ohgaki.net/2009

In Session Phishing

In Session Phishingという興味深いアドバイザリが公開されています。

具体的な記載はありませんが、現在広く利用されているInternet Explorer, Firefox, Safari, ChromeでJavaScriptを利用するとユーザが特定のサイトにログインしていたか判別できるようです。

Recently Trusteer CTO Amit Klein and his research group discovered a vulnerability in the JavaScript engine of all leading browsers – Internet Explorer, Firefox, Safari, and Chrome – which allows a website to check whether a user is currently logged onto another website. The source of the vulnerability is a specific JavaScript function. When this function is called it leaves a temporary footprint on the computer and any other website can identify this footprint. Websites that use this function in a certain way are traceable. Many websites, including financial institutions, online retailers, social networking websites, gaming, and gambling websites use this function and can be traced.

ユーザが訪問したことがあるサイトを検出する方法はあります。訪問済みのURLは色が変わることを利用して検出します。マーケティング目的で実際に利用されています。しかし、この方法ではユーザが実際に今ログインしているかどうかは判別できません。アドバイザリによると、ログインしているかどうか判別できる足跡が検出できる、としています。

自分がサイトにログインしている最中に「現在、攻撃されている可能性があるので再ログインをしてください」とメールを送ればより効果的なフィッシングが行えます。

もうしばらくすれば詳細が明らかになるかも知れませんが、最近のブラウザ全てに影響するようなのでJavaScriptやDOMの仕様に関係する問題の可能性が高いです。その場合は簡単に修正できない可能性がかなり高いのではないかと思います。

フィッシングでなくてもマーケティング目的で利用されそうな気もします。

PHP4.4.9のセキュリティ状態

PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。

PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。

もっと読む

エンティティ化された文字による任意コード実行

小泉さんが発見され昨年末に公開された脆弱性です。詳しくはアドバイザリをご覧いただくとして概要を解説します。

CVE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-5557

アドバイザリ
[Full-disclosure] CVE-2008-5557 – PHP mbstring buffer overflow vulnerability

かなり特殊な設定といえる状況で問題となるようですが、ちょうどgihyo.jpで文字エンコーディングに関連したセキュリティ問題を解説しているので紹介します。

http://gihyo.jp/dev/serial/01/php-security/0019
http://gihyo.jp/dev/serial/01/php-security/0020

もっと読む

現行版のPHPに任意メモリ参照バグ – 攻撃コード付き

随分前から共有型Webホスティングサービスでは安全性を確保できないので、安全性を重視するサイト(ECなど)は最低限でも仮想ホスト型の共有サービスを利用すべきである、と言っています。

今回のエントリはPHPをApacheモジュールで共有型ホスティングサービスを利用しているユーザに影響します。SSLを利用している場合は秘密鍵を盗まれます。このバグはPHP 5.2.8でも修正されていません。当然ですがPHP 4.4.9でも修正されていません。
もっと読む

パスワードハッシュはsaltと一緒にハッシュ化する

このタイトルにするとsaltとは、という議論をもう一回する事になるのかもしれませんが、最も近い用語はsaltだと思うので、saltを用語として使います。

随分前からパスワードハッシュはユーザが提供したパスワードと、システムが保持している秘密のランダム文字列と一緒にハッシュ化する方がより安全である、と言っていました。異論がある方もいらしたのですが、どうしてより安全となるのか、場合によっては比べ物にならないくらい安全になるのか、良く分かるビデオを見つけたので紹介します。
もっと読む