La piratería de su propia aplicación

Question

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

Cómo siempre he empezado a escribir mis propias aplicaciones de Windows en C # y cuando se trata comprobar la seguridad de mi aplicación C #, estoy realmente sólo un principiante.

Sólo me preguntaba si alguien tiene alguna buena tutoriales / de leame en cómo cortar su propio uso de las ventanas y la escritura de código seguro.

Answer 1

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

• 19 pecados capitales de la seguridad del software (con ejemplos en varios idiomas)
• Writing Secure Code

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

Hay una interesante presentación de PowerPoint de Microsoft acerca de la evaluación de amenazas, riesgos y ASP aquí .

Answer 2

Además de todas las respuestas obvias para evitar desbordamientos de búfer, inyección de código, sesión highjacking et. Alabama. usted debe encontrar a alguien más para comprobar su código / software, ya que sólo se puede pensar en formas de piratear el software que sepa cómo prevenir. Sólo porque no se puede encontrar una manera de cortar su propio software que no quiere decir que nadie más puede.

Answer 3

Esto es algo que es muy difícil para que usted pueda hacer, y creo que se está acercando el problema desde el ángulo equivocado. Si usted está escribiendo una aplicación de cualquier tamaño a continuación, tratar de hacer frente a la seguridad, al final, mediante la búsqueda de formas específicas de romper su propio software, es casi imposible.

Esto es por varias razones. Que ya piensa en su software de una manera determinada. Se piensa en formas específicas de interactuar con él, y usted sabe cómo conseguir el mejor de él. Usted no piensa en ello en términos de formas de explotar, y esto es una cosa difícil de hacer con el software que está íntimamente familiarizado.

Otro problema es que la tarea en este punto es demasiado grande como para hacer frente a. Cualquier problema que usted encuentra puede abrir cualquier número de otros problemas. Una revisión de todo el sistema de seguridad es en absoluto suficiente granular.

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

Después de eso, creo que es una cuestión de responder rápidamente a cualquier preocupación de seguridad que se le informa de.

Answer 4

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

• No utilizar SQL dinámico, que luego son vulnerables a la inyección de SQL. Más bien utilizar consultas SQL con parámetros.
• No tienen ID de incremento como user_id = 1, 2, 3, etc, etc y luego utilizar eso en una URL, something.aspx? User_id = 1, i entonces puedo adivinar la próxima sesión de Identificación y esperanza. Lo mismo para las cuentas y lo que cada vez más es sensible.
• Cuidado con XSS, (cross site scripting). Si acepta la entrada del usuario y lo almacena directamente, asegúrese de que no pueden ir de alerta de inserción () por su nombre o algo.

Esto es de ninguna manera una lista completa. Sólo las cosas que se han topado recientemente.

Answer 5

Se podría hacer mucho peor que la lectura de Ross Anderson Ingeniería de Seguridad libro. La primera edición se puede descargar en formato PDF y es una buena lectura. No he leído la segunda edición, pero sospecho que es mejor y tiene más golosinas en ella.

Ten en cuenta que es un libro que explica cómo construir la seguridad en desde el principio, no la forma de romper la seguridad, pero la exposición de las fallas de seguridad surtidos debe darle una buena idea de dónde empezar a buscar.

Answer 6

Para garantizar la aplicación de forma triunfo abrirlo y tratar de hacer todo lo que el usuario lambda no debe hacer! Voy a explicar:

Si "dice entrar yes o no", intente con A-Z, 0-9, porque eso es lo que algunos usuarios lo hacen para tratar de encontrar algún rastro de pila que podría ser interesante. Así que ponga validadores en todas partes.

Cuidado con conexión a bases de datos, pero si viene de web dev debe ser más consciente que yo:.)

La parte más difícil es tener cuidado acerca de las pérdidas de memoria o cosas por el estilo, pero eso es en las grandes aplicaciones grandes o en aplicaciones no están bien desarrollados.