Browser's XSS Filter Bypass Cheat SheetYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
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という仕様が提案されて
<script>alert(1)</script>のお求めはAmazon CDストア - Qiita
本記事は脆弱性"&'<<>\ Advent Calendar 2015の15日目の記事です。 11/18にAmazonがリリースしたAmazon Musicというサービスに関連するXSSを2つ発見・報告したのでそのお話です。 1. Amazon MusicにあったXSS このページから "><_><script>alert(document.domain)</script>と検索すると alertが出ました。 画面右側のペイン内にて、aタグのhref attribute内に検索クエリを出力している箇所にあるバグに起因しています。この文字列は本来何らかの処理を通じてエスケープされていたのですが、適当に<hoge>のような文字列を一つ挟むとaタグのhref attributeから漏れて出力されていました。 11/19に発見・報告し、11/26に修正されました。 何故かAmazonのセキュリティ
色んなXSS – nootropic.me
2015/4/16(木)：ページの一番下に追記を記述しました。 その昔、なんとかキャンプというセキュリティのイベントに参加した時「アウトプットが大事」と言われたのを思い出しました。 でも、普通自分の見つけた知識は後生大事に抱えておきたいもんだと思います。 そこで今回はそういった何かしょーもないものを捨てるべく、溜め込んだ色んなXSSのPoCを少し書き出してまとめました。 今まで自分で見つけたものや海外のSecurity Researcher達から収集したものもあります。 さて、今回リストアップしたPoCの見方ですがいくつかの項目があります。 一番上の「手法」はタイトルみたいなものだと思って下さい。 二番目の「PoC」はスクリプトを実行する為のコードです。殆どがアラートが出るだけのスクリプトの為危険なコードは無いつもりですがご自分のブラウザで実行する際は自己責任でお願いします。リンクをクリッ
SECCON2013 北陸大会の前日勉強会の資料 スライド形式のはこちら https://speakerdeck.com/mala/seccon2013-slide
スマートフォンのセキュリティについて ma.la 自己紹介 http://ma.la https://twitter.com/bulkneets LINE株式会社 livedoor方面の人です 仕事 JavaScript, Perl 元々の専門領域はUI, フロントエンド Webアプリ全般 認証認可周り セキュリティに関する業務 自社サービスのリリース前にチェックしたりとか 何か新しい攻撃手法見つかったら調査 他社サービスの問題見つけて報告したり オープンソースプロダクトのバグ報告したり そもそも何でJavaScriptを書いてた人間が セキュリティに関することをやっているのか あらゆるデバイスでHTML + JavaScriptが使われている どこまで悪用できるのか、どうやって修正すべきなのか 社内でもっとも詳しい 基本的にはWebの人 iOS / Android アプリ開発あまり詳しく
単純ではない、最新「クロスサイトスクリプティング」事情
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
Masato Kinugawa Security Blog: Referrer文字列によるXSS
リファラを使った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
Masato Kinugawa Security Blog: Flash動画プレイヤー「ふらだんす」に存在したXSSから学ぶ、FlashのXSS3パターン
ストリーミング・ジャパンが以下のURLで提供しているFlash動画プレイヤーの「ふらだんす」に存在し修正された、僕が報告した3件のXSSについて書きます。 http://www.streaming.jp/fladance/ 更新しましょう 2013年4月12日に提供されたバージョン 2.1.5以降 を使っていなければXSSの穴をサイトに作っていることになります。一応「ふらだんす」の上で右クリックすると使っているバージョンがわかるので脆弱かどうか確認できますが、こういったFlashの動画プレイヤーの更新情報をちゃんとチェックしている人はほとんどいないと思うので、最近導入した人でなければまず脆弱なものを使っていると思います。心当たりがある人は「2.1.5」に更新しましょう。あるいは使っているサイトをみかけたら教えてあげましょう。 これ以降は技術的な話です。 技術的な話 あらかじめことわっておく
IPAテクニカルウォッチ 『DOM Based XSS』に関するレポート：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：藤江 一正）は、IPAに届け出られる「DOM Based XSS」の脆弱性に関する届出が2012年後半から増加していることを踏まえ、それらの情報を分析して当該脆弱性の概要や対策のポイントをまとめた技術レポート（IPAテクニカルウォッチ 第13回）を公開しました。 IPAに多くの届出があるクロスサイト・スクリプティング（XSS）の脆弱性ですが、2012年第1四半期から第3四半期の期間では合計38件だった「DOM Based XSS」と呼ばれるタイプのクロスサイト・スクリプティングの脆弱性の届出が、第4四半期だけで92件（第3四半期までの件数比約2.4倍増）と急増しました。 一般にクロスサイト・スクリプティングは、サーバ側のプログラムに作り込まれてしまう脆弱性ですが、「DOM Based XSS」と呼ばれるクロスサイト・スクリプティングの脆弱性は、
Masato Kinugawa Security Blog: ホストの前に文字が置けることを忘れるな
今日は、 そもそもホストの前に任意の文字列を置けるということを忘れていると、うっかりそこにJavaScriptで触ってしまった時に問題が起こる場合があるよね、という話をします。 以前紹介したlocation.hrefの問題に似ていますが、今回取り上げているのは文字列がデコードされることにより起きうる問題ではなく、文字列が取得されることで起きうる問題についてです。 まずは、様々な形でJavaScriptでURLを確認できるスーパーウェブサイトを用意致しましたので、ホストの前に文字列を含むURLが、どの値で取得されているかを実際に見てみてください。 http://user:pass@vulnerabledoma.in/location/ (※このページはURLをそのまま書きだしているため、当然DOM based XSSがありますが 、その挙動も含めて確認できるようにする目的があるので、あえてそ
[Shibuya.xss] セキュリティ小ネタ二本
Social Media Marketing Trends 2024 // The Global Indie InsightsKurio // The Social Media Age(ncy)
![[Shibuya.xss] セキュリティ小ネタ二本](https://cdn-ak-scissors.b.st-hatena.com/image/square/64ef1591a4edffcd43d953f1405f8f3b11d51741/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F1-120404124043-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
XSSを回避しつつ、テンプレートからJavaScriptにJSONで値を渡す方法 - blog.nomadscafe.jp
「HTMLのscriptタグ内にデータを埋め込む際のエスケープ処理モジュール書いた」に引き続いて、XSSを避けつつ複数の値をJSONで渡す方法。 答えはmalaさんが書いてます テンプレートエンジンでJSONを生成する(多くの場合間違えるので、推奨しない) scriptタグの中でJSONを使わない 可能であればJSONライブラリのオプションで<>/いずれかをエスケープする。 生成されたJSON文字列の<>/いずれかを正規表現などを使って置換する。 JSONのvalueに当たる部分には「HTMLエスケープ済みの文字列を入れる」という規約を設けて事前にエスケープする。 の3番目以降。 ということで実装してみる。目標としてはXslateのfilterとして実装 [% hashref | json %] の様な形をとり、JSONのvalueにあたる部分はすべてHTML Escapeし、HTML中に
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
TAS design – タスデザイン
TAS designについて Web制作とサービスサイトを運営してまいりました「TAS design」は、2020年4月に「TAS design合同会社」を設立しました。 弊社サービスの詳細はコーポレートサイトをご覧ください。 https://tasdesign.co.jp/ サービスサイト TAS design合同会社では下記のサイトを運営しております。 Buffet time 東京 https://buffets.tasdesign.co.jp/ 素敵な場所で心躍る時間を。東京の食べ放題ホテルビュッフェを紹介します。 すぐトク https://sugutoku.tasdesign.jp/ クーポンやスマホ決済の還元などのお得な情報を紹介します。
第4回 Flash、JSONでのクロスドメインアクセス | gihyo.jp
Flashを用いたクロスドメインアクセス 前回までは、クロスドメインアクセスを行うための方法として、リバースProxyを使う方法とJSONPを使う方法を紹介しましたが、どちらの方法も少し変わった方法だったと思います。なにか無理やりのように感じた方もいるのではないでしょうか。今回紹介するFlashを使った方法では前回までの方法とは違い、自然な形でクロスドメインアクセスを行うことができます。 Flashでは、呼び出される側で設定を行うことでクロスドメインアクセスが可能になります。 設定といっても非常に簡単で、呼び出される側のWebサーバにcrossdomain.xmlというファイルを設置するだけです。このときのURLは http://www.example.com/crossdomain.xml となります。 ファイルの内容は以下のようになります。 crossdomain.xmlの内容 <cr
perl - EncodeでXSSを防ぐ : 404 Blog Not Found
2009年03月03日19:00 カテゴリLightweight Languages perl - EncodeでXSSを防ぐ 良記事。 第7回■文字エンコーディングが生み出すぜい弱性を知る：ITpro だけど、問題点のみ具体例があって、対策にないのが片手落ちに感じられたので、その点を補足。 結論だけ言ってしまえば、Perlなら以下の原則を守るだけです。 404 Blog Not Found:perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基本方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなダイアリーのヘルプ - はてなダイアリーXSS対策
IEに依存した Webアプリケーション セキュリティ