¿Cuáles son los mejores recursos para la seguridad del sitio?

Este es un espacio bastante grande, pero recomendaría comenzar con el Proyecto de seguridad de aplicaciones web abiertas (OWASP). que se puede encontrar en línea en http://www.owasp.org/. La guía de desarrollo que han publicado es un excelente lugar para comenzar desde el punto de vista del desarrollo y, en gran medida, no se centra en ninguna tecnología específica, sino en la idea general de las aplicaciones web. Desafortunadamente, no creo que el proyecto OWASP ESAPI (Enterprise Security API) para PHP haya llegado muy lejos, pero puedo estar equivocado ya que no soy un programador de PHP. Además, buscaría en la lista de los 10 mejores de OWASP. CUALQUIERA de estas cosas es Googleable (Bingable?).

Sé que puede parecer que me estoy apoyando en el proyecto OWASP, y soy miembro, pero creo que si estás buscando un punto de partida consolidado, es el lugar para ir. En cuanto a la seguridad AJAX, en realidad es solo una extensión de la seguridad general de las aplicaciones web, pero a menudo se ignora porque es “invisible” para la mayoría de las personas. Además, muchas herramientas de prueba no son capaces de analizarlo en profundidad. Andrew van der Stock hizo una gran presentación hace unos años al respecto (http://www.greebo.net/owasp/ajax…), que es un buen comienzo.

Ahora que te he asustado, aquí hay algunos “mandamientos” con los que vivo:

  1. Lo que no está explícitamente permitido se niega. Siempre.
  2. No, bajo ninguna circunstancia, escriba su propio código de seguridad. Siempre. Incluso el mejor código auditado tiene errores, y todo lo que escriba estará plagado de errores que otras personas ya han resuelto. Esto no es un golpe contra ningún programador, sino la dificultad general de todos los casos extremos.
  3. Esto va doble para el código criptográfico. Si incluso lo piensas, aléjate de la computadora. Incluso Bruce Schneier se ha equivocado.
  4. No confíes en nada que recibas del usuario. Siempre. Nada. No me importa cuánto creas que puedes. Las firmas digitales y la autenticación HMAC de cookies son críticas. Valide la entrada en todas partes.
  5. Saca y pica tus contraseñas, por amor a todo lo que es bueno en este mundo. No es perfecto, pero es fácil.
  6. El diablo está en los detalles. La configuración de Apache, PHP, etc. es crítica, y necesitará profundizar para encontrar algunas buenas guías. Desearía poder ayudarte más con PHP, pero puedo recomendar el libro Apache Security de O’Reilly y hacerme amigo de mod_security.
  7. En el momento en que te encuentras pensando “¿pero por qué alguien haría eso?” retroceda y suponga que alguien hará cualquier cosa que se pueda hacer. Intentarán acceder a todo a través de todo tipo de métodos.
  8. Monitoree lo que sucede con su sitio para saber si algo sucede antes, en lugar de más tarde.
  9. Mantenga su software actualizado. Esto se aplica a SO, aplicaciones y bibliotecas. Siga las listas de correo y las alertas de seguridad religiosamente.
  10. Elimine la funcionalidad que no es realmente necesaria. Escuchará el término “superficie de ataque” continuamente en la comunidad de seguridad, y básicamente se refiere a la cantidad de su sistema que está “expuesto” al exterior. Cuanta menos funcionalidad expongas al exterior, mejor. Esto se aplica a su aplicación, pero también elimina los componentes y paquetes innecesarios del sistema operativo. No necesita X Windows en un servidor web.
  11. Elija contraseñas reales para sus cuentas administrativas. Use claves SSH, no autenticación de contraseña.
  12. Incluso si se está ejecutando detrás de un cortafuegos, debería ejecutarlo en cada máquina con solo las piezas básicas activadas.

Eso es un comienzo. La seguridad es muy difícil, e incluso las mejores personas se equivocan debido a la cantidad de variables, y honestamente, debido a la naturaleza generalmente descuidada de la mayoría del software. Pedir ayuda es lo mejor que puede hacer, y ese es el primer paso, así que gracias.

Qué poco entiende la mayoría de la gente sobre la seguridad web.
Con algunas excepciones notables, la configuración del cortafuegos ahora se entiende bastante bien, solo abra el puerto 80. Pero lamentablemente eso no proporciona mucha seguridad para muchos de los vectores de ataque web más comunes. Específicamente, eso no brinda protección para los errores de falsificación de solicitudes en sitios cruzados (CSRF) ni para los problemas de XSS explorados aquí. ) y otros marcos. De hecho, esta lista de ataques http://www.owasp.org/index.php/C … no contiene ninguno que esté inhibido por la configuración del firewall.
De hecho, muchos marcos web proporcionan una superficie expuesta bastante grande desde el punto de vista de la seguridad. Sin embargo, existe una clase emergente de marcos que es bastante a prueba de balas, conocidos como sitios estáticos. Eso no significa que los sitios no tengan niveles controlados de interacción o animación, sino que el sitio y el marco no tienen código de ejecución en el servidor, en un sentido muy real está completamente precompilado. Muchos sitios de pequeñas empresas son muy susceptibles a este enfoque.
Una implementación líder es Blogofile. Curiosamente, esto se implementó recientemente en Google App-engine, (Detalles aquí) También puede ejecutarse en una instancia de micro sitio gratuito en Amazon ec2 y / o EC3 por muy poco, por lo que para el tráfico de tamaño medio el alojamiento es gratuito o casi.
Me gustaría recibir más información sobre cómo elegir plataformas para la seguridad, IIS vs Apache, varias bases de datos, configuraciones y comparaciones de marcos.