水無月ばけらのえび日記

投稿ミスったかな…。

>属性値を動的生成する場合、属性値を必ず二重引用符で括り、" と & と < をエスケープする。

それだけではまずいです。以下の"それマルチバイトで"のところ参照。

openmya.hacker.jp/hasegawa/public/20061209/momiji.html

>javascript: などで始まることがないように注意する。

data: スキーマも危険です。

>たやすいですかね? 確かにXSSがあればたやすいのですが、他の脆弱性がなければ難しいと思うのですけどね。

>しかし、本当にたやすく盗まれるのだとすると、どういう対策をしたら良いのでしょう。Cookieを使わずにとなると、携帯サイトのようにURLにつけたりする事になると思いますが、それはもっと危険だと思いますし……。

ip (範囲)をチェックすれば良いと思います。中間者攻撃には意味ないですが、セッションハイジャックは防げます。ただし、セッションハイジャックができるということは正規利用者を操ることができるため、どこまで有効かは分かりませんが。

>それだけではまずいです。以下の"それマルチバイトで"のところ参照。

　文字符号化方式についてはここでは議論していませんが、それは別途注意すべきでしょうね。属性値に限らず、XSSに限らず発生する問題です。

>data: スキーマも危険です。

　それは「など」に含んでいるつもりです。tel: や mailto: なども場合によっては問題がありますし、危険なものを列挙する方向では考えたくないですね。その後ろに書いてあるように、http: か https: 以外は入ってこないようにした方が良いという考えです。

>ip (範囲)をチェックすれば良いと思います。

　同組織内に攻撃者がいたら防げません。携帯サイトならばそれなりに効果があると思いますが、PCサイトでは危険ではないでしょうか。

>　同組織内に攻撃者がいたら防げません。携帯サイトならばそれなりに効果があると思いますが、PCサイトでは危険ではないでしょうか。

　いや、携帯サイトでも危険は危険ですよね。Referer漏洩の危険が相対的に少ない、というのはあるのかもしれませんが。

# 携帯サイトだって、好きでURLにつけているわけではないはず。

>>ip (範囲)をチェックすれば良いと思います。

>　同組織内に攻撃者がいたら防げません。携帯サイトならばそれなりに効果があると思いますが、PCサイトでは危険ではないでしょうか。

むしろ全員が特定少数のゲートウェイからのアクセスになってしまう携帯サイトでは効果が期待できないと思います。

それはそれとして、以下の2つの分類は同じ「メタ文字の不適切な取り扱いバグ」が原因の脆弱性なのにも関わらず、出力先がHTMLかそうでないかで別になっているのが気になります。攻撃対象がクライアント側かサーバ側かということなのかもしれませんが、この分類方法だといわゆるタイプ2のXSSが漏れるので良くない感じがします。

・入力値をそのまま出力してしまう「エコーバック問題」

・ 悪意のパターンが注入されてしまう「入力問題」