API呼び出しで403エラー(AWS WAF編)
事象
ある日、Webアプリケーションの開発中、何の問題もなくAPI呼び出しして正常応答だったのに突然エラーになってしまいました。
プログラムも特に直近修正していないし、なぜ?
ちなみにAPIからの応答は、403: Forbidden。
403ということは、なにか権限不足?
一通り権限のチェックをしてみたけれど特に怪しいところも変なところもない。なんなんだ?
いろいろ調べた結果、タイトルで既にネタバレしていますが、インフラチームが追加したWAF(Web Application Firewall)が通信内容をチェックしてブロックしていたのでした。
ちゃんと動いてたんだ~(^^;)
確認方法
AWSマネジメントコンソールからWAFの設定画面を開き、WebACLsをクリックします。
右側のプルダウンから該当するルールセットを選択します。どのルールで引っかかっているか分からないと思うので一通り確認します。
今回はこのAWSManagedRulesCommonRuleSetというAWSが予め用意している一般的なルールセットで引っかかってました。
WAFで検知したリクエストのうちサンプリングしたものが表示されます。
- Meric name:WAFのルールセット名
- Source IP:リクエスト送信元IPアドレス
- URI:検知したリクエスト
- Rlue inside route group:ルールセット内に定義されているルール詳細
- Action:WAFがどう処理したか
- Time:検知時刻
Action(⑤)がBLOCKになっているので、APIに飛ばしたリクエストがブロックされてしまっています。ちなみにURI(③)をクリックすると更にリクエスト内容の詳細が確認できます。
今回はGeneric_RFI_BODYというルールに引っかかってブロックされてしまいました。公式ドキュメントによると、
IPv4 アドレスを含む URL を埋め込むことにより、ウェブアプリケーションの RFI (リモートファイルインクルージョン) を悪用しようとする試行に対してリクエストボディを検査します。例としては、
ベースラインルールグループ コアルールセット (CRS) マネージドルールグループhttp://
、https://
、ftp://
、ftps://
、file://
などのパターンがあり、悪用の試みに IPv4 ホストヘッダーが含まれています。
ということでどうやらリクエストにIPアドレスが含まれていたのでブロックしたみたいです。
マネージドルールを使うと簡単な設定で一般的に危ないリクエストをこのように弾いてくれますので便利な反面、今回のようにシステムが想定外の動作をしてしまう可能性もあります。
目的に機能を実現するにはこのルールを変更しなければならない時もあります。そんな時は、WAFのルールを一部変更することでブロックしないようにすることができます。
WAFの設定を変更
ブロックされていたリクエストを通過させて問題ことの確認が取れたら、WAFで通過できるよう設定を変更します。
WAFの画面で該当するルールセットを選択しEditボタンをクリックします。
このようにルールセットに定義されている各ルールについて、どう処理するか細かく設定できます。
今回は、RFI_BODYがブロックされてしまっていたので、これを通過(Allow)に変更して設定を保存すれば設定変更完了です。
設定変更結果の確認
ブロックされたリクエストを再度送ってみましょう。
おお、今度は通過!設定変更がうまくいきました。これでエラーはもう出ないはずです。
まとめ
このように開発中には起きなかった問題がインフラ設定によって発生することもありますので、ブログラムコードに問題が見つからない場合はインフラの設定を確認してみましょう。あっさり解決するかもしれません。
- WAFのマネージドルールを使うと簡単にWebアプリケーションへの攻撃を防ぐことができる
- どんなルールがあるのか確認しておく必要がある
- 遅くてもシステム開発の総合テストぐらいからセットしておくと安全
- ルールを変更する場合はセキュリティ的に問題がないか慎重に検討してから行う
それにしてもロードバランサーやAPI Gatewayにアタッチすればすぐにセキュリティの強化ができるWAFは便利ですよね。
コメント