IE9以降でもHTMLフォームでファイル名とファイルの中身を外部から指定できる
昨日の日記「IE8以前はHTMLフォームでファイル名とファイルの中身を外部から指定できる」にて、福森大喜さんから教えていただいた内容として、ファイルアップロードのHTMLフォーム（enctype="multipart/form-data"）にて、アップロードするファイル名とファイルの中身を外部から指定できることを報告しました。この際にIE8以前という条件がありましたが、今度は、三井物産セキュアディレクションの望月岳さんから、「それIE9以降でもできるよ」と教えていただきました。既にご存じだったそうです。福森さん、望月さんという日本を代表するバグハンターから「秘伝のたれ」をおすそわけいただいたようで、興奮気味ですw まず、おさらいとして、IE8以前でのパターンは下記の通りでした（要点のみ）。 <form enctype="multipart/form-data" action="pro_ad
機密情報を含むJSONには X-Content-Type-Options: nosniff をつけるべき - 葉っぱ日記
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
JSONのエスケープをどこまでやるか問題 - 葉っぱ日記
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
教科書に載らないWebアプリケーションセキュリティ 第1回 ［これはひどい］IEの引用符の解釈 − ＠IT
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 小さな話題が面白い 皆さん、はじめまして。はせがわようすけと申します。 「教科書に載らないWebアプリケーションセキュリティ」ということで、Webアプリケーションのセキュリティに関連する、普段あまり見掛けないような小さな話題を取り上げていきたいと思います。 セキュアなWebアプリケーションを実現するために、開発者の方だけでなく、Webアプリケーションの脆弱性検査を行う方々にも読んでいただきたいと思っています。重箱の隅を楊枝でほじくるような小さな話題ばかりですが、皆さんよろしくお願いします。 さて第1回は、Internet ExplorerがHTMLを解釈する際の引用
IE7 によるファイルアップロード時のフルパスの送信 - 葉っぱ日記
Internet Explorer 6 では、<input type="file"> を使用してファイルのアップロードを行うときに、ファイル名をフルパスで送信するため、マイドキュメントなどに置かれてるファイルをアップロードすると、ログインユーザ名がサーバ側に漏洩するという問題がありました*1。 例えば、マイドキュメントに置かれているファイルを送信した場合、IEから送られるリクエストは以下のようになります(抜粋)。 POST /upload.cgi HTTP/1.1 Content-Type: multipart/form-data; boundary=---------------------------7d611f24420292 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.432
高木浩光＠自宅の日記 - IE 7の普及でサーバ証明書失効によるトラブルが表面化する
■ IE 7の普及でサーバ証明書失効によるトラブルが表面化する Internet Explorer 6まででは、「サーバー証明書の取り消しを確認する」の設定（「インターネットオプション」の「詳細設定」タブのところにある）が、デフォルトでオフになっていたが、IE 7で、これがデフォルトでオンになった。 Internet Explorer 7 における HTTPS セキュリティの強化点, Microsoft Windows Vista にパフォーマンス強化および OCSP プロトコルのサポートが追加されたことで、Windows Vista 上で実行される IE７ では既定で失効状態のチェックが有効になり、セキュリティが強化されます。 この影響が出始めているようだ。 QNo.2856522 証明書エラーがでてしまいます・・, 2007年3月22日 ビスタに変えてから、XPの時に普通に入れていたサ
フィードリーダーの脆弱性まわりのこと
最近、FreshReaderに脆弱性があったということで、いくつか調べて直したり、赤松さんと連絡取り合ったり、それからはてな使ってないのにユーザー様とか書かれて不愉快な気分になったりしてたんですが。 この記事はひどすぎると思う。 フレッシュリーダーの脆弱性に関連してSage++のこと そもそもの問題として「ローカルディスク上のHTMLファイルをブラウザで開くと超危険」です。XMLHttpRequestやIFRAMEでローカルファイルの内容を読み取れるからです。Sageに脆弱性があるということは、あらゆる個人情報の漏洩につながります。「開発者の個人情報を晒すリスクが云々」というのは、個人的には分からなくもないですが、ユーザーの個人情報を危険に晒していることを認識すべきです。 開発者本人が過去に書いているので、危険性の大きさは十分に認識できているはずです。「脆弱性がある」と公表してしまった時点
sta la sta - たった1行のJavaScriptコードでInternet Explorerをクラッシュさせる方法
注意！ IEを使用中の方は、リンク先の記事内にクラッシュコードのあるサンプルページへのリンクがあるので、クリックしないようにくれぐれもお気をつけ下さい！ 「you can find the code here」の「here」にあります。クラッシュをテストしたい方は別ですが。 http://www.modernlifeisrubbish.co.uk/how-to-crash-internet-explorer.asp 普段、ネットサーフィンでIEを使用している方にとっては、あまり嬉しくない話だろう。 こちらの記事の方がIEとFireFoxの両方で動作するJavaScriptコードを書く仕事をしている最中に、偶然にも、IEをクラッシュさせるコードを見つけてしまったそうな。 そのコードは複雑怪奇なものではなく、以下のようなたった1行のコードのようだ。 記事内に、上記コードを仕組んだサンプルページ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
