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時にその値も合わせて送信するようにします。

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

サイト全体

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; // 完全に禁止する場合

サイト全体

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

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

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

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

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

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

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