java - org - owasp top 10 2016
playframework owasp top 10 (2)
Estoy pensando en usar Play para un proyecto a gran escala, por lo tanto, ¿alguien tiene un framework Play probado para OWASP Top 10? ¿Hay algún problema de seguridad que conozca en Play framework?
Acerca de A3, hay que tener cuidado. El juego tiene dos tipos de variables de sesión. Una es session() que está firmada digitalmente, y la otra es flash() que no está firmada. Además, ambos se almacenan en las cookies del lado del cliente , lo que puede generar problemas de privacidad si decide almacenar datos confidenciales allí.
También en lo que se refiere a A7 (criptografía), tenga en cuenta que Play ofrece una biblioteca Crypto conveniente, pero su encriptación utiliza el modo ECB, que nuevamente abre un nuevo grupo de posibles problemas .
En el OWASP Top 10 y Play ( here hay información):
A1: inyección
Utiliza JPA y escapa de las cadenas por defecto
A2: Secuencias de comandos entre sitios (XSS)
Desde la versión 1.0.1, el motor de plantillas de Play escapa automáticamente la cadena
A3: Autenticación rota y gestión de sesión
El juego es apátrida, no hay sesión involucrada. Las cookies están protegidas con criptografía. El almacenamiento de datos de forma segura en la base de datos (contraseñas) a través de hashing depende del usuario, no del marco
A4: Referencias de objetos directos inseguros
De nuevo, esto depende de que el desarrollador verifique el acceso a los recursos permitidos, no tanto el marco
A5: falsificación de solicitudes entre sitios (CSRF)
Las solicitudes POST permiten tokens de autenticidad para evitar esto. Por supuesto, esto depende de que el desarrollador use GET / POST correctamente
A6: Mala configuración de seguridad
El proceso de informe de errores predeterminado parece seguro en la producción (sin pérdidas de seguimiento de la pila). La única preocupación sería la entrada "atrapar todo" en las rutas, pero esto debería comentarse en el modo de producción
A7: Almacenamiento criptográfico inseguro
El desarrollador es responsable de cifrar la información sensible en la base de datos
A8: Error al restringir el acceso a la URL
El desarrollador debe implementar una restricción de seguridad (a través de @Antes, como en el tutorial) para no permitir el acceso a páginas prohibidas.
A9: Protección insuficiente de la capa de transporte
Play soporta SSL
A10: Redirecciones y reenvíos no validados
La redirección de reproducción se realiza a través de 302, no en cadenas codificadas, lo que debería evitarlo.
TL; DR: En las partes en que el framework puede hacer todo el trabajo, Play lo hace. En las partes que el desarrollador necesita para hacer todo el trabajo, bueno, el desarrollador debe hacer todo el trabajo. Piezas que necesitan el 50% de cada una, Play da su 50%.
Pongámoslo de esta manera: no hay ninguna razón por la que debas considerar jugar menos seguro que cualquier otro marco Java. En muchos casos puedes considerarlo más seguro. Y, dado que Play es un marco fácil de desarrollar, sin estado y de REST, tiene menos posibilidades de desordenarlo.