今日話題になった Gumblar の亜種によって FFFTP の設定情報から FTP 情報が漏れる件で、FTP 自体の危険性と FFFTP 自体の特性、さらに Gumblar 対策という点で少し情報が混乱している状況が見受けられます。そこでその点を簡単にまとめてみました。 去年あたりから、「Gumblar （ガンブラー）」 に代表されるような、FTP のアカウント情報を何らかの手段で盗み出して Web サーバにアクセスし、Web サイトを改竄して被害を広めていくタイプのウィルスが問題になっていますが、今日になって広く利用されているフリーの FTP クライアントである 「FFFTP」 にアカウント情報漏洩の危険性が見つかったということで話題になっていました。 「FFFTP」のパスワードが"Gumblar"ウイルスにより抜き取られる問題が発生 ： 窓の杜 ただ、この問題で、FTP 自体の危険性
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
日本での最初の感染が通販サイトのGENOだったため、２ちゃんねるその他でそう呼ばれました。 このwikiでは2009年4～5月頃に話題となったウイルスを「GENOウイルス」と表記します。 （名前が名前なため、一般的には、攻撃元のURLより「Gumblar」と呼ぶことが多いようです。） これの何が怖いって、普通にホームページを見ただけで感染するから大騒ぎしたのです。 しかし、2009年5月、攻撃元がなくなったため、次第に事態は収束していきました。 2009年10～11月頃、「GENOウイルス」と非常によく似たウイルスが猛威を振るい始めました。 これはKasperskyのウイルスニュースより「Gumblar.X」と呼ばれています。 （似てはいるものの、基本的に「GENOウイルス」とは別物と考えてください。）
コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基本的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基本的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
以前、ITmedia Biz.IDでも紹介されていた、「Dropbox」 と 「TrueCrypt」 を組み合わせて Dropbox で扱うファイルを暗号化する方法ですが、周りでも結構仕事で Dropbox を使う人が増えてきたみたいですので、ここらでもう少し詳しく、この暗号化から同期して利用するまでの手順を紹介してみようと思います。 暗号化ソフト TrueCrypt は開発が終了し、公式サイトにおいて BitLocker への移行が推奨されています。 以前、ITmedia Biz.IDでも紹介されていた、2GB まで無料で使えるオンラインストレージ、「Dropbox」 と、フリーの暗号化ソフト、「TrueCrypt」 を組み合わせて Dropbox で扱うファイルを暗号化する方法ですが、私も DropBox 導入時からこの方法で一部のファイルを暗号化して同期するようにしています。 周りで
ある日，プロジェクトでチームリーダーを務めている高野氏は不測の事態に遭遇し，一人ひそかに青くなっていた… このプロジェクトは，あるユーザー企業で大規模Webアプリケーションの開発に取り組んできた。開発言語は「Ruby」，フレームワークとして「Ruby on Rails」（RoR），データベースには「MySQL」を採用。これをRed Hat系Linuxである「CentOS」上に配備して動作させる想定だ。 既に開発フェーズに入り，メンバー各自が社用PCにJavaの開発環境である「NetBeans」などをインストールし，開発作業を進めていた。OSは基本的にWindows XPで統一されている。しかしながら，開発環境はNetBeansだけでなく「Eclipse」や単なるエディタを使ったものなど，バラエティに富んでいる。 プロジェクトのキックオフから7カ月たった時点まで，プロジェクトの常としてある程
アクセス制御（アクセスせいぎょ、Access Control）は、対象へのアクセスを制御すること、また制御する仕組みである。 すなわち、対象（部屋・スマートフォンなど）へのアクセス（出入り・利用など）を制御する（鍵の持ち主のみ入室できる、スマホの持ち主のみ利用できる）仕組みである。部屋に入るための鍵/錠前や、スマホを利用するための指紋認証はアクセス制御の一例である。対象の特性から、物理セキュリティ、コンピュータセキュリティ、ネットワークセキュリティなどに分けられ、各々下記の意味を持つ。 コンピュータセキュリティにおけるアクセス制御とは、主体/subjectによる対象/objectへのアクセスを許可・拒否すること、またそれを実現する仕組みを指す。例えば人間やプロセス（主体）によるシステムやファイル（対象）への読み／書き／実行（アクセス）を許可・拒否することはアクセス制御である。 アクセス制御
(Last Updated On: )私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けにもう少し解りやすい
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
PHPにはHTTPセッション管理モジュールが標準で付いてきます。このセッションモジュールには非常に重大なセキュリティ上の脆弱性が修正されずに残っています。その脆弱性とはセッションアダプションです。 セッションアダプションとは、セッション固定化攻撃に利用される脆弱性です。PHPのセッション管理モジュールがセッションアダプションに脆弱であることは、かなり以前、何年も前から知られています。しかし、開発者の理解不足より脆弱性が放置されたままになっています。 セッションアダプションとは セッションアダプションとは、ブラウザ等から送信された未初期化セッションIDをそのまま利用してセッションを初期化してしまう脆弱性です。ユーザが送信してきたIDでも第三者に予想できない文字列であれば大丈夫なのでは？と考える方もいると思います。その通りで第三者に予想できなければ問題ないですし、仮に予想できてもログインする際
(Last Updated On: )追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。 PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。 セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。 セッションアダプショ
JavaScript を使った CSRF 対策の方法として、以前 Kazuho@Cybozu Labs で紹介されました。 CSRF 対策 w. JavaScript CSSXSS に対して脆弱でない CSRF 対策とはどのようなものか、という議論が続いているようですが、JavaScript を用いてよいのであれば、簡単な対策手法が存在すると思います。 ここでさらに一歩進めて、既存の FORM 要素に onsubmit 属性、および hiddenフィールドを直接追加せずに、JavaScript ファイルを１つインクルードすることにより、既存アプリケーションの書き換えをさらに少なくする方法を紹介したいと思います。 以下の JavaScript ファイルをHTMLの最後でインクルードする方法です。 fight_csrf.js sessid_name = ""; scripts = docume
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
