知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法：HTML5時代の「新しいセキュリティ・エチケット」（3）（1/2 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。前回は、同一オリジンポリシーを突破する攻撃の代表的事例であるXSSについて、特にDOM based XSSと呼ばれるものについて解説しました。今回はその続きとして、XMLHttpRequestによるXSSを解説します。 XHR Level 2によるリモートからのコード挿入によるXSS 従来、XMLHttpRequest（以下、XHR）は、表示しているドキュメントと同じオリジン（オリジンについては第1回を参照）としか通信できませんでしたが、現在の主要なブラウザーではXHR Level 2と呼ばれる実装により、オリジンを超えて通信することが可能になっています。 これは、Jav
Webアプリ開発者のためのHTML5セキュリティ入門
Enterprise x HTML5 Web Application Conference 2014の発表資料です。
PHPのJSONのエスケープ
(Last Updated On: 2023年12月8日) 追記：最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。 JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。 PHPにJSON形式のデータに変換するjson_encode関数とjson_decode関数をサポートしています。 JSON関数がサポートされている
GoogleのJSON(モドキ)の先頭にwhile(1); がつく理由 - 葉っぱ日記
なぜGoogleはJSONの先頭に while(1); をつけるのか #JavaScript #HTML #Ajax #StackOverflow - Qiita これはクロスサイト・リクエスト・フォージェリ対策。違うよ！全然違うよ！ 攻撃者の作成した罠ページにてJSONを<script src="target.json">みたいに読み込んで、ゴニョゴニョやることでJSON内の機密情報に攻撃者がアクセス可能というのは合ってるけど、それを「クロスサイト・リクエスト・フォージェリ」とは言わない。無理に何か名前をつけて呼ぶとすれば、「JSON Hijacking」という俗称や、あるいは単純にクロスサイトでの情報漏えい、程度ですかね。 ちなみに、ArrayコンストラクタやObjectでのアクセサを定義してJSONをJSとして読み込んで内部にアクセスする手法は、現在のところ公にされているところでは古
Masato Kinugawa Security Blog: エンコーディングの切り替えによるSelf-XSSを考える
Shift_JISにすると、UTF-8でひらがなの「く」を構成する「0xE3818F」の先頭2バイトが、まず「縺(0xE381)」という文字と解釈され、残った「0x8F」が、後続の、二重引用符のエスケープシーケンスである「\(0x5C)」と１つの文字、「十(0x8F5C)」を作ってしまうのです。これにより、エスケープシーケンスがなくなった二重引用符は、そこで文字列リテラルを閉じることになります。こうして、その後ろに書かれたアラートが動いてしまうという訳です。 つまりこれは、攻撃者に誘導され、ユーザー自身が文字エンコーディングを切り替えた場合、本来XSSがないページでもXSSが起こせる場合があるということです。 IE以外のブラウザは、親フレームのエンコーディングを変更した場合、クロスドメインでも子フレームのエンコーディングまで変更するので、こんな誘導の仕方もできます。 http://l0.c
CSRF Attack using JavaScript | Base Lab
Most of you are aware of the CSRF attack. I use JS on a daily basis but I actually never thought that the code I develop could be CSRF-prone. You saw that coming - I was wrong and I want to share that harsh lesson. Let’s assume you’re developing a web app called omg-app.com (obviously because it’s so good it will make everyone say OMG!). The app is getting bigger, lots of people use it, new featur
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
JavaScript must die
Gian said... Nice presentation. I'm reasonably ignorant about Javascript security issues, because I never got past the fact that the language is a bit of a dog. Which is why I was advocating proof-carrying code to replace JS: http://www.plsadventures.com/2009/08/worrying-trends-in-programming.html The logistics of such a thing are still a little vague, but it appears to me that fine-grained securi
JavaScriptが10年ぶりのバージョンアップ、ECMAScript 5th Edition
12月15日、JavaScript、正式にはECMAScriptと呼ばれる言語の仕様策定が完了したとEcma Internationalが発表しました（ECMAScriptは、JavaScriptの基となる仕様の名称です）。 今回承認されたのはECMA-262 5th edition（ECMAScript 5th Edition）と呼ばれる仕様で、いわゆるJavaScript 2.0と呼ばれるものです。12月3日にはEcma Internationalの第98回総会において承認されていました。 （追記：ECMAScript 5th EditionがJavaScript 2.0として実装されるかどうかは不明でしたので、修正します。タイトルにも「JavaScript 2.0」が含まれていたので、タイトルも合わせて変更しました。） ECMAScriptの最新仕様は4月に最終候補が提出されており、
［さらに気になる］JSONの守り方
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） 次は、JSONにおけるセキュリティ対策 皆さんこんにちは、はせがわようすけです。第4回「［気になる］JSONPの守り方」はJSONPについて説明しましたので、今回は「JSON」についてもセキュリティ上注意すべき点について説明します。 JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。 まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。 ［サーバ側］ HTTP/1.1 200 OK Content-Type: application/json; charset=
教科書に載らないWebアプリケーションセキュリティ 第1回 ［これはひどい］IEの引用符の解釈 − ＠IT
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 小さな話題が面白い 皆さん、はじめまして。はせがわようすけと申します。 「教科書に載らないWebアプリケーションセキュリティ」ということで、Webアプリケーションのセキュリティに関連する、普段あまり見掛けないような小さな話題を取り上げていきたいと思います。 セキュアなWebアプリケーションを実現するために、開発者の方だけでなく、Webアプリケーションの脆弱性検査を行う方々にも読んでいただきたいと思っています。重箱の隅を楊枝でほじくるような小さな話題ばかりですが、皆さんよろしくお願いします。 さて第1回は、Internet ExplorerがHTMLを解釈する際の引用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
http://www.adsafe.org/
google-caja -Project Hosting on Google Code
SecureStore 1.0 Proposal | NCZOnline
Towards more secure client-side data storage - Human Who Codes