先日、Twitterでどのように脆弱性を見つけるかに興味あるんだろうかと書いたら、意外に色々な人から反応があったので、これまでに自分が見つけた脆弱性のいくつかについてどういう経緯で見つけたのかちょっと書いてみます。 JVN#89344424: 複数のメールクライアントソフトにおける、添付ファイルによりメールクライアントソフトが使用不能になる脆弱性 これは、添付ファイル名にUnicodeの円記号を含めておくと、メーラ側でShift_JISに変換する際にバックスラッシュに変換されてしまって想定外のディレクトリに添付ファイルが展開されてしまったり、あるいは「©on」のような名前のファイルを添付しておくことでShift_JISに変換してCONというファイルを開こうとしてメーラが固まってしまうという問題です。これは、私自身が文字コードの問題について調べ始めた初期段階で、Unicodeからの変換で問題

「XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会」を読んで。 IPAを通じて脆弱性の報告が来るということは、脆弱性の発見者がセキュリティ専門家だったりするため、対策が取られるまで公開されないことが予測できる。つまりIPAから脆弱性の報告が来る=緊急ではないという図式が成り立ってしまう！！XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会よりううむ。個人的には、脆弱性を発見した場合にはむしろ専門家以外の素人ほどIPAを通じて報告するほうがよいと思っている。理由は以下の通り。 連絡先の把握が困難 Webサイトにもよりますが、脆弱性報告のための窓口を用意しそれを明確に示しているWebサイトはあまり多くはありません。そのような連絡先をサイトごとに逐一探すくらいであれば、IPAに連絡するほうが手間が圧倒的に少なくて済みます。また、一般的な問い合わせ窓口

挙手の要求 聴衆の気を引くための古典的手段だけど、手を挙げた結果は以降の流れにはまったく役に立たない。 PlayStationとWii「どちらがWeb2.0的か」 予約語だけのソース見せて「これは何をするプログラムでしょう?」 Perlが好きな人！きらいな人！挙手 <img src=1.gif src=2.gif> どっちの画像が表示される？ 量で圧倒 普通ならLTの時間枠内で終わらない量を詰め込む。 100枚超えるプレゼンを5分で PolyglotコードをPerl/Ruby/Google/v8でそれぞれ動かすデモを5分に詰め込む ネタ画像 話の本筋とはぜんぜん関係ないどうでもよい部分で勝負用のネタ画像を表示する。 「ぐぐるな危険」 鈴木ヒロミツ画像 「おまえはすでに死んでいる」 話し方 話し方にあまり抑揚をつけない。盛り上げる部分でもテンション上げたりしない。むしろネタほどおとなしく。

XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） JSONPだって、セキュリティを気にしてほしい 皆さんこんにちは、はせがわようすけです。今回は、JSONPを使用する場合のセキュリティについて解説しましょう。 JSONPとは、JSON with Paddingの名称が示しているとおり、JSON形式のデータにコールバック関数の呼び出しのためのコードを付加することで、クロスドメインでデータの受け渡しを実現するためのデータ形式です。JavaScriptからクロスドメインでのデータが簡単に扱えることなどを理由に、多数のWebアプリケーションでAPIの一部としてJSONP形式でデータの提供が行われています。 具体的な例を見

今回は、「⁠先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />

今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1～4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U＋0000からU＋007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C（\⁠）⁠、0x2F（/）などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1　UTF-8でのビットパターン

こんにちは！近頃咳と痰と鼻水と鼻づまりがすごく多い、金曜日の天使ことhasegawayosukeです。 ActivePerlで任意のx86バイナリを実行しているようなときには、バイナリ部分のデバッグに結構手間取るときがあります。あまり準備に手間をかけずに気合いだけでad-hokに修正したいときは my $x86 = "\x8b\x44\x24\x08......"; print unpack( 'H2' x length( $x86 ), $x86 ); のように、実行するバイナリコードを目視で確認すればよいのですが、jmp命令が入るとアドレスの計算などがけっこう面倒になります。そんなときはやはりデバッガを使ってデバッグしたくなるのが人情なので、ActivePerlとデバッガをうまく連携させる方法を考えました。 Visual Studioがインストールされた環境では、「C:\Windows

今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃

前回に引き続き、UTF-7によるクロスサイトスクリプティング（XSS）について説明していきます。 UTF-7によるXSSは、攻撃対象のコンテンツの文字エンコーディングが不明瞭な場合に、そのコンテンツを被害者のブラウザ（Internet Explorer）で開いたときに、そのコンテンツの文字エンコーディングがUTF-7であるとIEに誤認させ、「⁠+ADw-script+AD4-」のようなUTF-7の文字列が有効なHTML要素として認識されるために発生します。 そして、「⁠文字エンコーディングが不明瞭」な具体的な状況として、以下のような条件のいずれかに該当するということを前回説明しました。 レスポンスヘッダ、meta要素のどちらでもcharsetが指定されていない charsetにIEが解釈できないエンコーディング名が指定されている meta要素でcharsetを指定しているときに、meta要

［無視できない］IEのContent-Type無視：教科書に載らないWebアプリケーションセキュリティ（2）（1/2 ページ） XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 無視できないIEの「Content-Type無視」問題 皆さんこんにちは、はせがわようすけです。 第2回では、Internet Explorer（以下、IE）の仕様でも特に悪名高い「Content-Type無視」について説明します。 IEのContent-Type無視問題は非常に複雑で、私自身も完全に説明できる自信はないのですが、それでもセキュアなWebアプリケーションを開発するうえで避けては通れない問題ですので、取り上げることにしました。

みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「⁠危険な文字列の検出」「⁠安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字

script の後ろにゴミを付け加えて、"<script" + XX + ">" のような表記にしてもスクリプトが動作する。XX に指定可能な文字は、IE6 では 0x00、0x09、0x0B、0x0C、0x20、0x2F。Firefox 1.5.0.7 では 0x08、0x09、0x20 となっている。というお話。 もう少し説明すると、IEでは 0x00 は完全に無視されますので、0x00 's' 0x00 'c' 0x00 'r' 0x00 'i' 0x00 'p' 0x00 't' のような表記でもスクリプトは動作します。また、0x0B や 0x0C はスペースと同意に扱われるようです。これらの応用としては、上記記事で挙げられている "script" の後ろに付け加えられるという例よりは <div (0x0B)onmouseover="...">のようなイベントハンドラの記述への適用

前回の続きの前に少しだけ。RIPさんの質問。 ところで、今回の内容を読んで気になっているというか悩んでる事。 今回の文章中の「Unicode」は、厳密には「UTF-16」と理解していいのだろか？ Windows 上での Unicode の標準的なエンコーディングですので、UTF-16LE と考えてください。ただし、いちいち Unicode と UTF-16、UTF-16LE という表記を使い分けるのも面倒なのと、Microsoft の文書類のほとんどが Unicode という表記になっており、それとの整合を合わせるためにも、UTF-16 または UTF-16LE と明記しなければならない状況でない限りは今後も Unicode と書くことにします。 さて、前回は WideCharToMultiByte を使用して Unicode を Shift_JIS に変換する場合に、WC_NO_BEST

Windows 上で Unicode を扱う場合に発生するセキュリティ上の問題点などについて不定期に書いていくことにします。以前の内容と重なる部分も多いですし、時間的にもどこまで書けるかわかりませんけれど…。 さて第1回目は、 Windows 上で Unicode を扱う際のもっとも基本とも言える WideCharToMultiByte を使用した Unicode から Shift_JIS (コードページ932)への変換についてです。 WideCharToMultiByte を使用する際に発生しやすい問題点は以下の2点です。 バッファサイズの指定ミスによるバッファオーバーフロー Unicode から Shift_JIS への変換における多対一のマッピング バッファサイズの指定ミスによるバッファオーバーフロー 変換前の Unicode の文字列は「文字数」で指定するのに対し(cchWideC

13~14일, 서울교육문화회관에서 개최 국·내외 해커들 실제 해킹시연 및 대응법 공개 국제 해킹/보안 컨퍼런스 POC2008(www.powerofcommunity.net/home.html)이 오는 11월 13 ~ 14일 2일간 서울 양재동 서울교육문화회관 거문고홀에서 열릴 예정이다. POC2008은 2006년에 시작돼 이번이 세 번째로 진행되는 POC 컨퍼런스다. 형식적인 논의에서 벗어나 실제 해킹/보안 기술만을 다루는 컨퍼런스로, 대부분의 발표자들이 실전해킹과 실전보안을 현장에서 직접 시연을 통해 보여주는 것이 POC만의 특징이다. 이것은 국내에서 열리는 형식적인 컨퍼런스와는 다르며, POC는 금전적 이익을 추구하지 않는 순수 비영리, 해킹 중심의 컨퍼런스로 자리매김하고 있다. 지난 1~2회에서는 GNU