SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
Webアプリでパスワード保護はどこまでやればいいか
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された - 徳丸浩の日記(2010-02-22)
_ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された twitterのケータイ版twtr.jpにおいて、DNS Rebindingによるなりすましを許す脆弱性が発見され、1/15に通報したところ、その日のうちに修正された。以下、その経緯について報告する。 経緯 今年の1月12日に読売新聞の記事が出たのを受けて、現実のサイトはどうなのだろうかと改めて気になった。 ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。 同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。
XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会
適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ
セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性
HASHコンサルティング株式会社 公開日:2009年11月24日 追記日:2010年1月21日 概要 iモードブラウザ2.0のJavaScriptとDNS Rebinding(DNSリバインディング)問題の組み合わせにより、iモードIDを利用した認証機能（以下かんたんログイン）に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景 携帯電話のかんたんログインとは、ケータイブラウザ（たとえばiモードブラウザ）に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送出される。現在、iモ
SSLの脆弱性でTwitterのパスワード入手に成功
研究者がSSLの中間者攻撃の脆弱性を悪用し、他人のTwitterパスワードを入手することに成功したと発表した。 SANS Internet Storm Centerや米IBM傘下のセキュリティ企業Internet Security Systems（ISS）のブログによると、TLS／SSLプロトコルに中間者攻撃の脆弱性が見つかった問題で、研究者がこの脆弱性を悪用してTwitterのログイン情報を盗み出すことに成功したと発表した。 脆弱性はTLS／SSLのリネゴシエーションの過程に存在し、理論的には中間者攻撃によってHTTPSセッションにデータを挿入することが可能になるとされていたが、当初の情報では実際に悪用するのは難しいと見られていた。 しかしISSなどによれば、研究者はこの脆弱性を突いて被害者がTwitterサーバに送ったHTTPパケットにアクセスし、パスワードなどのログイン情報を取得する
twitter の OAuth で思ったより豪快に認可してしまっている件 - 知らないけどきっとそう。
忘れたころに追記 API で _twitter_sess は発行されているようですが、web の UI にアクセスはできなくなったみたいです（つまり豪快さは解消されてます） OAuth コンシューマが twitter API にアクセスすると、ブラウザでログインしたときと同様のセッションクッキーが発行されている模様です GET https://twitter.com/account/verify_credentials.xml Authorization: OAuth realm="", oauth_consumer_key="***", oauth_nonce="***", oauth_signature="***", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1253358338", oauth_token="***",
SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ - hideden.hatenablog.com
2009-08-02 15:10:00 iPhone使わない方法を追記 iPhoneを色々いじってる過程でやってみたら出来たのでメモ。さほど悪い事は出来ないと思うけど、色々自己責任で。 iPhoneとSBMガラケーでは全く別のネットワークを使用しているため、通常iPhoneからは公式サイトやIPでアクセス制限をかけてる勝手サイトは見る事が出来ない。特に見る必要も無いのだが、実験としてやってみた。 iPhoneは通常 "smile.world" というAPNに接続している。一方、ガラケーはググって見たところ "mailwebservice.softbank.ne.jp" というAPNに接続しているらしい。っと言うことは、iPhoneの接続先をこれに変えてしまえばiPhoneもSBMガラケー側のネットワークに入れる・・・はず。 用意するモノ 香港版 or SIMUnlock済みの iPhone
Slowloris HTTP DoS 攻撃について
ちょっと前に Apacheに新たな脆弱性発見 - スラッシュドット・ジャパン で紹介されていた脆弱性なんですけど・・・会社のお達しで各サービス毎に状況報告ってイベントがあったので、ちょいと脆弱性試験してました。そのまとめです。 Apacheに、DoS攻撃に繋がる脆弱性が新たに見つかったそうだ（本家/.記事より） この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。 脆弱性はApache 1.x、 2.x、 dhttpd、 GoAhead WebServer、そしてSquidにて確認されているが、IIS6
i-mode2.0は前途多難 - ockeghem's blog
既に発表されているように、NTTドコモの夏モデルからi-modeの仕様が大幅に拡張され、JavaScript、Cookie、Refererに対応するようになった。これら仕様変更はセキュリティの面からも影響が大きいため、私は夏モデルの中から、P-07Aを発売開始日(5月22日)に購入した。そして、リリースどおりJavaScript、Cookie、Refererが動作することを、実機にて確認した。 ところが、P-07Aと同日に発売開始されたN-06Aは、その日のうちに一時販売停止のお知らせが出る。 この度、弊社の携帯電話「N-06A」において、iモード接続時の不具合が確認されましたので、販売を一時見合わせさせていただきます。 なお、本事象に伴い、本日発表いたしました「N-08A」の販売開始日につきましても、5月28日から延期となります。 「N-06A」の販売再開及び「N-08A」の販売開始時期
PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
第25回 PHPのアキレス腱 ── セッション管理 | gihyo.jp
PHPにはHTTPセッション管理モジュールが標準で付いてきます。このセッションモジュールには非常に重大なセキュリティ上の脆弱性が修正されずに残っています。その脆弱性とはセッションアダプションです。 セッションアダプションとは、セッション固定化攻撃に利用される脆弱性です。PHPのセッション管理モジュールがセッションアダプションに脆弱であることは、かなり以前、何年も前から知られています。しかし、開発者の理解不足より脆弱性が放置されたままになっています。 セッションアダプションとは セッションアダプションとは、ブラウザ等から送信された未初期化セッションIDをそのまま利用してセッションを初期化してしまう脆弱性です。ユーザが送信してきたIDでも第三者に予想できない文字列であれば大丈夫なのでは？と考える方もいると思います。その通りで第三者に予想できなければ問題ないですし、仮に予想できてもログインする際
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
高木浩光＠自宅の日記 - Bluetoothで山手線の乗降パターンを追跡してみた , ユビキタス社会の歩き方(6) Bluetoothの「デバイスの公開」「検出可能にする」..
■ Bluetoothで山手線の乗降パターンを追跡してみた この日記を書き始めてからもう6年になろうとしている。書き始めたきっかけは、RFIDタグのプライバシー問題が理解されないことに焦りを感じたからだった。当時の空気では、RFIDタグは5年後くらいに普及し、しだいにRFIDの埋め込まれた日用品で溢れかえるようになり、10年後くらいにプライバシー問題が顕在化すると目されていた。しかし、6年経った現在、私の靴にRFIDタグは埋め込まれていない。 当時の議論で描かれていたRFIDタグの問題は、無線LANやBluetoothにも共通することであり（MACアドレスがユニークIDとなる）、それらの方が先に普及するかもしれないという予感はあったが、現時点でも、無線LAN機器を持ち歩いている人はごく一部の人に限られている。しかし、Bluetoothはどうだろうか。これまでにも何度か、最近のBluetoo
第7回■文字エンコーディングが生み出すぜい弱性を知る
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
高木浩光＠自宅の日記 - Googleドキュメントの「招待メール」の危険
■ Googleドキュメントの「招待メール」の危険 ことの始まり 先々週の話。1月23日に次の記事が出ていた。 『Google Docs』の設定にご用心：知らないうちに書き換えも？, WIRED VISION, 2009年1月23日 この記事の趣旨は、「Googleスプレッドシート」の共有設定の画面の説明文「Let people edit without signing in」が誤解を招くために、誤って、誰にでも閲覧や編集を許す設定にしてしまいかねないという話である。この画面は、日本語表示では図1の表記となっている。 WIRED VISIONの記事の言い分では、「people」が上の招待メール送信先の人々のことを指すように読めて、下の「プライバシー」設定も変更しないといけないように誤解してしまうという。 そもそも、この機能の意図されている動作はどういうものか。私も試しているうちに一時混乱し
ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
$c->uri_for の汚染 - 酒日記 はてな支店
Bugtraq: WordPress XSS vulnerability in RSS Feed Generator を見て。 Catalyst でも $c->uri_for() で生成される文字列は、安全な文字列であると (なんとなく) 思い込んでいたらそうではないのだな。 <a href="[% c.uri_for('/') %]">みたいにエスケープしないで書くと、host 部分は $ENV{HTTP_HOST} (リクエストヘッダの Host:) から生成されることが多いので XSS が起きる。 これだと汚染された Host: を送ったクライアントにしか効かないような気がするんだけど、出力を Cache していると他のクライアントにも影響を及ぼせると。 まあ、出力はちゃんとエスケープしろ、という話だから目新しくはない。 $ GET -H 'Host:"><body onload=a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文字コードに起因する脆弱性とその対策
http://tokumaru.org/d/20080722.html
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog
