¿Qué características de seguridad debería tener un marco PHP?

Bueno, construir la seguridad en un marco no es una tarea fácil. Tomemos por ejemplo la protección XSS que mencionaste. La tendencia actual en la seguridad de las aplicaciones web indica que se requieren tres cosas para tratar las fallas de inyección:

• validación de entrada
• validación de salida
• escape de salida sensible al contexto ( no es una tarea fácil)!

Incluso cuando se manejan todos los servidores anteriores, aún podría ser vulnerable al ataque DOM XSS cuando se introdujo un código de JavaScript vulnerable en la aplicación (y, por ejemplo, jQuery también podría introducir DOM XSS )

Personalmente, creo que las características más importantes y, a menudo, descuidadas de los marcos son la configuración predeterminada segura y los ejemplos de código seguro. Los desarrolladores a menudo copian y pegan el código o dejan la configuración predeterminada. Entonces, si está introduciendo tokens como protección CSRF, agréguelos a cada formulario de manera predeterminada y permita que se desactive en código / configuración.

Si está buscando algún tipo de lista de verificación para marcos seguros, una vez hubo un proyecto OWASP (ahora cerrado) - Manifiesto de seguridad de aplicaciones web . Su objetivo era proporcionar dicha prueba y actualmente es la mejor lista de verificación que existe. También navegue por varias hojas de trucos OWASP para ayudarlo a implementar Cada control de seguridad.

Recomiendo agregarle medidas anti-automatización. Un usuario del marco podría elegir qué páginas quiere proteger con esta función (por ejemplo, una página de inicio de sesión o un formulario de comentarios). Si un atacante enviara el formulario varias veces, se enfrentaría con un CAPTCHA para cada solicitud subsiguiente, según su IP (¡no el ID de sesión!).

Además, el manejo de sesiones es una tarea tediosa. El marco debe asegurarse de que:

No se aceptan sesiones generadas por el usuario Esto para evitar el secuestro de la sesión, donde un atacante genera un ID de sesión para que otra persona lo utilice

Los ID de sesión se vuelven a generar después de la autenticación Para que cuando un atacante logre convencer a una víctima de que use un ID de sesión determinado, el atacante no tendrá una sesión autenticada cuando la víctima inicie sesión

Los ID de sesión de las sesiones autenticadas nunca se transmiten a través de HTTP Pero use SSL para todas las cosas autenticadas

Las cookies de sesión tienen las marcas adecuadas HttpOnly, y marca de seguridad para sesiones autenticadas

Además, recomiendo que el marco le permita al desarrollador establecer políticas de almacenamiento en caché. Para las páginas que se sirven a usuarios autenticados, que pueden contener datos confidenciales de privacidad, el almacenamiento en caché debería ser fácil (o incluso predeterminado) para desactivar.

Oh, alegría - otro framework PHP. Disculpe mi sarcasmo, pero ya hay una gran cantidad de marcos flotando en la naturaleza. La mayoría está hinchada, lenta y llena de errores de seguridad. Pero al menos está intentando abordar los problemas de seguridad por adelantado.

Diría que es cuestionable si un marco debe proporcionar su propia capa de abstracción de base de datos. p.ej. A veces, el patrón de registro activo es útil, pero no siempre.

Por mucho, el complemento de seguridad más valioso sería la garantía de compatibilidad con versiones anteriores para alentar a su base de usuarios a actualizar cuando lance nuevas versiones.

Según mi comentario en otra parte, la validación no es un problema de seguridad, las representaciones correctas de los datos lo son. Sería bueno proporcionar un mecanismo simple para cambiar entre representaciones para diferentes destinos y desde / hacia formatos neutros de destino (lo que generalmente significa algunos ajustes a la codificación base64).

para problemas funcionales no es algo malo, por ejemplo. asegurándose de que la fecha de salida de una reserva sea posterior a la fecha de llegada.

El registro es muy importante.

Merece la pena considerar la posibilidad de considerar la zona de pruebas de E / S de archivos.

Como dice Chris: debe proporcionar prevención contra el secuestro / fijación de sesiones.

Podría considerar proporcionar un marco de autenticación (después de todo, si tiene listas de control de acceso (ACL), ya está imponiendo algunas restricciones sobre cómo se implementa la autenticación).

Si desea un marco realmente seguro, piense cómo implementaría las sesiones que no se pueden buscar (las únicas soluciones que he encontrado para esto dependen de los demonios para la separación de privilegios, por lo que son totalmente inadecuadas para la mayoría de las personas que lo harían). desea proteger los datos de la sesión, es decir, aquellos en paquetes de alojamiento compartido baratos).

Hay muchas otras cosas fuera del dominio de seguridad, por ejemplo, Soporte de mensajería asíncrona. Pero tenga en cuenta que cada vez que agregue más funcionalidad, puede estar negando la posibilidad de usar un marco complementario junto al suyo (por ejemplo, smarty, gaviota, la doctrina es muy capaz en áreas específicas)

Motor de reglas de validación de entrada. (y salida para esa materia)