タグ

securityに関するscorelessdrawのブックマーク (118)

  • クレジットカード決済における本人認証について : LINE Corporation ディレクターブログ

    こんにちは、ライブドアで決済システムを担当している森です。 今回は、クレジットカード決済における人認証について書かせていただきます。 【01】3D Secure と e-SCOTT 皆さんは「3D Secure」というクレジットカード人認証サービスをご存知でしょうか。 「3D Secure」とは、クレジットカード決済を行なう際に、カード番号と有効期限のほかに、クレジットカード会社に登録してあるパスワードでも認証を行なうサービスです。 パスワード認証を行なうことで、カードの「盗難」や「なりすまし」などによる不正利用の防止が可能となります。 また、入力されたパスワードは、カード発行会社に直接暗号化されて送信されるため、サイト運営会社(livedoor デパートなど)では取得できない仕組みになっており、情報漏洩による事故も防ぐことができます。 このサービスは、元々ビザ・インターナショナルが

    クレジットカード決済における本人認証について : LINE Corporation ディレクターブログ
    scorelessdraw
    scorelessdraw 2008/05/29
    セキュリティってよりもチャージバック対策って意味の方が大きい気もするんだが
  • 検証ラボ - 目次:ITpro

    注目すべき製品や技術について,実際に細部にわたって検証・評価を行い,公正な観点からレポートする。現場ではやりたくてもできない,やるヒマがない,でも結果は知りたいテーマを取り上げる。 観点の絞り込みで設計レビューは改善できるか? 要件定義書や設計書のレビューでは、後工程での修正コストを低減させる「重大な指摘」を数多く挙げることが重要だ。その方法の一つとして、レビューの観点を絞り込むことが提唱されている。観点を絞り込むことで、重大な指摘はどれだけ増えるのか。レビューの研究者である森崎修司氏に、二つの検証結果を報告してもらった。 ウイルスを観察してみる ウイルスやワームはパソコンやサーバーの中でどのように動作するのか。その動きを目で見ることは,脅威を体感するという意味で意義がある。そこで,検証マシンを用意し,実際に感染させ,発症させ,その挙動を観察した。 KVS「Cassandra」の実力 デー

    検証ラボ - 目次:ITpro
  • 高木浩光@自宅の日記 - 新型myloのオレオレ証明書を検出しない脆弱性がどれだけ危険か

    自己署名の証明書になっていた。 これは明らかにセキュリティ脆弱性だ。この種類の脆弱性(ブラウザが証明書を検証しない)は、伏せておくよりも早く事実を公表して利用者に注意を促した方がよいという考え方もあり、すぐに日記に書こうかとも考えたが、このケースではIPA、JPCERT/CCを通した方が修正が早く行われるのではないかと考え、IPAの脆弱性届出窓口に通報した。 この届け出は3月27日に受理された。そして日、JVNで公表となった。修正版が提供されているので、利用者はアップデートで対応できる。 JVN#76788395 ソニー製 mylo COM-2 におけるサーバ証明書を検証しない脆弱性, JVN, 2008年4月23日 パーソナルコミュニケーター "mylo" COM-2 セキュリティ脆弱性対策プログラムご提供のお知らせ, ソニー株式会社, ソニーマーケティング株式会社, 2008年4月2

  • 高木浩光@自宅の日記 - Amazonは注文履歴の消去を拒否、アカウント閉鎖後もデータは残る

    Amazonはやっぱり怖い そろそろ使うのをやめようと思う 今は朝6時。数時間前、寝ようとしたころに大騒ぎになっていた。 密かな趣味が全公開--Amazonのウィッシュリスト、改め「ほしい物リスト」に注意?, CNET Japan Staff BLOG, 2008年3月12日 これはひどいことになった。HATENA Co., LTD. では暗号解読のをお求めのようだった。 幸い私は、ウィッシュリストを空にしていたので、何も見られることはなかったが、自分のAmazon登録メールアドレスを入れると、氏名と「茨城県」などの情報が表示された。(メールアドレスも非公開のものを使っているが、ワイルドカード指定もできたようなので、どうなっていたかわからない。もっとも、私は実名を隠していないが。) そもそも何年か前、この「ウィッシュリスト」なるサービスが始まったとき、やたらウイッシュリストへの登録が

  • 高木浩光@自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと

    ■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式

    scorelessdraw
    scorelessdraw 2008/03/02
    “公開鍵と秘密鍵が「逆に使える」というのはRSAアルゴリズムがたまたま(まあまあ)そうなだけであって、そのような性質を持たない他の公開鍵暗号方式がたくさん存在する。”
  • OpenID や OAuth の役割と、既存のシングル・サインオンとの違い:Goodpic

    This shop will be powered by Are you the store owner? Log in here

  • スラッシュドット ジャパン | UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意

    jbeef曰く、"家に「Cross Site Scripting Discovered in Google」というストーリが掲載された。 これは、Web Application Security Consortiumが主宰するメーリングリストに投稿された記事を伝えるもの。その記事によると、Google.comにXSS(クロスサイトスクリプティング)脆弱性が見つかり、発見者が11月15日にGoogleに連絡したところ、12月1日に修正されたという。この脆弱性の原因と対策は以下の通り。" (つづく...) "まず、Googleの404 Not Foundのページはこの例のように、リクエストされたURLのパス名を画面に表示するようになっている。ここで、そのパス名にHTMLのタグを構成する文字「<」「>」が含まれている場合、Googleは、これをきちんと「&lt;」「&gt;」にエスケープして出

  • 高木浩光@自宅の日記 - 「ダウンロード違法化」で漏洩情報のWinny流通を抑止できるか

    ■ 「ダウンロード違法化」で漏洩情報のWinny流通を抑止できるか 11月の情報ネットワーク法学会大会の個別発表で、「匿名ファイル交換ソフトで違法複製物をダウンロードした者の法的責任」というご発表があった。その際に私は質問をしたのであるが、その意味するところは聴衆の方々にもわかりにくいものだったと思われるので、その趣旨をここに書き留めておくことにする。その前に、その考察に至る背景から。 「ダウンロード違法化」を望むのは権利者だけではない いわゆる「ダウンロードの違法化」、つまり、違法複製物又は違法配信からの録音録画を著作権法30条の適用対象外とする著作権法改正に向けた文化審議会著作権分科会私的録音録画小委員会の検討は、昨今の反対派の論調では単純に「権利者(流通業者)の横暴」とみなされているようだが、私には、それとは別の動機によって(を伴って)推進されているように感じられる。 それはつまり、

  • 高木浩光@自宅の日記 - オレオレ警告の無視が危険なこれだけの理由

    警告を無視して先に進むと、その瞬間、HTTPのリクエストが cookie付きで送信される。 もし通信路上に盗聴者がいた場合*2、そのcookieは盗聴される。セッションIDが格納されているcookieが盗聴されれば、攻撃者によってそのセッションがハイジャックされてしまう。 「重要な情報さえ入れなければいいのだから」という認識で、オレオレ警告を無視して先を見に行ってしまうと、ログイン中のセッションをハイジャックされることになる。 今見ているのとは別のサイトへアクセスしようとしているのかもしれない さすがに、銀行を利用している最中でオレオレ警告が出たときに、興味位で先に進む人はいないかもしれないが、銀行を利用した後、ログアウトしないで、別のサイトへ行ってしまった場合はどうだろうか。通常、銀行は数十分程度で強制ログアウトさせる作りになっているはずだが、その数十分の間に、通信路上の盗聴者により、

  • 高木浩光@自宅の日記 - こんな銀行は嫌だ

    ■ こんな銀行は嫌だ 「こんな銀行は嫌だ――オレオレ証明書で問題ありませんと言う銀行」……そんな冗談のような話がとうとう現実になってしまった。しかも、Microsoftが対抗策を施した IE 7 に対してさえ言ってのけるという。 この原因は、地方銀行のベンダー丸投げ体質と、劣悪ベンダーが排除されないという組織の構造的欠陥にあると推察する。 【ぶぎんビジネス情報サイト】アクセス時に表示される警告メッセージについて ぶぎんビジネス情報サイトでは、サイトURL(https://www.bugin.cns-jp.com/)ではなく、ベースドメイン(https://www.cns-jp.com/)でSSLサーバ証明書を取得しております。このため、サイトにアクセスする際、ブラウザの仕様により次の警告メッセージが表示されますが、セキュリティ上の問題はございませんので、安心してぶぎんビジネス情報サイトを

  • 高木浩光@自宅の日記 - 無線LANのMACアドレス制限の無意味さがあまり理解されていない

    ■ 無線LANのMACアドレス制限の無意味さがあまり理解されていない 職業マスメディアに代わって、ブログスタイルのニュースサイトが人気を博す時代になってきた。海外の話題を写真の転載で紹介する安直なニュースも人気だ。 このことろなぜか、無線LANのセキュリティ設定について書かれた記事を何度か見た。おそらく、ニンテンドーDSがWEPしかサポートしていないことが不安をもたらしている(そして実際に危険をもたらしている)ためだろうと思われる。 セキュリティの解説が増えてきたのはよいことなのだが、内容に誤りのあるものが少なくない。 実は危険な無線LAN, らばQ, 2007年10月21日 この記事には次の記述があるが、「接続されなければMACアドレスは盗まれない」という誤解があるようだ。 MACアドレスというのは、機器固有のIDのようなものです。たいていの無線LANアクセスポイントにはMACアドレスフ

  • MD5は復号できる!? | ブログが続かないわけ

    前回のエントリ(パスワードを平文で管理するのはダメだ)のブクマコメントでYappoさんから貴重な情報を頂いた。 MD5が復号できるというのだ。 しかも、それができるDigest::MD5::ReverseというCPANモジュールがあるという。 これには驚いた。いろいろな情報を当たったところ、やはりMD5などのハッシュは復号できないと書いてあるからだ。 http://www5f.biglobe.ne.jp/~h-it/mlcont/mc0200.htm http://gimite.net/bcbqtree/qtreemain.cgi?mode=thread&thread=376 http://www.postgresql.jp/document/pg803doc/html/encryption-options.html しかし、こういうところでいう「復号できない」というのは「復号するアルゴリ

    MD5は復号できる!? | ブログが続かないわけ
  • 高木浩光@自宅の日記 - 対策にならないフィッシング対策がまたもや無批判に宣伝されている, 追記(26日)

    ■ 対策にならないフィッシング対策がまたもや無批判に宣伝されている 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日 「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。(略) 「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」(中島氏)。また、偽サイトとはシンクロしないため、フィッシング詐欺を100%防止することも可能だ。 ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日 今回の新機能は、安全・簡便・低コストで、そう

  • Webアプリケーションセキュリティフォーラム - Journal InTime(2007-07-05)

    _ Webアプリケーションセキュリティフォーラム というわけで、発表して来た。 スライド(PDF) スライド原稿(RD) 自分の発表はともかく興味深い話を色々聞けてよかった。 とくに奥さんと高木先生のバトルが面白かった。 追記: リクエストがあったのでバトルの内容について少し。 (曖昧な記憶に基づく再現で言い回しは違うと思うし、内容にも私の勘違いがあるかもしれません。念のため) 高木先生 Greasemonkeyの説明の部分がよく聞こえなかったんですが。 奥さん (内容を説明) 高木先生 ええと、「クッキーが漏洩する程度なので問題ない」と聞こえたような気がしたんですが。 私の心の声 (最初から聞こえてたんじゃ…) 奥さん ローカルファイルにアクセスできたり、任意のコマンドを実行されたりするのに比べれば、ということですね。 高木先生 いや、それは違うと思うんですよ。銀行サイトのクッキーが漏洩

  • 高木浩光@自宅の日記 - 「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る

    ■ 「ガラパゴス携帯のパラダイス鎖国」をWebの技術面から見る ワンクリック不当請求が問題となり携帯電話事業者各社が「お知らせ」を発表した2004年夏、8月29日の日記で総務省の「次世代移動体通信システム上のビジネスモデルに関する研究会」について少し触れた。実はもっと詳しく書くべき興味深い内容があったのだが、あまり言うのもいやらしい(せっかく解決に向けて動いて頂いているようなのに)という事情が当時はあったため、その後何もしていなかった。いまさらではあるが、これについて書き留めておく。 2000年に旧郵政省が「次世代移動体通信システム上のビジネスモデルに関する研究会」を開催していた*1。2001年に総務省情報通信政策局が報告書を公表している。 第1回 議事要旨, 郵政省, 2000年7月 第2回 議事要旨, 郵政省, 2000年9月 第3回 議事要旨, 郵政省, 2000年12月 第4回 議

  • 高木浩光@自宅の日記 - EZwebサイトでSession Fixation被害発生か?, サブスクライバーIDをパスワード代わりに使うべきでない理由

    ■ EZwebサイトでSession Fixation被害発生か? au booksでの事故 意図的な攻撃でなく偶発的な事故なのかもしれないが、auの公式サービス「au books」のEZwebサイトで、Webアプリケーションの脆弱性が原因の情報漏洩事故が起きたようだ。 顧客情報漏えい:書籍販売サイト「au Books」で, 毎日新聞, 2007年6月26日 ゲーム攻略(1冊1890円)の紹介サイトからアクセスし、その攻略を買おうとすると、他の顧客の氏名、住所、電話番号、生年月日、会員パスワードが表示された。そのまま購入手続きをとると、他の顧客が購入したことになってしまうという。 au携帯電話におけるオンライン書籍販売サイト「au Books」におけるお客様情報の誤表示について, KDDI, 2007年6月26日 1. 発生事象 年6月22日20時37分から23日18時45分までの間

  • 高木浩光@自宅の日記 - ケータイWebはそろそろ危険

    ■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基手順は、(パスワードやカード番号などの)重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが(任意サイトへの)リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ

  • 高木浩光@自宅の日記 - 銀行2.0はまだ来ない

    ■ 銀行2.0はまだ来ない 4月に、「IE7ユーザーにいまさらSSL2.0を使わせようとする銀行」というブログエントリを見かけた。それによると、Internet Explorer がバージョン7に移行し始めたことを契機に、「SSL 2.0を使用する」に設定変更するよう指示している銀行があるのだという。Internet Explorer 7がセキュリティ上の理由でSSL 2.0をオフに変更したにもかかわらずだ。 例えば武蔵野銀行は、4月の時点で図1の解説を掲示していた。 Internet Explorer7の場合は「SSL2.0を使用する」がチェックされていない場合が多いのでご注意ください。 他にも山形銀行が同様の解説を掲示していた。いったいどうしてこんなことになるのかと、問題点の指摘がてら、なぜ書いているのか聞いてみた(4月に電話で)。すると、だいたいこういうやりとりになった。 ある銀行:

  • Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT

    Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP(Open Web Application Security Project)は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ

    Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT
    scorelessdraw
    scorelessdraw 2007/06/15
    ブクマ数
  • Apacheに対するサービス拒否攻撃を回避する方法

    筆者は最近,Apache HTTPサーバーに対するサービス拒否攻撃を防御するWebベースのセキュリティ・ツール「mod_evasive」を使い始めた。mod_evasiveは特定の挙動を探してそれをブロックするモジュールである。 mod_evasiveは,筆者が昨年の12月に紹介した「Suhosin」に似ている(関連記事:PHPの「守護神」Suhosin)。SuhosinはPHPスクリプティング・エンジンの安全性を大幅に高めるパッチである。Suhosinは,害を及ぼす危険性を持つありとあらゆるWebベースのコンテンツを検出し,それらがPHPエンジンを越えてシステムやネットワークに到達するのを防ぐ上で役に立つ。 mod_evasiveが機能する仕組みを説明しよう。mod_evasiveはまずURLリクエストをApacheサーバーに送信するIPアドレスの記録を取る。その後,あらかじめ設定した許

    Apacheに対するサービス拒否攻撃を回避する方法