脆弱性
NIJIBOXDay 22

2017年に遭遇したWEBサービスの脆弱性

17卒でニジボックスに入社した@ats05です。

入社から9ヶ月目、現在は交通系サービスの予約システムの開発・運用をしています。

そこで実際に発生していた脆弱性と、実施した対策について忘れないため記事にしたいと思います。

教科書的な脆弱性対策の話ではなく、実装時に見落としていた脆弱性なので、より活きた情報ではないかなと。

1.メールヘッダの改行コードインジェクション

発生箇所

クライアントサイト内、メールアドレスを登録する部分

原因

登録処理のバリデーション不備

メールアドレスを登録する際、htmエンコードされた改行コード(%0d%0a)を利用することで、メールヘッダに複数のメールアドレスを挿入することが可能になり、想定外の操作がされてしまう可能性があります。

今回の事象では、メールアドレスをhogehoge@example.com%0d%0aCc:fugafuga@example.comとして入力すると、メール送信時に改行コードを判断し、

To:hogehoge@example.com
Cc:fugafuga@example.com

というメールヘッダが作成されてしまいます。

対策

メールアドレスを正規表現で補足しようとすると、特定のキャリアでのみ特殊な文字が許されていたりと非常に厄介なようです。

複雑にしすぎた正規表現は見るだけでもうアレなので、極力シンプルにしたいところです。

というわけで、結局これに落ち着きました -> ^[\w_.-]+@[\w_.-]+$

フロントエンドのバリデーションはもちろん行いますが、ローカルプロキシ等を使えばいくらでも回避できるので、

きちんとバックエンドでもチェックします。

2.XSRF

発生箇所

あるwebアプリ上で、APIサーバにデータを送信するsubmitボタン

原因

認証トークンの不備

現時点で、主要なフレームワークにはほぼXSRFの対策が組み込まれています。

具体的には、ランダムな値をhidden属性のフォームで送信するといった方法が取られています。

今回はこれが発生したのは、あるwebアプリ(SPA)から別のAPIサーバにPOSTする部分で、ここはフレームワークの管轄外になってしまいます。

自動で挿入されているため逆に見落としが発生しがちなポイントでした。

対策

サーバでセッションと紐付いたランダムな値を発行し、webアプリ側ではPOST時にその値も合わせて送信するようにします。

フレームワークが自動でやってくれていることを手動で実装できれば十分だと思います。

3.クリックジャッキング

発生箇所

サイト全体

原因

iframe等でページを任意のサイトに埋め込めてしまうようになっている

クリックジャッキングの説明は割愛しますが、要は必要のあるページ以外iframe等で呼び出せないようにしてしまえばいいわけですね。

対策

Apache/Nginxの設定ファイルに以下の記述を追加

  • Apache

    Header append X-Frame-Options SAMEORIGIN // 同一生成元での埋め込みのみ許可する場合
    Header append X-Frame-Options DENY // 完全に禁止する場合

  • nginx

    add_header X-Frame-Options SAMEORIGIN; // 同一生成元での埋め込みのみ許可する場合
    add_header X-Frame-Options DENY; // 完全に禁止する場合


4.CookieのSecure属性不備

発生箇所

サイト全体

対策

Secure属性をオンにする設定をする

フレームワークによって異なるが、設定ファイルのCookieに関連する項目付近にあるはず

CookieがSecureでないと、httpsでないときもそのcookieを送信してしまいます。つまり、スニッフィングツールなどで簡単にCookieを盗聴できてしまいます。

セッション管理を利用されて、なりすまし等が可能になってしまいます。


XSSやSQLインジェクションなど有名で派手な脆弱性は意識的に気をつけていますが、こうした小さい項目はあまり注目していませんでした。

ある個人のアカウントがなりすまされてしまったり開発者が意図しない動作を引き起こされてしまうと、そこから別の犯罪に利用されたりという可能性があります。

脆弱性の情報に触れるたび、「うちのサービスでは大丈夫だったかな...」と思い返すようにしたいですね。