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インジェクションなど有名で派手な脆弱性は意識的に気をつけていますが、こうした小さい項目はあまり注目していませんでした。
ある個人のアカウントがなりすまされてしまったり開発者が意図しない動作を引き起こされてしまうと、そこから別の犯罪に利用されたりという可能性があります。
脆弱性の情報に触れるたび、「うちのサービスでは大丈夫だったかな...」と思い返すようにしたいですね。