スライド概要 SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。 PHPカンファレンス2022での講演資料です。 PHPカンファレンスでの動画URL https://www.youtube.com/watch?v=jZ6sWyGxcCs
Published: 02 July 2021 at 13:27 UTC Updated: 05 July 2021 at 10:03 UTC Cross-Site Scripting and the alert() function have gone hand in hand for decades. Want to prove you can execute arbitrary JavaScript? Pop an alert. Want to find an XSS vulnerability the lazy way? Inject alert()-invoking payloads everywhere and see if anything pops up. However, there's trouble brewing on the horizon. Malicious
This documentation is outdated and available for historical reasons only. To learn how to enable strict Content Security Policy in your application, visit web.dev/strict-csp. Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly cross-site scripting. It is enabled by setting the Content-Security-Policy HTTP response header
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
In the past few months I've been helping fight a rather interesting attack vector dubbed as "self xss" by the Facebook security team. It's been a rather fun journey. What is XSS? XSS, or Cross-site scripting, is a category of attack where the attacker is able to inject JavaScript code onto a page viewed by others. A very simple example would be if Wikipedia allowed the script tag to be used in wik
Shift_JISにすると、UTF-8でひらがなの「く」を構成する「0xE3818F」の先頭2バイトが、まず「縺(0xE381)」という文字と解釈され、残った「0x8F」が、後続の、二重引用符のエスケープシーケンスである「\(0x5C)」と１つの文字、「十(0x8F5C)」を作ってしまうのです。これにより、エスケープシーケンスがなくなった二重引用符は、そこで文字列リテラルを閉じることになります。こうして、その後ろに書かれたアラートが動いてしまうという訳です。 つまりこれは、攻撃者に誘導され、ユーザー自身が文字エンコーディングを切り替えた場合、本来XSSがないページでもXSSが起こせる場合があるということです。 IE以外のブラウザは、親フレームのエンコーディングを変更した場合、クロスドメインでも子フレームのエンコーディングまで変更するので、こんな誘導の仕方もできます。 http://l0.c
今時のブラウザがどれくらいUTF-7をまだサポートしているか調べてみたのでメモ。全てWin32上。 IE8 レスポンスヘッダでcharset=utf-7と指定したとき、およびコンテンツの先頭(<html>より前)にUTF-7のBOMである +/v8- を挿入しておいた場合にUTF-7となる。<meta>でcharset=utf-7と指定した場合はページを表示したときにはUTF-7とはならないが、リロードするとUTF-7となる。 IE9beta レスポンスヘッダでcharset=utf-7と指定したとき、およびコンテンツの先頭(<html>より前)にUTF-7のBOMである +/v8- を挿入しておいたとき、<meta>でcharset=utf-7と指定したときにそれぞれUTF-7となる。 Firefox 3.6.13 <meta> で charset=utf-7 と指定しておくと、ページを
公開: 2010年2月28日1時10分頃 とあるサイトでXSS脆弱性らしきものを発見。いつもはこんな感じの3段階で脆弱性を確認しています。 「"><s>test」を入れて打ち消し線が出ることを確認する「"><script>alert(document.cookie)</script>」を入れてみる。IE8ではXSSフィルタで蹴られるが、ソース上に<script>が出ていることを確認する (「<script>」という文字列だけ消す、というような処理があるかどうか確認するため)実際にスクリプトが動作することを確認最後に実際にスクリプトの動作を確認するわけですが、IE8ではXSSフィルタを無効にしなければならず、それが非常に面倒くさいです。Firefoxの場合、NoScriptを入れているとやっぱりXSSフィルタが効いてしまいます。というわけで、XSSフィルタのないGoogle Chromeを使
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く