Shibuya.XSS techtalk #10 の発表資料です。
Shibuya.XSS techtalk #10 の発表資料です。
Product { this.openCategory = category; const productMenu = document.querySelector('.product-menu'); window.DD_RUM.onReady(function() { if (productMenu.classList.contains('show')) { window.DD_RUM.addAction(`Product Category ${category} Hover`) } }) }, 160); }, clearCategory() { clearTimeout(this.timeoutID); } }" x-init=" const menu = document.querySelector('.product-menu'); var observer = new Muta
前回、XSSAuditorのバイパスのチートシートを作ったという記事を書きましたが、さきほど、IE/EdgeのXSSフィルターのバイパスも公開しました。 https://github.com/masatokinugawa/filterbypass/wiki/Browser's-XSS-Filter-Bypass-Cheat-Sheet#ieedge%E3%81%AExss%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF%E3%83%BC この公開に合わせて、今日は強力なIE/EdgeのXSSフィルターのバイパスを1つ紹介しようと思います。 このバイパスはPOST経由以外の全てのReflected XSSで使えます。1年以上前に以下のようなツイートをしましたが、今から紹介するのがこのとき発見したベクターです。 I found pretty useful IE XSS
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
2月頃、リッチテキストエディタの TinyMCE のXSS脆弱性を報告しました。 特にセキュリティの修正をしたといったアナウンスはありませんが、数日前に公開された4.3.9でこの問題が修正されています。Twitterのプロフィールにも、「World's #1 most popular open source #WYSIWYG editor」 とあるくらい、世界的にも非常によく使われているリッチテキストエディタのようですので、更新を促すためにこの記事を書きます。 XSS脆弱性は 4.3.8 以下のバージョンにあります。 僕の知る限りでは、TinyMCEのPreview Plugin機能を使っていなければ影響を受けません。 この機能を呼び出さないようにするか、4.3.9以上に更新してください。 これ以下は、技術的な説明になります。この脆弱性の発生原因は、技術的にも少し面白いです。 発火する場所
Update: English version is here: http://mksben.l0.cm/2016/04/easyxdm-xss-docmode-inheritance.html ------------------ EasyXDM というクロスドメインでのあれこれを便利にしてくれるライブラリの 2.4.20 で、自分の報告したXSS脆弱性が修正されています。使っている人はアップデートしましょう。 Release Security update - 2.4.20 · oyvindkinsey/easyXDM · GitHub https://github.com/oyvindkinsey/easyXDM/releases/tag/2.4.20 以前にも脆弱性が指摘されていますが、それとは別の問題です。 http://blog.kotowicz.net/2013/09/exp
Today's topic is attacks against browser's XSS filter. XSS filter is a security function built in browsers. It aims to reduce the actual exploitation risk when web applications are vulnerable to XSS. The filter is regarded as a “best-effort second line of defense”. This means the filter is not expected to block 100% of attacks in the first place. The “first line” here is conventional security meas
A few days ago, I made a poll on Twitter to see what people think is the worst setting for the XSS filter/auditor. The results are very surprising: Which header setting of XSS filter/auditor do you think is the worst? — File Descriptor (@filedescriptor) March 17, 2016 In short, the worst goes to X-XSS-Protection: 0, followed by X-XSS-Protection: 1; mode=block, and finally X-XSS-Protection: 1 being
XSSパターン(暫定版) XSSのパターンを幾つか集めてみました。出典は下の方にあります。 1.'';!--"<XSS>=&{()}``\" テスト文字列。まずはこの文字列を突っ込む。 2.<script>alert(1);</script> 単純なパターン 3."><script>alert(1);</script> 単純なパターン2 4.<script src=http://nootropic.me/xss.js></script> ダブルクォートやシングルクォートが使えない際 5.<ScrIpt>alert(1);</SCript> 単純にscriptタグが禁止されている際に使用出来る。他のタグでも使うことが出来る。 6.<a onmouseover="alert(document.cookie)">XSS</a> aタグを使用したXSS。 7.<a onmouseover=aler
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く