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

OWASP ha denominado 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 ha gustado cómo suena: "Muéstrame las 10 principales vulnerabilidades". Una respuesta bastante similar está aquí: enlace , en el medio de la filosofía. El primer párrafo expresa plenamente mi opinión. Déjame citar:

  

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

La inyección SQL es grande 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, por sus siglas en inglés) es otra que no me falta. También es una buena idea verificar los ataques de canonicalización de archivos, especialmente si es compatible con cargas de usuarios o descargas de cualquier tipo.

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

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

• entrada de saneamiento! Encuentre una buena biblioteca para limpiar sus datos antes de que sean utilizados por el sistema subyacente. ¡Las inyecciones de comandos de XML, SQL, Html son muy 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 interesaría por las habilidades de "fuerza bruta". Por supuesto, los usuarios necesitan contraseñas seguras, y también la estructura del directorio y los archivos siempre pueden ser forzados por la ley bruta. Recuerde que la seguridad por oscuridad no funciona sola :)

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 , Krebs Java Security Report y el Informe de seguridad de WHID para obtener información sobre qué ataques están ocurriendo realmente en Internet.

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 comprobación que debe hacer es asegurarse de que la entrada del usuario no se alimenta directamente en la cadena para una consulta dinámica; la entrada del usuario es cualquier cosa que viene 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, siempre tenga en cuenta: "no confíe en la información proveniente del cliente".

Entonces, al no confiar en la entrada del usuario, ahora tiene que 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 a una cierta longitud; eliminar el resto y luego introducirlo en la consulta. Es una buena idea evitar por completo las consultas dinámicas y utilizar consultas parametrizadas y procedimientos almacenados en la base de datos.

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

Tienes que prestar especial atención a la parte de autenticación; La entrada de nombre de usuario y contraseña parece una funcionalidad fácil; 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 haya iniciado sesión, esta sesión no esté expuesta a través de HTTP; es decir, tienes que revisar 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úrate de que la sesión tenga los indicadores Secure y HTTPOnly establecidos; y asegúrese de que caduque después de un tiempo de inactividad o cierre de sesión manual. El restablecimiento y cambio de contraseña también son funcionalidades muy sensibles; que necesita un largo post para discutir.

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