Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types | Articles | web.dev
DOM-based cross-site scripting (DOM XSS) happens when data from a user-controlled source (like a username, or a redirect URL taken from the URL fragment) reaches a sink, which is a function like eval() or a property setter like .innerHTML that can execute arbitrary JavaScript code. DOM XSS is one of the most common web security vulnerabilities, and it's common for dev teams to accidentally introdu
リンクを作る時の target="_blank" の危険性 - 隙あらば寝る
html で リンクを新しいタブ(やウィンドウ)で開かせたい場合、target="_blank" を指定するが、 この使い方には落とし穴があるらしい。 www.jitbit.com リンクを開いた先の javascript から、開いた元のページを操作できてしまうとのこと。 気になったので確認してみた。 悪用のパターン insecure.html が最初に開くページで、ここに target="_blank" なリンクがある。 このリンクを押すと new_window.html を新しいタブで開く。 この new_window.html に javascript が仕込まれており、元ページを操作されるという話。 具体的には window.opener.location="./evil.html" と実行すると、元タブは evil.html に遷移する。 実際試してみたのが ここ。 リンクを開
target="_blank" で開くリンクには rel="noopener" をつける - Qiita
The performance benefits of rel=noopener - JakeArchibald.com より target="_blank" でリンクを開く場合は、rel="noopener"をつけておくのが良い。 管理画面などでは rel="noopener noreferrer"というかたちでnoreferrerをつけるとさらに良いかもしれない（参考：http://qiita.com/wakaba@github/items/707d72f97f2862cd8000 ） target="_blank" で開いたWindowは、 window.opener を使って親のWindowを操作することができる。つまりtarget="_blank"で開いたサイトで任意の操作ができてしまうことになるけど、Same origin の仕組みが働く。ので、Same originではない場
target="_blank" のセキュリティリスク(デモ動画あり)
HTMLを勉強する際に最初に覚えるものの1つにa要素(タグ)があります。HTMLのアイデンティティと言っても過言ではない、ハイパーリンクを実現する大事な要素です。 href属性に設定されたリンク先のURLをどのウィンドウ等に表示するかを決めるtarget属性というものがあります。任意の値を設定してウィンドウに名前を付ける事で、複数のa要素から同じウィンドウへリンク先URLを表示する事もできますし、常に新しいウィンドウを開く_blankのような、あらかじめ挙動が設定されている値もあります。 target="_blank" のセキュリティリスク リンクの開き方を決定するtarget要素ですが、この挙動を利用してリンク先からリンク元のウィンドウを操作できるというセキュリティリスクが公開されています。 Target="_blank" - the most underestimated vulner
恐怖のHTML5 ApplicationCache Poisoning
自己紹介 (SelfIntroduction) @kyo_ago ApplicationCache Poisoning歴1年3ヶ月の新米です。 (ApplicationCache Poisoning NEWBIE.)
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
これなら合格！ 正しいリダイレクターの作り方
これなら合格！ 正しいリダイレクターの作り方：HTML5時代の「新しいセキュリティ・エチケット」（4）（1/3 ページ） えっ、まだmeta refreshとか301使ってるの？ リダイレクターの作り方も時代とともに移り変わります。記事を読んだらすぐに使えるセキュリティ・エチケットを紹介しましょう。 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。今回は、「オープンリダイレクター」という脆弱性について説明します。 オープンリダイレクターとは？ オープンリダイレクターとは、あるURLを開くと自動的に他のページにジャンプするリダイレクト機能が、攻撃者によって任意の外部ページへのリダイレクターとして利用可能になっている問題です。 「http://example.jp」上で提供されるWebアプリケーションにて、例えば「http://example.jp/go?url=/nex
JavaScript文字列の動的生成におけるエスケープ - 葉っぱ日記
「JavaScript文字列を動的生成する」と一言で言っても、例えば <html>... <script> // HTML内のscript要素内に生成 var s = "ここに動的生成される"; </script> だったり、 <div onclick='foo("ここに動的生成される");'> だったり、 <script src="external.js"></script> // external.js var s = "ここに動的生成される"; だったり、さらに複雑な組み合わせだったりといろんな状況があって、基本的には「JavaScriptとしてのエスケープ」に加えてその外側の(場合によってはネストしている)コンテキストに応じたエスケープが必要、という話。 で、面倒だったら var s = decodeURIComponent( "ここに動的生成される" ); にして、生成する側はU
HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書
HTML5 は、WHATWG および W3C が HTML4 に代わる次世代の HTML として策定を進めている仕様であり、HTML5 およびその周辺技術の利用により、Web サイト閲覧者 (以下、ユーザ) のブラウザ内でのデータ格納、クライアントとサーバ間での双方向通信、位置情報の取得など、従来の HTML4 よりも柔軟かつ利便性の高い Web サイトの構築が可能となっています。利便性が向上する一方で、それらの新技術が攻撃者に悪用された際にユーザが受ける影響に関して、十分に検証や周知がされているとは言えず、セキュリティ対策がされないまま普及が進むことが危惧されています。 JPCERT/CCでは、HTML5 を利用した安全な Web アプリケーション開発のための技術書やガイドラインのベースとなる体系的な資料の提供を目的として、懸念されるセキュリティ問題を抽出した上で検討を加え、それらの問題
Manual - Documentation - Zend Framework
Caution: The documentation you are viewing is for an older version of Zend Framework. You can find the documentation of the current version at: https://docs.zendframework.com/zend-escaper/ Escaping Javascript — Zend Framework 2 2.1.5 documentation Zend\Escaper Escaping Javascript¶ Javascript string literals in HTML are subject to significant restrictions particularly due to the potential for unquo
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
swfobject.js がアレな話 - ほむらちゃほむほむ
もばいる全盛感のある世間的には今更，FLASH なんてどうでもいいし，swfobject.js 自体 2009年から更新されてないから，こんな古いものをと言われかねないような話ではあるものの，日本語での言及をあまり見てないし，つい先日もさる通信キャリアがトップページでやらかしてて多分知られてないんだろうなと思ったので書こうと思った次第． swfobject.js とは何か この記事の対象読者にとっては説明するまでもない話とはおもうけど一応前置きとして説明しておくと，swfobject.js は FLASH を web ページに埋め込むための JavaScript のライブラリ．クロスブラウザ対応してたり，面倒な HTML-tag のお作法を覚えなくても良くなったりとでデファクトスタンダードな感じのモノ．2007年とちょい古いがリクルートMTL の SWFObject v2.0 ドキュメント
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Live DOM Viewer++ | XSS Academy
Web Platform Security @ CMS Security Summit 2020
Tangled World of Web Technology ― Are we safe?
次世代プラットフォームのセキュリティモデル考察(前編)
[PDF] Electronの倒し方
文字列からHTMLを組み立てる話 Shibuya.XSS techtalk #5
Google Code Archive - Long-term storage for Google Code Project Hosting.
HTML5 Security Cheatsheet