2009年3月18日(水曜日)
秋期限定栗きんとん事件 上
公開: 2009年3月19日0時10分頃
とりあえず上巻は読み終わったので。
- 秋期限定栗きんとん事件 上 (www.amazon.co.jp)
別れた二人がどうなるのかと思ったら、「小鳩&小佐内」ではなくて「小鳩vs小佐内」風の展開なのですね。それはそれで面白い。ていうか小鳩、クラスメイトの名前覚えろよ! いくら何でもひどすぎます。
そして瓜野。小佐内さんになんてことを……。小佐内さんのナイスディフェンスで、たぶん瓜野自身が命拾いをしたはず。
ともあれ、このまま下巻を読みます。
- 「秋期限定栗きんとん事件 上」にコメントを書く
「成立しない」の意味
公開: 2009年3月19日0時10分頃
XSS脆弱性の危険性に関連して、ockeghemのブックマーク - 2009年3月17日 (b.hatena.ne.jp)のブックマークコメントの意味が一瞬分からなかったので、反応してみたり。
最近頻発しているとLAC社が伝えるサイト改ざんによるマルウェア埋め込みはSQLインジェクションが直接原因だが、XSSもないと成立しない。参考 http://d.hatena.ne.jp/ockeghem/20080718/p1 http://itpro.nikkeibp.co.jp/article/COLUMN/20080624/309303/ 2009/03/17
最初「成立しない」という意味が分からなかったのですが、これはSQLインジェクションで「<script>……」とか「<iframe>……」とかいう文字列をひたすらDBにつっこんで、それがサイト上にそのまま表示されることを期待する攻撃ですね。この攻撃でDBに「<script>……」と入れられても、XSS脆弱性がないサイトであれば、それは「<script>……」と出力されるはずです。その場合スクリプトは動作しませんから、XSSがなければ、攻撃者の用意したスクリプトは実行されない、と言えます。
ただ、SQLインジェクションが成立した時点でDBのデータは壊されてしまいますので、明らかに被害は発生します。これを「攻撃が成立しない」と言ってしまって良いのか、やや微妙に思います。徳丸さんは「攻撃者の意図は完遂されない」という意味で「成立しない」と言われているのだと思いますので、それはそれで正しいと思いますが。
※ただ、可能性としては、「入力時に一律HTMLエンコードを行い、DBにはエンコード後の文字列を格納する」というポリシーで設計されている可能性もあって、その場合には、この攻撃は成立するけれどもXSS脆弱性があるとは言えない、ということもあり得ると思います。いや、もちろんそんな変な設計は推奨しませんけれども。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性 / SQLインジェクション / 与太話
XSS脆弱性の危険性
公開: 2024年12月21日16時10分頃
「世間の認識と脅威レベルのギャップ――XSSは本当に危ないか? (www.atmarkit.co.jp)」。
脆弱性の脅威が過剰に評価されている傾向はあると思いますね。脆弱性検査の結果なんかで「500エラーが出ている」とか「HTTP応答ヘッダでサーバのバージョン情報が出ている」とかいったものが問題にされたりしますが、「それ対応する必要あるの?」と思います。検査している方としても、「念のため」レベルで報告しているのだろうと思いますが、受け取り側はそうは受け取らない場合もあるようで。まあ、報告の書き方の問題なのかも知れませんけれども。
緊急度をざっくりいくつかに分けて考えるとすると、だいたいこんな感じなのでしょうか。
- 緊急: 今すぐサイトを閉鎖して対応しなければならないもの
- 重要: 早急に対応しなければならないもの
- 要対応: 急ぎではないが、対応が必要と考えられるもの
- 対応不要: 対応が不要と考えられるもの
SQLインジェクションで実際に攻撃が行われた場合や、サーバが不正アクセスされたような場合は「緊急」。SQLインジェクションが発見されたが攻撃はされていないと考えられるような場合は、緊急と言いたいところですが、実際は「重要」レベルの対応になるでしょう。XSSはたぶん「要対応」レベルですね。ただ、川口さんが元記事にも書かれているように、持続型XSSの場合は脅威の度合いは少し高いのではないかと思います (予告.inみたいなケースもあるので)。
ところで、通常のXSS脆弱性の特徴は、なんといっても「発見しやすい」という事だと思います。
脆弱性を見つける“だけ”なら技術力がなくてもある程度発見可能
というのはまったくその通りだと思いますが、通常、ウェブアプリケーションの開発には「テスト」という工程があるはずで、そのテストにおいてもXSS脆弱性は発見されやすいはずです。そして普通、XSSは単なる実装上のバグに過ぎず、簡単に修正できます。
※もっとも、「このXSSを修正するためには設計を見直す必要があるので今は修正できません」という主旨のことを言われた経験もありますが。
ですから、まともにテストをやっていれば、簡単なXSS脆弱性は残らないと思うわけです。XSSは、まともにテストをやっているかどうかという点を見るためのバロメータになると思います。というわけで個人的には、外注先を選定するような場合、XSS脆弱性があるかどうかという点は結構重視しています。
※判断基準にできるくらい見つかってしまうのもおかしいとは思うのですけれど。
……あと、たまに、IPAに届け出られたXSS脆弱性の件数を「被害件数」と思っている人がいて、「XSSの被害はたくさん発生している」と誤解されている場合もあったりしますね。
関連する話題: セキュリティ / クロスサイトスクリプティング脆弱性
- 前(古い): 2009年3月16日(Monday)のえび日記
- 次(新しい): 2009年3月19日(Thursday)のえび日記