http://blog.ohgaki.net/char_encoding_must_be_validated まあ、当たり前にはならないでしょう。どう考えても不正な文字エンコーディングを受け付ける言語やらフレームワーク、DB、ブラウザが悪いと思う。不正な文字エンコーディングをチェックするというのはバッドノウハウだと思うし。そんなことに対応するのは大変すぎるからねぇ。 アプリ開発者を啓蒙するより、PHPとか直したほうが早いと思うんだけど。 XSSやSQLインジェクションが発生しないようにエスケープ処理やバインド機能を使うというのは、プログラムの基本に立ち返って、どんなデータが渡されても正確に処理を実行するために必要なことなので、当たり前といえると思う。 でも、不正な文字エンコーディングのチェックはプログラミング手法ではなく、それを受け取って変に解釈してしまうDBやらブラウザなどが直せないから
(Last Updated On: )私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けにもう少し解りやすい
文字コードが引き起こすセキュリティ上の問題として、もっとも興味深いもののひとつである、Unicodeから他の文字コードへの「多対一の変換」で引き起こされる問題点について、今回と次回で説明します。 ご存じのとおり、Unicodeには非常に多数の文字が収録されていますが（現在最新版のUnicode 5.1.0では100,713文字が収録されているそうです）、Unicodeから他の文字コードへの変換においては、互換性や可読性の維持のためか、複数のUnicodeの文字が他の文字コードでは単一の文字に変換されることがあります。 この「多対一」の変換が、開発者も想定していなかったような問題を引き起こす原因となることが多々あります。 具体的な例として、Windows上でのUnicodeからの変換について説明します。 Windows上でのUnicodeからShift_JISへの変換 Windows上で
文字コード指定の無いUTF-8のコンテンツでは、ブラウザ側の文字コード自動認識でシフトJISと誤認させることで、HTMLの特殊文字を一切使わずにXSSが成立する場合があります。 原理 UTF-8 では１文字が３バイトマッピングされる場合があります。 そこで、これをShift_JISと誤認させると、３バイト目と次の１バイトをセットで１文字と誤認させることができます。これにより、HTMLの区切り文字の効力を失わせてスクリプトを注入することが可能です。 例："あ" = E3 81 82 なので、シフトJISと誤認すると "縺" (E381) +余分な先行バイトの 0x82 具体例 例えば、動的なコンテンツ（UTF-8で応答を生成） <html> <head> <title>abcde</title> </head> <body> <form> <input type=text value="ユー
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式（文字エンコーディング）においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
前回に引き続き、UTF-7によるクロスサイトスクリプティング（XSS）について説明していきます。 UTF-7によるXSSは、攻撃対象のコンテンツの文字エンコーディングが不明瞭な場合に、そのコンテンツを被害者のブラウザ（Internet Explorer）で開いたときに、そのコンテンツの文字エンコーディングがUTF-7であるとIEに誤認させ、「+ADw-script+AD4-」のようなUTF-7の文字列が有効なHTML要素として認識されるために発生します。 そして、「文字エンコーディングが不明瞭」な具体的な状況として、以下のような条件のいずれかに該当するということを前回説明しました。 レスポンスヘッダ、meta要素のどちらでもcharsetが指定されていない charsetにIEが解釈できないエンコーディング名が指定されている meta要素でcharsetを指定しているときに、meta要
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。（1）文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と，（2）文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング（1）――冗長なUTF-8符号化問題 まず，（1）の不正な文字エンコーディングの代表として，冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン（表1に再掲）を見ると，コード・ポイントの範囲ごとにビット・パターンが割り当てられているが，ビット・パターン上は，より多くのバイト数を使っても同じコー
今回から5回にわたって，アプリケーション全体に関する文字コードの問題と対策について説明する。文字コードがセキュリティとどう関わるのか，疑問に思うかもしれないが，Webアプリケーションで文字コードを指定可能な個所は非常に多く，しかも文字コードの選定や処理方法次第ではぜい弱性の原因になることが分かってきている（図1）。実は文字コードはWebアプリケーションのセキュリティ問題の最新の話題と言ってよい。 2008年10月に開催されたセキュリティ・イベントBlack Hat Japan 2008では，ネットエージェントの長谷川陽介氏が「趣味と実益の文字コード攻撃」と題して，文字コード問題の広範なプレゼンテーションを発表した 。そのプレゼンテーション資料が発表されている のでこの問題の詳細に関心のある方は参照されたい。ここでは，セキュアなWebアプリケーションを開発するために文字コードの問題をどのよう
第02回まっちゃ445の懇親会の帰りに考えていた事なのですが、メモし忘れていたのであらためて。 HTMLの中に変数を出力する際、何も考えずに文字列をそのまま出力すると、HTMLのマークとみなされる文字が含まれていた場合にまずいことが起こります。たとえば#PCDATAの中に出力する場合、「<」や「&」がそれぞれSTAGOやEROとして解釈されますので、これらをそのまま出力しないようにする必要があります。以下のように文字実体参照に置き換えるのが一般的です。 < → <& → &同様に、二重引用符で括られた属性値リテラルに出力する場合は「"」と「&」がマークとして解釈されます。XHTMLの場合は「<」も書けないことになっていますので、これも置き換える必要があります。 " → "< → <& → &※#PCDATAの中で「"」を変換しても問題は起きないので、多
【PostgreSQLウォッチ】第27回 SQLインジェクション脆弱性を修正，日本語ユーザーに大きな影響 連載目次へ >> SQLインジェクションに関する脆弱性の修正などを行ったPostgreSQL 8.1.4,8.0.8，7.4.13，7.3.15の各バージョンが，5月23日一斉にリリースされた（関連記事）。いずれも同じメジャーバージョン系列であれば，dump/restoreによるデータ移行なしでアップグレードできる(ただし，8.1，8.1.1から8.1.4への移行については注意が必要。詳細は付属のリリースノートを参照されたい)。 修正が提供されないPostgreSQL 7.2以前のバージョン 今回対策された脆弱性はPostgreSQL 7.2以前にも存在するが，開発者のポリシーにより，7.2以前はサポートの対象になっていない。いまだに7.2 以前のバージョンを使っているユーザーは，7.
朝ごはんをたべていたら思いついたのでどんなものなのか皆さんに伺ってみたくなりました。 ○クロスドメインアクセス対策例JSON、JSONP、JavaScriptで機密情報を配信する場合、クロスドメインアクセスの対策（＝クロスドメインアクセスを不可能にする対策）が必要になります。 以下にSea Surfers MLで議論されていた方法を紹介します。 (一部省略 by hoshikuzu) 方法２．while(1)、およびコメントアウト法サーバ側がデータの先頭にwhile(1) {}をつける、または全体をコメントアウトした状態で返し、クライアント側でこれを取り除いてevalする方法です。方法１と考え方としてはほとんど変わりません。while(1)の方法はGMailでも使われています。 ここでのコメントアウト法が果たして有効なのかどうか答えを知りたく思います。教えて君になっていますが、まことにすみ
[Namazu-users-ja 1051] [技術資料] Namazu 2.0.18 に新設された Charset ディレクティブ関連の話 Tadamasa Teranishi yw3t-trns ＠ asahi-net.or.jp 2008年 3月 12日 (水) 21:45:27 JST 前の記事 [Namazu-users-ja 1050] 日本語全文検索システム Namazu 2.0.18 リリース 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ] 寺西です。 Namazu 2.0.17 以前の namazu.cgi はデフォルトではレスポンスヘッダの ContentType に charset を出力しません。 この時、Web ブラウザの charset 自動認識の誤認により脆弱性の問題が 起こることがあります。 http://www.namazu.o
基本方針 最新版はおそらく安全だとは思いますが、確実とは言えません。 Namazu は完全に無保証です。すべてあなたの責任のもとに運用し てください。ただし、セキュリティの問題にはできる限り対応する つもりです。まずい点を見つけたら連絡してください。 既知の問題 2.0.20 または 2.0.20 より古いヴァージョンには、 IE6,7の脆弱性対策ができていません。 このため Namazu 2.0.21 以降を利用することを推奨します。 2.0.19 または 2.0.19 より古いヴァージョンには、 バッファオーバーランの脆弱性があります。 2.0.17 または 2.0.17 より古いヴァージョンには、 Web ブラウザのエンコード自動認識の誤認による UTF-7 エンコーディングされた検索式の脆弱性があります。 2.0.15 または 2.0.15 より古いヴァージョンには、ディレクトリト
Namazu 2.0.17 以前の namazu.cgi はデフォルトではレスポンスヘッダの ContentType に charset を出力しません。 この時、Web ブラウザの charset 自動認識の誤認により脆弱性の問題が 起こることがあります。 http://www.namazu.org/security.html しかし、Namazu 2.0.6 以降には namazu.cgi で出力するレスポンスヘッダの ContentType を .namazurc で直接指定する機能を有しています。 ContentType "text/html; charset=EUC_JP" など明示的に指定することでレスポンスヘッダの ContentType に charset を 出力することができ、この脆弱性の問題を回避することができます。 ただし、この場合は charset の値が固定され
IPAによる「安全なウェブサイトの作り方」の改定第3版が出ていました。あちこちにUTF-7によるXSSネタが出てきているんですが、いくつか気になる点がありました。 まずはP.25から。 HTTP のレスポンスヘッダのContent-Type フィールドには、「Content-Type:text/html; charset=us-ascii」のように、文字コード(charset)を指定することができますが、この指定を省略した場合… 安全なウェブサイトの作り方 改定第3版 (P.25)より。charset をきちんとつけようという例で US-ASCII を示すのはあまり頂けないなと思います。Internet Explorer においては、US-ASCIIの場合は最上位ビットを無視するという問題が2006年から放置されてますので、US-ASCIIを指定してもそれはそれでWebアプリケーション開発
■ [Security] 文字コードとXSS (書きかけ) 例によってセキュリティホールmemoより。厄介ですねぇ……。 キチンと全文書に文字コード指定をしておく マイナーな文字コードで送信するときは、対応環境と影響を考えておく。 不安なら ASCII 完全上位互換の文字コード (ASCII の有効バイトは常に ASCII と同じ意味を持つ EUC-JP、UTF-8 など) を使う。 cross-site injection で META が埋め込めるとかは論外。 位は比較的簡単だし、やっておかないといけないかな。 で、ちょっと気になっているのとしては、とりあえず、UTF-7 はやばやばなのは明らかとして、 ISO-2022-* への派生している議論はちょっとずれている気がしている。 とりあえず、 Bugzilla.jp の 4868: ASCIIと互換性のない文字コードはユーザーの指定で
おくればせながら下記を拝見しました。 UTF-7 XSS Cheat Sheet Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. 上記のような対策を必要とするサイトでは放置しておけばUTF-7系のXSS以外でもXSSの危険性は存在しうると思われます。ですので… あと、ヤマガタさんの反応を読みながら思ったんですが、一般的なXSS対策で「<」「>」などを「<」「>」にエスケープするように、機械的に「+」を「+」にエスケープしてやれば、万が一のときでもUTF-7によるXSSを防げるような気もしたんですけど、あまり深く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
