今も新規開発され続けるPHP 4アプリケーション - ockeghem's blog
この日記をご覧の方には先刻ご承知のことだろうが、去る7月13日に、PHP 4のEOL(End Of Life)アナウンスが公式に宣言された*1。 これによると、PHP 4のメンテナンスは2007年12月31日まで、重大なセキュリティホールへの対応も2008年8月8日までとなっている。このため、既存の膨大なPHP 4アプリケーションのマイグレーションをどうするかは大きな課題である。 ここまでは皆さんご存知の情報であろう。 しかし、PHP 4アプリケーションは今も開発され続けている。私がそれを知ったのは、Webアプリケーションの脆弱性診断をしているからである。診断にてPHPなどの脆弱性を発見した場合はこれまでも都度報告していたが、2007年7月13日以降は、PHP 4を使っているだけでも、(脆弱性ではないが)上記情報を報告し、PHP 5への移行を推奨してきた。そういうレポートを書く際には、「き
火星に到着したスピリッツの探索機が密かに仕組まれたバックドアのおかげで息を吹き返したオハナシ
素敵だ・・・ 火星着陸時の衝撃で地上探索機搭載のコンピュータのフラッシュメモリのファイルシステムが壊れたのでOS再起動の永遠の繰り返しになってしまった。起動するとフラッシュメモリのエラー検知をして再起動・・・。地球からのコマンド送信しての通常の初期化起動も無効になるし万が一のための最低限モードによる起動指示もきかない。対策のために何日も全スタッフは24時間苦しんだんだって。ところで起動ってエネルギー食べちゃうんだよね。起動直後にそれまでの活動履歴を地球に送信する仕組みなんだけど電波出し始めて履歴がはいっているフラッシュメモリの中身を検索すると落ちる。これの繰り返し。クソデータにみちた電波のたれながしが繰り返されてエネルギーが減っていく・・・そうこうしているうちに太陽光による発電とバッテリーとのつりあいがとれなくなってエネルギーの完全な不足になり瀕死状態に。極寒の夜がくれば耐えられないかもし
IEにおけるEUC-JPの処理方法でShift_JISがからんでくる件 - hoshikuzu | star_dust の書斎
http://d.hatena.ne.jp/hoshikuzu/20071018#p1 の続編。（私の中ではこちらを先に気がついたのですけれど。） Fileを読めるADODB.Streamを使って検証してみようというオハナシです。 16進の[0x8FD9EA59]というデータをもったテキストファイルを作成し、ローカルに保存します。これをADODB.streamで読ませます。読ませるにあたって、バイナリではなくテキストモードとし、エンコードを、EUC-JPとして指定したり、Shift_JISとして指定したりして、読みこんだ結果、ADODB.streamがそれを、どんなUnicodeとして解釈しているかを見ようというわけです。 Shift_JISとして読ませますと次のようになります。 [0x8FD9EA59]を、[0x8FD9]+[0xEA59]として２バイトずつに区切って理解し、Shift_
高木浩光＠自宅の日記 - ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する
■ ユビキタス社会の歩き方(5) [重要] 自宅を特定されないようノートPCの無線LAN設定を変更する 昨日の日記を書いて重大なことに気づいたので、今日は仕事を休んでこれを書いている。昨日「最終回」としたのはキャンセルだ。まだまだ続く。 目次 Windowsの無線LANはプローブ要求信号として自動接続設定のSSIDを常時放送している Windowsの新たな設定項目「このネットワークがブロードキャストしていない場合でも接続する」をオフに Windowsの無線LANが放送するSSIDからPlaceEngineで自宅の場所を特定される恐れ 電波法59条について再び Windowsの無線LANはプローブ要求信号として自動接続設定のSSIDを常時放送している 昨日の日記の図3で、probe request信号の例としてSSIDが「GoogleWiFi」になっているものを使った。これは昨日キャプチャし
Don'tStopMusic - Rails のセキュリティガイド , RubyGems が Ruby 1.9 でテストが通ったようです
_ [Rails] Rails のセキュリティガイド QuarkRuby: Ruby on Rails Security Guide では、Rails でアプリを開発する際にセキュリティ面で気を付けなければいけないことを簡潔にまとめています。 いま社内向けに Rails のセキュリティガイドラインをまとめているので参考になります。上記のページに、OS コマンドインジェクションとセッション固定化、HTTP ヘッダインジェクションを追加すれば一般的な脆弱性は大体カバーできますね。 なお、Rails のセキュリティについて興味のある方は、前田さんのWebアプリケーションセキュリティフォーラム発表資料は必読です。 追記 自分の備忘録として脆弱性に関してまとまった情報があるサイトや資料を挙げておきます。 QuarkRuby: Ruby on Rails Security Guide : 簡潔な一覧
世代交代が迫る「暗号技術」（前編）
ポイント ・2010年に米国政府の標準暗号技術の一部が切り替わる ・暗号技術には，安全性を保てなくなるという“寿命”がある ・「標準」規格の切り替えに備え，基本の仕組みを理解しよう Webシステム，顧客管理システム，文書管理システムなど，企業において暗号技術はさまざまなシステムで利用されている。今や暗号技術は，情報システムを支える重要な基盤技術の一つである。 その暗号技術において，「2010年問題」と呼ばれる大きな変化が待ち受けている。引き金となるのは，米NIST（国立標準技術研究所）。米国政府が調達するシステムで使う暗号技術の規格を定めており，現在一般に広く使われている「SHA-1」というハッシュ（元になるメッセージを縮めて容量の小さな値を作ること）の規格を2010年に除外し，より安全性の高い「SHA-2」だけにすると発表した（図1）。 暗号技術でNISTは世界的に影響力を持っているので
「サニタイズ言うな」の先駆け? - ockeghem's blog
昔の投稿記事などを整理していたら、2001年に日経オープンシステム誌(この雑誌も今はないが)に投稿したWebアプリケーションセキュリティの寄稿が目に止まった。古い記事なので、「今だったらこうは書かないよなぁ」という部分もあるし、「ずいぶんと気負いこんで書いているな」という部分もあったが、その中に「サニタイズ言うな」と関連する内容が合ったので、引用として許される範囲で紹介したい。 「危険な文字の除去」は簡単だが推奨できない このクラッキングの回避策としてまず思い付くのは，「危険な文字を削除する」というアプローチである。SQLの場合に「危険な文字」となるのは前述のシングル・クオートであるから，この文字さえ削除してしまえば，SQL改ざんのクラッキングは不可能になる。任意の文字列からシングル・クオートを取り除くプログラムの例を図3に示した。 一般にこの種のテクニックはインターネットでは広く利用され
Web 2.0的アプリのセキュリティ：再考「機密情報にJSONPでアクセスするな」｜アークウェブのブログ
SEの進地です。 2007年1月に投稿した「Web 2.0的アプリのセキュリティ：機密情報にJSONPでアクセスするな」は多くの方にお読みいただきました。誤りも指摘され、元エントリーに改修を加えましたが、かなり読みづらい状態になってしまっています。また、JSON、JSONPのセキュリティに関する新たな話題もSea Surfers MLで議論されているのを読み、自分自身の認識や理解も変化しているので、このエントリーでもう一度JSON、JSONP（+JavaScript）に機密情報を含めることの是非と方策を整理、検討したいと思います。 ○JSON、JSONP、JavaScriptによるデータ提供時にセキュリティ対策上留意すべき特徴 JSON、JSONP、JavaScriptによるデータ提供時に留意すべき特徴としてあるのが、「クロスドメインアクセス可能」というものです。JSONPだけでなく、JS
荻上式BLOG - 騙しサイトで表示される「個人情報を取得しました」画像を集めてみた
アダルトサイトっぽいページでリンク先に飛ぼうとすると、「個人情報を取得しました→登録が完了しました→何日以内に払え、払わないと通報」的な画像が表示されることがよくあります。ソーシャルブックマークなどでセルクマしてランキング操作しているサイトもあるので、知らずに訪れて焦ってしまう方も少なからずいるのでは。 しかし、それらの画像のほとんどはただの gif 画像。「請求の 正体見たり gif 画像」ということで、さっさとページを閉じ、サイトの URL を検索してみるとかが吉かと。 ところでそれらの画像って、マジマジと見ると大抵マヌケな感じがしてほほえましい。今までも当サイトで何度か取り上げたのだけれど、他にもそういう画像がないかと釣りサイトを巡ってみた。というわけで、以下ではそれらのサイトから収集した gif 画像を紹介します。画像をクリックすると、それぞれの画像を単体でみれるよ。再生が一回で終
仙石浩明の日記: chroot されたディレクトリから脱出してみる
要約すれば、 「chrootなんて簡単に抜けられるからセキュリティ目的で使っても意味ないよ。」 ってことね。そうだったのか。 そうだったのか orz Note that this call does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'. chroot するときは、そのディレクトリへ chdir しておくのが常識と 思っていたので気づいていなかった。 つまり、 故意にカレントディレクトリを chroot 外へもっていけば、 chroot された
徳丸浩の日記 - mod_imagefight考 - 画像版サニタイズ言うな
SQLインジェクション対策はおすみですか? 開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、 脆弱性発見後の適切な対策まで ● 画像版サニタイズ言うな しばらく前から、竹迫さんのイメージファイト(mod_imagefight)が、第10回セキュリティもみじセミナーなとで発表され話題になっていましたが、LL魂で発表されたプレゼン資料が公開されましたので、私もようやく内容を見させていただきました。 先日、PHPの攻撃コードが隠された画像ファイルが、大手ホスティングサイトで発見されたとの報道がなされました。GIF,PNG,JPEG,BMP形式の画像ファイルには、PHPのRFI攻撃で使用されるコードやJavaScriptのソースなどを埋め込むことができます。画像に埋め込まれた攻撃コードと戦う5つの方法について解説し、安全な画像アップローダの実装について考察します。
Secure Login で素早く安全にサイトにログインする | Lifehacking.jp
Speed up and protect your logins with Secure Login | Lifehacker Lifehacker で紹介されていて初めて知った Firefox のアドオンです。Opera の杖アイコンと同じ機能を実現して、パスワードの入力を安全に、素早く行うことができます。 ページが開くと同時にパスワードを挿入してくれるだけのパスワードマネージャに任せていると、Javascript 経由でパスワードを盗むことが可能だという話ですので、こうした一手間を便利にやってくれるアドオンがあるのは頼もしいですね。 このアドオンをインストールすると、ログインフォームが黄色に囲まれて、パスワード入力欄が存在することを示します。このとき鍵のアイコンをクリックするか、設定したショートカットを押せばパスワードが入力され、自動的にログインできます。複数のパスワードが保管されてい
RSSで任意のドメインに誘導されてしまう脆弱性 | 水無月ばけらのえび日記
「tDiaryの脆弱性に関する報告(2007-07-23) (www.tdiary.org)」……って、これ、えび日記のRSSが脆弱という話とまるっきり同じですね。RSSが変だと指摘されて……という流れまで全く同じです。 そういえば脆弱性の詳細を書くと言いつつ全く書いていなかったので、深く反省。改めて書いておきます。 えび日記の RSS の脆弱性についてこの「えび日記」は RSS 1.0 のフィードを生成していますが、そのフィード中の URL のドメインを任意のものに変えられてしまうという脆弱性がありました。 RSS の中では絶対 URL が必要になりますが、Web アプリケーションが自身の「正しい」絶対 URL を知るのは意外に難しいのです。たとえば ASP.NET の場合、Request.Url の値を取ると現在の URL が分かるのですが、このとき、ドメインは単にリクエストの Hos
葉っぱ日記 - レジストリの HKCR￥MIME￥Database￥charset 以下に定義されています。
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
Greasemonkey スクリプトは安全ではありません
■ Greasemonkey スクリプトは安全ではありません Webアプリケーションセキュリティフォーラム の奥さんと高木先生のバトルより。 高木先生 ええと、「クッキーが漏洩する程度なので問題ない」と聞こえたような気がしたんですが。 Greasemonkey には超絶便利な GM_xmlhttpRequest があるので、どのウェブサイト上でスクリプトを動かそうが、あらゆるサイトにアクセスする事が可能です。この観点から考えると、クッキーが漏洩するどころの騒ぎではありませんし、スクリプトを有効にするドメインが限られていた所で大した意味はありません。例えば Google Search を便利にするようなスクリプトに、mixi のパスワードを任意の値に変更させるようなトロイを仕込む事も難しくないでしょう(実際に作って試しました*1)。もちろん対象サイト上に、XSS や CSRF の脆弱性がなく
はてな足あとちょう - ぼくはまちちゃん！
☆よみこみ中だと思うよ！ ５分くらいまってね！ http://d.hatena.ne.jp/hatenadiary/20070711/1184149449 http://s.hatena.ne.jp/ http://d.hatena.ne.jp/hatenastar/20070711/1184152733 http://d.hatena.ne.jp/hatenadiary/20070711/1184149817 http://d.hatena.ne.jp/Hamachiya2/20070711/star http://s.hatena.ne.jp/guide http://d.hatena.ne.jp/hatenastar/20070711/1184149175
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Momonga-devel.ja:03550] RFC: デフォルト文字エンコーディングの取扱いについて
http://www.machu.jp/posts/20071023/p01/
http://www.tietew.jp/articles/2007/02/07/misunderstood-html-escaping
mixiのユーザーのプロフィールを外部へ持ち出し、データベース化するシステムは作成可能*ホームページを作る人のネタ帳
