¿Qué debe saber todo programador sobre seguridad? [cerrado]

427

Soy un estudiante de TI y ahora estoy en el tercer año en la universidad. Hasta ahora hemos estado estudiando muchos temas relacionados con las computadoras en general (programación, algoritmos, arquitectura de computadoras, matemáticas, etc.).

Estoy muy seguro de que nadie puede aprender todo acerca de la seguridad, pero estoy seguro de que hay un conocimiento "mínimo" que todo programador o estudiante de TI debe saber y mi pregunta es ¿cuál es este conocimiento mínimo?

¿Puedes sugerir algunos libros electrónicos o cursos o cualquier cosa que pueda ayudar a comenzar con este camino?

security 
— MH
fuente
66
— Thomas
118
Regla # 1: Nunca confíes en la entrada del usuario. Ni siquiera si es tu abuela
— Anthony Forloney
2
..y este hilo también tiene la gran información - stackoverflow.com/questions/72394/…
— Sripathi Krishnan
mi pregunta no es solo acerca de los programadores y sus errores, también acerca de los estudiantes de informática y ciencias de la computación
— Mohamad Alhamoud
1
Mire sus mensajes de error. Si bien desea ser fácil de usar, la diferencia entre "Esta cuenta no existe" y "La contraseña no es válida" puede ser peligrosa en algunos casos.
— Michael Mior

Respuestas:

551

Principios a tener en cuenta si desea que sus aplicaciones sean seguras:

  • ¡Nunca confíes en ninguna entrada!
  • Valide la entrada de todas las fuentes no confiables: use listas blancas, no listas negras
  • Planifique la seguridad desde el principio: no es algo a lo que pueda recurrir al final
  • Hágalo simple: la complejidad aumenta la probabilidad de agujeros de seguridad
  • Mantenga su superficie de ataque al mínimo
  • Asegúrate de fallar de forma segura
  • Usa la defensa en profundidad
  • Adherirse al principio del menor privilegio
  • Usar modelado de amenazas
  • Compartimentar : para que su sistema no sea todo o nada
  • Ocultar secretos es difícil, y los secretos ocultos en el código no permanecerán en secreto por mucho tiempo
  • No escribas tu propia criptografía
  • Usar crypto no significa que estés seguro (los atacantes buscarán un enlace más débil)
  • Tenga en cuenta los desbordamientos del búfer y cómo protegerse contra ellos.

Hay algunos libros y artículos excelentes en línea sobre cómo hacer que sus aplicaciones sean seguras:

Entrene a sus desarrolladores en las mejores prácticas de seguridad de aplicaciones

Codebashing (pagado)

Innovación de seguridad (pago)

Brújula de seguridad (de pago)

OWASP WebGoat (gratis)

— bignum
fuente
+1 "software explotador: cómo romper el código" es un gran libro, sin embargo, esa presentación de diapositivas a la que está vinculado es horrible.
— torre
77
Sin embargo, desafortunadamente es casi imposible instanciar el principio de menor privilegio en cualquier sistema moderno. Por ejemplo, el kernel de Linux (fuente que estoy usando actualmente) contiene más de 9.4 millones de líneas de código C y más de 400K líneas de ensamblaje, todo lo cual se ejecuta en un contexto sin restricciones. Un simple error de cálculo (quizás intencional) en una de estas millones de líneas comprometerá todo el sistema. Tal vez en el próximo siglo o dos surja una solución, tal vez no, ya que a nadie le importa crear sistemas operativos / lenguajes / marcos seguros.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
Agregaría "El manual del hacker de aplicaciones web" a esa lista.
— emitido
34
Reemplace "¡Nunca confíe en la entrada del usuario!" a "¡Nunca confíes en ninguna entrada!". Las entradas que provienen de otro software deben tratarse de la misma manera que las entradas del usuario; por ejemplo, en el registro del sitio web, la mayoría de las personas no pensarían en el campo User-Agent / ID del navegador como "entrada del usuario", pero puede contener fácilmente, por ejemplo, un Inyección SQL.
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Bueno, existe el sistema operativo experimental de Microsoft Research (Singularity) construido en .NET, que apunta a la seguridad como un objetivo principal (sin desbordamientos del búfer, ¡sí!). Sin compartir memoria de proceso, sin auto-modificación de código, incluso los controladores de dispositivo son solo otro proceso aislado de software en .NET. Es un concepto bastante interesante, pero sería muy difícil llevar esto a la gente (lo más importante, prácticamente no puede hacer una compatibilidad hacia atrás con el software existente o incluso los controladores; un poco como los primeros 10 años de Linux: D).
— Luaan
102

Regla n. ° 1 de seguridad para programadores: no lance su propia

A menos que usted sea un experto en seguridad y / o criptógrafo, use siempre una plataforma, marco o biblioteca de seguridad bien diseñada, bien probada y madura para hacer el trabajo por usted. Estas cosas han pasado años siendo pensadas, parcheadas, actualizadas y examinadas por expertos y hackers por igual. Desea obtener esas ventajas, no descartarlas tratando de reinventar la rueda.

Ahora, eso no quiere decir que no necesite aprender nada sobre seguridad. Ciertamente necesita saber lo suficiente para comprender lo que está haciendo y asegurarse de estar usando las herramientas correctamente. Sin embargo, si alguna vez se encuentra a punto de comenzar a escribir su propio algoritmo de criptografía, sistema de autenticación, desinfectante de entrada, etc., deténgase, dé un paso atrás y recuerde la regla # 1.

— Tyler McHenry
fuente
10
Esta es una mala regla en mi opinión. Básicamente, puede ser objetivo solo por la plataforma que seleccione, en lugar de cualquier interés real en sus activos. Piense en todos los agujeros de seguridad que se encuentran en las plataformas de terceros, y en todos los productos que son instantáneamente vulnerables solo porque lo usan. No sería tan rápido confiarle mi seguridad a un tercero.
— Fosco
99
Creo que esta es una buena regla para Crypto: rodar su propio cifrado es una receta para el desastre. Pero poner en marcha su propio motor de blog puede ser más seguro como señala Fosco: si lo hace, es menos probable que se vea atrapado por ataques automáticos con los que tienen que lidiar las instalaciones de WordPress.
— James P McGrath
55
Cuando se trata de criptografía, esta regla es absolutamente correcta. No escriba su propia criptografía, punto. Cuando se trata de usar plataformas de terceros, depende. Algunas plataformas son inherentemente más seguras, algunas plataformas son inherentemente menos seguras, y la mayoría de las plataformas probablemente brindan algunas características de seguridad pero también algunos vectores de ataque conocidos. Tome la vulnerabilidad reciente de Rails que causó un agujero de seguridad en github . Indudablemente, Rails ofrece muchas funciones de seguridad, pero también tiene algunas funciones potentes con valores predeterminados inseguros.
— Michael Kopinsky
77
Cuando se trata de criptografía, no haga lo suyo, pero entienda lo que está usando. Si no entiende por qué usar la misma clave de cifrado para RC4 para dos mensajes es una idea horrible, lea antes de usar cualquier cifrado de flujo, por ejemplo.
— Christopher Creutzig,
3
Incluso después del error HeartBleed, es evidente que esta es una buena regla. Imagine lo difícil que hubiera sido encontrar un error similar a un sangrado en un proyecto personalizado o propietario. Si rueda el suyo, solo se esconde detrás de la oscuridad y no sabrá qué errores podrían estar siendo explotados.
— Sqeaky
71

Todo programador debe saber cómo escribir código de explotación.

Sin saber cómo se explotan los sistemas, está deteniendo accidentalmente vulnerabilidades. Saber cómo parchear el código no tiene ningún sentido a menos que sepa cómo probar sus parches. La seguridad no es solo un montón de experimentos mentales, debes ser científico y probar tus experimentos.

— 89%
fuente
10
Yo diría que esto no es necesario en absoluto. Solo adhiérase al principio: si el atacante puede causar daños en la memoria de cualquier tipo, considérese dueño. No es necesario entrar en los detalles de escribir realmente exploits (de trabajo).
— newgre
66
@newgre no todas las vulnerabilidades son un desbordamiento de búfer. Hay unos pocos miles de vulnerabilidades cubiertas por el sistema de enumeración de debilidad común. Un programador necesita comprender la mente del atacante o, sin saberlo, cometerá errores.
— torre
1
Sé que no cada uno de ellos es un desbordamiento del búfer, pero cualquier cosa que generalmente se conoce como un "exploit" se basa en algún tipo de corrupción de memoria: desbordamientos del búfer, doble liberación, desbordamientos del montón, desbordamientos relacionados con enteros, cadenas de formato , etc. Por supuesto, hay otras cosas como errores lógicos, pero ese no era el tema de esta respuesta para empezar.
— newgre
55
@newgre Ese es un tipo de exploit, pero hoy se escriben más exploits para aprovechar los defectos de las aplicaciones web que los problemas de corrupción de memoria. Los exploits se escriben aprovechando la inyección SQL, la inclusión de archivos locales, CSRF y XSS, estos son los problemas comunes. (Fuente: exploit-db.com )
— torre el
1
Estoy de acuerdo, si usted mismo puede escribir exploits, ¡puede comprender lo que puede llegar a la mente de los hackers al máximo!
— linuxeasy
42

La seguridad es un proceso, no un producto.

Muchos parecen olvidarse de este hecho obvio.

— ericteubert
fuente
23

Sugiero revisar CWE / SANS TOP 25 errores de programación más peligrosos . Fue actualizado para 2010 con la promesa de actualizaciones periódicas en el futuro. La revisión de 2009 también está disponible.

De http://cwe.mitre.org/top25/index.html

Los 25 errores de programación más peligrosos de CWE / SANS 2010 son una lista de los errores de programación más extendidos y críticos que pueden conducir a serias vulnerabilidades de software. A menudo son fáciles de encontrar y fáciles de explotar. Son peligrosos porque con frecuencia permitirán a los atacantes hacerse cargo del software por completo, robar datos o evitar que el software funcione en absoluto.

La lista de los 25 principales es una herramienta de educación y conciencia para ayudar a los programadores a prevenir los tipos de vulnerabilidades que afectan a la industria del software, al identificar y evitar errores demasiado comunes que ocurren incluso antes de que se envíe el software. Los clientes de software pueden usar la misma lista para ayudarlos a solicitar un software más seguro. Los investigadores en seguridad de software pueden utilizar los 25 principales para centrarse en un subconjunto estrecho pero importante de todas las debilidades de seguridad conocidas. Finalmente, los gerentes de software y los CIO pueden usar la lista de los 25 principales como un indicador de progreso en sus esfuerzos para asegurar su software.

— jschmier
fuente
1
Tenga en cuenta que los 4 errores principales en esa lista (y un montón de los otros también) son todos el mismo error: confiar en la entrada.
— Chris Dodd
13

Un buen curso de iniciación podría ser el curso MIT en Redes y seguridad informática . Una cosa que sugeriría es no olvidarse de la privacidad. La privacidad, en algunos sentidos, es realmente fundamental para la seguridad y a menudo no se cubre en cursos técnicos sobre seguridad. Puede encontrar material sobre privacidad en este curso sobre Ética y Derecho en relación con Internet.

— revs tvanfosson
fuente
El enlace del curso MIT no funciona
— AntonioCS
1
Enlaces corregidos (por ahora). Gracias.
— tvanfosson
10

El equipo de Web Security en Mozilla compiló una gran guía , que cumplimos en el desarrollo de nuestros sitios y servicios.

— Potch
fuente
8

La importancia de los valores predeterminados seguros en marcos y API:

  • Muchos de los primeros marcos web no escaparon al html de forma predeterminada en las plantillas y tuvieron problemas de XSS debido a esto
  • Muchos de los primeros marcos web hicieron que sea más fácil concatenar SQL que crear consultas parametrizadas que conducen a muchos errores de inyección SQL.
  • Algunas versiones de Erlang (R13B, tal vez otras) no verifican los certificados de igual SSL por defecto y probablemente hay muchos códigos de erlang que son susceptibles a ataques SSL MITM
  • El transformador XSLT de Java por defecto permite la ejecución de código arbitrario de Java. Ha habido muchos errores de seguridad graves creados por esto.
  • Las API de análisis XML de Java por defecto permiten que el documento analizado lea archivos arbitrarios en el sistema de archivos. Más diversión :)
— benmmurphy
fuente
5

Debes saber sobre las tres A's. Autenticación, Autorización, Auditoría. El error clásico es autenticar a un usuario, sin verificar si el usuario está autorizado para realizar alguna acción, por lo que un usuario puede mirar las fotos privadas de otros usuarios, el error que cometió la Diáspora. Muchas, muchas más personas se olvidan de Auditoría, usted necesita, en un sistema seguro, poder saber quién hizo qué y cuándo.

— rapadura
fuente
1
No toda autorización requiere autenticación. "De ABAC a ZBAC" contrasta el control de acceso NBAC (basado en autenticación) con soluciones que no requieren autenticación. "IBAC, RBAC, ABAC e incluso CBAC: el control de acceso basado en reclamos se basa en la autenticación ... Por simplicidad, este documento los trata como una solución única e ignora las versiones que han implementado aspectos de la arquitectura ZBAC. En conjunto se denominan autenticación. Control de acceso basado (NBAC) ".
— Mike Samuel
4
  • Recuerda que tú (el programador) tiene que asegurar todas las partes, pero el atacante solo tiene que encontrar una torcedura en tu armadura.
  • La seguridad es un ejemplo de "incógnitas desconocidas". A veces no sabrá cuáles son las posibles fallas de seguridad (hasta después).
  • La diferencia entre un error y un agujero de seguridad depende de la inteligencia del atacante.
— Rory
fuente
4

Yo agregaría lo siguiente:

  • Cómo funcionan las firmas digitales y los certificados digitales
  • ¿Qué es el sandboxing?

Comprenda cómo funcionan los diferentes vectores de ataque:

  • Desbordamientos / desbordamientos de búfer / etc en código nativo
  • Ingenieria social
  • DNS spoofing
  • Hombre en el medio
  • CSRF / XSS y col.
  • inyección SQL
  • Ataques de cifrado (por ejemplo: explotar algoritmos de cifrado débiles como DES)
  • Errores de programa / marco (por ejemplo: la última falla de seguridad de github )

Puedes buscar fácilmente en Google todo esto. Esto te dará una buena base. Si desea ver las vulnerabilidades de las aplicaciones web, hay un proyecto llamado google gruyere que le muestra cómo explotar una aplicación web que funcione.

— Miguel Ping
fuente
4

cuando está creando una empresa o cualquiera de sus propios softwares, debería pensar como un hacker. Como sabemos, los hackers tampoco son expertos en todas las cosas, pero cuando encuentran alguna vulnerabilidad, comienzan a buscar información sobre todo las cosas y finalmente atacar nuestro software. para prevenir tales ataques debemos seguir algunas reglas bien conocidas como:

  • siempre trate de descifrar sus códigos (use cheatsheets y google the things para obtener más información).
  • ser actualizado por fallas de seguridad en su campo de programación.
  • y como se mencionó anteriormente, nunca confíe en ningún tipo de usuario o entradas automatizadas.
  • use aplicaciones de código abierto (sus fallas de seguridad más conocidas son conocidas y resueltas).

Puede encontrar más recursos de seguridad en los siguientes enlaces:

para obtener más información en google sobre los flujos de seguridad de su proveedor de aplicaciones.

— rahul_pratap
fuente
3
  1. Por qué es importante.
  2. Se trata de compensaciones.
  3. La criptografía es en gran medida una distracción de la seguridad.
— Ricardo
fuente
3

También asegúrese de consultar la Lista de los 10 principales de OWASP para obtener una clasificación de todos los principales vectores de ataque / vulnerabilidades.

Es fascinante leer sobre estas cosas. Aprender a pensar como un atacante te entrenará sobre qué pensar mientras escribes tu propio código.

— Michael Kopinsky
fuente
2

Saca y pica las contraseñas de tus usuarios. Nunca los guarde en texto sin formato en su base de datos.

— Abdull
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.