API-Security-Checklist/README-ja.md at master · shieldfy/API-Security-Checklist · GitHub
という
認証
Basic認証
を 利用せず、 標準的な 認証を 利用する (例: JWT、 OAuth)。
Basic認証
について Apache 等の
HTTPサーバーで 設定できる 簡易な 認証です。 ベーシック認証(Basic認証)とは
?設定方法と 注意点・エラーに なる 原因を 解説 | Webmedia nginx でも
設定できるのか 気になったのですが、 以下の 記事を 見る 限りできるようです。 Nginx で Basic 認証 - Qiita
認証
、トークンの<wbr>生成
、パスワードの<wbr>保管
の 車輪の 再発明を 行わず、 標準化されている ものを 利用する。
オレオレで
ログインでは最大リトライ回数(Max Retry)
と jail機能を 利用する。
- jail機能
API Security Checklist に
以下の
全ての 機密情報は 暗号化する。
ここは
JWT (JSON Web Token)
jwt に
ブルートフォース攻撃を 困難に するため、 ランダムで 複雑な キー(JWT Secret
)を 使用する。
- JWT
JWTに
JSON Web Token(JWT)の
JWT Secret
セキュリティ視点からの3.2. 脆弱な<wbr> HMAC 鍵を<wbr>ブルートフォースに<wbr>よる<wbr>特定
に
ペイロードから アルゴリズムを 抽出しては いけない。 必ず バックエンドで 暗号化する (HS256
またはRS256
)。
JWT ハンドブック の
以下は、
JSON Web Encryption (JWE) は
データを 第三者に 対 して 不透明に する ⼿段を 提供します。 この 場合、 不透明とは 読み取れない ことを 意味します。 暗号化された トークンを 第 三者が 調べる ことは できません。 この 機能は、 さまざまな ⽤途に 活⽤できます。
ペイロードを
トークンの 有効期限(TTL
, RTTL
)を 可能な 限り短くする。
TTL
(time to live) RTTL
(reflesh time to live) に
以下の
どれくらいの
JWTの ペイロードに 機密情報を 格納しては いけない。 それは 簡単に 復号できる。
ペイロードには、
個人情報とは
OAuth
OAuth の
サーバサイドで 常にredirect_uri
を 検証し、 ホワイトリストに 含まれる URLのみを 許可する。
これは
常にtokenではなく codeを 交換するようにする (response_type=token
を 許可しない)。
"response_type=token
を
OpenID Connect ではresponse_type=token
を
英文で
state
パラメータを ランダムな ハッシュと 共に 利用し、 OAuth認証プロセスでの CSRFを 防ぐ。
以下の
デフォルトの scopeを 定義し、 アプリケーション毎に scopeパラメータを 検証する。
scopeパラメータの
アクセス
HTTP/HTTPS での
DDoSや ブルートフォース攻撃を 回避する ため、 リクエストを 制限(スロットリング)する。
GCPの
Apache HTTPサーバー、
以下は、
仕事では
bucket4j を
MITM(Man in the Middle Attack)を 防ぐため、 サーバサイドでは HTTPSを 使用する。
日本語だと、
SSL Strip attackを 防ぐため、 SSL化とともにHSTS
ヘッダを 設定する。
以下、HSTS
に
SSL Strip attack に
以下はSSL Strip attack
での
入力
API の
操作に 応じて 適切な HTTPメソッドを 利用する。GET(読み<wbr>込み)<wbr>
, POST<wbr>(作成)
, PUT/PATCH(置き<wbr>換え/更新)
, DELETE<wbr>(単一レコードの<wbr>削除)
。 リクエストメソッドが リソースに 対して 適切ではない 場合、405 Method Not Allowed
を 返す。
この辺りは、
リクエストの Acceptヘッダ(コンテンツネゴシエーション)のcontent-type
を 検証する。 サポートしている フォーマット(例: application/xml
, application/json
等)は 許可し、 そうでない 場合は406 Not Acceptable
を 返す。
指定ミスの
Accept ヘッダの
POSTされた データのcontent-type
が 受け入れ可能(例: application/x-www-form-urlencoded
, multipart/form-data
, application/json
等)かどうかを 検証する。
このケースも、406
エラーを
ユーザーの 入力に 一般的な 脆弱性が 含まれていない ことを 検証する (例: XSS
, SQLインジェクション
, リモートコード実行
等)。
以下の
この辺りの
URLの 中に 機密情報(認証情報
, パスワード
, セキュリティトークン
)を 利用せず、 標準的な 認証ヘッダを 使用する。
オレオレで
キャッシュ、 Rate Limit policies (例: Quota
, Spike Arrest
, Concurrent Rate Limit
)を 有効化し、 APIリソースの デプロイを 動的に 行うため、 APIゲートウェイサービスを 利用する。
APIゲートウェイを
DDoSや
ブルートフォース攻撃を 回避する ため、 リクエストを 制限(スロットリング)する。
その他、
- API gateway (API ゲートウェイ) とは
- 機能と 役割 | Red Hat - API ゲートウェイ パターンと、
クライアントから マイクロサービスへの 直接通信との 比較 | Microsoft Docs
処理
プログラミングに
壊れた 認証プロセスを 回避する ため、 全ての エンドポイントが 認証に より 守られている ことを 確かめる。
「認証の
ユーザーに 紐付いた リソースIDを 使用しては ならない。/user/654321/orders
の 代わりに/me/orders
を 利用する。
個人情報に
情報自体に
オートインクリメントな IDを 利用せず、 代わりにUUID
を 利用する。
これも
XMLファイルを パースする 場合、XXE
(XML external entity attack)を 回避する ため、 entity parsingが 有効でないことを 確認する。
以下の
XMLファイルを パースする 場合、 exponential entity expansion attackに よるBillion Laughs/XML bomb
攻撃を 回避する ためentity expansion が 有効でないことを 確認する。
Java では
ファイルアップロードには CDNを 利用する。
API での
CDN を
大量の データを 扱う 場合、 バックグラウンドで Workerプロセスや キューを 出来る 限り 使用し、 レスポンスを 速く 返すことで HTTPブロッキングを 避ける。
HTTPコネクション数にも
デバッグ・モードを 無効に する ことを 忘れないでください。
API Security Checklist の
出力
X-Content-Type-Options: nosniff
を ヘッダに 付与する。
XSS を
- X-Content-Type-Options - HTTP | MDN
- 知っていれば
恐くない、 XMLHttpRequestに よる XSSへの 対応方法:HTML5時代の 「新しい セキュリティ・エチケット」 (3)(2/2 ページ) - @IT
X-Frame-Options: deny
を ヘッダに 付与する。
IFrame での
Content-Security-Policy: default-src 'none'
を ヘッダに 付与する。
これは
BFFが
フィンガープリントヘッダを 削除する - X-Powered-By
, Server
, X-AspNet-Version
等。
これは
content-type
を 必ず 付与する。もし<wbr>application/json
を 返す 場合、content-type
はapplication/json
に する。
クライアントプログラムや、
認証情報
, パスワード
, セキュリティトークン
と いった 機密情報を 返さない。
ストレートに
処理の 終了時に 適切な ステータスコードを 返す(例: 200 OK
, 400 Bad Request
, 401 Unauthorized
, 405 Method Not Allowed
等)。
これも
CI & CD (継続的インテグレーションと 継続的デリバリー)
セキュリティとは
ユニットテスト/結合テストの カバレッジで、 設計と 実装を 継続的に 検査する。
自動テストを
コードレビューの プロセスを 採用し、 自身に よる 承認を 無視する。
コードレビューに
プロダクションへ プッシュする 前に、 ベンダの ライブラリ、 その 他の 依存関係を 含め、 サービスの 全ての 要素を アンチウイルスソフトで 静的スキャンする。
Java の
デプロイの ロールバックを 用意する。
リリース後に
「何故やるのか?」の
モニタリング
2022年11月に
APIやAPIの
すべての サービスと コンポーネントに 集中ログインを 使用します。
中央集権的な、
認証、
- そもそも
監視システムを 使っていない。 - 監視システムを
使っているけど、 認証認可が 中央集権的ではない。 - APIの
認証が ない。
などの
すべての トラフィック、 エラー、 リクエスト、 および レスポンスを 監視ために、 エージェントを 使用します。
監視システムだと、
- エラー、
リクエスト、 トラフィック、 レスポンスを 監視しているか? - 監視している
監視システムは すべて 同一か ?
SMS、 Slack、 Email、 Telegram、 Kibana、 Cloudwatch、 などの アラートを 使用します。
このチェック項目は、
と
通知を
* 通知の
* エラー時の
クレジット・カード、 パスワード、 PIN、 などの 機密データを ログに 記録していない ことを 確認します。
これは
各情報を
APIリクエストと インスタンスを 監視ために IDSや IPSシステムを 使用します。
IDSは、不正侵入検知システム
で侵入防御システム
です。
それぞれの
アプリケーション開発担当と、
以上です。
コメント