なぜ出力時のHTMLエスケープを省略してはならないのか - Qiita
メリークリスマス！ 週末もPHPを楽しんでますか？ ところでWebセキュリティはWebアプリケーションを公開する上で基礎中の基礎ですよね！ メジャーな脆弱性を作り込まないことはWeb開発においては専門技術ではなく、プロとしての基本です。 中でもXSS (Cross-Site Scriptingクロスサイトスクリプティング)やインジェクションについての考慮は常に絶対に欠いてはならないものです。 現実にはプログラミングには自動車のような運転免許制度がないため、自動車学校に通わず独学で公道に出ることができてしまいます。つまりは基礎知識がないままにWebプログラマとして就職したり、フリーランスとして案件を請けることも現実には罷り通っています。それは一時停止標識も赤信号も知らずにタクシー営業しているようなものです。 このような事情により、体系的な理解のないWeb開発初心者は (時にはn年のキャリアを
Masato Kinugawa Security Blog: CVE-2020-11022/CVE-2020-11023: jQuery 3.5.0で修正されたSecurity Fixの詳細
English version is here: https://mksben.l0.cm/2020/05/jquery3.5.0-xss.html 先月、jQuery 3.5.0がリリースされました。 このバージョンでは、僕が報告した問題がSecurity Fixとして含まれています。 jQuery 3.5.0 Released! | Official jQuery Blog https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/ 報告したバグは、CVE-2020-11022、 CVE-2020-11023 として採番されています。 https://github.com/advisories/GHSA-gxr4-xjj5-5px2 https://github.com/advisories/GHSA-jpcq-cgw6-v4j6
Janetter、ネタツイートのXSSが刺さり無限に「んほぉぉ！イッぐぅぅ！！」とダイアログが出る体にさせられる
TERRY @terry_u16 湯婆婆「契約書だよ。そこに名前を書きな。働かせてやる。」 千尋> <script type="text/javascript">for(;;){alert("んほぉぉ！イッぐぅぅ！！");}</script> 湯婆婆「フン。んほぉぉ！イッぐぅぅ！！んほぉぉ！イッぐぅぅ！！んほ 2017-04-28 12:02:34
どのようにして5,000ドルのGoogleマップXSSを発見したか | POSTD
数ヵ月前、私はGoogleマップを、もっと正確に言うとGoogleストリートビューを利用しました。Googleストリートビューは子供の頃に思い描いた未来的なテレポートみたいで、とても気に入っています。私は、普段そうするように、その時もアドレスバーを見ました。2014年のいつ頃からか、パラメータは単なるクエリの文字列ではなくなり、その代わりに感嘆符で区切られた英数字の奇妙な寄せ集めになったようです。 難解で、現在のところ公開されたドキュメンテーションもなく、多くの人々に毎日使用され、リバースエンジニアリングが可能なプロトコル。こういうコードを目の前にすると、私は解読したくてウズウズしてきます。 私はブラウザのWebコンソールも見てみました。AJAX APIへのリクエストが同じようにエンコードされていただけではなく、もしレスポンスの一部が画像だった場合、その他のレスポンスは暗号を用いたバイナリ
XSSフィルターの使い方/ Shibuya.XSS techtalk #9
2017/3/30 に行われた Shibuya.XSS techtalk #9 の発表資料です。
続 Yahoo広告配信用 s.yimg.jp ドメインでのXSSの解説(多重縛りXSS編)
zoku_yimg_jp_dom_xss2.md 以下の記事の続きです。 https://gist.github.com/masatokinugawa/304d243b6a5142500b9b9efb3fb540c0 今回は、前回の記事に比べると、テクニカルなXSSの解説寄りです。 この知識が多くの人にとってどれほど役に立つかはわかりませんが、攻撃を通すまでのステップが複雑で面白かったので共有したいと思います。 前回の修正後 var url_strings = []; var url_params = parseQuery(location.href); var proto = ((location.protocol === 'https:')? 'https:' : 'http:'); var entry = proto + '//yads.yjtag.yahoo.co.jp/tag?'
30xリダイレクトのレスポンスボディでもXSS(その2) - 葉っぱ日記
この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」11日目の記事です。昨日のネタの続きです。 昨日は30x応答のレスポンスボディを表示させるために21/tcpなどへのポートへリダイレクトさせるという方法を紹介しました。Firefoxではレスポンスボディを表示させるそれ以外の方法として、CSPを使うという方法があります。 リダイレクタが設置されているサイトが http://page1.example.jp/、リダイレクト先が http://page2.example.jp/ だったとします。 GET /redir?q=http://page2.example.jp/?"><script>alert(1)</script> HTTP/1.1 Host: page1.example.jp ← リダイレクト先と異なるオリジン HTTP/1.1 301 Moved Per
30xリダイレクトのレスポンスボディでもXSS - 葉っぱ日記
この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」10日目の記事です。小ネタですみません。 301や302のリダイレクトのレスポンスボディにてXSSが存在することが稀にありますが、30x応答ではボディ部分は表示されないのでXSSが存在しても脅威は発生しないというのが多くの方の理解ではないでしょうか。 GET /redir?q=http://example.jp/?"><script>alert(1)</script> HTTP/1.1 Host: example.jp HTTP/1.1 301 Moved Permanently Location: http://example.jp/?"><script>alert(1)</script> Content-Type: text/html; charset=utf-8 document has moved to
実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
Host:リクエストヘッダによるXSS - 葉っぱ日記
本日、とある会合にてTwitterで交わされていたこの会話が話題になりました。 紹介されている例はHostヘッダの操作を経路とする攻撃ということであり、Hostヘッダインジェクションという脆弱性はないと思いますよ / “PHPにおけるHostヘッダインジェクション脆弱性 ― A Day in Serenit…” https://t.co/sTzTQEE7a8— 徳丸 浩 (@ockeghem) 2015, 11月 6 @ockeghem @okumuri 実はIEでは細工したホストヘッダを送出できる手法が知られています。間違いなくIEのバグですが、このせいで値をそのまま出力しているサイトではXSSがありえてしまいます。ここが参考になります： https://t.co/G419aaUgNi— Masato Kinugawa (@kinugawamasato) 2015, 11月 9 知る人ぞ
React.js に XSS 対策を求めるのは間違っているだろうか
Transcript 1. React.js に XSS 対策を 求めるのは間違っている だろうか #edomaesec 2015 5/30 LT 2. @clariroid 3. くらりど 4. React.js 5. React.js 6. React.js 青い紐 7. React.js • UI を構築する JavaScript ライブラリ 8. React.js • UI を構築する JavaScript ライブラリ • Virtual DOM 9. React.js • UI を構築する JavaScript ライブラリ • Virtual DOM • Component Composable 10. React.js • UI を構築する JavaScript ライブラリ • Virtual DOM • Component Composable • Server-side R
色んなXSS – nootropic.me
2015/4/16(木)：ページの一番下に追記を記述しました。 その昔、なんとかキャンプというセキュリティのイベントに参加した時「アウトプットが大事」と言われたのを思い出しました。 でも、普通自分の見つけた知識は後生大事に抱えておきたいもんだと思います。 そこで今回はそういった何かしょーもないものを捨てるべく、溜め込んだ色んなXSSのPoCを少し書き出してまとめました。 今まで自分で見つけたものや海外のSecurity Researcher達から収集したものもあります。 さて、今回リストアップしたPoCの見方ですがいくつかの項目があります。 一番上の「手法」はタイトルみたいなものだと思って下さい。 二番目の「PoC」はスクリプトを実行する為のコードです。殆どがアラートが出るだけのスクリプトの為危険なコードは無いつもりですがご自分のブラウザで実行する際は自己責任でお願いします。リンクをクリッ
Universal XSS攻撃に利用されるIEのゼロデイ脆弱性の解析 | トレンドマイクロ セキュリティブログ
セキュリティ企業「Deusen」のセキュリティ専門家 David Leo氏は、Microsoft の Internet Explorer（IE）に存在する新たな脆弱性を報告しました。この脆弱性を利用することにより、攻撃者はブラウザの同一生成元ポリシーを侵害することが可能になります。同一生成元ポリシーは、ある生成元や Webサイトから読み込まれた文書やスクリプトが、異なる生成元からプロパティを取得したり設定したりするのを制限します。 同一生成元ポリシーを侵害することによって、攻撃者はセッションの乗っ取り、認証情報（クッキー）の窃取、フィッシング攻撃の開始が可能になります。今回の脆弱性は「ユニバーサルクロスサイトスクリプティング（Universal XSS、UXSS）」の攻撃を可能にし、すべての Webサイトが「クロスサイトスクリプティング（XSS）」と呼ばれる攻撃に脆弱になります。 UXSS
Masato Kinugawa Security Blog: Cure53 XSSMas Challenge '14 Writeup
12月と言えばXSS-Masの季節ということで、最近は、XSS-Mas前から1月の終わりまで開催されていた、賞金付きXSSチャレンジ「Cure53 XSS-Mas Challenge 2014」に挑戦していました。 XSSチャレンジというのは、出題者がわざとわかりにくい形でXSSに脆弱にしたページ(例：特定の記号や文字が使えない、文字数制限がある等)で、指定した条件(alert関数 で「1」の文字をだすとか)をクリアして、スクリプトが実行できることを証明するという、XSSを嗜む人たちの間で楽しまれる一種のパズルゲームです。 実際にXSSで攻撃可能なことを証明しないといけない場面でも、特定の制約がかかることは多く、こういったチャレンジは単なるパズル遊びというだけでなく、攻撃の発想を養ううえでとても有益なものです。
mXSS - Mutation-based Cross-Site-Scripting のはなし - 葉っぱ日記
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ（1）：［これはひどい］IEの
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法
知っていれば恐くない、XMLHttpRequestによるXSSへの対応方法：HTML5時代の「新しいセキュリティ・エチケット」（3）（1/2 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。前回は、同一オリジンポリシーを突破する攻撃の代表的事例であるXSSについて、特にDOM based XSSと呼ばれるものについて解説しました。今回はその続きとして、XMLHttpRequestによるXSSを解説します。 XHR Level 2によるリモートからのコード挿入によるXSS 従来、XMLHttpRequest（以下、XHR）は、表示しているドキュメントと同じオリジン（オリジンについては第1回を参照）としか通信できませんでしたが、現在の主要なブラウザーではXHR Level 2と呼ばれる実装により、オリジンを超えて通信することが可能になっています。 これは、Jav
よくわかるPHPの教科書 PHP5.5対応版のクロスサイト・スクリプティング
たにぐちまことさんの よくわかるPHPの教科書がこのたび改版されて、よくわかるPHPの教科書 【PHP5.5対応版】として出版されました。旧版はmysql関数を使ってSQL呼び出ししていましたが、mysql関数がPHP5.5にて非推奨となったための緊急対処的な内容となっているようです。つまり、従来mysql関数を呼び出していた箇所をmysqliの呼び出しに変更したというのが、主な変更点のようで、これ以外はあまり変更点は見あたりません。 既に、Amazonでは、熱烈な読者の方からの詳細のレビューが届いています。 神本御降臨！ 言わずと知れたPHPプログラミング書籍のロングセラー。 2010年9月に発売された前作の改訂版。 PHPのバージョンも最新の5.5に対応、内容は前作と殆ど同じ。 少し前に前作を購入した方も本書を購入した方がいいでしょう。 【中略】 それにしても、帯の「３万人に読まれた定
単純ではない、最新「クロスサイトスクリプティング」事情
単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ） 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yahoo広告配信用 s.yimg.jp ドメインでのXSSの解説