タグ

securityに関するoto-oto-otoのブックマーク (90)

  •  XSSとCSRFの違い早わかり - たぬきん貧乏日記 〜No Worry, No Hurry. Eat Curry!〜

    http://d.hatena.ne.jp/ockeghem/20071203 あー・・・・・ええと。うん。それ違うから。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く その表現は非常にまずい。まず「攻撃スクリプト」が混同されている。 少なくともサーバ上で「攻撃スクリプト」が動作するのはもう CSRF ではない。CSRF の場合,脆弱ではあっても悪意はない来のスクリプトが記述された通りの「正常な」動作をしているにすぎないからだ。 第二に,CSRF でも悪意のスクリプトがブラウザ上で動作するパターンがある。というより記事内で例示されている CSRF ではブラウザ上で罠サイトに設置された攻撃スクリプトであるところの JavaScript が動作しているものだ。アプリケーションにポストする内容の話

     XSSとCSRFの違い早わかり - たぬきん貧乏日記 〜No Worry, No Hurry. Eat Curry!〜
  • 最速インターフェース研究会 :: livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事

    livedoor wireless、MACアドレスによる認証を開始--ニンテンドーDSにも対応 http://japan.cnet.com/news/com/story/0,2000056021,20339983,00.htm に関して、Web屋のネタ帳の人が 「セキュリティのセの字も考えてないライブドアの公衆無線LANサービス」という記事を書いているのですが、 http://neta.ywcafe.net/000698.html 何か色々間違ってると思うので、書いておきます。これはライブドアの中の人じゃなくて、1ユーザーとしての立場で書いてるのと、あとネットワーク管理者でもなんでもないんで、そこら辺信頼できるかどうかは各自ご判断ください。 まず、実際自分で試してみたのですが、これは接続したい機器のMACアドレスを事前に登録しておくとWEB認証をスキップできるというもので、そもそもWEPキ

  • パスワードの強度 - rubyco(るびこ)の日記

    奥村先生のパスワード再考というエントリを読んで、パスワードの強度をビット長で表すプログラムをRubyで書いてみました。 # Base 2 logarithm module Math def self.log2(n) log(n) / log(2) end end # Bit length def password_strength_by_bits(ary, length) Math.log2(ary.length ** length) end lower = ('a'..'z').to_a upper = ('A'..'Z').to_a digit = ('0'..'9').to_a alpha = lower + upper alnum = lower + upper + digit p password_strength_by_bits(lower, 8) #=> 37.6035177

    パスワードの強度 - rubyco(るびこ)の日記
  • セブン銀行

    セブン銀行
  • ボット対策啓発サイト、サイバークリーンセンター公開 | スラド

    NHKのニュース経由。総務省、経済産業省、テレコムアイザックなどは共同して、ボットとなったPCへの対策を啓蒙するサイトサイバークリーンセンターを開設した。 サイト内では、ボットとは何かについての解説、ボット対策ソフト(このソフトの著作権は経産省だが、一部はトレンドマイクロ製)の配布、Windows (Microsoft) Update やウイルス対策ソフトの導入の推奨、などの活動を行っている。 私も今対策ソフトを実行してみたところだが、操作は手軽で実行は10秒ほどで終了した。見たところ2994種類のボットの有無がチェックされたようだ。

  • T.Teradaの日記 - ログイン直後のレスポンスの返し方

    多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう?というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して(HTTP1.1では303応答)、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ

  • 固有IDのシンプル・シナリオ

    結城浩 RFIDなどの、固有IDの問題を考えるためのシンプル・シナリオを提示します。 シンプルなシナリオと具体例を通して、固有IDの注意点がどこにあるかを明確にしましょう。 目次 はじめに このページについて このページの構成 わたしについて 「固有IDのシンプル・シナリオ」 時刻(A): 場所(A)にて 時刻(B): 場所(B)にて ボブが知りえたこと シンプル・シナリオ適用例 適用例1: メンバーズカード 適用例2: IDの自動読み取り 適用例3: 読取機を持ち歩く人 適用例4: ダイヤの密輸 適用例5: 徘徊老人の命を救う 適用例6: 遊園地の迷子探し 適用例7: 携帯電話 固有IDに関連するQ&A 固有IDのシンプル・シナリオで、何を言いたいのか? メンバーズカードの例は問題なのか IDには個人情報が盛り込めないのではないか? 暗号化すれば大丈夫? 強固なセキュリティでデータベース

    固有IDのシンプル・シナリオ
  • すべてはここから始まった〜SHA-1の脆弱化 ― @IT

    米国は、現在利用されているすべての米国政府標準の暗号技術を2010年までにより安全な暗号技術へ交代させていく方針を明確に打ち出している。現在、世界中で使われているデファクトスタンダードの暗号技術は、そのほとんどすべてが米国政府標準の暗号技術に準じているため影響は極めて大きい。2010年に向けて現在使われている暗号技術はどのように変わっていくのだろうか(編集部) 2005年2月15日、世界的な暗号の権威であるBruce Schneier氏のBlog「Schneier on Security」で公表された「SHA-1 Broken」という情報は、驚きをもって世界中を駆け回った。現在、ハッシュ関数のデファクトスタンダードとして最も広く利用されているSHA-1に対して、中国・山東大学のXiaoyun Wang氏とHongbo Yu氏、セキュリティコンサルタントのYiqun Lisa Yin氏のチー

    すべてはここから始まった〜SHA-1の脆弱化 ― @IT
  • AAで図解!ずばり一目で全く解らないコンピュータセキュリティ(解説付き)

    最終更新日: Wednesday, 29-Nov-2006 03:22:38 JST これはオリジナルの文章に水無月ばけらさんの鳩丸ぐろっさりを初めとする用語解説へのリンクと何故そのAAを使っているのかの簡単な説明を加えた物です。 Webバグ CSRF (Cross Site Request Forgeries) DoS (サービス拒否) サニタイズ オレオレ証明書 Cookie Monster SQL インジェクション HTTP Response Splitting (レスポンス分割) HTTPのページのフレームにHTTPSのページを表示 バッファオーバーフロー フィッシング Forceful Browsing (強制ブラウズ) クロスサイトスクリプティング ゼロデイ(0day)攻撃 ディレクトリトラバーサル セッションハイジャック 権限昇格 OS

  • 「サニタイズ言うなキャンペーン」私の解釈

    高木浩光さんの「サニタイズ言うなキャンペーン」 という言葉自体はずいぶん前から存在したのだが、 続・「サニタイズ言うなキャンペーン」とはにて高木さん自身がいくつも誤解の例を挙げているように、 そしてまた最近も 駄目な技術文書の見分け方 その1にて「まだわからんのかね」と言われているように、 「わかりにくい」概念なんだろうとは思う。 そこで、僭越ながら、「サニタイズ言うなキャンペーン」について、 私なりの解釈を書いてみようと思う。 もっともこれが正解であるという保証はないのだが、 間違っていたらどなたかツッコミいただけることを期待しています(_o_) そもそも何のせいで「エスケープ」しなければならないのか たとえば住所氏名を登録させるWebアプリケーションは珍しいものではないと思う。 そこで、私が「Taro&Jiro's castle サウスポール」 とかいう恥ずかしい名前のマンション(?)

    oto-oto-oto
    oto-oto-oto 2006/11/29
    ブクマコメントも
  • AAで図解!ずばり一目で全く解らないコンピュータセキュリティ

    最終更新日: Wednesday, 29-Nov-2006 02:46:05 JST Webバグ CSRF (Cross Site Request Forgeries) DoS (サービス拒否) サニタイズ オレオレ証明書 Cookie Monster SQL インジェクション HTTP Response Splitting (レスポンス分割) HTTPのページのフレームにHTTPSのページを表示 バッファオーバーフロー フィッシング Forceful Browsing (強制ブラウズ) クロスサイトスクリプティング ゼロデイ(0day)攻撃 ディレクトリトラバーサル セッションハイジャック 権限昇格 OS コマンドインジェクション オープンプロキシ Webバグ \  __  / _ (m) _ビーコーン |ミ| /  `´  \ ('A`

  • はてなのログインについて、ユーザー名とパスワードをいちいち入力せずに、「指定したURL」を入力することで自動的にログインできるようなURLは見つけることはで…

    はてなのログインについて、ユーザー名とパスワードをいちいち入力せずに、「指定したURL」を入力することで自動的にログインできるようなURLは見つけることはできますでしょうか?またどのような方法で見つけたかもぜひ教えてください。もちろんログイン画面の「次回から自動的にログイン」を使用しないことが前提です。

  • 高反発マットレスの選び方 | アフィブログに騙されない為の高反発マットレス手記

    ウレタン系高反発マットレスでよく言及されるのが密度です。それを頑張って分かりやすく説明してみます。

  • 高木浩光@自宅の日記 - 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない

    ■ 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない 「ぼくはまちちゃん」 ――知られざるCSRF攻撃, 上野宣, @IT, 2005月4月27日初版、2006年11月8日修正版 ●リファラーで発信元をチェック HTTPリクエストを受けたとき、そのリクエストがどこのWebページから発行されたものかを示すリファラー(REFERER)と呼ばれる情報を得ることができる。この情報を活用し、来意図したWebページ以外からのリクエストを拒否することで、CSRFによる外部からのリクエストを防ぐことができる。 ただし、ユーザーがリファラー情報を出力しないブラウザを使っている場合、このチェックを導入すると正当な操作でも受け付けなくなってしまう。 懸念されるリファラー情報偽装に対する問題だが、以前はリファラー情報を発行するのは攻撃を踏んでしまった自分自身なので、リファラー情報を偽装する動機がなく

  • いつの時代も、真実はひとつだけ:藤田憲治「雑誌づくりの舞台裏」

    記者:「次の特集で、ウイルス対策ソフトの性能を測ってもいいですか?」。 私 :「えっ」「性能って何?」。 記者:「ウイルスの検体を集めてですね、今売られているウイルス対策ソフトが、どのくらいの割合でウイルスを検出できるか知りたいんです」。 私 :「でも、いまどきのウイルス対策ソフトに、あんまり差はないはずだよ。製品化されてだいぶ時間も経ってるし。テストに膨大な時間がかかるわりに、性能に差が付かなくて『記事が書けない!』ってことになるんじゃないかなぁ」。 5年前で、ウイルス検出率はほぼ100% 私の言い分には、きちんとした“理屈”がありました。今から約5年前の2001年末、同様の企画を考え、記事を執筆したことがあったのです。そのときは7種類のウイルス対策ソフトを集め、289種類のウイルス検体を、それぞれの製品が検出するかどうかテストしました。 結果は、7製品中6製品の検出率が100%で

  • 日本発次世代暗号方式「Camellia」、OpenSSL Projecrtが採用 | OSDN Magazine

    NTT持ち株会社は2006年11月8日、三菱電機と共同開発した128bitブロック暗号アルゴリズム「Camellia」(カメリア)が、OpenSSL ProjecrtのSSL/TSLプロトコル用暗号ツールキット「OpenSSL toolkit」に採用されたと発表した。 9月にリリースされたOpenSSL 0.9.8c版からCamelliaが搭載された。同ツールキットに搭載される128bitブロック暗号はAESに続いて2番目。「AESと同等の安全性と処理性能を有すると位置づけられた」(NTT)としている。なお、0.9.8.x版の搭載ではコンパイルされず、次回のメジャーバージョンアップ時に標準インストールされる予定。 Camelliaは2000年にNTTと三菱電機が共同開発。ISO/IEC国際標準暗号、欧州連合推奨暗号、電子政府推奨暗号などの国際的な暗号方式の標準化規格・推奨規格に選定されてい

    日本発次世代暗号方式「Camellia」、OpenSSL Projecrtが採用 | OSDN Magazine
  • 5分で絶対に分かるSSL-VPN − @IT

    SSLって何だったっけ? SSL-VPNを学ぶ前に、まず「SSL」についておさらいしてみましょう。 SSL(Secure Sockets Layer)は、Webサーバとのやりとりを暗号化してくれるもので、ショッピングサイトなどでクレジットカード番号を入力するページでおなじみでしょう。SSLは「やりとりを盗聴されていないこと」「相手が偽物ではないこと」「やりとりを誰かが改ざんしていないこと」を証明してくれる、縁の下の力持ちとなります。 SSLという言葉を知らなくても、この鍵のマークにはお世話になっている人も多いと思います。SSLはPC向けのブラウザだけではなく、携帯電話やゲーム機、PDAなどのブラウザでも実装されている、とても一般的なプロトコルです。 SSLの歴史は古く、1995年に登場したNetscape Navigator 2や、1996年に登場したInternet Explorer 3

    5分で絶対に分かるSSL-VPN − @IT
  • 2006-11-07

    Windows XP を一般ユーザー (Administrators でも Power Users でもないユーザー) の権限で、特殊なドライバが動いている状態でも、特殊なバックグラウンドサービスが動いている状態でもなく、クリーンインストールした普通の状態で、ある工夫 (?) をした EXE ファイルを実行するだけで、簡単にブルースクリーンにしてクラッシュさせることができる ことに、今年の 4 月ごろに気付いた。 普通、一般ユーザー権限でいくらコードが暴走しても、Windows XP は滅多にブルースクリーンになることはない (メモリ等のハードウェアや、サードパーティのデバイスドライバにバグがある場合を除く) のだが、ある方法を使えばいともたやすく一般ユーザー権限からシステムのカーネルを停止させて、コンピュータを異常再起動させることができる。 2006 年 4 月に、この現象 (?) を偶

    2006-11-07
  • 高木浩光@自宅の日記 - 駄目な技術文書の見分け方 その1

    ■ 駄目な技術文書の見分け方 その1 はてなブックマークのホッテントリを見ていたところ、300を超えるユーザに登録された以下の記事があった。 今夜分かるSQLインジェクション対策, 上野宣, @IT, 2006年11月2日 また上野宣か。顔見知りなのでズバリいくことにする。 しかし、その対策はまだ当に理解されていないように思える。 へえ。 終わりの方を見てみると、 Webアプリケーションの対策 入力値のSQLの特殊文字を適切にエスケープ 入力値=プログラム(プロセス)に外部から入ってくるもの シフトJISの場合には1バイト文字を整理 SQLの記述をなくすためにO/R(Object/Relational)マッピングを活用 攻撃者に役立つ情報を与えないために、不要なエラーメッセージ(データベースが出力するエラーなど)の表示を抑止 対策に「準備された文」(prepared statement)

  • 「OSのバグを毎日1件公開する」プロジェクトが始動,第1弾はMac関連のバグ

    OS関連の新しいバグを11月中に毎日1件ずつ公表するプロジェクト「Month of Kernel Bugs(MoKB:カーネル・バグ月間)」が米国時間11月1日から開始された。同日付けでこのプロジェクト最初のバグとなる,AirPort(AirMac)カードのデバイス・ドライバに関するバグが公表された。 MoKBの目的は,テスト・ツールおよびテスト手順の有効性と,OS(Mac OS X,FreeBSD,Solaris,GNU/Linuxなど)のカーネル・コード(例えば,ネットワークやファイル・システムに関連するコード)の品質を検証すること。ツールとしては,ファイル・システムに関するバグは「fsfuzzer」,そのほかのバグについては「isic」および「sysfuzz」,「mangle」を利用するという。 このプロジェクトにおいて最初に報告されたバグは,1999年から2003年に出荷されたPo

    「OSのバグを毎日1件公開する」プロジェクトが始動,第1弾はMac関連のバグ