我正在考虑在一个大型项目中使用Play,那么,有没有人在OWASP Top 10中对Play框架进行过测试?你知道Play框架中是否存在任何安全问题吗?
A1: 注入攻击
使用JPA默认转义字符串
A2: 跨站脚本攻击(XSS)
从版本1.0.1开始,Play的模板引擎会自动转义字符串
A3: 破损的身份验证和会话管理
Play是无状态的,没有会话涉及。Cookie使用加密保护。安全地将数据存储在数据库中(例如密码)取决于用户而不是框架
A4: 不安全的直接对象引用
同样,这取决于开发人员验证对允许资源的访问,而不是框架
A5: 跨站请求伪造(CSRF)
POST请求允许使用真实性令牌来防止此类攻击。当然这取决于开发者正确地使用GET/POST方法
A6: 安全性配置错误
默认的错误报告流程在生产环境下似乎很安全(没有堆栈跟踪泄露)。唯一需要注意的是路由中的“catch all”条目,但在生产模式下应将其注释掉
A7: 不安全的加密存储
开发人员需要负责对数据库中的敏感信息进行加密
A8: 未限制URL访问权限
开发人员必须实现安全限制(通过@Before方法,例如教程中的方法)来禁止访问被禁止的页面。
A9: 不足的传输层保护
Play支持SSL
A10: 未验证的重定向和转发
Play使用302进行重定向而不是硬编码字符串,这应该可以防止此类攻击
TL;DR: 当框架可以完成全部工作时,Play 会完成。当开发者需要自己完成全部工作时,则需要开发者自己来完成。而对于需要50% 框架和50% 开发者的任务,Play 将完成其中的50%。
换句话说:你没有理由认为 Play 比其他 Java 框架不安全。在许多情况下,你甚至可以认为 Play 更加安全。由于 Play 是一款易于开发、无状态且符合 REST 规范的框架,因此出错的可能性更小。
session()
,它是数字签名的,另一种是 flash()
,它没有签名。此外,两者都存储在客户端的cookies中,如果你决定在那里存储敏感数据,可能会引起隐私问题。Crypto
库,但它的加密使用ECB模式,这又开启了一整组潜在问题。
PreparedStatement
来防止SQL注入? - Jonas