XSSを報告したらちょっと不便になった
この記事は脆弱性"&'<<>\ Advent Calendar 2015の16日目の記事です。
2015年のアドベントカレンダーですが、大昔(2013年)にミスタードーナツ公式ページにあったXSSの話をします。
2013年3月
ミスタードーナツの公式サイトへ行った時、偶然にも検索画面で怪しい文字列を発見してしまいました。最近ではあまり見かけなくなった ie=utf-8&oe=utf-8 のようなパラメータです。
XSS界隈の人なら恐らくこんな感じのパラメータを見たらちょっと変えてみてどのような挙動を起こすか試したくなるはずです。
実際にoe=utf-8を変えたらそれに対応する値がmetaのcharsetに入るようでした。当時のことを詳しく覚えていませんが、ここから直接XSSしたわけじゃないので多分値はエスケープされていたと思います。
エンコーディング周りでは当時UTF-7が終わりを迎える時期でしたが幾つかのUTF-7 XSS記事が出回っていたためそれを試してみると、IE8なんかでは普通にcharset=UTF-7として認識されました。
というわけでレアケースなUTF-7 XSSが確認できたのでIPA経由で報告し、1ヶ月後には修正されたのですが修正方法がちょっと残念でした。
検索ボックスがそのまま消えた
奇跡的にInternetArchiveで検索ボックスが消える様子が確認できたのでそのスクリーンショットを貼ります。
報告前2月18日
修正後5月3日
サイト内の検索が無くなったため、若干アクセシビリティは減ったはずです。
回避はできなかったのか
当時送信したIPAへの届け出のメールを見たところ、当時のフォーマットには回避策の欄が(多分)無かったようです。そのためどのように修正するのが最善かがうまく伝わらなかったと思われます。今のフォーマットには回避策の欄があるので、脆弱性を報告するときは現状の機能を損なわないように的確に修正案を書きましょう。
--
14:35 追記 間違えてソフトウェアの方と比較してしまったらしく、今もWebの脆弱性報告には回避策の欄はないようです。脆弱性を報告して機能が消えるのはつらい…。
「回避策」は今もソフトウェアのほうだけだし、記入の手引きを見るに開発者ではなくユーザーの回避策を書く欄なのでは。
https://t.co/cqoVv7PsRP
XSSを報告したらちょっと不便になった - バランスを取りたい
https://t.co/zrRoclArWo
— kusanoさん@がんばらない (@kusano_k) 2015, 12月 16