XSS フィルター回避チートシート - OWASP
この資料は、アプリケーションのセキュリティテストを行う技術者に、クロスサイトスクリプティングのテストを支援するガイドを提供することに重点を置いています。この資料の初期版は、RSnake から OWASP に寄付されたもので、彼のセミナーの XSS チートシートが元になっています(http://ha.ckers.org/xss.html)。現在このサイトにアクセスすると、この新しいサイトにリダイレクトされるようになっており、今後はここで保守や強化が行われる予定です。最初に作成された OWASP 対策チートシート、XSS (クロスサイトスクリプティング) 対策チートシートは、RSnake の XSS チートシートをベースにしています。彼に謝意を表します。私たちは、攻撃に関する複雑なチートシートにあらゆる巧妙なトリックを列挙して、とにかくこれらを防ぐアプリケーションを構築せよと開発者に言うのでは
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
Locking the Throneroom 2.0
This document summarizes Mario Heiderich's presentation titled "Locking the Throne Room - How ES5+ will change XSS and Client Side Security" given at BlueHat, Redmond 2011. The presentation discusses how new features in ECMAScript 5 (ES5), such as Object.defineProperty(), can be used to prevent cross-site scripting (XSS) attacks by locking down access to sensitive DOM properties and methods on the
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
An interesting way to determine if you are logged into social web sites ✩ Mozilla Hacks – the Web developer blog
Thanks! Please check your inbox to confirm your subscription. If you haven’t previously confirmed a subscription to a Mozilla-related newsletter you may have to do so. Please check your inbox or your spam filter for an email from us. Jan! You could upload an image to a security-sensitive bug in Bugzilla to check if a user is logged in as a member of the security group, but this would change over t
JavaScriptの文字列リテラルでXSS - T.Teradaの日記
たまに以下のようにJavaScriptの文字列リテラルに値が入るアプリを見ることがあります。 <script> var foo="●"; ... </script> 値は「●」の箇所にHTMLエスケープされて出力されます（下の方の例も同じ）。 こんなケースでどうXSSするか？という話です。 簡単にXSSできるケース 以下のパターンだとXSSするのは簡単です。 <script> var foo="●"; var bar="●"; ... </script> ?foo=\&bar=-alert(123)//のような値を与えるだけです。 難しいケース 次はこんなパターンを考えます。 <script> var foo="●"; var bar="●"; ... </script> こうなると難易度はぐっと上がります。というよりも、ほとんどの場合はXSSできません。 しかし、状況次第ではXSSできる
構造化テキストの間違ったエスケープ手法について : 404 Blog Not Found
2010年09月22日21:30 カテゴリLightweight Languages 構造化テキストの間違ったエスケープ手法について 昨晩のtwitter XSS祭りは、ふだんもtwitter.comは使わない私には遠くの祭り囃子だったのですが、せっかくの自戒の機会なので。 Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について 正しいアプローチは、全てのルールを同時に適用することです。 これは残念ながら(おそらく)必要条件であっても十分条件ではありません。 こういう(かなりええかげんな)正規表現でtweetをparseしていたとします。 re_http = '(?:https?://[\\x21-\\x7e]+)'; re_user = '(?:[@][0-9A-Za-z_]{1,15})'; re_hash
Stanford Javascript Crypto Library
The Stanford Javascript Crypto Library (hosted here on GitHub) is a project by the Stanford Computer Security Lab to build a secure, powerful, fast, small, easy-to-use, cross-browser library for cryptography in Javascript. SJCL is easy to use: simply run sjcl.encrypt("password", "data") to encrypt data, or sjcl.decrypt("password", "encrypted-data") to decrypt it. For users with more complex securi
安全な HTMLDocument の生成方法について - nothing but trouble
何が危ないのか img.onerror や img.onload は src 属性の内容が評価された段階で実行されるので、外部ソースに対して HTMLDocument を構築する際などで、意図していないタイミングでスクリプトが実行されるケースがある。 具体的には、以下のような場合。 var source = '<img src="not_found.jpg" onerror="alert(1)">'; var range = document.createRange(); range.createContextualFragment(source); // onerror が実行される var img = document.createElement('img'); img.setAttribute('onerror', 'alert(1)'); img.src = 'not_found.
jCryptionが危険な理由。 - うっくつさん本を読む。
http://www.moongift.jp/2009/08/jcryption/の話。http://takagi-hiromitsu.jp/diary/を検索すれば幾らでも情報は見つかるとは思うけれど、自分のためにも書いておく。 前振り。 このjCryptionはMan-In-the-Middle攻撃に弱いはずだ。どのように攻撃されるかを具体的に書いてみる。登場人物は クライアント Alice サーバ Bob クラッカー Charlie の三名。 通常の通信。 通常手順での通信は クライアント 通信 内容 サーバ Alice ---接続--> リクエスト Bob Alice <--応答--- Bob公開鍵(平文) Bob Alice ---ポスト--> 暗号文 by Bob公開鍵 Bob というようになっている。 Man-In-the-Middle攻撃。 Man-In-the-Middl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
うごメモはてなのXSS - 素人がプログラミングを勉強していたブログ