この記事は脆弱性"&'<<>\ Advent Calendar 2014の17日目の記事です。今日は少し昔話をしようと思います。がはは。 かつて、日本製TwitterのようなWassrというサービスがありました。当時、Twitterは数日に一度くらいはサービスが落ちていて、Twitterユーザーも「またか」と思いながら我慢して使うようなサービスであり、Twitterが落ちるたびにWassrはユーザーを増やすとともに、画像の添付のように当時Twitterにはまだなかった機能をどんどんアグレッシブに取り入れていく、使っていて楽しいサービスでした。 さて、そんなWassrがある日絵文字機能を導入しました。当時はUnicode絵文字もなくスマートフォンも普及しておらず、主にレガシーな携帯電話で使える絵文字をなんとかWeb上でも使えるようにしたという感じのものでした。 絵文字をパレットから選択すると
HTML5に関連したセキュリティの話題で、とりあえずこれまでに話した資料の一覧や、考察した記事。今後もっと増える予定です。「このAPI使う上で気を付けることないの？」みたいなリクエストもあればぜひ言って下さいませ。 JavaScript Security beyond HTML5 (2013-09-20 Developers Summit Kansai 2013) HTML5セキュリティ その1:基礎編、XSS編 (2013-06-13 OWASP Night 6th) Web::Security beyond HTML5 (2012-09-28 YAPC::Asia 2012) HTML5時代のWebセキュリティ (2012-09-15 第5回愛媛情報セキュリティ勉強会) Same-Origin Policy とは何なのか。 - 葉っぱ日記 XMLHttpRequestを使ったCSRF対
localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して
Ajaxなアプリケーションにおいて、サーバからJSONを返す場合に、JSON自体はvalidであるにも関わらず、(IEの都合で)エスケープが不足していて脆弱性につながってる場合があるので、書いておきます。 発生するかもしれない脆弱性 JSONのエスケープが不足している場合に発生する可能性のある脆弱性は以下の通りです。 JSON内に含まれる機密情報の漏えい XSS それぞれの詳細については後述します。 開発側でやるべきこと 文字列中のUnicode文字は "\uXXXX" な形式にエスケープするとともに、ASCIIな範囲であっても「/」「<」「>」「+」も同様にエスケープすることにより、前述の脆弱性を防ぐことができます。 Perlであれば、以下のような感じになります。JSON->ascii(1) に続けて、JSON文字列を正規表現で置換しているあたりがキモになります。 use utf8; u
ローカルのHTMLファイルからどこまで読み取れるか選手権 2011 - 金利0無利息キャッシング – キャッシングできます - subtech を読んでの補足。 IE9 on Windows 7 においてXHRを使ってローカルファイルを読み取る場合について、「許可するとやりたい放題」と書かれているとおり、IEが表示する警告をいったん「許可する」側に選択するとhtml内の JavaScript (あるいはVBScript)において通常のローカルのプログラムと同様にあらゆる操作が可能になります。(写真は英語版IE9) これは、IE6 / XP SP2 以降で導入された「ローカルコンピュータのロックダウン」が解除された状態になり、WSHやHTAと同様に、ローカルリソースへのアクセスや任意のActiveX Objectの生成を含め任意のコード実行が可能な状態になったということです。 ローカルに置い
Eric Lawrence さんから、IE9 RC Minor Changes List - EricLaw's IEInternals - Site Home - MSDN Blogs の翻訳の許可をもらったので訳してみました。間違い等あれば教えてください。 遡ること9月に、私はIE9のマイナーな変更点のリスト*1を公開しました。今日は、IE9リリース候補版で変更された点について紹介します。注意：このリストは当時言及しなかったBetaでの変更点もいくつか含んでいます。 もちろん、ここには含まれていない多数の変更点があるので、この記事を完全なリストとは思わないでください。また、IEBlog上で論じられているような大きな機能変更については意図的に飛ばしている点にも注意してください。 過去にこのブログで論じた、IE9の新機能や改善点については BetterInIE9タグを検索することで参照でき
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
id:hoshikuzu さんが言ってたので書いてみた。こんな感じ↓。コードはすぐ書けたけど、この記事書くのに30分以上かかってる気がする。 javascript:(~~[])[<_>{/...$/({})[~~[]][~~[]]}{/../({})[~~[]][1]}{/...$/({}[{}])[ ~~[]][~~[]]}{/..$/(!{})[~~[]][~~[]]}{/./(!![])[~~[]][~~[]]}{/...$/(!![])[~~[]][ ~~[]]}{/..$/(!![])[~~[]][~~[]]}{/...$/({})[~~[]][~~[]]}{/./(!![])[~~[]][~~[]]}{ /../({})[~~[]][~~!![]]}{/...$/(!![])[~~[]][~~[]]}</_>][<_>{/...$/({})[~~[]][~~[] ]}{/../
javascript:(ﾟΘﾟ)=ﾟωﾟﾉ=3, (/｀ｍ´）ﾉ ~┻━┻ //*´∇｀*/)javascript:(ﾟДﾟ) =_=3; /^_^/ [-_-1] - /;*_*/ とりあえずエラーなく動くというだけで、実行結果にも絵にもまったく意味はないです。任意のコードをAAだけで実行させるのは、まだまだ遠い道のりです。
Java変態文法最速マスター - プログラマーの脳みそをリスペクト。 JavaScriptの変態文法・技法一覧です。あんまり使わないけど、知ってるとXSSとか攻撃したいのにWAFに妨害されるなど、いろいろ制約があるという場合に便利。 文字列の生成 引用符を使わずにさくっと文字列を作る。fromCharCode とか使ってもいいけどめんどくさいので、正規表現やE4Xを利用。 alert( /string/.source ); alert( <>string</> ) 空白文字を使わず記述 文脈上、スペースを書きたいけれどいろいろ制約があって書けない場合にはコメントで代替。実行するコードを作り上げてevalしてもいいけど大袈裟なので。 var/**/x=1; */ を含むコードブロックをコメントアウト コードの塊りをコメントアウトしようと思って /* */ で囲むと、コード内に string.
jQueryを使うと、ajax 経由で取得した XML ドキュメントのような、ブラウザ(window,document)と切り離された対象でも簡単に操作することができます。例えば、リモートから取得したRSSであれば、以下のようなコードで各項目(item)のタイトル(title)やリンク先(link)、日時(dc:date)を取得することができます*1。 $.ajax( { url : "http://www.example.com/rss.xml", dataType : "xml", type : "get", success : function( xml ){ var s = ""; $( xml ).find( "item" ).each( function(){ s += $(this).find( "title" ).text() + " <" + $(this).find(
http://www.st.ryukoku.ac.jp/~kjm/security/memo/2009/05.html#20090513__Google2より 任意の期間には設定できないのかな。 適当にパラメータ指定すればできますね。 http://www.google.com/search?q=TAKESAKO&hl=ja&lr=lang_ja&sa=N&output=search&tbs=qdr:d3&tbo=1 あるいは http://www.google.com/search?q=TAKESAKO&hl=ja&lr=lang_ja&as_qdr=m2 利用できるのは y:年、m:月、d:日、h:時間、n:分、s:秒、w:週 あたりみたいです。もっとも、秒などを指定してもあまり意味はないようですが。 ちなみに、英語指定(パラメータでhl=en)のときは、tbs に sbd:1 を追加
第13回Admintech.jp勉強会 を無事開催することができました。参加された皆様、本当にありがとうございました。参加者のみなさんがいるからこそ勉強会が成り立っています! 次回も是非ご参加をお願いいたします。 いろいろ内容のメモを書こうと思ったのですが、おそらく各講師の方から発表資料(の抜粋)が後日公開されるのと、id:heavenshell さんが非常にすばらしいまとめを書いてくれていますので、それを見てくださいませ(id:heavenshell さん、ありがとうございます!!) というわけで、私の発表資料を http://utf-8.jp/public/20080927/h6.html?file=data.txt に置いておきます。id:amachang の s6 を改造して、プレゼンデータをHTMLの外に追い出して、テキストファイルにはてな記法に近い形で書けるようにしています(h
IEBlog : IE8 Security Part IV: The XSS Filter について、記事を書いた David Ross さんに翻訳許可をもらいましたので、訳してみました。誤訳や指摘がありましたらガンガン突っ込みをお願いいたします(他の記事も時間をとって訳していこうと思います)。当然ながら、これは私が私的に訳したものであり、Microsoftによる公式な翻訳/見解ではありません。 (訳注追加) 「reflected / Type-1 XSS」というのは、攻撃コードが被害者からのリクエスト自身に含まれるタイプのXSSで、サーバ側のアプリケーションでユーザからのリクエストに含まれる攻撃コードを「反射的」に返すような種類のXSSです。典型的には「"><script>...」のような語を検索したときに <input type="text" value=""><script>..."
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
まっちゃさんが困ってるみたいなので。こんな感じで CustomRule.js を書き換えると、任意のヘッダを追加/書き換えできます。X-FORWARD-FOR も同じ感じで書き換えできます。(書き換えても、プロキシで上書きされる予感) class Handlers { //この2行を追加 public static RulesOption("Add X-MyOriginal-Header") var m_AddXMyOriginal: boolean = false; (中略) static function OnBeforeRequest(oSession:Fiddler.Session) { //この3行を追加 if (m_AddXMyOriginal ){ oSession.oRequest[ "X-MyOriginal-Header" ] = DateTime.Now.ToStri
Fiddler2は Proxy 型の HTTP デバッガで、送受信のルールを JScript で柔軟に記述することで様々なカスタマイズができます。例えば、IE では止めにくい Referer も、Fiddler のルールをカスタマイズすることで簡単に止めることができます。手順は次のとおり。 まず、Fidller の "Rules" メニューから "Customize Rules..." を選択すると、メモ帳で "CustomRules.js" が開かれるので、以下のように記述します。 class Handlers { //この2行を追加 public static RulesOption("Disable Referer") var m_DisableReferer: boolean = false; //これより下は元のまま。 public static RulesOption("Hid
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
はてブで 「すべてをエンコードすると決めた」といいながらメタキャラクタしかエスケープしないのはなぜ？ と書いたら、b:id:HiromitsuTakagi さんに /↓hasegawayosuke「なぜ」<意味不明 / と言われてしまいますた。 全ての文字をエスケープしようなどと非現実的なことは言わないけれど(とはいえMicrosoft Anti-Cross Site Scripting Libraryのようにほとんど全ての文字を実体参照に置き換えるものもあるので、あながち非現実的とも言えないのかも知れない)、エスケープ対象を「'」「"」「<」「>」「&」の5文字に限定しているのは何かこの記事に書かれていない理由があるはずだと思ったからです。 この5文字さえ確実にエスケープしていれば XSS が防げるかというと、多分そうでもないだろうと個人的には思うわけでして。 例えば IE ではバックク
少し前に JSONP が XSS を引き起こすかもしれないという点に関する興味深い記事を奥さんが書かれていました。 Kazuho@Cybozu Labs: JSONP - データ提供者側のセキュリティについて JSONP における Padding 部分(だけでなくJSON部分も。4/5追記)に攻撃者が HTML と解釈可能なスクリプトを注入することにより、JSONP なデータを直接 IE で開いた場合に HTML と解釈され XSS が発生する、という点について書かれています。 ここで、IE が JSONP を HTML と解釈する理由は以下の2点。 IEのよく知られた機能「拡張子ではなく、内容によってファイルを開くこと」により、内容が HTML っぽい場合には、Content-Type: text/javascript が無視され HTML として解釈される。 上述の設定が「無効」に設定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
