備忘録：Bucket4Jによるレートリミット

目的

ログイン、登録画面にレートリミットを導入します。

ログイン試行や登録処理の大量送信を避けるためです。

（他には、アカウント毎の試行回数制限（クライアントへ上限突破で通知等）、Webアプリケーション全体で適用するAWS ShieldとAWS WAFは検討中です。お財布に優しい範囲で...）

実装の前に

今回、使用する資料です。

トークンバケット - Wikipedia(バースト等の用語理解にも...)

流れとしては、

バケツにトークンが入っていて、リクエスト毎に消費していく。

トークンは設定に基づいて補充される。

空になると429を返す。

具体的には...

Bucketインターフェース：最大容量のトークンバケットを返す。

BandWidthクラス：バケットの制限を定義する。帯域幅を使用してバケットの容量と補充速度を設定する。

Refillクラス：トークンがバケットに追加される固定レート（一定時間内に追加されるトークン数）を定義する

スロットラー（Throttler）：特定のリソースやサービスに対するリクエストやアクションの頻度を制限するための仕組みやツールを指す

Refillでは三種類の補充方法がある。

①Greedy：トークンが利用可能になり次第、頻繁に補充する。

②Interval：間隔を空けて補充する。例だと、補充してから一分後に100トークン。

③IntervallyAligned：特定の時間に補充する実装ができる。

感想

SpringSecurityから始まったセキュリティを考えた実装ですが、アプリが完成していくにつれて、力を入れるべき点だと思います。

もちろん、アプリケーション側の実装でもWebSocketを使用しているので、エスケープ処理や認可処理、改ざん対策等を考えています。

今後の方向性としましては、現状のまま進めて、何かしらのツールから脆弱性の診断を行う&セキュリティの学習を継続して改善していく...でしょうか。

余談

朝から晩までプログラミングをしています。

Bootstrapは使用してきましたが、操作により、要素を無くしたり、隠したり...動的に追加した要素にデザインを加えるのが、時間のロスに繋がったと思います。
JavaScriptの基礎はまだですが、調べ調べで望む実装にはできたと思います。

また、MDN Docsには、セキュリティで懸念する事項の記載があるので、そのまま勉強になります。

等です。

なかなか記事を書く時間がないのが、心苦しいところです。

AWSと基本情報技術者試験の学習、機械学習等を念頭に置いた数学の学習、コーディング力向上のため競プロ...後者になるにつれて、時間が取れない傾向にありますが、成果を出せる人になりたいので、可能な限り、続けます。

yuusuke-roughの日記