本稿はCodeZineに2015年12月28日に掲載された記事の再掲となります。 クロスサイトスクリプティング(XSS)は、古くから存在し開発者にもっともよく知られたセキュリティ上の問題のひとつでありながら、OWASP Top 10でも2010年に引き続き2013年でも3位と、未だに根絶できていない脆弱性です。 本記事では、Webアプリケーションの開発においてXSSを根絶するために必要な対策の基本を本気でお伝えします。 はじめに OWASPでは開発者に向けたセキュリティ対策のためのドキュメントやチートシートを多数用意しており、XSSへの対策としても「XSS (Cross Site Scripting) Prevention Cheat Sheet」というドキュメントが用意されています。 ただし、このXSS Prevention Cheat Sheetはシンプルなルールを定めたチートシートで
こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん！ addslashes本当にマジでチョームカつくんですけどぉぉお〜！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜！ サテ技本に載ってたからずっとaddslashes使ってるんですけどぉ〜！ 日本語が化けるんですぅ〜！ ぷんぷくり〜ん（怒）」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か
要するに、解決されるまではログアウトしとけということだそうデス。 【2011/04/20 12:20 追記】ひゃっはー的なおまけを追加しました。 【2011/04/20 00:30 追記】多分これで最後。以降は Evernote の正式発表を待った上で、それを信用して利用するかどうかは各個人の判断にお任せします。 【2011/04/19 17:05 追記】午後の部追記。なお、エントリを起こされている方がおりましたのでご紹介。＞『bulkneets氏によって報告されたEvernoteのXSS脆弱性とは 危険と対策』( http://d.hatena.ne.jp/pichikupachiku/20110419/1303158373 ) 続きを読む
結局、「アドレスバーを見ただけでXSS型のフィッシング詐欺を判別できる人がどれだけいるのか」という問題。日頃ブラウジングをしていて何気なく出てきたフィッシングを、アドレスバーを見ただけで一発で見分けられるのか。 そもそも、アドレスバーでXSSの防止が期待できると主張している人がいるのでしょうか……? ここで言われている「XSS型のフィッシング詐欺」という攻撃は、入力フォームにXSS脆弱性があって入力欄や送信先を改竄できてしまうパターンだと思います。この手の入力フォームはたいていPOSTで動作するようになっていますので、XSS攻撃もPOSTで行われることでしょう。POSTによるXSSではアドレスバーに攻撃の気配は全く現れませんので、どんなにアドレスバーを凝視してもXSS攻撃を見分けることはできません。 ※中にはGETで攻撃できるフォームもありますが、例外的なケースだと思います。 ですから、そ
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
2009年9月16日、W2Cマークアップエンジニア・ワーキンググループでお話しした「マークアップエンジニアが知っておきたい3つの脆弱性」に関するサポートページです。とりあえず資料がダウンロードできます。 資料ダウンロードプレゼンテーション資料の PDF 版がダウンロードできます。 bakera_w2cWG.pdf (PDFファイル 487KB) 無断での再配布はご遠慮ください。また、資料内に含まれる画面キャプチャは全て削除されていますので、一部不自然な空白があります。 以下に若干の補足があります。 マークアップエンジニアが知っておきたい3つの脆弱性:補足 参考サイト話の中で触れたり、参考にしたりしたサイトです。 情報処理推進機構 (www.ipa.go.jp)経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」(PDF) (www.meti.go.jp)ソフトウェア等の脆弱性関連情報
文字コード指定の無いUTF-8のコンテンツでは、ブラウザ側の文字コード自動認識でシフトJISと誤認させることで、HTMLの特殊文字を一切使わずにXSSが成立する場合があります。 原理 UTF-8 では１文字が３バイトマッピングされる場合があります。 そこで、これをShift_JISと誤認させると、３バイト目と次の１バイトをセットで１文字と誤認させることができます。これにより、HTMLの区切り文字の効力を失わせてスクリプトを注入することが可能です。 例："あ" = E3 81 82 なので、シフトJISと誤認すると "縺" (E381) +余分な先行バイトの 0x82 具体例 例えば、動的なコンテンツ（UTF-8で応答を生成） <html> <head> <title>abcde</title> </head> <body> <form> <input type=text value="ユー
個人的な感想 HTMLページへのXSSのベクタを類別すると少なくとも3種類考えられます。ひとつはDOM構造の破壊、ふたつめはBOMへの不正介入、三つ目はその他の方法によるスクリプト注入です。 ※見慣れない類別ですね。少々解説を。ここでBOMとは、ブラウザオブジェクトモデルのことを指します。例えばa要素にjavascript擬似スキームによるスクリプト記述を混入させることができるならば、BOMへの不正介入を許可していることになり即ちXSSベクタの成立を許していることになります。この時、DOMを壊しているわけではないことにご留意ください。ところでBOMの設計はブラウザごとに多型でありやっかいであることにため息をつくことがあります。 閑話休題。 長谷川さんの提起によるIEのinnerHTMLにおけるバッククォート問題は、ひとつめの類別のDOM構造の破壊に悪用されるタイプであると思います。 長谷川
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 小さな話題が面白い 皆さん、はじめまして。はせがわようすけと申します。 「教科書に載らないWebアプリケーションセキュリティ」ということで、Webアプリケーションのセキュリティに関連する、普段あまり見掛けないような小さな話題を取り上げていきたいと思います。 セキュアなWebアプリケーションを実現するために、開発者の方だけでなく、Webアプリケーションの脆弱性検査を行う方々にも読んでいただきたいと思っています。重箱の隅を楊枝でほじくるような小さな話題ばかりですが、皆さんよろしくお願いします。 さて第1回は、Internet ExplorerがHTMLを解釈する際の引用
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
to-RさんのXSSの脆弱性を限りなくなくす方法を読んでなんかもにょもにょしたのでエントリーを書く。多分、to-Rさんはこれから書くことに関して理解してて、あの対策を行なってるのかもしれないけど、それでも書く。自分の勉強も兼てるので変なところがあれば教えていただけるとありがたいです。 入力時エスケープは非常にややこしい 確かに、入力値に必ずエスケープしておけば、XSS対策漏れにはなるかもしれない。けれど非常にややこしいことになる。 例えば、受け取ったデータの文字列に対して文字数制限のバリデーションを行なうときにわざわざアンエスケープの処理を行なわないといけないし、DBへの保存の際にもアンエスケープが必要になる。ブログとかでフォームから受け取ったデータのうち、一部のタグは許容するときとかもかな。 ベストの対策はアプリの性質に合わせたエスケープなんだけども、これって完全になくすにはかなりの几帳
XSSの脆弱性を限りなくなくす方法 XSSがはやっているので便乗しておきます。 私がよく使う方法なんですが、この方法を利用するとXSSの脆弱性を限りなくなくすことが出来ます。 対応方法は、PHPファイルの最初に以下のコードを挿入するだけ。 foreach($_GET as $key => $value){ $_GET[$key] = htmlspecialchars(htmlspecialchars_decode($value,ENT_QUOTES),ENT_QUOTES); } foreach($_POST as $key => $value){ $_POST[$key] = htmlspecialchars(htmlspecialchars_decode($value,ENT_QUOTES),ENT_QUOTES); } これで自動的にエスケープの処理を行ってくれます。 通常のXSS対
今読み返すと、あちこちに変な日本語が混じっていますね。 訂正するのも嫌らしいのでそのままにしておきます。 はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。 このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。 そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。 このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。 これを踏まえて以下記述します。 「#」ではじまるのがはてなブックマークのコメントです。 #2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう？ #2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの！？ 申し訳ないです。
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
浅学なので不正確の極みなのでしょうけれど…HTMLを作成することの原初的かつ本源的な意味合いって、まず最初にテキストありき、からスタートすべきだと思っています。 ここにテキストがある。適切な形式でweb上でパブリックにしたい。そのためにはマークアップが必要だし便利だ。というわけ。 マークアップするに先立って、マークアップに必要な記号と元のテキストの文の符号とがぶつかってはまずいので、プレ処理として「一種のエスケープ」が必ず必要。HTMLの世界では文字参照というやりかたでテキストを前処理しておき、マークアップに備えるということですよね。 だから、いわゆる「適切な文字参照でXSSを防ぎましょう」というのは、本当のところオカシナ話なんですよね。XSS以前に適切な文字参照は必要なのであって。なんとならば、テキストそのままではマークアップできないからで。 HTMLについて以上のような勘所を知っていれ
こんにちはこんにちは！！ クロスサイトスクリプティングの時間です！ XSSというと…！ まっさきに思いつくのが、入力データ送信 → 確認表示の部分での無害化漏れですよね！ たとえばこんな感じのフォームから受け取ったパラメータを、 確認として表示するページとか！ (入力) <form action="register.cgi" method="post"> タイトル：<input type="text" name="title"> ← 「ぼくはまちちゃん！」を入力 本文：<input type="text" name="body"> ← 「こんにちはこんにちは！！<script>alert(1)</script>」を入力 </form> (確認) <p>この内容で登録していい？</p> <p> タイトル： ぼくはまちちゃん！<br> 本文： こんにちはこんにちは！！<script>alert
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
