¿Qué le gustaría ver en el libro de seguridad ASP.NET de un principiante?

Question

Este es un ejercicio de recopilación de información desvergonzada para mi propio libro.

Una de las charlas que doy en la comunidad es una introducción a las vulnerabilidades del sitio web. Por lo general, durante la charla puedo ver que al menos dos miembros de la audiencia se ponen muy pálidos; y esto es algo básico, Cross Site Scripting, SQL Injection, Information Leakage, Cross Site Form Requests, etc.

Entonces, si puede pensar en ser uno, como desarrollador web principiante (ya sea ASP.NET o no), ¿cuál cree que sería información útil sobre la seguridad web y cómo desarrollarse de forma segura? Yo ya estar cubriendo la OWASP Top Ten

(Y sí, esto significa stackoverflow estará en la lista de los acuses de recibo, si alguien se le ocurre algo que no he pensado todavía!)

todo se hace ahora, y publicado , gracias a todos por sus respuestas

Answer 1

En primer lugar, quisiera señalar las inseguridades de la web de una manera que las hace accesibles a las personas para quienes el desarrollo con la seguridad en mente puede (desafortunadamente) ser un concepto nuevo. Por ejemplo, muéstreles cómo interceptar un encabezado HTTP e implementar un ataque XSS. La razón por la que quieres mostrarles los ataques es para que ellos mismos tengan una mejor idea de lo que están defendiendo. Hablar de seguridad más allá de eso es grandioso, pero sin entender el tipo de ataque que deben frustrar, será difícil para ellos "evaluar" con precisión sus sistemas en busca de seguridad. Una vez que puedan probar la seguridad intentando interceptar mensajes, colocar encabezados falsos, etc., al menos sabrán si la seguridad que intentan implementar está funcionando o no. Puede enseñarles los métodos que desee para implementar esa seguridad con confianza, sabiendo si se equivocan, en realidad lo sabrán porque les fallarán las pruebas de seguridad que les mostró para probar.

Answer 2

Programación defensiva como un tema arquetípico que cubre todos los ataques en particular, ya que la mayoría, si no todos, son causados ​​por no pensar lo suficiente defensivamente.

Haga que el tema sea la columna central del libro. Lo que me hubiera servido mucho en aquel entonces fue conocer técnicas para no confiar nunca en nada, no solo consejos para dejar de fumar, como "no permitir comentarios de SQL o caracteres especiales en tu entrada".

Otra cosa interesante que me gustaría haber aprendido antes es cómo realmente probar para ellos.

Answer 3

Foxes

Answer 4

creo que todas las vulnerabilidades se basan fuera de los programadores no pensar, ya sea lapsos momentáneos de juicio, o algo que no han pensado. Una gran vulnerabilidad que estaba en una aplicación que me pidieron que "arreglara" fue el hecho de que habían devuelto 0 (cero) desde el método de autenticación cuando el usuario que iniciaba sesión era un administrador. Debido al hecho de que la variable se inicializó originalmente como 0, si ocurrió algún problema, como que la base de datos esté inactiva, lo que provocó que emitiera una excepción. La variable nunca se establecería en el "código de seguridad" adecuado y el usuario tendría acceso de administrador al sitio. Un pensamiento absolutamente horrible entró en ese proceso. Entonces, eso me lleva a un importante concepto de seguridad; Nunca establezca el valor inicial de una variable que represente un "nivel de seguridad" o algo de ese tipo, en algo que represente el control total de Dios del sitio. Mejor aún, use las bibliotecas existentes que se hayan consumido en grandes cantidades de entornos de producción durante un largo período de tiempo.

Answer 5

Me gustaría ver cómo ASP.La seguridad de NET es diferente de la seguridad de ASP Classic.

Answer 6

Me alegra saber que tendrá el OWASP Top Ten. Por qué no incluir también la cobertura de los errores de programación Top 25 de SANS/CWE.

Answer 7

Siempre trato de mostrar el peor de los casos en cosas que pueden salir mal. Por ejemplo, cómo una inyección de script entre sitios puede funcionar como un ataque de caja negra que incluso funciona en páginas de la aplicación a las que un hacker no puede acceder o cómo incluso una inyección SQL puede funcionar como una caja negra y how a hacker can steal your sensitive business data, incluso cuando su sitio web se conecta a su base de datos con una cuenta normal de acceso no privilegiado.

Answer 8

Cómo asegurarse de que su método de seguridad sea escalable con SQL Server. Especialmente cómo evitar que SQL Server serialice las solicitudes de varios usuarios porque todos se conectan con la misma ID ...