IPA（独立行政法人情報処理推進機構、理事長：西垣 浩司）は、ウェブサイトのセキュリティ対策を推進するため、「情報システムを安全にお使いいただくために」及び「ウェブサイト構築事業者のための脆弱性対応ガイド」を含む報告書をとりまとめ、2009年6月8日から、IPAのウェブサイトで公開しました。 本報告書は、「情報システム等の脆弱性情報の取扱いに関する研究会」（座長：土居 範久　中央大学教授）において、昨年10月から行われた検討の成果です。 IPAでは、情報サービス事業者、セキュリティベンダー、セキュリティに関する有識者など約20組織に対して、昨年10月から本年3月までにヒアリングを行い、ウェブサイトの脆弱性対策を促進する上での課題を抽出しました。 このヒアリングにおいて、ウェブサイトを公開している企業の中には、システム導入・運営上の意思決定を担う層の脆弱性に関する知識が乏しく、運用・保守の予

Loading...

id:hasegawayosuke氏にそそのかされるような格好で、「はじめてのPHPプログラミング基本編5.3対応」という書籍を購入した。 本書は、ウノウ株式会社の下岡秀幸氏、中村悟氏の共著なので、現役バリバリのPHP開発者が執筆しているということ、下記のようにセキュリティのことも少しは記述されているらしいという期待から購入したものだ。 目次から抜粋引用 07-07 Webアプリケーションのセキュリティ [セキュリティ] 08-04 データベースのセキュリティ [SQLインジェクション] 09-13 セキュリティ対策 [セキュリティ] 本書をざっと眺めた印象は、「ゆるいなぁ」というものであるが、その「ゆるさ」のゆえんはおいおい報告するとして、その経過で致命的な脆弱性を発見したので報告する。 問題の報告 それは、本書P280に登場する「SQLインジェクション対策用の関数(dbescape)」

フィッシング対策協議会では、フィッシング詐欺被害の対象となり得るサービス事業者および消費者に対する｢フィッシング対策ガイドライン｣を策定しましたので、公表いたします。このガイドラインは次の内容を記載しています。 １．サービス事業者におけるフィッシング詐欺対策 ・フィッシング詐欺被害を抑制するための対策 ・フィッシング詐欺被害の発生を迅速に検知するための対策 ・フィッシング詐欺被害が発生してしまった際の対策 ２．消費者におけるフィッシング詐欺対策 ・フィッシング詐欺への備え ・フィッシング詐欺に遭ってしまった時 サービス事業者の方々におかれましては自社サービスにおけるフィッシング対策の促進・充実を図っていただき、消費者の方々におかれましてはフィッシング詐欺に対する正確な知識を持つことによる的確な対応に役立てていただければ幸いです。 プレスリリース「フィッシング対策ガイドライン」

DNSの危機に対応を! 〜キャッシュ毒入れ新手法 Kaminsky Poisoning 〜(8/28 脅威についての説明追記) 2008年7月、セキュリティ技術者 Dan Kaminsky 氏が考案したDNSに対する新たな攻撃手法が明らかになり、8月6日、Kaminsky氏による発表がセキュリティ関連の国際会議 Black Hatで行われました。 これはDNSキャッシュサーバに偽の情報を注入（毒入れ/Poisoning）するものです。DNSは原理的にキャッシュへの毒入れ脆弱性を持ち合わせており、特に脆弱な実装のDNSサーバソフトウェアでは過去に何度か対応が図られてきました。今回あきらかになった手法は従来手法よりはるかに効率的に、状況によってはほぼ確実に毒入れができるというもので、大変危険なものです。 すでに攻撃コードも公開されており、被害も発生していることが報告されています。 まず、以下の

総務省が6月に発表したアンケート調査結果によると、子どもにインターネットを利用させる際にフィルタリングが必要だと思うと回答した人が94.3％に上った。しかしながら、自宅で子どもがPCでインターネットを利用している家庭のうち、フィルタリングソフト／サービスを利用しているのは30.2％（就学前～高校生までの平均）だった。 利用しない理由としては、「親子でコミュニケーションをとり、利用のルールやマナーを身につけさせればよいと思うから」（19.7％）、「出会い系サイトを利用することはない等、子どもを信用しているから」（18.2％）、「子どもがまだ小さいため、必要性を感じないから」（17.5％）が上位に挙がっており、これに「フィルタリングソフトの存在を知らなかったから」（13.9％）、「利用の仕方がわからないから」（10.9％）が続く。 ■URL 総務省「平成19年度電気通信サービスモニターに対する

●WAFってなに？ WAFとは、Web Application Firewallの略称である。 Webアプリの普及と高機能化に伴って、それらをターゲットとする攻撃は年々増加の傾向にあるが、従来型のネットワークファイアウォールでは、サービスを行っていないポートへの外部からの接続をブロックするといった、低いレベルでの対策しか行えない。 Webアプリの脆弱性を狙った攻撃を正確に検知し防御するためには、アプリケーション層における通信内容を理解し、その妥当性を判断できる仕組みが必要なのである。 また、クレジットカード情報取り扱いのセキュリティ標準であるPCIDSSの要件6.6にも、WAFの設置もしくはアプリケーションのコードレビューの実施が明記されており、2008年7月から必須要件となるため、今後のWebアプリのセキュリティを語る上で欠かせない存在になりつつある。 ●最近の攻撃傾

bakera.jp > 水無月ばけらのえび日記 > WASForum Conference 2008: Webセキュリティのマルプラクティス – 思い込みによるソフトウェアエラーをなんとかしろ

IEBlog : IE8 Security Part IV: The XSS Filter について、記事を書いた David Ross さんに翻訳許可をもらいましたので、訳してみました。誤訳や指摘がありましたらガンガン突っ込みをお願いいたします(他の記事も時間をとって訳していこうと思います)。当然ながら、これは私が私的に訳したものであり、Microsoftによる公式な翻訳/見解ではありません。 (訳注追加) 「reflected / Type-1 XSS」というのは、攻撃コードが被害者からのリクエスト自身に含まれるタイプのXSSで、サーバ側のアプリケーションでユーザからのリクエストに含まれる攻撃コードを「反射的」に返すような種類のXSSです。典型的には「"><script>...」のような語を検索したときに <input type="text" value=""><script>..."

補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2） 備忘のため転載いたしますが、この記事は2008年7月16日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 なお、「ホワイトリスト」という用語の定義については、以下の記事の「第二種ホワイトリスト」に相当するとお考えください。この記事の投稿当時、ホワイトリストという用語の定義の揺れについては意識しておりませんでした。 僕が「ホワイトリスト」を採用しなかった訳 補足終わり 近々WAF(Web Application Firewall)の話題を取り上げたいと思っている(→WAFの話題はこちら)。WAFの説明には決まってホワイトリストとブラックリストという用語が出てくる。しかし、WAFの宣伝やブログなどのエントリを読んでいると、ホワイ

＜内容＞ 平成２０年７月７日夕刻、当機構前役員が在職中お世話になった方々に本人の辞任の挨拶を電子メールで送信する際、本来は受信者の方々のメールアドレスが隠れる送信方法（ｂｃｃ）を用いるべきところ、６３７名の方々に、誤ってメールの宛先に他の受信者の方のメールアドレスが分かる状態で送信してしまいました。既に流出したアドレスの所有者の方には、お詫びのメールを送信し、併せて同メールの削除を依頼したところです。 ご関係の皆様にはご迷惑をおかけしましたことを深くお詫び申し上げます。 ＜今後の対応＞ 当機構では、今回の事態を厳粛に受け止め、今後このような事態が生じないよう、改めて全職員に対し、電子メール送信時における注意事項について機構内に周知徹底を図ります。 本件内容に関するお問い合わせ先：