SQLインジェクションにより改ざんされたがXSS対策はとられていた - ockeghem's blog
うわさのngg.jsを調べていたらこんな表示のサイトを見かけました。 HTMLソースは以下の通り 宮城県、福島県、山形県、岩手県、秋田県<script src=http://www.XXXXXX.com/ngg.js></script> おそらく、SQLインジェクションによりSCRIPT要素を埋め込まれたものの、XSS対策がとられていたので、JavaScriptの実行はされない状態で表示されているのだと思います。 第5回 クロスサイト・スクリプティング対策も忘れずに | 日経 xTECH（クロステック）で書いたように、SQLインジェクションによるマルウェア埋め込み対策として、XSS対策も怠らないようにと書いたばかりですが、(たまたまでしょうが)それを実証するような画面を見かけましたので報告します。 なお、改ざんされたサイトはIPA経由で届け出ました。
第5回 クロスサイト・スクリプティング対策も忘れずに
最近問題となっているWebサイトの改ざんは，サイトの改ざん自体が目的ではなく，改ざんされたコードを参照した一般ユーザーを危険なサイトに誘導して，マルウエアを導入することを最終的な目的としている。この目的のため，HTMLのIFRAME要素やSCRIPT要素が利用される場合が多い。 先に説明したように，SQLインジェクションのぜい弱性を利用してデータベースの内容を，これら要素を使った内容に書き換えることが可能な場合がある。それでも，その内容をそのまま表示するかどうかはサイトの作りによって異なる。 一般的にデータベース中の「<」などの特殊記号をそのまま表示するとクロスサイト・スクリプティングのぜい弱性（XSS）の原因となるので，表示の際にこれらの文字をエスケープすることが行われる（図1）。 現実には多くのサイトにおいて，SQLインジェクションによって挿入されたIFRAME要素やSCRIPT要素が
とある改竄報告ページにあった脆弱性の話 | 水無月ばけらのえび日記
更新: 2008年7月30日 少し前、トレンドマイクロのサイトが改竄された (www.itmedia.co.jp)という話がありましたが、トレンドマイクロのサイトには「弊社ウイルス情報ページの改ざんについて」というお知らせが掲載されていました。 それを見ていたら、ふとページの右上に検索フォームが存在するのに気づいたのですが、その検索フォームにXSSがあってズッコケたので届け出ていたのでした。 そして今日、IPAの方からこんなメールが。 トレンドマイクロの件につきまして、ウェブサイト運営者より、届出いただきました脆弱性に対する修正が完了したとの報告がありましたのでご連絡いたします。 有名サイトですし、改竄報告ページが脆弱というのは面白いので日記に書こうかなと思い、念のため確認してみたわけです。 するとこれが、入力された文字列からタグ部分だけ消去するという、典型的なダメ回避策なわけですよ。そし
セカンドオーダ・クロスサイト・スクリプティング
このところ，検索エンジンへのiframeインジェクション攻撃が大量に発生している。これについて，何人かが詳しい情報を寄せてくれた。Dancho Danchev氏ブログ投稿記事は，これまでの経緯を知るのにうってつけで，さらに被害を受けた人気ニュース・サイトを何カ所か掲載している。かなり多くの攻撃を受けているらしい米USAトゥディ紙も，記事に米IBMの研究開発チームX-Forceの見解を載せている（関連記事：IFRAME攻撃，USAToday.comなど主要なWebサイトが続々とターゲットに）。 米グーグルの検索エンジンが攻撃の発端となっていることから，多くの注目を集めている。ただし，ここではっきりさせておきたいのは，今回のぜい弱性そのものはグーグル（あるいは，そのほかの主要検索エンジン）の中に存在しない。攻撃の中心となるのは，Webサイト上のアプリケーションが「searched-for」コン
2008-04-01
朝ごはんをたべていたら思いついたのでどんなものなのか皆さんに伺ってみたくなりました。 ○クロスドメインアクセス対策例JSON、JSONP、JavaScriptで機密情報を配信する場合、クロスドメインアクセスの対策（＝クロスドメインアクセスを不可能にする対策）が必要になります。 以下にSea Surfers MLで議論されていた方法を紹介します。 (一部省略 by hoshikuzu) 方法２．while(1)、およびコメントアウト法サーバ側がデータの先頭にwhile(1) {}をつける、または全体をコメントアウトした状態で返し、クライアント側でこれを取り除いてevalする方法です。方法１と考え方としてはほとんど変わりません。while(1)の方法はGMailでも使われています。 ここでのコメントアウト法が果たして有効なのかどうか答えを知りたく思います。教えて君になっていますが、まことにすみ
予約語なしにJavaScriptでいろいろしてみる - hoshikuzu | star_dust の書斎
JavaScriptで。文字列'al%65rt%28%22Hello%20World%21%22%29'をunescape()してやってその後にeval()に通せば、結果として「Hello World!」とalertされると思います。 この操作を、安直なXSS対策ブラックリストにおけるヨワヨワな守備の回避を目的に、JavaScriptの予約語（と言ってよいですか？）を、陽には一切、使わずに行ってみるという試みです。以下。 <script> ( (21)['c' + 'onstructor']['co' + 'nstructor'] ( ( ( (21)['con' + 'structor']['cons' + 'tructor'] ('retur' + 'n unesc' + 'ape') ) () ) ('al%65' + 'rt%28%22Hello%20World%21%22%29'
2008-03-12
仮退院しました。6/10までに症状がおさまらないようなら手術を視野に入れた治療を始めることになりそうです。つまり再入院です。それまでは毎日が頭痛との闘いです。 現在、鼻の穴の奥にある前頭洞への入り口が炎症でふさがっています。前頭洞が密室に。部屋の内部でなにが起きているかについては、CTやMRIでは写りません。しかし確実にその部屋の中に何者かが存在していることだけは判明しています。私も映像でソレをみましたがかなり大きく白い影が。その何者かの内圧が高くなっており、神経を刺激してのたうちまわるような痛みが発生したのです。 何者かは、以下の数種類が考えられます。まず、生体内の水のようなサラサラしたもの。次に膿。次に前頭洞内側の粘膜などの腫れ。最後に、大きくなりつつある腫瘍。さきほども申し上げたように、この数種類のうちドレであるかについては現在のところ判明していません。ひとつだけわかる方法があります
安全なウェブサイトの作り方 改定第3版 - 葉っぱ日記
IPAによる「安全なウェブサイトの作り方」の改定第3版が出ていました。あちこちにUTF-7によるXSSネタが出てきているんですが、いくつか気になる点がありました。 まずはP.25から。 HTTP のレスポンスヘッダのContent-Type フィールドには、「Content-Type:text/html; charset=us-ascii」のように、文字コード(charset)を指定することができますが、この指定を省略した場合… 安全なウェブサイトの作り方 改定第3版 (P.25)より。charset をきちんとつけようという例で US-ASCII を示すのはあまり頂けないなと思います。Internet Explorer においては、US-ASCIIの場合は最上位ビットを無視するという問題が2006年から放置されてますので、US-ASCIIを指定してもそれはそれでWebアプリケーション開発
ホワイトリストはどう作る?
(Last Updated On: 2018年8月13日)まずホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません。 例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1 私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力／出力の
PHPのhtmlspecialcharsにはENT_QUOTESを付ける:phpspot開発日誌
htmlspecialchars ( ) でセキュリティ対策（ ENT_QUOTES もね！） PHPのhtmlspecialcharsにはENT_QUOTESを付ける。 htmlspecialchars でXSS対策をしていたと思ったら、デフォルトでは シングルクオートをエスケープしてくれない(マニュアル参照) htmlspecialchars($str, ENT_QUOTES); ENT_QUOTES を指定することで、シングルクオートも ' にエスケープ出来ます。 ZAPAブロ〜グのZAPAさんの指摘するh関数を定義してフレームワークなどに組み込んでおくのがスマートなのかもしれませんね→htmlspecialchars関数を簡単にする 意外に知られていないかもしれないので、念をのため紹介しておきます。(知っている人はごめんなさい) その危険な例をしめしてみます。 例えば、h
printenv at xss-quiz.int21h.jp
printenv at xss-quiz.int21h.jp Your IP address: 133.242.243.6 () NameValue HTTP_ACCEPT*/* HTTP_CACHE_CONTROLno-cache HTTP_CONNECTIONclose HTTP_HOSTxss-quiz.int21h.jp HTTP_USER_AGENTHatenaBookmark/4.0 (Hatena::Bookmark; Analyzer) QUERY_STRING REMOTE_ADDR133.242.243.6 REQUEST_METHODGET REQUEST_SCHEMEhttp REQUEST_URI/
2008-01-18 - hoshikuzu | star_dust dairy - about UTF-7 XSS Cheat Sheet
おくればせながら下記を拝見しました。 UTF-7 XSS Cheat Sheet Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. 上記のような対策を必要とするサイトでは放置しておけばUTF-7系のXSS以外でもXSSの危険性は存在しうると思われます。ですので… あと、ヤマガタさんの反応を読みながら思ったんですが、一般的なXSS対策で「<」「>」などを「<」「>」にエスケープするように、機械的に「+」を「+」にエスケープしてやれば、万が一のときでもUTF-7によるXSSを防げるような気もしたんですけど、あまり深く
UTF-7 XSS Cheat Sheet
Countermeasures against XSS with UTF-7 are: Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. For more information about UTF-7 trick, see "Cross-site scripthing with UTF-7". These XSS patterns are tested on IE6 and IE7. Yosuke HASEGAWA <hasegawa@openmya.hacker.jp> Last modified: 2008-01
画像ファイルによるクロスサイト・スクリプティング(XSS)傾向と対策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2007年12月6日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 最近、画像ファイルを用いたクロスサイト・スクリプティングが注目されている。本稿では、画像を悪用したXSSについて説明した後、対策方法について解説する。 画像によるXSSとはどのようなものか Internet Explorer(IE)の特性として、コンテンツの種類を判別する際に、レスポンスヘッダ内のContent-Typeだけでなく、コンテンツの内容も判断基準にしている。このため、Content-Typeが例えばimage/gif(GIF画像)となっていても、中身がHTMLであればHTMLと解釈して表示する。
クイズ:XSSとCSRFはどこにありますか? - ockeghem's blog
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
twitterにクロスサイトスクリプティング(XSS)脆弱性があればパスワードを変更できる - ockeghem's blog
秋のDK収穫祭などで騒がれている、いわゆるDK祭り。 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 http://blog.livedoor.jp/dankogai/archives/50959103.html 現象から見てセッションハイジャックされたと思われるが、原因となる脆弱性が小飼弾氏の主張どおりCSRF(Cross Site Request Forgeries)だったのか、パスワードは窃取されたのか、元々のパスワードが類推しやすいものだったのかなど、議論を呼んでいる。 私は、現象からみて、原因となる脆弱性はCSRFではなく、XSSだったと思う*1。twitterにXSS脆弱性があれば、セッションハイジャックにより、第三者が小飼弾氏になりすまして発言するところまでは可能だ。しかし、一般的にはXSSではパスワードまでは窃取できない。id:ha
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Internet Explorer Download Zones Mix-up leads to XSS
2008-03-13
はてなダイアリーのヘルプ - はてなダイアリーXSS対策
