1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

サーバ側の処理にアクセス制御は必須

Last updated at Posted at 2024-11-06
1 / 9

HTTPプロトコルの特徴

  • ステートレス
    文脈を持たない
    =毎回のリクエストに必要な情報全てが詰め込まれる

画面仕様によるアクセス制御は信用できない

  • ブラウザからのリクエストとは限らない
  • ログインしないとこの画面には到達できないから、このリクエストも送信できない・・・と考えてはならない!
  • アプリが想定しない順序でリクエストを送る手段はいくらでもある
    curlコマンド/Postman/開発者ツール/負荷ツール など・・・

HTTP通信を安全に実装する際の考え方

  • 全リクエストが「信用できない」と考える
  • リソース単位でアクセス可否を設計する
    • 認証なしでアクセス可能(ログイン画面など)
    • 認証されていないとアクセスできない(ほとんどのリソースはこれ)

実装面では、1カ所で認証するべき

  • たいていのフレームワークに、全リクエストで統一的に処理を仕込む手段が提供されている
  • たいていのフレームワークに、認証を実現する手段が提供されている

認証済みかどうかだけでは不足

  • 同じサービスの他人の情報を覗こうとしていないか、チェックが必要
  • サーバ側で保持する情報と照合して、許可されるデータのみクライアントに返す

応用・パラメータも同様

  • リクエストに載ってくる全てのパラメータは信用できない
  • 必須かどうか/フォーマット/長さ/改行有無/不正な文字(非可視文字)など
  • セキュリティホールとなることもある

余談・WebSocketについて

  • 毎回必要な情報を全て送るのは非効率
  • WebSocketは一度接続したらずっと接続している
    → 接続時に安全を確認したら、基本ずっと安全

最後に

  • HTTPリクエストはブラウザを前提としません
  • 全リクエストを信用できないと考えよう
  • リソース単位でアクセス可否を設計しよう
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?