安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scri
Cross Site Scripting Prevention - OWASP Cheat Sheet Series
Introduction Index Alphabetical Index ASVS Index MASVS Index Proactive Controls Index Top 10 Cheatsheets Cross Site Scripting Prevention Cheat Sheet¶ Introduction¶ This cheat sheet helps developers prevent XSS vulnerabilities. Cross-Site Scripting (XSS) is a misnomer. Originally this term was derived from early versions of the attack that were primarily focused on stealing data cross-site. Since t
XSSの攻撃手法いろいろ - うなの日記
html5securityのサイトに、XSSの各種攻撃手法がまとめられているのを発見せり!ということで、個人的に「お!」と思った攻撃をサンプルつきでご紹介します。 1. CSS Expression IE7以前には「CSS Expressions」という拡張機能があり、CSS内でJavaScriptを実行できたりします。 <div style="color:expression(alert('XSS'));">a</div> 確認 @IT -［柔軟すぎる］IEのCSS解釈で起こるXSS で詳しく解説されていますが、CSSの解釈が柔軟なことともあいまって自前で無害化するのはなかなか困難。以下のようなコードでもスクリプトが実行されてしまいます。 <div style="color:expr/* コメントの挿入 */ession(alert('XSS'));">a</div> 確認 <div s
ma<s>atokinugawa's blog
http://masatokinugawa.l0.cm/ 最近僕が発見し、修正されたTwitterの脆弱性を3つ紹介します。 1.旧Twitterの文字列処理に絡んだXSS 去年の夏くらいに、Twitter Web上で € 〜 ÿ の文字参照が含まれるツイートをXMLHttpRequestで読み込んだ際に表示が乱れるという問題に気付き*1、その時はこれは脆弱性には繋がらないだろうという判断をしたのだけど、今年の4月になって改めて調べたところ貫通しました。 表示が乱れるというのは、€ 〜 ÿ の文字参照が含まれるツイートがあると、一部の文字が\XXXXの形式に化けたり、ツイート周辺の「"」が「\"」になったりするものだったのですが、今回は「"」が「\"」になる点が脆弱性を発生させていました。 この条件でXSSさせようと思ったら、ツイートを細工してURL
はてなブログ | 無料ブログを作成しよう
ネイルで使う材料で、DIY時の木割れやネジ跡を派手にしたらかわいい OSB合板でちょっとしたボックスをつくりました。 ビス止め下手すぎて木を割ったり穴あけすぎたりした場所に、好きな派手色の樹脂を詰めてパテ代わりにしてみました。 ちょっと某HAYっぽみ出て可愛かったので、自分用にメモです。 手順 塗装 派手色グミジェルで失敗部分…
JavaScript変態文法最速マスター - 葉っぱ日記
Java変態文法最速マスター - プログラマーの脳みそをリスペクト。 JavaScriptの変態文法・技法一覧です。あんまり使わないけど、知ってるとXSSとか攻撃したいのにWAFに妨害されるなど、いろいろ制約があるという場合に便利。 文字列の生成 引用符を使わずにさくっと文字列を作る。fromCharCode とか使ってもいいけどめんどくさいので、正規表現やE4Xを利用。 alert( /string/.source ); alert( <>string</> ) 空白文字を使わず記述 文脈上、スペースを書きたいけれどいろいろ制約があって書けない場合にはコメントで代替。実行するコードを作り上げてevalしてもいいけど大袈裟なので。 var/**/x=1; */ を含むコードブロックをコメントアウト コードの塊りをコメントアウトしようと思って /* */ で囲むと、コード内に string.
location.hash の危険性 - 技術メモ帳
いわゆる、document.write するものには エスケープをしないと行けないのではあるが、 location.hash は、サーバーが生成する部分ではないため 見落としやすいのだろうなぁという事を最近思った。 たとえば、nun.nu というリダイレクタ。 古くからあったように思う。 http://nun.nu/ location.hash の値をそのまま document.write してしまっている。 もちろん、通常のリダイレクト先URLの部分に関してはきちんと HTMLの特殊文字のエスケープが行われている。 残念な事に結果的に、URLに #hogefuga のように指定する事によって XSS を行う事が出来てしまっているのである。 試しに、alert を出す実証コードをここに示す。(Firefoxでしか動作確認していない。) http://nun.nu/http://www.go
UTF-8の動的コンテンツをShift_JISと誤認させることで成立するXSS - masa141421356’s blog
文字コード指定の無い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="ユー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなダイアリーのヘルプ - はてなダイアリーXSS対策
[PDF] Our Favorite XSS Filters and how to Attack Them