Hackear su propia aplicación

Question

Soy un desarrollador web que es muy consciente de la seguridad y trato de hacer que mis aplicaciones web sean lo más seguras posible.

¿Alguna vez he empezado a escribir mis propias aplicaciones de Windows en C# y cuando se trata de probar la seguridad de mi aplicación C#, realmente no soy más que un novato.

Solo me pregunto si alguien tiene buenos tutoriales/léame sobre cómo hackear su propia aplicación de Windows y escribir código de seguridad.

Answer 1

Los libros de Michael Howard son un buen punto de partida;

• 19 Deadly Sins of software security (con ejemplos en varios idiomas)
• Writing Secure Code

hay un montón de enlaces y artículos interesantes desde el blog de Michael Howard here

Hay una presentación de PowerPoint interesante de Microsoft acerca de la amenaza evaluación, riesgos y ASP here.

Answer 2

Además de todas las respuestas obvias para evitar desbordamientos de búfer, inyección de código, secuestro de sesión et. Alabama. Debería buscar a alguien más para que verifique su código/software porque solo puede pensar en formas de piratear su software que sabe cómo prevenir. Solo porque no puede encontrar una forma de piratear su propio software que no significa que nadie más pueda hacerlo.

Answer 3

Para asegurar su aplicación de formulario de victoria, ábrala e intente hacer todo lo que el usuario de lambda no debe hacer. Explicaré:

Si responde "ingrese yes o ", intente con A-Z, 0-9 porque eso es lo que hacen algunos usuarios para intentar encontrar algún rastro de pila que pueda ser interesante. Así que ponga validadores en todas partes.

Tenga cuidado con la conexión a bases de datos, pero si proviene de un desarrollador web, debe ser más consciente que yo :).

Lo más difícil es tener cuidado con las pérdidas de memoria o cosas por el estilo, pero eso es en aplicaciones grandes o en aplicaciones no bien desarrolladas.

Answer 4

Esto es algo que es muy difícil para usted, y creo que está abordando el problema desde el ángulo equivocado. Si está escribiendo una aplicación de cualquier tamaño, entonces tratar de lidiar con la seguridad al final, buscando formas específicas de romper su propio software, es casi imposible.

Esto es por una serie de razones. Ya piensas en tu software de cierta manera. Piensa en formas específicas de interactuar con él, y sabe cómo obtener lo mejor de él. No piensas en términos de formas de explotarlo, y esto es algo difícil de hacer con un software con el que estás íntimamente familiarizado.

Otro problema es que la tarea en este punto es demasiado grande para tratar. Cualquier problema que encuentre puede abrir cualquier cantidad de otros problemas. Una verificación de seguridad de todo el sistema no es lo suficientemente granular.

Lo que debe hacer es pensar en seguridad mientras escribe el software. Conozca las mejores prácticas y considere cada método y clase que escribe desde una perspectiva de seguridad.Esto va de la mano con las pruebas unitarias, trate de considerar qué entradas podrían hacer que esta parte específica de mi programa se rompa. y luego tratar con ellos en ese nivel.

Después de eso, creo que es cuestión de responder rápidamente a cualquier inquietud de seguridad de la que tenga conocimiento.

Answer 5

Podría hacerlo mucho peor que leer el libro Security Engineering de Ross Anderson. La primera edición se puede descargar como PDF y es una buena lectura. No he leído la segunda edición, pero sospecho que es mejor y tiene más beneficios.

Tenga en cuenta que es un libro que explica cómo crear seguridad desde el principio, no cómo romper la seguridad, pero la exposición de fallas de seguridad variadas debería darle una buena idea de por dónde empezar a buscar.

Answer 6

Pequeñas cosas que he encontrado a través de mi propia experiencia.

• No utilice SQL dinámico, entonces es vulnerable a la inyección SQL. Más bien use consultas SQL con parámetros.
• No tengo identificadores de incremento como user_id = 1, 2, 3, etc. y luego los uso en una URL, something.aspx? User_id = 1, entonces puedo adivinar la próxima identificación y esperanza de la sesión. Lo mismo para las cuentas y lo que sea más sensible.
• Tenga cuidado con XSS, (scripts de sitios cruzados). Si acepta la entrada del usuario y la almacena directamente, asegúrese de que no puedan ir a Insertar alerta() por su nombre o algo así.

Esto de ninguna manera es una lista completa. Solo las cosas con las que me he encontrado recientemente.