はじめに

※当記事にはWAFの設定に関しての具体的内容は含まれていない旨ご了承ください🙏
Rails及びAWSを活用した案件開発を行っていたある日のことでした

問題

「特定のユーザーがログインしようとした際、必ずエラー画面が表示されてしまうので調査頂きたい」といった趣旨のお問い合わせがありました。
ひとまずアプリケーションのログをAthenaで追ってみても問題事象に関連していそうなログが残っておらず、一見して原因が分からないという状況でした。

今回の対処法: WAFの検証ルールを緩和

アプリケーションのログに何も残っていないという点から、より前段で止まっていると仮定してWAFのログを確認しました。すると以下のようなログが残っていました

AWS-AWSManagedRulesSQLiRuleSet
MANAGED_RULE_GROUP
BLOCK
[{conditiontype=SQL_INJECTION, location=BODY, matcheddata=[authenticity_token, &, user, [login_name], --dayo&user[password]=test_password&commit=ログイン]}]

内容を確認すると、ユーザーからのログインリクエストがWAFによってSQLインジェクションと判定されブロックされてしまっているようです。

そして対象ユーザーのアカウント情報を改めて確認した所、ログインIDがtky--dayoといった--を含む形になっていました

SQLにおいて--を使用すると以降の記述がコメントとして扱われるという性質があるため、このような検出がなされたようです。
(例えばログインID、パスワードの一致を要求する所、ログインIDに--を混ぜることでパスワード部分の判定を回避しようとするなど)

アカウント登録周りの実装を確認した所、', ", ;, #あたりは禁止文字として入っていたものの、--は抜けてしまっていたようでした...😢

以前当案件において実施された外部脆弱性診断等の結果も加味して、アプリケーション上の当該処理部分はSQLiへの耐性を十分持っていると開発チーム内で判断しましたので
今回はWAFを統括管理しているSRE部署にWAFのルール設定緩和(特定のパス、パラメータにおいて--を許容する)をお願いして、事象の解決という運びとなりました🙏

おわりに

このような問題に後から対応しようとすると

都度のWAFのルール緩和
- 無停止で比較的楽に対応出来る反面、セキュリティ的に弱くなることには変わりないですし、この文字・パターンもダメだった～的なイタチごっこに...
既存ユーザーのログインID変更＋アカウント登録時の禁止文字・パターン追加
- ~~単純に色々と辛いです~~

といった対応が必要となってくると考えられるため、
ログイン処理周りなどはWAFの存在等も加味した上で最初にしっかりと設計しておくことが肝要であるという学びを得ました

参考にさせて頂いた記事など