クライアントサイドでのXSS対策
(Last Updated On: 2007年8月1日)詳しくはリンク先を見て頂くとして、XSSは クライアントサイドで発生する 通常JavaScriptで発生する と言う点着目してスクリプトにサインを付けクライアント側でもXSSを検出しようと言う話です。フェイルセーフ対策としては有用だと思います。Flash, PDF, Javaなどのオブジェクトにもサインすればより良いと思います。サインさえ付けておけばあとは決まったJavaScriptコードを全てのページに追加するだけなのでそれほど難しい対策ではありません。
T.Teradaの日記 - DeXSSを試した
DeXSSはJavaのアンチXSSライブラリです。掲示板やWebメールなどのアプリで、HTMLタグを許容しながら、JavaScriptを除去したい場面で使用します。 XSS攻撃対策用のライブラリ - DeXSS 1.0登場 | エンタープライズ | マイコミジャーナル DeXSS -- Java program for removing JavaScript from HTML（DeXSS開発者のページ） ちょっと触ってみました。 概要 以下のようなシンプルな処理をします。 ・TagSoupでParse ・正規表現でHTML要素/属性をフィルタ プログラムは実質数百行程度しかありません。 問題点 ソースを見たり、実際に使ってみると多くの欠陥が目に付きます。 ブラックリスト まず最大の問題は、ホワイトリスト方式ではないことです。要素/属性名/属性値は、定義された正規表現（ブラックリスト）でフ
XSS攻撃対策用のライブラリ - DeXSS 1.0登場 | エンタープライズ | マイコミジャーナル
米XeroxのLeigh L. Klotz, Jr.氏は26日(米国時間)、DeXSSの最新版となるDeXSS 1.0.0を公開した。DeXSSはJavaで実装されたSAX2パーサ。XSS攻撃対策を実施するためのライブラリとして開発されている。成果物はAcademic Free License ("AFL") v. 3.0のもと、オープンソースソフトウェアとして公開されている。 ユーザからのテキスト入力を受け付けるダイナミックなサイトでは、XSS(Cross Site Scripting)のような攻撃を受ける可能性がでてくる。DeXSSはHTMLパーサであるTagSoupを活用することでHTMLを読み込んでSAX2イベントを生成。スクリプトや属性を削除するための機能を提供する。 同ライブラリではフィルタの形式でイベントに対する処理を記述。また同梱されている機能を使って文字列変換などを実施で
マルチバイトの落とし穴 − ＠IT
ブラインドSQLインジェクションも不必要情報の脆弱性も覚えた星野君。だけど覚えないといけないことはまだまだありそうです。今日も赤坂さんといっしょにお勉強。 「はい、これでクロスサイトスクリプティングやってみせて」赤坂さんがそういって見せてくれた勉強用のWebアプリケーション、あれ、見たところ完ぺきなんですが…… 高橋さん 「どうよ？」 星野君 「え……。どうって何がですか？」 高橋さんは唐突に会話を始めることが多い。大抵の場合、星野君には何の話か分からない。 高橋さん 「こないだ赤坂さんとWebアプリの検査したでしょ。どうかなって」 星野君 「どう……っていうか、なんか難しい感じでした。簡単なのはすぐに見つけられると思うんですけど……」 高橋さん 「ふーん……」 高橋さんはしばらく考え込んだ後、赤坂さんに声を掛けた。 高橋さん 「ねぇ、赤坂さん。いまって暇？暇だよねー？」 赤坂さん 「いや
＠IT：クロスサイトスクリプティング対策の基本
最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング」と呼ばれる脆弱性が有名であるが、クロスサイトスクリプティング脆弱性について正確に理解している人が依然として少ないと感じる。 本稿では、クロスサイトスクリプティングとはどのような脆弱性であるのか、この脆弱性を持ったサイトが攻撃されるとどのような被害が起き得るのか、なぜそのようなセキュリティホールが作り込まれてしまうのか、どのように対策をすればよいのかを解説していく。 ※以下本文中では、クロスサイトスクリプティング脆弱性のことを「XSS」と表記する。「Cross Site Scripting」の略であるから「CSS」と表記している記事もあるが、「Cascading Style Sheets」の略も「CSS」となり紛らわしいため、「XSS」と表記する場合が多くなってきている。本稿で
Microsoft Support
All Microsoft Global Microsoft 365 Teams Copilot Windows Surface Xbox Deals Small Business Support Software Windows Apps AI Outlook OneDrive Microsoft Teams OneNote Microsoft Edge Skype PCs & Devices Computers Shop Xbox Accessories VR & mixed reality Certified Refurbished Trade-in for cash Entertainment Xbox Game Pass Ultimate PC Game Pass Xbox games PC and Windows games Movies & TV Business Micro
JavaScript tutorial - Security
JavaScript is designed as an open scripting language. It is not intended to replace proper security measures, and should never be used in place of proper encryption. See also my article about cross site scripting. JavaScript has its own security model, but this is not designed to protect the Web site owner or the data passed between the browser and the server. The security model is designed to pro
Cross site scripting
Navigation Skip navigation. Site search Site navigation How To Create home More information JavaScript tutorial - security Table of contents What is cross site scripting What is cross site request forgery Who is to blame How can users protect themselves How do you know what type of login a site is using How can Web sites protect themselves Cross site scripting Escaping data Never trust URLs you ar
目から鱗 w/SQLite » PHP のセキュリティーに関する考察
一般的なこととして、PHP製のソフトウエアに関するセキュリティーに関して、考えてみたい。さまざまなセキュリティーホールのうち、SQLインジェクションとクロスサイトスクリプティングを取り上げ、主にサーバーの設定を中心に考察してみる。 この記事は、随時編集する可能性があります。また、疑問などありましたら、ご指摘いただければ恐縮です。 データベースとしてMySQLの使用を前提にしています。 1. はじめに PHP のセキュリティーを考える上でまずはじめに見ておきたいのが、register_globalsとmagic_quotes_gpc(及びmagic_quotes_sybase)である。ここでは、これらの設定の推奨値を register_globals=off magic_quotes_gpc=on magic_quotes_sybase=off としたい。これ
安全なWebアプリケーションの実現に向けて ― ＠IT
検査項目をしっかり定義 星野君 「大まかにいうと、Webアプリケーション開発で、『セキュリティテスト』っていう工程を明確に定義しましょうって感じですかね」 赤坂さん 「ほー」 星野君 「実際。『なんとなく大丈夫そう』っていうレベルでしかセキュリティって考えられていない場合が多いから、テスト項目を作りましょうって感じでいろいろ具体例を挙げてました」 赤坂さん 「へぇ～。具体例ねぇ～」 Webアプリケーションの安全性を高めるためには、実際に攻撃パターン（脆弱性の可能性を示唆できるパターン）を試すことが必要となってくる。すべての攻撃パターンを網羅することは難しいが、各攻撃パターンで共通している部分を取り出して検査することで、ほとんどの攻撃を防ぐことが可能となる。 以下に、代表的な脆弱性4つに対する検査パターンおよび確認事項について示す。これらの項目を実施するだけで格段にセキュリティが向上する。
WebAppSec - WebAppSec Wiki - XSSの実例
data スキーマを使ったスクリプトの実行 † data スキーマは、画像やIFRAMEなどのデータをHTML中に埋め込んで使用するための方法で、RFC2397で定義されています。複数のWebメールにてこれを使用してスクリプトの実行が可能な脆弱性がありました。 <iframe src='data:text/html;base64,PHNjcmlwdD5hbGVydCgiZGF0YToiK2RvY3VtZW50LmNvb2tpZSk7PC9zY3JpcHQ+'></iframe> <img src='data:text/html;base64,PHNjcmlwdD5hbGVydCgiZGF0YToiK2RvY3VtZW50LmNvb2tpZSk7PC9zY3JpcHQ+'> 多くのWebアプリケーションでは、http もしくは https スキーマのURIのみを入力値として許可すれば十分だと
PHP と Web アプリケーションのセキュリティについてのメモ
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
WEBデザイナーの為のXSS(クロスサイトスクリプティング)入門 - to-R
情報処理推進機構のXSS（クロスサイトスクリプティング/Webアプリケーションに存在するセキュリティホール）が公開されて、ネット上では盛り上げっているようです。 まぁ、これを機会にXSS(クロスサイトスクリプティング)って言葉をはじめて聞いたデザイナー・プログラマーの方は、正しい知識・正しい対処法を勉強しましょう。 とくにプログラムなんてちょっと改造するだけというレベルの、WEBデザイナーさんに注意してもらいたいです。 XSSはwebページにスクリプトを埋め込む攻撃法方法 XSSは別のサイト(これはどこでも良い)から攻撃先のurlに対して特定の文字列を送ることにより攻撃先のurlでスクリプトを実行する攻撃方法です。 XSS脆弱性のあるスクリプトはこんなスクリプトである。 <input type="hidden" name="name"value="<?php print $_POST[na
高木浩光＠自宅の日記 - WASF Times版「サニタイズ言うな！」
■ WASF Times版「サニタイズ言うな！」 技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。 「サニタイズしろ」だあ？ Webアプリを作ったらセキュリティ屋に脆弱性を指摘された――そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか？ 「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの？プログラムの内容からして必要のないことなのに？ そう
「拡張子ではなく、内容によってファイルを開くこと」は『クロスサイトスクリプティングを許すこと』と同じ。 - Windows Script Programming
「拡張子ではなく、内容によってファイルを開くこと」は『クロスサイトスクリプティングを許すこと』と同じ。 [参考URL] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3312 と言っても、どういうふうに危険なのか、分りました？ 例えば、 「これは、MVP紹介ページの写真です。」 というリンクがあって、これをクリックすると、画像ファイルが読み込まれます。 この場合は、問題ありませんが、 一般には、こういう安全そうなURLをクリックすることが危険なのです。 このような場合に、セキュリティレベル「中」以下の設定では、 画像ファイルをその中身でHTMLと判断することがあり、 その場合は、スクリプトがそのセキュリティゾーンで動きます。こわー。 もし、そのサイトが信頼済みサイトに登録されていれば、信頼済みサイトゾーンで動きます。 信頼済み
T.Teradaの日記 - SessionSafe: Implementing XSS Immune Session Handling
SessionSafeは、ハンブルグ大学のMartin Johnsさんが書いたWeb APの方式案です。 もしWeb APにXSS脆弱性があって、これが攻撃されたとしても、 セッションIDが盗まれない 当該ページ以外の情報が窃取・改竄されない ことを目指しています。 面白いなーと思ったので、内容について少し書きます。 なお、元記事を高速斜め読みしたので、この日記の内容には間違いが含まれているかもしれません。興味のある方は原本を見てください。 セッションIDが盗まれない 以下の二つのドメインがあるとします。 www.example.com secure.example.com セッションIDのCookieは、secureサブドメインに発行します。 Webページを表示する際はwww.example.comのURLにアクセスします。そこで返すHTMLに色々と仕掛けを施します。 HTMLの仕掛け
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Security1-2. クロスサイトスクリプティング
https://b.hatena.ne.jp/HiromitsuTakagi/20070202
『Ywcafe.net』へのコメント
YahooのXSSの話 - nothing but trouble
