skipfishをためす - 2010-04-10 - T.Teradaの日記
Googleから新しい検査ツールが出たとのことで、中身を見てみました。 Google Code Archive - Long-term storage for Google Code Project Hosting. ツールの作者はRatproxyと同じくMichał Zalewski氏ですが、今回のツールはRatproxyとは違って"Active"な検査ツールです。 最新版のVersion 1.29ベータをダウンロードして使ってみました。 シグネチャと検査結果 こちらのページを参考にしてダウンロード・インストールしました。 skipfishインストールメモ | 俺のメモ プログラムはC言語で書かれており、ヘッダファイルを含めて10KL程度の規模です。 インストール後にツールを起動すると、開始点として指定したページからリンクをたどって自動的に検査してくれます。検査が終わるとHTMLのレポー
IE8のXSSフィルタが裏目に出る例 - 2009-06-22 - T.Teradaの日記
IE8のXSSフィルタは、WebアプリにXSS脆弱性があったとしても、それが発動する可能性を減らしてくれるものです。 しかし、そのXSSフィルタが裏目に出るようなこともあります。 例えば、以下のような静的なHTMLファイル（test.html）を作ってWebサーバにおきます。 <h3>ie8 test</h3> <!-- 1 --> <script> var u=document.URL; </script> <!-- 2 --> <script> u=u.replace(/&/g,'&').replace(/</g,'<'); </script> <!-- 3 --> <script> document.write('URL:'+u); </script> 上のページは静的なページで、DOM Based XSSの脆弱性もありません。ですが、被害者のユーザがIE8を使っている
[セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記
こんな場合、普通はjavascriptやdataスキームなどを使ってXSSさせるのでしょう。 <a href="ここにHTMLエンコードされて入る">link</a> しかし、このアプリは「javascript://...」のように、先頭からアルファベット数文字が続き、その直後に「://」が付いている値以外は、エラーではじいてしまいます。 この「:」のあとの「//」が曲者です。 dataスキーマを試してみましたが、「//」があるとどうやらダメらしいということで、javascriptスキームで頑張ってみます。 まずはこんな感じです。 <a href="javascript://hoge[0x0A]alert(111)">link</a> 「//」が行コメントの開始になるため、[0x0A]（LF）や[0x0D][0x0A]（CRLF）を入れてみて、その後に動かしたいJavaScriptコードを
![[セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/3ce21f422dafba32f7c257ef3ed09227bfdd2c5e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711092219%2F1548045373)
preg_replaceによるコード実行 - T.Teradaの日記
最近少し調べていたのが、PHPの任意コード実行系の脆弱性です。中でも、preg_replace関数（Perl互換の正規表現による置換を行なうための関数）を不適切な方法で使った場合に発生する脆弱性について調べていました。 せっかくなので、日記にまとめてみます。 3種類の脆弱性 preg_replace関数を使ったPHPコード実行系の脆弱性には、大きく分けて3つの種類があります。 第一引数への挿入を許す e修飾子付き・第二引数への挿入を許す e修飾子付き・第三引数への挿入を許す 以下でそれぞれについて見ていきます。 タイプ１：第一引数への挿入 以下のコードに、任意のPHPコードが実行可能な脆弱性があります。 $m = preg_replace("/([^<]*)$kw([^>]*)/i", "\\1<font color=red>$kw</font>\\2", $m); $kwと$mは外部から
[セキュリティ]ImageFight - T.Teradaの日記
画像を用いたXSSとRFI対策のためのApache Moduleが出たようです。 LL魂お疲れ様でした[LLSpirit] | TAKESAKO @ Yet another Cybozu Labs もう夜遅いので、気づいた事を少しだけ書きます。 とりあえずは、PNGのXSS対策の部分についてだけ。 このプログラムは、IHDR領域の後にコメントを挿入する。 攻撃者は、IHDRのwidth/heightの合計8Byteに攻撃コードを挿入可能。 8Byte内に、xmpやtitleなどの開始タグを入れておけば、plaintextタグの効力を無効にできる。PLTEにxmpなどの終了タグとscriptタグを挿入することで攻略可能。 あるいは、8Byte内に「<a id=`」などを入れることで、コメントを属性値内に押し込めることができる（バッククォートを使っている）。 徳丸さんが日記で書いているように、
![[セキュリティ]ImageFight - T.Teradaの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/74e9aa9f9e6621a9d728a9460cede25902d1fbda/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711094607%2F1548045577)
T.Teradaの日記 - frame hijacking？
http://sla.ckers.org/forum/read.php?2,13283,13283 のスレッドを読みました。 frame（iframe）のURLが、よそのドメインのページ内のJavaScriptから書き換えられてしまうという問題について書かれています。 例えば、被害サイト（victim.com）に以下のようなiframeを使用したページがあるとします。 <!-- http://www.victim.com/foo.html --> <body> ・・・ <iframe src="framepage.html"></iframe> 攻撃者は、攻撃サイト（evil.com）に以下のようなページを用意し、そこにユーザを誘導します。 <!-- http://www.evil.com/ --> ・・・ <script> function popup() { var x=window.
[セキュリティ]画像へのPHPコマンド挿入 ― T.Teradaの日記
だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ
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要素/属性をフィルタ プログラムは実質数百行程度しかありません。 問題点 ソースを見たり、実際に使ってみると多くの欠陥が目に付きます。 ブラックリスト まず最大の問題は、ホワイトリスト方式ではないことです。要素/属性名/属性値は、定義された正規表現（ブラックリスト）でフ
T.Teradaの日記 - [セキュリティ][PHP]htmlspecialcharsと不正な文字の話
PHPでは、HTMLエスケープ用の関数としてhtmlspecialcharsが用意されています。 今日の日記では、htmlspecialcharsについて書きます。これと近い働きをするhtmlentitiesについても触れます。 htmlspecialcharsの基本 こんな感じで使います。 <?php echo htmlspecialchars($string, ENT_QUOTES, "UTF-8"); ?> 関数の引数は３つあります。 引数省略概要 第一引数不可エスケープ対象の文字列 第二引数可クォート文字の扱い（後述） 第三引数可文字コード（後述） 第二引数は、以下の3つの値のいずれかを指定可能です。 値エスケープ対象文字 ENT_NOQUOTES< > & ENT_COMPAT< > & " ENT_QUOTES< > & " ' 第二引数を指定しない場合のデフォルトは、ENT_
![T.Teradaの日記 - [セキュリティ][PHP]htmlspecialcharsと不正な文字の話](https://cdn-ak-scissors.b.st-hatena.com/image/square/c91c8eeda1375f58b5db5dfd5bc3be22f6a9a79f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711095435%2F1548045647)
Jiktoのソース - teracc’s blog
Jeremiah Grossman氏のブログなどに書かれていますが、非公開としていたJiktoのソースコードが流出したそうです。 あわせて、先月のShmooConでのプレゼン資料が公開されています（概要だけならば、この資料の方が理解しやすいです）。 ソースコードとプレゼン資料を見ましたが、どうも私が想像していたのとは違いました。どちらかというと、JiktoはカスタムWebAP用の脆弱性スキャナに近いもののようです（Niktoとは毛色が違います）。 Jiktoは他のカスタムWebAP用の脆弱性スキャナと同じように、リンクを辿ってページを探索し、脆弱性の有無を調べます（ページはXHRで取得する）。現状では、検査対象となる脆弱性は、XSSとバックアップファイルの存在のみで、しかも非常にシンプルな攻撃パターンしか備えていません。 ポイントは、プロキシサイトや、同等の動きをするGoogle Tran
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の仕掛け
XSSの本 - teracc’s blog
XSS（クロスサイトスクリプティング）に関する本が出版されるようです。 XSS Attacks: Cross Site Scripting Exploits and Defense 作者: Seth Fogie,Jeremiah Grossman,Robert Hansen,Anton Rager,Petko D. Petkov出版社/メーカー: Syngress発売日: 2007/05/23メディア: ペーパーバック購入: 2人 クリック: 31回この商品を含むブログ (8件) を見る ネタ元は以下。 http://sla.ckers.org/forum/read.php?2,5825,6517#msg-6517 買おうと思ってAmazonのショッピングカートに入れたのですが、￥6,488という値段、544ページという圧倒的ボリューム（しかも英語）にビビりました。多分、しばらくは買わない
T.Teradaの日記 - ログイン直後のレスポンスの返し方
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう？というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して（HTTP1.1では303応答）、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
