30

私は大規模なプロジェクトにPlayを使用することを考えています。OWASP Top 10 で Play フレームワークをテストした人はいますか? Play フレームワークで知っているセキュリティ上の問題はありますか?

4

2 に答える 2

41

OWASP Top 10 と Play について (ここにいくつかの情報があります):

  • A1: 注射

    JPA を使用し、デフォルトで文字列をエスケープします

  • A2: クロスサイト スクリプティング (XSS)

    バージョン 1.0.1 以降、Play のテンプレート エンジンは自動的に文字列をエスケープします。

  • A3: 壊れた認証とセッション管理

    Play はステートレスであり、セッションは関与しません。クッキーは暗号化によって保護されています。ハッシュを介してデータベース (パスワード) にデータを安全に保存することは、フレームワークではなくユーザーに依存します。

  • A4: 安全でない直接オブジェクト参照

    繰り返しますが、これは開発者が許可されたリソースへのアクセスを検証することに依存し、フレームワークにはあまり依存しません

  • A5: クロスサイト リクエスト フォージェリ (CSRF)

    POST リクエストでは、認証トークンを使用してこれを防止できます。もちろん、これはGET/POSTを適切に使用する開発者に依存します

  • A6: セキュリティの構成ミス

    デフォルトのエラー報告プロセスは、本番環境では安全なようです (スタック トレース リークはありません)。唯一の懸念事項は、ルートの「キャッチオール」エントリですが、これは本番モードではコメントアウトする必要があります

  • A7: 安全でない暗号ストレージ

    開発者は、データベース内の機密情報を暗号化する責任があります

  • A8: URL アクセス制限の失敗

    開発者は、禁止されたページへのアクセスを禁止するために、(チュートリアルのように @Before を介して) セキュリティ制限を実装する必要があります。

  • A9: トランスポート層の保護が不十分です

    Play は SSL をサポートしています

  • A10: 検証されていないリダイレクトと転送

    再生リダイレクトは、ハードコードされた文字列ではなく 302 経由で行われるため、これを防ぐことができます。

TL;DR: フレームワークがすべての作業を行うことができる部分では、Play がそれを行います。開発者がすべての作業を行う必要がある部分では、開発者がすべての作業を行う必要があります。それぞれの 50% を必要とするパーツ、Play はその 50% を与えます。

このように言いましょう: Play が他の Java フレームワークよりも安全でないと考えるべき理由はありません。多くの場合、より安全と考えることができます。また、Play は開発者にとって簡単で、ステートレスで REST フレームワークであるため、混乱する可能性は少なくなります。

于 2011-06-17T10:06:16.310 に答える
5

A3については、注意が必要です。Play には 2 種類のセッション変数があります。1 つはデジタル署名されたもので、session()もう1 つは署名されていないものです。また、どちらもクライアント側の Cookie に保存されるため、機密データをそこに保存するとプライバシーの問題が発生する可能性があります。flash()

また、A7 (暗号化) に関しては、Play は便利なライブラリを提供しますCryptoが、その暗号化は ECB モードを使用することに注意してください。

于 2014-03-18T13:35:13.260 に答える