ikepyonのお気楽な日々〜技術ネタ風味〜 このページをアンテナに追加 RSSフィード

気になった日々のニュースとメモのためのリンクと戯言のページ

To Do(というかやりたいこと。何時終わることやら)
-ITIL導入のための成熟度チェックシートみたいなの(あると便利だよね?)
-Hacknotes Web Security Portable Reference和訳(出版社募集中)
-Webアプリケーションセキュリティ検査ツールの改良(一応完成)
-Hacker HighSchoolの資料の日本語訳
-OSSTMMの日本語訳
-「燃えるセキュアプログラミング」若しくは「サルでも分かるセキュアプログラミング」とか書いてみたいなぁみたいな。

これだけはチェックしときなはれ!!受入れテスト用セキュリティチェックリスト公開中
Webアプリケーションセキュリティはてなぐるーぷ(テスト中やで)
SQL Injectionの仕組みと対策公開中
RSS feed meter for http://d.hatena.ne.jp/ikepyon/
Secure Coding に入ろう!! [MLの詳細]
メールアドレス
SKUF Meeting なかのひと

2008-02-28 Macbookほしい!!

だれかくださいw

[]セッションを使ったフォーム処理にありがちな問題点 セッションを使ったフォーム処理にありがちな問題点を含むブックマーク セッションを使ったフォーム処理にありがちな問題点のブックマークコメント

http://d.hatena.ne.jp/teracc/20080225#1203957135

改めて読み直してみると、この問題は別にセッション変数を使っているか使ってないかにかかわらず起きることだな。これにも書いているとおり、最終的な処理を行う前に全てのデータのチェックを行うというのは必要だと思う。

まあ、Webアプリの場合、画面遷移がユーザの操作によって自由にできてしまうということを忘れているため(多分、もともとクライアントサーバシステムを開発していた開発者に多いと思う。あくまで主観なので)、こういった問題が出るのだと思うけど。画面遷移が自由にできる=開発者が想定するべきことが増えるということなので、そこが従来のクライアントサーバシステムに比べ、ちょっと面倒なところだと思う。

画面遷移での値の受け渡しは、Hiddenでもセッション変数でもいいけど、Hiddenの場合は必ずエスケープ処理が必要だ。ところが、エスケープ処理を全てにおいて実施するというのを忘れてしまうことがあるがため(実際多くのXSSの問題はエスケープ漏れにあると思う)に、セッション変数を使ったほうが危険性が減るんじゃないかなぁと思うのですよ。ってこう書くと、「Hiddenは危険脳」といわれそうだw

後実装を確認していないのでわからないのだけど、セッション変数の管理ってどうやってるのだろう?メモリ上で管理している?もしそうなら、大量のアクセスがあったときに問題が起こりそうだけど、実際のところどうなんだろう?

トラックバック - http://d.hatena.ne.jp/ikepyon/20080228

2008-02-27 北海道か沖縄に住みたい

花粉が飛ばないところに住みたいなぁ。できれば、北海道沖縄農家をしたいなぁw

[]パスワードアカウントロック パスワードとアカウントロックを含むブックマーク パスワードとアカウントロックのブックマークコメント

http://d.hatena.ne.jp/ockeghem/20080226/p1

あたりを読んで、脊髄反射的に思ったこと。

アカウントロックって、ある特定の人のパスワードを取得するという攻撃を防ぐには非常に有効だけど、そのサービスを使用しているユーザーであれば誰でもいいのでパスワードを取得するという攻撃にはあまり有効じゃないよなぁと。

アカウントロックは通常、あるユーザIDでのログインに既定回数失敗した場合、そのアカウントを一時的に使えなくするということなので、パスワードを固定してユーザIDを変えていくようなブルートフォース攻撃には無力だったりする。それに特定のアカウントを狙わないのであれば、内側のループユーザIDにして、パスワードを外側のループにすることで、一定時間たてばクリアされるアカウントロックを回避して攻撃するなんてこともできるしw(試行するユーザIDを大量に用意しておけば、同じユーザIDを別のパスワードで試す前にクリアされるだろうし)。

ユーザIDランダムな英数字を使っていたらこのような攻撃は困難だけど、数字だけとか、メールアドレスとか使っていたら飛躍的に簡単になるんじゃないかなぁ?

まあ、そもそもパスワードに簡単なもの使うなというのは前提条件としてあるんだけど、サービスを利用している人全員が、推測されにくいパスワードを使っているってことはそうそうあるわけじゃないと思うのですよ。特にユーザの数が多くなればなるほど・・・

そのためにもパスワードに簡単なものを設定できないようにするってのが必要じゃないかと思ったりする。

とはいえ、アカウントロック無意味な対策というわけではなく、特定の人のパスワードを取得するという攻撃には有効なのでやるべきだとは思う。それに、ログをしっかりとっていれば、攻撃を受けていることはわかるので、ブルーフォース攻撃を防ぐことはできると思うけどね。

トラックバック - http://d.hatena.ne.jp/ikepyon/20080227

2008-02-22 眠すぎる

そろそろ眠くなってきた。

[]アプリケーション脆弱性 アプリケーションの脆弱性を含むブックマーク アプリケーションの脆弱性のブックマークコメント

ちと、文章ネタに思案しているので、メモ代わりに。

脆弱性の切り口っていくつかあると思うんだ。

  1. 発生する事象よる切り口
  2. 作りこんでしまう開発工程による切り口
  3. 発生する原因による切り口
  4. 被害が発生したときの影響による切り口
    • 機微情報漏洩する、一時的な利用停止とか

まだまだあるだろう。

いや、だからどうだというわけではなく、どういう風に発生するのか?というのがわかれば、どういったところに気をつければいいか?というのがわかるだろうし、どの工程で作りこんでしまうのか?というのがわかれば、どの工程で気をつければいいというのがわかるんじゃないかなぁ?という漠然としたアイデアだったりする。

コーディング時に作りこんでしまうんだったら、単体テストでどういうパターンテストを行えばいいかとかわかって、効率よく開発できるんじゃないかなぁと思ったりする。

検査ツールのテストでは、結合テスト以降しかできないから手戻りが大きくなって大変だねぇ。

さて、文章どう構成しようかなぁ?

トラックバック - http://d.hatena.ne.jp/ikepyon/20080222

2008-02-20 大ポカしてしまったorz

こういうのをやると嫌になる。

[]システムエンジニアリング システムエンジニアリングを含むブックマーク システムエンジニアリングのブックマークコメント

http://anoda.cocolog-nifty.com/mad/cat2986968/index.html

なかなか面白い。

要求とスペックは違うものとかためになるなぁ。

[]検査ツール 検査ツールを含むブックマーク 検査ツールのブックマークコメント

http://webappsec.sakura.ne.jp/modules/wfdownloads/viewcat.php?cid=2

メールで受け付けて配るのが面倒になってきたのでw、公開してみるテスト。一応ダウンロードするにはユーザ登録が必要だけど。それに、すでに入手している人は同じものなのでダウンロードする必要はないです。

ya_taya_ta 2008/02/20 16:54 「犬ポカ」って何だろうとちょっと悩みました orz

yamagata21yamagata21 2008/02/20 17:32 動物をいぢめちゃダメですっっ!(ちがうw

ikepyonikepyon 2008/02/20 19:03 「犬ポカ」ってwww

yamagata21yamagata21 2008/02/21 10:54 年初に大規模な改修をするって話は〜?w >同じもの

ikepyonikepyon 2008/02/21 15:59 すんません。いろいろ修正していたら、コードが気に入らなかったのでフルスクラッチで書き直し中ですm(_ _)m
いやまあ、一部修正したものはあるのですが、サニタイズみたいな処理がHTTPClientにあるので(内部データを全てURLでコードして持っているとか)一からHTTP周りとか作り直し中なんです。加えてJUnitとか使って、単体テストするとか(今まで結合テストしかしてなかったw)やっているので、進んでいません。
最近、乗り気になっているので、ゴールデンウィークぐらいまでには完成させていです。

yamagata21yamagata21 2008/02/21 16:45 本格的ですね。楽しみにしてます。

2008-02-15 くぅ

なんか眠いなぁ。

今年の花粉対策は、鼻につめる薬にしよう

[]某ツール 某ツールを含むブックマーク 某ツールのブックマークコメント

そろそろ面倒になってきたので、某所に公開するか。もちろん公開版はシグネチャなしにするけどw

トラックバック - http://d.hatena.ne.jp/ikepyon/20080215

2008-02-14 煮干の日

[] Taint support for PHP (from no titleさんとこ)  Taint support for PHP (from no titleさんとこ)を含むブックマーク  Taint support for PHP (from no titleさんとこ)のブックマークコメント

ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080130.README.html

PHPにTaintをサポートしたパッチが出たらしい。

確かにうまく使えばセキュリティの向上が期待できるけど・・・

PHPで開発している人は結構こぴぺ超人wが多そう(独断と偏見だけどな)なので、こんなオプションつけても「俺の作ったアプリうごかね→こんなオプションいらね→taint_error_levelを削除→うごいた!!→セキュリティホールてんこ盛りorz」となりそうな予感orz

トラックバック - http://d.hatena.ne.jp/ikepyon/20080214

2008-02-13 今日は移動が多かった

[]ウィルス作成罪 ウィルス作成罪を含むブックマーク ウィルス作成罪のブックマークコメント

http://kiyosakari.blog105.fc2.com/blog-entry-59.html

ふむ、セキュリティテストのためにウイルスを作成しても罰せられないというのであれば、作成したウィルスを受け取った人が悪意を持ってウィルスを使用した場合、ウィルスを作成した人にセキュリティテストと言う目的しかなかった場合、幇助罪には問われないのだろうか?

Winnyの作者に著作権法違反幇助が適用されたので、そのあたりが気になる。

もしかしたら、意思が無いと言うことで罪にはならないのかもしれないけど、逮捕はされてしまうのではないか?

逮捕されると日本じゃ社会的に抹殺されるからなぁ。

mohnomohno 2008/02/14 20:25 おじゃまします。
> セキュリティテストと言う目的しかなかった場合、幇助罪には問われないのだろうか?
問われないと思いますよ。
ダイナマイトを製造した業者が、「工事に使う」という人に売って、実際にはテロが目的だった、というようなものだと思います。まあ、本当に工事に使うかどうか怪しい人に売ったら、過失を問わるかもしれませんが。
あと、逮捕には現行犯でない限り、裁判官が発行する逮捕状を取る必要があるので、悪意の確認(証拠)もなしに逮捕というのは難しいでしょう。
ちなみに、金子氏の場合、メールなどから犯意が認定されたのであって、P2P ツールを開発したことで有罪になったのではありません。
判決文→ http://www.venus.dti.ne.jp/~inoue-m/hn_061213WinnyHoujyoTisai.html

kiyosakarikiyosakari 2008/02/14 21:39 初めてコメントさせて頂きます。

幇助犯とならないか,とご指摘の点ですが,提示されている例の場合,故意が認められないため,幇助犯は成立しないのではないか,と思います。

幇助犯とされるためには,幇助犯としての故意,つまり,(1)正犯(渡されたウイルスをバラまいた人)の実行行為(「実行の用に供する」こと)を認識しており,かつ,(2)自らの行為によって,正犯の犯罪を容易にするということを認識し,「それでも構わない」と思っていた(認容していた)ことが必要となります。

Winnyの場合,これによる著作権侵害が横行していることを認識し,そのような方法で使われることを認容した上で,Winny2をリリースしていることから,幇助犯の成立が認められた事例であると理解しています。
そうすると,提示されている例とはかなり異なるように思います。

逮捕される可能性という点についてですが,ウイルスをバラまいた(供用した)人物に対する捜査の過程で事情を聞かれることくらいはあるかも知れません。
日本の捜査機関は身柄拘束について慎重ですので,そう心配するものではないというのが,私の考えです。


不正指令電磁的記録取得等の罪を必要以上に恐れる必要はないとは思いますが,もう少し不安を取り除けるような条文になってもいいと思っています。

ikepyonikepyon 2008/02/15 15:01 mohnoさん、kiyosakariさんありがとうございます。
なるほど、逮捕の危険性はそうはないということですね。ただ、事情徴収されたときの対応には気をつける必要がありそうですね。何を言質にされて、逮捕に発展するかわかりませんしw

トラックバック - http://d.hatena.ne.jp/ikepyon/20080213

2008-02-08 他山の石

わからないことがあったら、まず誰かに質問する前に自分でいろいろ試してみようと思った今日この頃

[]コードコピペ コードのコピペを含むブックマーク コードのコピペのブックマークコメント

最近どころかかなり前から、言語初心者向け解説ページとか「今夜わかるPHP」wとかいう初心者向けのものにコードがいくつか書かれているんだけど、多くの場合セキュリティ対策というか、どんな場合でも正しく動くようなコードになっていない。

まあ、そういうところの言い分は、説明がしにくいとか、シンプルにしてわかりやすくしたいからとかなんだけど、ちょっと待ってって思う。

そういうのは作者自身が解説めんどくさいからというただのいいわけじゃないのか?

初心者にこそ、一見すると正しく動いているように見える欠陥のあるコードではなく、どんな場合でも意図したように動くコードをサンプルとして知ってもらうほうが大切じゃないかと思う。

初心者にとって、コードの内容を理解して、自分なりに書いてみるということは敷居が高いと思うんだよ。だから、初心者はサンプルコードコピペを行って、正しく動いている気になっているんじゃないかな?実際には初心者が書いたコードに欠陥があるとも知らずに・・・

もちろん、欠陥があり機能だけを説明するサンプルコードが悪いわけではない。ただし、それはあくまで上級者(自分でコードを理解して使える人)にとって悪くないだけで、初心者コードを理解せずにそのままコピペしてしまう人)にとっては益より害のほうが大きいと思う。

初心者にはコードのよしあしなんてわからないだろうし(だから手っ取り早くコピペすることが多い気がする)。

少なくとも今は、サンプルコードコピペするなら、その内容を理解したうえで考えられる問題がないことを確認してからするべきだと思う。

まあ、私もサンプルコードを参考にしてコピペしたりするけど、一応内容理解した上でやってるからなぁ。

サンプルコードを作る人はコピペされて使われるってことも考えて、どんな場合でも意図したように動くようにするか、条件を明確にして作ってほしいなぁ。

でも、まずはサンプルコードコピペ禁止!!ってのを提唱してみるw

トラックバック - http://d.hatena.ne.jp/ikepyon/20080208

2008-02-06 雪降ってた

[]CVEでみるPHPアプリケーションセキュリティ CVEでみるPHPアプリケーションセキュリティを含むブックマーク CVEでみるPHPアプリケーションセキュリティのブックマークコメント

http://gihyo.jp/dev/serial/01/php-security/0001

今更ながらですがw

この統計の取り方はちょっとPHPに対して不利じゃないかな?

PHPRubyASPで開発されたアプリケーション絶対数が違いすぎると思うんだよ。だから、前にも何度か統計とって見たけど、あまり意味のないもんだと書いてるんだが・・・

例えば、PHPは100個のアプリケーションがあり、平均すると1個のアプリケーションに対し、0.5個の脆弱性がある50個の脆弱性のあるアプリケーションがある。一方、Rubyは10個のアプリケーションがあり、平均すると1個のアプリケーションに対し、1個の脆弱性があるとする5個の脆弱性アプリケーションがある。

そうすると、「PHPアプリケーション発見された脆弱性は50個に対して、Rubyアプリケーションでは105個となり10倍の脆弱性がありました。」という結果しかえられない。実際には両方とも全体の50%のアプリケーションにしか脆弱性がないにもかかわらず・・・

これをもって、PHPはひどいといってるように思えるんだけど・・・

別にPHPを擁護するつもりもないし、Rubyを貶めるつもりもないけど、統計の魔術にはまってるなぁと。

PHPアプリと他の言語アプリ脆弱性数で安全な言語はどっちか?を判断するのであれば、1個のアプリあたり何個の脆弱性が見つかったのか?ってのを見ないといけないと思う。

もしかしたら、PHPアプリの90%は脆弱性がなくて、Rubyアプリの90%に脆弱性があるかもしれないし・・・多分そんなことはない気がするけど。

前にも書いた気がするけど、PHPの問題は一見するとセキュリティ対策っぽい対策や、きちんと影響を考えられずに便利だからという理由で実装された機能が散見されるところだと思う。

こういったところを、改善していけばよくなると思うんだよなぁ。

2008-02-05 腹減りすぎで、腹痛い

[]In Secure Magagine 15 In Secure Magagine 15を含むブックマーク In Secure Magagine 15のブックマークコメント

http://www.net-security.org/dl/insecure/INSECURE-Mag-15.pdf

なんか面白そうな記事があったので、後で読む

[]Open Source Vulnerability Database 2.0 Open Source Vulnerability Database 2.0を含むブックマーク Open Source Vulnerability Database 2.0のブックマークコメント

http://osvdb.org/

こんなのがあったのか。結構詳細に検索条件が指定できるみたい。

[]Programing 2.0での「コピー・アンド・ペースト」の危険度w Programing 2.0での「コピー・アンド・ペースト」の危険度wを含むブックマーク Programing 2.0での「コピー・アンド・ペースト」の危険度wのブックマークコメント

元ネタhttp://itpro.nikkeibp.co.jp/article/COLUMN/20080111/290867/

 プログラミングの人気が高まるにつれ,自らのアイデアを表現したいと考える開発者がますます増えている。この表現方法は,ちょっとしたお遊びプログラムから,本格的なアプリケーションにいたるまでさまざまだ。では,これらのコードを作成しているのは誰なのだろう。たいていの場合,開発者ではない。インターネットの登場により,面倒なコーディング初心者の代わりに行ってくれる初心者向け解説サイトが大幅に増えた。これらのWebサイトは実際に使えるわけではないが,事実上コード提供源となっている。Googleで検索すると,このような解説サイトが山のようにヒットする。

 そこで筆者は誰かが作った初心者向け解説サイトの一つを訪れ,そこに掲載されているサンプルコードを元に,自らの新しいアプリケーションを仕立て上げた。このサンプルコードは,誰でも内容を理解して使用することができ,さらにそれさえも面倒な場合は,代わりに同じコードコピー・アンド・ペーストしてくれる。ここで筆者が実際に行ったのは,自分のサイトコードコピペすることだけだった。

 上記の処理でどこが問題か分かるだろうか。Webアプリケーションの脅威が急増する中で,このようなやり方は自ら災難を招くことになる。第一に,コピーしたコードが悪質なものかもしれない。Webサイトの中には,ユーザーが作成した不適切なコードを上手く対策しているものもあるが,それでも悪用につながる小さな抜け穴(セキュリティ・ホール)が存在する可能性はある。

なんてのはどうか?w

やたやた 2008/02/07 12:23 最近のWebサイトはリッチな「AJAX」を使用したサイトが増えてますが
一方、Webアプリは「ZEIJAX」な…(以下略

ikepyonikepyon 2008/02/07 13:02 ZEIJAXwww

2008-02-04 昨日寝すぎた

[]安全なWebアプリのために言語ができること 安全なWebアプリのために言語ができることを含むブックマーク 安全なWebアプリのために言語ができることのブックマークコメント

http://www.rubyist.net/~matz/20080129.html#p02

ちと気になったのでメモ

ORマッパーによるDBへのアクセスというのは、DBデータを抽象化してくれるので便利だとは思うのだけど、かなりオーバーヘッドが大きいと思う(実際のところはコード読んでないのでわからないのだけど)ので、使い勝手が悪いと思う。それより、バインメカニズム(Prepared Statement)しか使えないとしたほうがいい気がする。

あとは、レスポンス出力時にデフォルトではエスケープ処理して出力、タグを使いたい場合は明示的に宣言しないと出力しないという風にするとかなのかなぁと思う。

例えばこんな感じ。

<%=hoge >

とするとエスケープされたhogeの値が出力される。

<nonescape%=hoge>

とするとタグを含んでhogeの値が出力される。って感じで。可能なら、前後HTML構造を解釈して、適切なエスケープをしてくれるとなおベスト(そういうのができるか疑問だけどw)。まあ、こうしても、全て「<nonescape%=hoge>」って書かれてしまうと意味がないのだけど、ケアレスミスによる脆弱性の混入は防げるんじゃないかと。

これがテンプレートシステムによる出力なのかな?

PHPに関しては、なんちゃってセキュリティ対策が多いのが問題だと思うんだよねぇ。言語仕様として、マルチバイトシングルバイトの取り扱いが違うというのも気持ち悪いし・・・

[]ライブドアFONが提携 ライブドアとFONが提携を含むブックマーク ライブドアとFONが提携のブックマークコメント

http://corp.livedoor.com/pressrelease/2008/02/0204-2.html

FONユーザーライブドアAP無料で使えるらしい。

でも、今のところ期間限定なのが、ちょっとなぁ

[]OWASP AppSec 2008 Conference OWASP AppSec 2008 Conferenceを含むブックマーク OWASP AppSec 2008 Conferenceのブックマークコメント

http://www.owasp.org/index.php/OWASP_Australia_AppSec_2008_Conference

2月27日2月29日で開催らしい。話し聞いてみたいけど、オーストラリアはいけねぇorz

[]ここらでアプリケーション脆弱性について考え直してみる ここらでアプリケーションの脆弱性について考え直してみるを含むブックマーク ここらでアプリケーションの脆弱性について考え直してみるのブックマークコメント

アプリケーション脆弱性ってのは、ぶっちゃけて言えばアプリケーションバグor仕様ミス(まあこれもバグの一つか?)のうち、狭義のセキュリティ上の問題になるものだと思うんだな。

ちなみにあらゆるバグは、完全性や機密性、可用性のどれか(複数ってのもあり)を侵害するものなので、広義のセキュリティ上の問題だったりすると思うんだが、それはそれとしてw

まず、一般的に言われているバグがどういう風に起こるか?というと、開発者が想定していない状態になるor結果が得られることであるといえると思う(それが異常終了するとか、予期していた結果が得られないとか)。また、開発者が想定していない使われ方をすると、やはり想定していない結果が得られたり、状態になってしまうことがある。

で、脆弱性があるアプリケーションとはバグor仕様ミスのあるアプリケーションであるともいえるので、脆弱性とはアプリケーション開発者が想定していない状態になるor使われ方をすると、セキュリティ上の脅威が発生することといえると思う(論理の飛躍ありすぎ?)。

では、開発者が想定していない状態にするor使い方をするとはどういうことか?

まず、どんなアプリケーション入力データと起動タイミングなどに依存してその挙動を開発者が思ったとおりに変えるといえる。

例えば、入力データ1と入力データ2の和を表示するようなアプリケーションの場合、入力データ1と2がそれぞれ、「1」、「2」のときは「3」を表示し、「4」、「5」の場合は「9」を表示するといった具合だ。

この例のアプリケーションで、入力データ1と2にそれぞれ、「abc」と「10」を入れた場合、どうなるか?

あるアプリケーションは、「abc10」と表示するかもしれないし、別のアプリケーションは「10」と表示するかもしれない。場合によってはエラーが発生して、エラーメッセージを表示するだろう。

このアプリケーション目的数値計算であるので、開発者が想定していた入力データは「abc」のような文字が入ってくることを想定していなかった場合、いずれにせよ想定していない結果が得られる(どういう事態が起こるかはプログラムの構造に依存するし、それが問題とならない場合もあるだろう)。その結果、セキュリティ上の問題が発生することもある。

一方、開発者入力データに何が入ってくるかandどういう状態で使用されるかわからないと仮定してアプリケーションを作っていたなら、その想定に間違いがなければ、どんな値が入力データとして渡されてもandどういう状態で使用していても、それは全て開発者想定の範囲内の挙動であり、それはバグとはいえない。

開発者が想定していない状態になるor使い方をするには、開発時に開発者が結果を想定していなかったデータを受け取ったり、想定していない状態でアプリケーションを使用すればよい。実際、これらが脆弱性につながっている。

まあ、あらゆる状態を想定するというのはそれなりの経験がないと難しいので、セキュリティ対策が難しいといわれるんだと思うけど・・・

実際のところ、こういう時どうなる?というのを常に考えながら作っていけば、ある程度安全なアプリって作れると思うんだよねぇ。

セキュリティ対策の基本は起こりうるあらゆる状態でも想定の範囲内に押し込めることだと思うんだよねぇ。もし、システム的にそれができないのなら、人的な条件付け(使う人、時、場所を限定するとか)を行うしかないかもね。でも、インターネットに公開するアプリケーションではそういった人的な条件付けというのは基本的に無理なので、システム的に条件をつけるしかないんだけどね。

トラックバック - http://d.hatena.ne.jp/ikepyon/20080204

2008-02-01 眠すぎる

例のブツ、コードが気に入らないので再度一から書き直すことにした。

やっぱり、コードにセンスがないよなぁorz

加えてテストファーストテストを行う予定。

XMLの読み込み部分は単体テストをしてたんだけど、それ以外はやってなかったし・・・

というわけで、次期バージョンは当分先になる予定

[]XSS Chalenges(from 21な人のところ) XSS Chalenges(from 21な人のところ)を含むブックマーク XSS Chalenges(from 21な人のところ)のブックマークコメント

http://xss-quiz.int21h.jp/

その内気が向いたらやるw

どうも攻撃パターンを探すことにあまり興味が出ない今日この頃

yamagata21yamagata21 2008/02/01 22:14 気が向いたら、ぜひw

トラックバック - http://d.hatena.ne.jp/ikepyon/20080201

1900 | 01 | 06 |
2003 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 02 | 03 | 04 |
2011 | 01 | 02 |