ダウンを検知して運用を良くするするためのツールだけど、実はそこに脆弱性があることも・・・
というお話。
世の中監視ソフトも出回ってるだけで色々あります。
それに単純な死活監視ものなら自社で開発しちゃったり、というのも珍しくないでしょう。
ではその監視ソフトは管理するコンソールを持っているとして、そうこんな感じに。
| ホスト | サービス | ステータス | 詳細 |
| ServerA | HTTP | 稼働中 | HTTP/1.x 200 OK |
良くあるWEBブラウザで見るタイプ、状態が一目でわかっていいよね。
丁寧にサーバレスポンスも記録してくれて親切！
だけども。
このようにレスポンスを 「取得 ⇒ DB格納 ⇒ WEB表示」とやるようにしているのって気になりますよね。
例えばこちら、 thttpd というHTTPサーバソフトがあります、シンプル＆軽さがウリです。
ソースにちょっと手を加えてみましょうか。
今回実験に使用したのは "thttpd-2.25b"。ソースを展開して、"libhttpd.c" の503行目、ちょうどHTTPのレスポンスを記述している部分を。
static char* ok200title = "OK";
↓↓
static char* ok200title = "OK <script>alert(\"XSS\")\;</script>";このように。
まあ何がしたいかは判るよね。
それではこの書き換えた thttpd をサーバ：testserver 上でコンパイルして起動します。
>thttpd -p 20000では、 http://testserver:20000/ にWEBブラウザでアクセスしてみましょう。
ぱっと見変哲はないけど、レスポンスヘッダを取得すると、
HTTP/1.x 200 OK <script>alert("XSS");</script>
Server: thttpd/2.25b 29dec2003
Content-Type: text/html; charset=iso-8859-1
--snip--こんな感じ、イカレたヘッダが混ざっているね。
これを監視サーバが食っちゃうと、、、
| ホスト | サービス | ステータス | 詳細 |
| ServerA | HTTP | 稼働中 | HTTP/1.x 200 OK <script>alert("XSS");</script> |
さて、無事に表示されるだけで済むかしら。
XSSならまだしも、SQLが通るようだと事によっては目も当てられない状況になるかもしれない。
さて、WEBアプリっていう側面で見れば当たり前の対策も、監視サーバの状態表示機能と位置付けたら結構対策を見落とすような気がする。
確かにこのケースはどういった経緯で発生するかなどは全く考慮してないけども、サーバ(通信相手)がいつも行儀のよいレスポンスを返してくれるとは限らないということは伝わっただろうか。
ちなみに監視サーバの代表例として、Nagiosの3は大丈夫だ。2.9頃にXSSの対策が入ってたが、もしかしたらこういうケースへの対策だったのかもしれないな。
このネタを思いついたのはそのNagiosのアナウンスを見てからだし。
