Otra propaganda de Kevin Wall en ¿Debo usar ESAPI?
Si está comenzando un nuevo proyecto o está tratando de asegurar un proyecto existente por primera vez, entonces antes considera ESAPI, debería considerar estas posibles alternativas:
- Codificación de salida: OWASP Java Encoder Project
- Desinfección de HTML general: OWASP Java HTML Sanitizer
- Validación: JSR-303 / JSR-349 Validación de Bean
- Criptografía fuerte: Keyczar
- Autenticación / autorización: Apache Shiro
- Protección CSRF: Proyecto OWASP CSRFGuard o Proyecto OWASP CSRFProtector
Tenga en cuenta que esto no es para sugerir que ESAPI está muerto, sino más bien para reconocer el hecho de que no está siendo tan bien mantenido como la mayoría de las empresas F500 desearían para su software empresarial.
OMI, si tiene la opción, debe utilizar marcos como Spring, que cuenta con instalaciones para hacer frente a muchos problemas de seguridad (por ejemplo, Spring Security para autenticación, CSRF). Para la salida, una vez más muchos frameworks / bibliotecas modernos se encargan de la codificación. P.ej. con JSP, luego use JSTL - tiene una biblioteca de etiquetas para la codificación HTML. Si está desarrollando clientes ricos, marcos como React codificarán HTML de forma predeterminada.
Un escenario en el que ESAPI sigue siendo útil es si está actualizando una aplicación heredada que carece de seguridad. Incluso entonces, ESAPI tiene suficientes problemas abiertos / vulnerabilidades que deberían hacer que se detenga. Es una triste situación y Kevin Wall parece ser un poco amargo:
La primera pregunta que se debe hacer es si ya está usando ESAPI en su proyecto y, de ser así, ¿tiene mucho en él? Si es así, entonces la respuesta a "¿Debo usar ESAPI?" probablemente es "sí". La segunda pregunta que debe hacer, si la estoy usando, ¿por qué no estoy contribuyendo de alguna manera? Pero no iremos allí.