it-swarm-es.com

¿Cuáles son los controles de seguridad más importantes para las nuevas aplicaciones web?

Me pregunto cuáles son los controles de seguridad de máxima prioridad que debe realizar antes de lanzar una nueva aplicación web.

Supongo que existen vulnerabilidades de fuerza bruta y secuencias de comandos entre sitios. ¿Cuáles son las otras cosas que absolutamente tiene verificar incluso si no tiene tiempo para ello?

16
Andreas Arnold

OWASP tiene el llamado Top Ten Project , que muestra cuáles son las vulnerabilidades más populares. Pero nunca debe limitarse solo a los cheques que se enumeran allí. Nunca me gustó cómo suena: "muéstrame las 10 principales vulnerabilidades". Una respuesta bastante similar está aquí: http://questions.securitytube.net/questions/1764/top-3-c-security-concerns , en el sentido de la filosofía. El primer párrafo expresa plenamente mi opinión. Permítanme citar:

Si su intención es escribir código seguro, le recomendaría evitar preguntas como "las 10 principales vulnerabilidades". No tiene sentido enfocarse solo en algún tipo de error deseado, porque hay posibilidades bastante similares de introducir errores de encasillamiento, desbordamiento de enteros, desbordamiento de uno por uno, desbordamiento de pila y otros si su conocimiento en C/C++ es débil y usted tener poca experiencia en programación.

14
anonymous

La inyección de SQL es importante si tiene algún tipo de interacción con la base de datos, y es relativamente fácil de probar. La falsificación de solicitudes entre sitios (CSRF) es otra que no me falta. También es una buena idea comprobar si hay ataques de canonicalización de archivos, especialmente si admite cargas o descargas de usuarios de cualquier tipo.

El resto realmente depende de su aplicación, el tipo de datos que contiene y quiénes son los usuarios.

5
Wally Lawless

Si fuera realmente crítico a tiempo, me aseguraría de que se verifique lo siguiente en mi solicitud:

  • ¡Saneamiento de entrada! Encuentre una buena biblioteca para limpiar sus datos antes de que sean utilizados por el sistema subyacente. ¡Las inyecciones de XML, SQL, Html y comandos son tan peligrosas!
  • CSRF
  • Las posibilidades de carga deben centrarse en no permitir el cruce de rutas y cargar scripts maliciosos que son analizados por el servidor

Me preocuparía por las habilidades de "fuerza bruta". Por supuesto, los usuarios necesitan contraseñas seguras, y también la estructura de directorios y los archivos siempre pueden ser forzados. Recuerda que la seguridad por oscuridad no funciona sola :)

3
Chris Dale

Creo que Ams tiene razón, sin embargo, en términos de su mayor exposición, vale la pena mirar las estadísticas. Consulte el Informe de violación de datos de Verizon , el Krebs Java Informe de seguridad y el Informe de seguridad WHID para algunos grandes fuentes de información sobre los ataques que realmente están ocurriendo en Internet.

3
Rory Alsop

Las amenazas más importantes son las que intentan acceder al backend, como la base de datos. La inyección de SQL está en la parte superior de la lista; la verificación que debe hacer es asegurarse de que la entrada del usuario no se ingrese directamente en la cadena para una consulta dinámica; la entrada del usuario es cualquier cosa que provenga del cliente; incluso si el usuario no puede editarlo en el formulario o en el navegador, imagine que puede interceptar el tráfico que sale de su navegador e inyectar cualquier cosa en cualquier campo. Por lo tanto, tenga siempre en cuenta: "no confíe en las aportaciones del cliente".

Entonces, al no confiar en la entrada del usuario, ahora debe validar cada entrada; para la inyección de SQL, debe eliminar cualquier carácter que no sea aceptado; por ejemplo, si se supone que el usuario busca un número, no acepte nada excepto una combinación de 0-9 con una longitud determinada; elimine el resto y luego introdúzcalo en la consulta. Es una buena idea evitar las consultas dinámicas por completo y utilizar consultas parametrizadas y procedimientos almacenados en la base de datos.

El siguiente ataque principal son las inyecciones que pueden apuntar a otros usuarios; como XSS. La historia con XSS es similar a la inyección SQL, no debe confiar en la entrada del usuario y hacer una validación de lista blanca al recibir cualquier entrada. En general, el lado del cliente verifica para asegurarse de que el formato en el que el usuario ingresó los datos no sea suficiente, y todo debe volver a verificarse en el lado del servidor.

Debe prestar especial atención a la parte de autenticación; la entrada de nombre de usuario y contraseña parece una funcionalidad sencilla; No lo es. Debe asegurarse de que, al iniciar sesión correctamente, se genere un nuevo valor de sesión y se establezca en la cookie del cliente. También debe asegurarse de que durante el resto del tiempo que el usuario esté conectado, esta sesión no esté expuesta a través de HTTP; es decir, tienes que pasar por SSL. La sesión debe ser aleatoria, lo suficientemente larga y no adivinable. La mayoría de los lenguajes de programación pueden encargarse de eso; no reinventes la rueda. Asegúrese de que la sesión tenga configurados los indicadores Secure y HTTPOnly; y asegúrese de que caduque después de un tiempo de inactividad o cierre de sesión manual. El restablecimiento y el cambio de contraseña también son funcionalidades muy sensibles; que necesita una publicación larga para discutir.

Una parte muy importante es la autorización. Una vez que un usuario está autenticado, no significa que haya terminado; cada usuario solo debe acceder a determinadas páginas o datos; por lo tanto, cada solicitud debe verificarse en el lado del servidor para evitar la escalada de privilegios.

1
Goli E