I've found a bug in Firefox sanitizer that can be exploited if the result of sanitizeToString is used in a sink that doesn't parse the HTML using fragment parsing algorithm (examples being: iframe.srcdoc, data:text/html,markup etc.) Proof of concept Here's the proof-of-concept: <iframe id=ifr></iframe> <script> const bypass = `<svg><font color><title><u rel="</title><img src onerror=alert(document
今回はTrusted Typesに対する個人の見解を書いてみます。 Trusted Typesはブラウザが文字列を文字列以外の型として扱うSinkに対して、開発者に型の変換を強制するセキュリティ機能です。Trusted TypesによりDOM-based XSSを原理的に減らし、DOM-based XSSに対するセキュリティレビューを簡潔にすることが出来ます。 安全でないデフォルト近頃のWeb開発ではTypeScriptがよく使われるようになりました。これは型を明示することにより、エラーを事前に防げるからです。 セキュリティでも同じことが言えます。そもそもelement.innerHTMLにStringを代入出来ること自体が間違っているのです。innerHTMLはHTMLを代入する為のものであり、Stringを代入してもHTMLとして型の変換がされてしまうからです(i.e. re-pars
ウェブアプリケーションの高度化に伴い、セキュリティに対する関心も年々高まりつつあります。特にXSS(クロスサイトスクリプティング)と呼ばれる脆弱性は簡単ながらも大きな被害をもたらします。アプリケーションの開発者は当然セキュリティを意識した開発を行うべきですが、人間の注意は万能ではなく、時に不注意から脆弱なアプリケーションを作成してしまいます。 こういった状況を改善するために、Trusted Typesという提案がなされています。Trusted Typesはよりセキュアなウェブアプリケーションを作る手段を提供し、安全性を高める補助をしてくれます。 Trusted Types HTMLやJavaScriptは非常に柔軟な仕組みを有しており、要素を動的に組み立てることが可能です。例えば以下の例を見てみましょう: const { username, email } = await api.getU
HTML's DOM offers a number of mechanisms to turn arbitrary strings into markup (.innerHTML = ...) or code (scriptEl.innerText = ..., el.onclick = ..., etc). Each of these mechanisms can serve as an XSS sink, giving an attacker the ability to feed code into a context that wasn't expecting it, leading to a class of DOM-based XSS attacks that we'd very much like to avoid. One way of addressing this i
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
The latest release of Burp includes a new engine for static analysis of JavaScript code. This enables Burp Scanner to report a range of new vulnerabilities, including: DOM-based XSSJavaScript injectionClient-side SQL injectionWebSocket hijackingLocal file path manipulationDOM-based open redirectionCookie manipulationAjax request header manipulationDOM-based denial of serviceWeb message manipulatio
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's also very simple to use and get started with. DOMPurify was started in February 2014 and, meanwhile, has reached version v3.1.6. DOMPurify is written in JavaScript and works in all modern browsers (Safari (10+), Opera (15+), Edge, Firefox and Chrome - as well as almost anything else using Blink, Gecko o
リファラを使ったXSSの小ネタです。 今回取り上げるのは、ターゲット自身が、細工したページを経由することでつけられたリファラによって攻撃を受けるケースです。このような攻撃の場合は、現実に経由可能なページからでしか攻撃文字列を送りこむことができません。 例えば、以下のように、document.referrerをそのままdocument.write()しているページがあるとします。 http://vulnerabledoma.in/location/ リファラを書き出している部分でXSSできるでしょうか。 IEでは単純です。 IEはURLのクエリに、エンコードせずに「"<>」などを含めることができるので、これらを含むURLから、リファラを書き出しているページへ遷移させれば、XSSが起きます。 http://l0.cm/xss_referrer.html?<script>alert(1)</sc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く