Eye-Fi Shareのセキュリティについて、ちょっと前の投稿「Eye-Fi Share」で簡単に書いたのだが、せっかくなので、もう少しきちんと説明しよう。 まず、昨年春に指摘されていたEye-Fiの複数の脆弱性の問題はSecurityFocusにて見ることができる。 The Eye-Fi Manager and Card are prone to multiple security vulnerabilities, including unauthorized image uploads to computers, remotely altering the destination folder, cross-site request-forgery vulnerabilities, and a denial-of-service vulnerability. SecurityFocu
今日ではほとんどのウイルス対策ソフトが書庫ファイルに対しウイルスチェックを行う機能を備えているが、多くのウイルス対策ソフトで「LZH書庫ファイルのヘッダー部分に細工を施すことでウイルスチェックを回避できる」という脆弱性が存在するとのこと（LZH書庫のヘッダー処理における脆弱性について）。 Micco氏はこれをJVN（Japan Vulnerability Note、JPCERTおよびIPAが共同運営する脆弱性情報集積サイト）に報告したところ、「不受理」となったそうだ。ZIPや7z形式の書庫にも同様の問題があるものの、そちらは「脆弱性」として受理されているとのこと。Micco氏曰く、 「ベンダー， JVN / IPA 等共に『LZH 書庫なんて知らねぇ～よ』という態度から変わることはない」と判断できましたので， UNLHA32.DLL， UNARJ32.DLL， LHMelt の開発を中止す
(4/23 12:46微調整) 私はOpenOffice.org日本語プロジェクトリード、かつ、OpenOffice.org Quality Assurance project leadで、さらにsecurity teamのメンバーである(なぜsecurity teamか? これはFreeBSD portingという利害である。何でもやっておくものだ;ただ、立場上情報を公にはできない。確認したくばmahoを指名して、セキュリティ報告をせよ)。 現状、OpenOffice.org日本語版を官公庁など公共機関で利用するには、セキュリティ対策が不十分である。そして誰でも参加できて、参加し、結果報告するだけで、対策できる。またプロセスの改善への参加も大歓迎である。なおアシストの「OpenOffice.org支援サービス」では、セキュリティポリシーは私には教えていただけ無かった。公開してないようでも
今日は、PHPでよく使用される正規表現エンジンであるPCRE（Perl Compatible Regular Expression）の、余り知られていない（と思う）制約について書きます。 プログラム 題材は下のPHPプログラムです。 <?php header('Content-Type: text/html; charset=latin1'); $url = $_REQUEST['url']; if (preg_match('/^(.*?):/s', $url, $match)) { $scheme = $match[1]; if ($scheme !== 'http' && $scheme !== 'https') { exit; } } echo '<a href="'. htmlspecialchars($url). '">link</a>'; 外部から受け取った「url」パラメータ
2010 年 3 月 29 日に Didier Stevens が公開した PDF 仕様 「Launch action」の悪用手法（元記事はこちら）が話題になっていますね。Didier Stevens 氏の PoC(zip) を Adobe Reader 9.3.1 で開いてみると、警告ダイアログが表示され、[OK] をクリックすると cmd.exe が実行されました。この「Launch action」仕様を調べてみて、思ったことをまとめます。 「Launch action」仕様について思ったこと これまで見てきた PDF ファイルの中に「Launch action」を使用したものがなかったことから、「Launch action」は（少なくとも僕のまわりでは）必要とされていない仕様だと考えます。各 PDF ビューアの「Launch action」に関する挙動を確認した限りでは、いきなり実行
何が危ないのか img.onerror や img.onload は src 属性の内容が評価された段階で実行されるので、外部ソースに対して HTMLDocument を構築する際などで、意図していないタイミングでスクリプトが実行されるケースがある。 具体的には、以下のような場合。 var source = '<img src="not_found.jpg" onerror="alert(1)">'; var range = document.createRange(); range.createContextualFragment(source); // onerror が実行される var img = document.createElement('img'); img.setAttribute('onerror', 'alert(1)'); img.src = 'not_found.
こんにちは、中川です。 先日、GoogleからWebアプリケーション向けの自動セキュリティスキャナ「Skipfish」が公開されたので、社内で利用しているCakePHPのアプリで試してみました。 Skipfish( http://code.google.com/p/skipfish/ )は、Webアプリケーションの脆弱性、SQLインジェクションやクロスサイトスクリプティング等を自動的に検出してくれるApache License 2.0のライセンスで公開されているオープンソースのツールです。 必要なライブラリは以下とのこと。 * GNU C Compiler * GNU Make * GNU C Library (including development headers) * zlib (including development headers) * OpenSSL (including
Mozillaは、CSSを利用することで利用者の訪問履歴が漏洩する可能性のあるWebブラウザの機能を改善することを明らかにしました。これは、楽天ad4Uのような、CSSやJavaScriptを用いて利用者の履歴を取得しているインターネット広告への対策として考えられたものです。 利便性のための機能から訪問履歴が漏洩 Webブラウザ上のリンクは、訪問したことのあるリンク先に対して色や文字の大きさなどのスタイルを変更することができます。これは、Webブラウザの画面上でどのリンクが訪問済みなのかを知らせるための、ユーザーの利便性を想定して作られた機能です。 しかし一部のインターネット広告では、これを利用して広告の中に大量のリンクを埋め込み、そのリンクの中から訪問済みのスタイルになっているリンクを自動的に探しだすことでユーザーの訪問履歴を取得。履歴情報をいわゆる行動ターゲティング広告の手段としている
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月29日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり DNSリバインディング攻撃により、無線LANアクセスポイント(AP)に設定したWPAのパスフレーズ(PSK)を読み出す実験に成功したので報告する。 先のエントリではDNSリバインディング攻撃によるルータ設定変更の実験を報告したが、エントリでも触れたように設定変更についてはCSRF脆弱性を悪用することによっても可能だ*1。両手法の違いとして、CSRFは攻撃先の情報を読み出すことはできないのに対して、DNSリバインディングでは読み出しも可能だ。DNSリバインディングによるセッションCookieの読み出し例につい
computerworld.jpは3月17日に『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』と題した記事を公開したが、一部誤報があるので訂正する。 米国White Hat Securityの研究者らがまとめた2010年版の深刻なセキュリティ脅威トップ10では、DNSリバインディングが1位となった。同社では、2006年から毎年、脅威トップ10を発表している。 http://www.computerworld.jp/news/sec/177029.html 当初、この記事を読んで違和感を覚えた。DNSリバインディングという攻撃手法そのものは以前から知られているものであるし、この記事で説明されている脅威の内容についても、以前から知られているものと違わない。このタイミングでなぜ、DNSリバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
マイナーかもしれないけど、HTTP Request Smuggling（通称HRS）という攻撃手法があります。詳しくはWizardBible vol.19の金床氏のHRS記事を参照。そして、それに関連して、IIS/5.0の48kbバグ（仕様?）というものがありまして、簡単に言うと、IIS/5.0は、Content-Typeヘッダが無い48kb以上のボディ部を持つHTTPリクエストに対して、無条件にボディ部を48kbに決めつけるというものです（以下、WizardBible vol.19のHRS記事から引用）。 IIS/5.0にはとてもわけのわからないバグがあるようで、48kb以上のボディ部を持ち、かつContent-Typeヘッダーフィールドが無いHTTPリクエストは、無条件にボディ部を48kbちょうどと決めつけてしまうようです。 ちなみにIIS/5.1も5.0同様48kb決めうちを行います
JavaScriptのXMLHttpRequestでのクロスドメイン制限を回避できるなら、iアプリはどうなんだろう？ ということで試してみた。ちなみにDocomoのiアプリは「制限したHTTP通信」をサポートしており、一応HTTPが扱えるが、携帯電話にダウンロードされたiアプリは、ダウンロード元のサーバへしかHTTP通信できない、また、HTTP以外の通信をサポートしない、という制限がある。 参考：Doja HttpConnection 「ダウンロード元のサーバへしかHTTP通信できない」という点においてJavaScript（Ajax?）と似ている。結果から言うと、iアプリもDNS Rebindingでダウンロード元以外のサーバへアクセス可能だと判明。 mydomain.comのIPアドレスを1.2.3.4にセット（1.2.3.4は自分が管理するサーバ） mydomain.com(1.2.3
イラストSNS「pixiv」の一部の作品に対し、「ツマンネ」「ヘタクソ」「気持ちわる」といった中傷コメントが意図せずに投稿されてしまう問題が起きた。運営会社が調べたところ、何者かがユーザーに脆弱性を悪用した外部URLをクリックさせ、意図しないコメントを投稿させていたことが分かり、既に脆弱性は修正した。 ピクシブの開発者ブログによると、問題は2月5日～14日に発生。イラストのキャプション欄などに貼られていたあるURLをクリックすると、外部サイトを経由し、中傷コメントが投稿されるようになっていた。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を悪用していた。脆弱性は14日に修正した。アカウントが乗っ取られたわけではなく、個人情報の漏えいや改ざんはないとしている。ウイルス感染の被害もないという。 pixiv
ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。 同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。 該当機種は、昨年５月以降に発表されたプロシリーズやスタイルシリーズなど。ｉモードブラウザ２・０は、ジャバスクリプトと呼ばれる機能が組み込まれており、携帯用のインターネットサイトと自動で情報をやりとりできる。 悪意ある携帯用サイトは、接続してきた利用者の携帯のジャバスクリプトを使って、利用者が会員になっている別のサイトに一瞬だけ接続させることができる。その時、この会員サイトに利用者の住所など個人データが登録されていると、盗み出されてしま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
