(Last Updated On: )JavaScriptの文字列をエスケープのエントリでJavaScript文字列をエスケープ後に直接出力するより、DOMから取得してはどうか？という提案があったのでエントリを作成しました。 まずJavaScript文字列をJavaScript文字列のエスケープで作成したescape_javascript_string関数を利用した場合の例です。 <span onmouseover="alert('<?php echo escape_javascript_string('Hello From <php>')?>');">マウスをのせてね！</span> JavaScriptでDOMの要素から取得する場合、以下のようになります。要素の取得にはjQueryを利用しています。 <script src="//ajax.googleapis.com/ajax/lib
これらの中で注目すべきは ‘ と ” と \ です。シングルクォート、ダブルクオートは文字リテラルを作成する為に利用され、\ でエスケープできることです。つまり、文字リテラルの最後に \ が現れると文字列の終端が無くなります。単独で不正なJavaScriptの挿入が可能になる訳ではありませんが、プログラムの構造が破壊される事を意味します。 PHPにはJavaScript文字列用のエスケープ関数が用意されていません。htmlspecialchars()やhtmlentities()で代用している場合も多いと思います。しかし、これらの関数ではJavaScript文字列のエスケープを十分に行う事ができません。 JavaScriptプログラムの構造が破壊される例 <?php $msg1 = 'test string\\'; $msg2 = ');alert(document.cookie); //
2009年9月16日、W2Cマークアップエンジニア・ワーキンググループでお話しした「マークアップエンジニアが知っておきたい3つの脆弱性」に関するサポートページです。とりあえず資料がダウンロードできます。 資料ダウンロードプレゼンテーション資料の PDF 版がダウンロードできます。 bakera_w2cWG.pdf (PDFファイル 487KB) 無断での再配布はご遠慮ください。また、資料内に含まれる画面キャプチャは全て削除されていますので、一部不自然な空白があります。 以下に若干の補足があります。 マークアップエンジニアが知っておきたい3つの脆弱性:補足 参考サイト話の中で触れたり、参考にしたりしたサイトです。 情報処理推進機構 (www.ipa.go.jp)経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」(PDF) (www.meti.go.jp)ソフトウェア等の脆弱性関連情報
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 小さな話題が面白い 皆さん、はじめまして。はせがわようすけと申します。 「教科書に載らないWebアプリケーションセキュリティ」ということで、Webアプリケーションのセキュリティに関連する、普段あまり見掛けないような小さな話題を取り上げていきたいと思います。 セキュアなWebアプリケーションを実現するために、開発者の方だけでなく、Webアプリケーションの脆弱性検査を行う方々にも読んでいただきたいと思っています。重箱の隅を楊枝でほじくるような小さな話題ばかりですが、皆さんよろしくお願いします。 さて第1回は、Internet ExplorerがHTMLを解釈する際の引用
前回に引き続き、今回も文字エンコーディングとセキュリティをテーマに解説します。前回は壊れた文字エンコーディングを利用した攻撃、文字エンコーディングを誤認識させる攻撃を紹介しました。今回はSJIS特定の問題を簡単に紹介します。 文字エンコーディングのエスケープ方式を利用する方法 ほとんどの文字エンコーディングは、マルチバイト文字の中に“\”などの特殊文字を含みません。しかし、例外があります。Shift_JISでは“\”がマルチバイト文字に含まれるので、これが原因で脆弱性が発生する場合あります。 SJISの“表” <?php echo rawurlencode(mb_convert_encoding('表', 'SJIS', 'UTF-8')); ?> 出力 %95%5C “%5C”は“\”です。“\”は文字列のエスケープなどに利用される特殊文字です。addslashes関
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対
第02回まっちゃ445の懇親会の帰りに考えていた事なのですが、メモし忘れていたのであらためて。 HTMLの中に変数を出力する際、何も考えずに文字列をそのまま出力すると、HTMLのマークとみなされる文字が含まれていた場合にまずいことが起こります。たとえば#PCDATAの中に出力する場合、「<」や「&」がそれぞれSTAGOやEROとして解釈されますので、これらをそのまま出力しないようにする必要があります。以下のように文字実体参照に置き換えるのが一般的です。 < → <& → &同様に、二重引用符で括られた属性値リテラルに出力する場合は「"」と「&」がマークとして解釈されます。XHTMLの場合は「<」も書けないことになっていますので、これも置き換える必要があります。 " → "< → <& → &※#PCDATAの中で「"」を変換しても問題は起きないので、多
言われてみれば、そう言えばそんな機能があったね、と思うような機能はよくあります。 JavaScript無しでフォームを制御する方法はHTML4が策定されている時に追加された機能です。 ……最初はまったく意味が分からなかったのですが、これ、label要素の話ですか!? label要素が「言われてみれば、そう言えばそんな機能があったね、と思うような機能」であり、「JavaScript無しでフォームを制御する方法」である、というのは想像を絶していました。少なくとも、Web屋では絶対に考えられない発言ですね。今世紀に入ってから作られたフォームでは、label要素が使われていないものの方が珍しいのではないかと思いますが……。 ※まともにWCAGなどを読んでいる人が作る場合は、という限定がつくかもしれませんが。 なんというか、住んでいる世界が違うのかなぁ。 ……ちなみに、label要素を使わなくても、
(Last Updated On: 2008年9月3日)言われてみれば、そう言えばそんな機能があったね、と思うような機能はよくあります。 JavaScript無しでフォームを制御する方法はHTML4が策定されている時に追加された機能です。 http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1 以下のLABELタグのサンプルは http://www.0x000000.com/?i=635 より拝借しています。 <label for="action"> <body> Etymology of "Foo" 1 April 2001 When used in connection with `bar' it is generally traced to the WW II era Army slang acronym FUBAR (`F
浅学なので不正確の極みなのでしょうけれど…HTMLを作成することの原初的かつ本源的な意味合いって、まず最初にテキストありき、からスタートすべきだと思っています。 ここにテキストがある。適切な形式でweb上でパブリックにしたい。そのためにはマークアップが必要だし便利だ。というわけ。 マークアップするに先立って、マークアップに必要な記号と元のテキストの文の符号とがぶつかってはまずいので、プレ処理として「一種のエスケープ」が必ず必要。HTMLの世界では文字参照というやりかたでテキストを前処理しておき、マークアップに備えるということですよね。 だから、いわゆる「適切な文字参照でXSSを防ぎましょう」というのは、本当のところオカシナ話なんですよね。XSS以前に適切な文字参照は必要なのであって。なんとならば、テキストそのままではマークアップできないからで。 HTMLについて以上のような勘所を知っていれ
昨日の日記(hiddenのあまりにも馬鹿げた使い方 - ockeghem(徳丸浩)の日記)では、yohei-y:weblog: ステートレスとは何かを引用させていただいて、hidden書き換えの危険性を説明した。その例として、ECサイトにて単価が変更できる場合を挙げたのだが、「本当にそんなサイトあるのか?」という疑問、ないし驚きをもたれた方も多いようだ。 私が直接見た中でも、単価をhidden(ないしCookie値)で平文で保持していて書き換えのできるECサイトはいくつか経験している。しかし、実際に1円で購入できるかどうかは試したことはない。犯罪行為になる可能性が高いからだ。 現実には、そのようなしょぼいサイトは、バックオフィス作業は手作業でやっているケースが多いと思う。よくあるのは、注文内容が担当者にメールで飛んできて、担当者がEXCELかなにかで手集計して商品手配やら入金確認なら発送を
「Twitterのクロスサイト・スクリプティング(XSS)対策は変だ (www.tokumaru.org)」。文字参照に変換した状態で DB に格納しているというのは、けっこう良くある話だろうと思います。この手のエスケープしすぎによる化けは、twitter に限らず、よく見かけますので……。 ※HTML のエスケープに限らず、入力欄に \ を入れて検索すると \\ に化けて、検索ボタンを押すたびに \ が増殖していくという面白いシステムも良くありますね。 一昔前のフリーの掲示板 CGI などでは、フォームの値を読み取るところで < → < " → " のように文字参照に変換してしまうのが一般的でした。この手のアプリケーションは、 絶対に HTML にしかデータを出力しないフォームからの入力以外のデータを処理しない作者が一人で開発しているので、出力時の処理も把握しているという
20日(米国時間)、HTML Purifierの最新版となる「HTML Purifier 2.0」が公開された。HTML PurifierはPHPで開発されたHTMLフィルタライブラリ。GNU LESSER GENERAL PUBLIC LICENSE Version 2.1のもと、オープンソースソフトウェアとして公開されている。標準仕様に準拠しているHTMLデータをフィルタリングするためのライブラリで、XSSなど危険性のあるコードを削除する際に役立つほか、BBCodeに対する代替ライブラリとしても活用できる。 2.0における主な変更点はアーキテクチャに対して2つの大きな変更が加えられた点にある。まず推奨されていない要素を標準推奨されているものに変換するTidyが変更されており、新しい要素や属性を簡単に作成するためのAdvanced APIにも変更が加えられている。以前のバージョンから2.
注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる (～中略～) HTMLエンコードというのは，例えば「&」「<」「>」「"」といった，HTMLとして特殊な意味を持つ文字（特殊文字またはメタ文字）を，意味を持たない別の文字列に置換することである。 この注釈はいらないでしょう。「メタ文字を、意味を持たない別の文字列に置換すること」を実体参照とは言いません。もちろん HTML の仕様には「HTMLエンコード」などという言葉は出てきませんが、ここではサーバ側での変換処理のことを呼んでいるわけですから、無理に SGML/XML の仕様で使われている用語に置き換えようとする必要は無いはずです。 ただ、「HTMLエンコード」という言い方は、Microsoft 製品に親しみのない人には違和感があるかもしれません。AS
クロスサイト・スクリプティングという言葉は元々，WebアプリケーションのHTMLエンコード漏れなどを利用することによって第三者にJavaScriptを実行させる手法を指す。広義では，HTMLのエンコードによる画面改変などを含むこともある。 前回述べたように，クロスサイト・スクリプティングのぜい弱性はWebアプリケーションに見付かるぜい弱性の半分以上を占める。数年前から指摘されているにもかかわらず，一向になくならない。その理由として，クロスサイト・スクリプティング対策あるいはHTMLエンコード注1）に対する「神話」があり，正しい対策の普及を遅らせているように思う。その「神話」の数々について説明しよう。 注1）実体参照（entity reference）というのが正式だが，あまり普及していない用語なので，HTMLエンコードという用語を用いる 「すべからくHTMLエンコードすべし」が鉄則 HTM
≪ 2008.10┃ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ≫ 高木氏が再びサニタイズ言うなキャンペーンの解説記事を掲載した。 高木浩光＠自宅の日記 - WASF Times版「サニタイズ言うな！」 今回のはかなり判り易く書かれていると思いますが、それでもまだ理解に欠ける人々もいるようで、アルファブロガーの宿命か？高木氏もたいへんだなぁと思ったり(笑) SQLインジェクションだと、SQL文をプログラム中で動的に生成するな！プレースホルダ使え！！で済む話なのですが、 use MyDBIPg; my $db=MyDBIPg->new($dsn); my %parm=( parm1 => $parm1, parm2 => $parm2
【講演1】 脆弱性の届出情報の深刻度評価についてCVSS のお話。「IPA が受付けた脆弱性をCVSSを用いて分析した結果を紹介します」ということで、具体的にこんな事例がこうなった、という話を期待していたのですが……。残念ながら統計データだけで、具体的な事例は出ませんでした。 もっとも、それは私の期待が大きすぎただけで、話としては普通に面白かったと思います。 【講演2】 安全なWebアプリケーションの作り方（番外編）極楽せきゅあ日記 (d.hatena.ne.jp)などで有名な園田さんの講演。中心はフレームワークのお話で、あとは書籍の脆弱性のお話など。 書籍の話ですが、個人が批判する分には問題ないと思うものの、何をもって誤りとするのかが難しいですね。「のけぞる本!」なんてコンテンツがありますが、これは HTML の仕様に照らして間違いだと言っているので、間違いだと断じるだけの論拠があります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
