playframework owasp top 10

问题:

I'm thinking about using Play for a large-scale project, so, has anyone battle-tested Play framework for OWASP Top 10? Are there any security problems you know of in Play framework?

回答1:

On the OWASP Top 10 and Play (some info here):

• A1: Injection

  Uses JPA and escapes strings by default

• A2: Cross-Site Scripting (XSS)

  Since version 1.0.1, Play’s template engine automatically escapes string

• A3: Broken Authentication and Session Management

  Play is stateless, no session involved. Cookies are protected with cryptography. Storing data safely on the database (passwords) via hashing depends on the user, not the framework

• A4: Insecure Direct Object References

  Again this depends on developer verifying access to allowed resources, not so much the framework

• A5: Cross-Site Request Forgery (CSRF)

  POST requests allow for authenticity tokens to prevent this. Of course this depends on developer using GET/POST properly

• A6: Security Misconfiguration

  The default error reporting process seems safe on production (no stack trace leaks). The only concern would be the "catch all" entry in routes, but this should be commented out in production mode

• A7: Insecure Cryptographic Storage

  Developer is responsible to encrypt sensible information in the database

• A8: Failure to Restrict URL Access

  Developer must implement a security restriction (via @Before, like in the tutorial) to disallow access to forbidden pages.

• A9: Insufficient Transport Layer Protection

  Play supports SSL

• A10: Unvalidated Redirects and Forwards

  Play redirect is via 302, not hardcoded strings, which should prevent this.

TL;DR: In the parts that the framework can do all the work, Play does it. In the parts that developer needs to do all the work, well, developer needs to do all the work. Parts that need 50% of each, Play gives its 50%.

Let's put it this way: there is no reason why you should consider Play less safe than any other Java framework. In many cases you can consider it more safe. And with Play being an easy to developer, stateless and REST framework you get less chances to mess it.

回答2:

About A3, you need to be careful. Play has two types of session variables. One is session() which is digitally signed, and the other is flash() which is not signed. Also both of them are stored in cookies client side, which may raise privacy concerns if you decide to store sensitive data there.

Also as it comes to A7 (cryptography), note that Play offers a convenient Crypto library but its encryption uses ECB mode, which again opens a whole new group of potential issues.