Seguridad popular "Cargo Cults"

• El código cerrado es más seguro que el código abierto, ya que los atacantes pueden ver el código fuente y encontrar y explotar vulnerabilidades. Aunque no estoy diciendo que esto sea siempre falso, con software de código abierto es al menos posible que expertos externos revisen el software en busca de vulnerabilidades / puertas traseras abiertas y luego las parcheen públicamente. Con software de código cerrado que simplemente no es posible sin desmontar meticulosamente el binario. Y aunque es posible que usted y la mayoría de los atacantes no tengan acceso al código fuente, es probable que existan atacantes poderosos (por ejemplo, el gobierno de EE. UU.) Que puedan obtener el código fuente o inyectar vulnerabilidades secretas en él.

• El envío de datos a través de una red es secreto si usted cifra los datos . El cifrado debe estar autenticado para evitar que un atacante altere sus datos. Debe verificar la identidad de la otra parte a la que está enviando la información o, de lo contrario, un intermediario puede interceptar y alterar su tráfico. Incluso con la autenticación y la identificación, el cifrado a menudo filtra información. ¿Hablas con un servidor a través de HTTPS? Los escuchas ilegales de la red (cualquiera en su ISP) saben exactamente cuánto tráfico envió, a qué dirección IP y cuál es el tamaño de cada una de las respuestas (por ejemplo, puede hacer huellas dactilares en varias páginas web según el tamaño de todos los recursos transferidos). Además, especialmente con los sitios web AJAX, la información que ingresa a menudo conduce a una respuesta del servidor que se puede identificar por sus patrones de tráfico. Consulte Fugas de canales laterales en aplicaciones web .

• Preguntas débiles para restablecer la contraseña : ¿Cómo se hackeó el correo electrónico de Sarah Palin ? Una persona pasó por el procedimiento de restablecimiento de contraseña y pudo responder a todas las preguntas correctamente a partir de información disponible públicamente. ¿Qué preguntas de restablecimiento de contraseña podría descubrir un conocido de Facebook?

• El sistema X es irrompible: utiliza el cifrado AES de 256 bits y tomaría mil millones de computadoras ordinarias de un billón de billones de billones de billones de años para una posible ruptura. Sí, puede ' t forzado de forma bruta ya que eso requeriría operaciones de ~ 2 ²⁵⁶ . Pero la contraseña podría ser reutilizada o en un diccionario de contraseñas comunes. O has pegado un keylogger en la computadora. O bien, amenazó a alguien con una llave de $ 5 y le dijeron la contraseña . Existen ataques de canal lateral. Tal vez el generador de números aleatorios fue defectuoso . Existen ataques de tiempo. Existen ataques de ingeniería social. Estos son generalmente los enlaces más débiles.

• Esta práctica débil es lo suficientemente buena para nosotros, no tenemos tiempo para esperar para hacer las cosas de manera segura . El gobierno de los EE. UU. No tiene que preocuparse por cifrar los feeds de video de sus drones - Quién sabrá escuchar las frecuencias portadoras correctas; además, las cajas de cifrado serán pesadas y costosas. ¿Por qué molestarse?

• Quantum Computers puede resolver rápidamente problemas de tiempo exponencial y romperá todos los métodos de encriptación . Las personas leen artículos de ciencia popular en computadoras cuánticas y escuchan que son estas entidades místicas y súper poderosas que aprovecharán el poder de cómputo de un número casi infinito de universos paralelos para hacer cualquier cosa. Es solo una parte verdad. Las computadoras Quantum permitirán que la factorización y los logaritmos discretos se realicen en el tiempo polinomial O (n ³ ) a través del algoritmo de Shor, lo que hace que RSA, DSA y el cifrado basados en esas funciones de puerta trampa sean fácilmente rompibles. De manera similar, las computadoras cuánticas pueden usar el algoritmo de Grover para forzar una contraseña que debe tomar el tiempo O (2 ^N ) solo en el tiempo O (2 ^{N / 2} ); efectivamente reduciendo a la mitad la seguridad de una clave simétrica: se sabe que el algoritmo de Grover de Granted es asintóticamente óptimo para las computadoras cuánticas, así que no espere una mejora adicional.

Algunos ejemplos:

• Teclas más grandes. RSA de 4096 bits, AES de 256 bits ... más bits siempre son mejores. (Vea los comentarios: no tiene sentido tener claves más grandes que el tamaño que garantiza el estado de "no se puede romper"; las claves más grandes implican una sobrecarga de la red y la CPU, a veces en grandes cantidades).

• La aplicación automática de "funciones seguras" como snprintf() en lugar de sprintf() (no servirá de mucho a menos que el programador pruebe el posible truncado y no impida el uso de un usuario) cadena como cadena de formato). Puntos extra para strncpy() que no hacen lo que la mayoría de la gente parece asumir (en particular, no garantiza un '%code%' final).

• "Pureza del administrador de seguridad". Como una aplicación de la separación de deberes y roles, todas las decisiones "relacionadas con la seguridad" deben ser tomadas por un especialista en seguridad, que es distinto de los diseñadores y desarrolladores del proyecto. A menudo llevado al extremo equivocado, donde el usuario que decide qué puertos de red deben dejarse abiertos en cualquier firewall no tiene ningún conocimiento sobre el proyecto, y se niega deliberadamente a aprender nada al respecto, porque la decisión independiente es más importante que la decisión informada .

Agregaré mis propios ejemplos de appsec que he visto al consultar:

• "Te enviaré un archivo zip cifrado e incluiré la contraseña en el mismo correo electrónico ... "Esto me ha sucedido más de una vez. Una puerta cerrada no permanecerá cerrada si deja la llave en la puerta.
• "Pero no pudiste tener inyección SQL recibida y inyección SMTP, llamamos sanitize() en todo! ". No hay manera de hacer una variable seguro para cada uso, necesita utilizar la rutina de saneamiento para el trabajo.
• "No podemos ser pirateados porque solo usamos la plataforma XXX / language / OS". Cada plataforma tiene problemas de seguridad, período .
• "Tenemos una evaluación de seguridad anual, no podrá encontrar cualquier cosa ". ¡Frecuencia! = Calidad . Tener evaluaciones frecuentes es algo bueno, ¡pero esto no garantiza nada!
• "Tenemos un WAF, lo que significa que no tenemos que aplicar parches cualquier cosa ". Sí, entonces esto sucede ... Tuve un cliente que no corrigió las vulnerabilidades CSRF conocidas, porque asumieron que la WAF podría detener estos ataques. afirmó que podía "evitar todos los top 10 de owasp", y que la interfaz de administración HTTP de WAF era vulnerable a CSRF.)

• Las contraseñas deben incluirse con sal y hacer hash antes de almacenarlas en la base de datos. SHA-1 es un buen ajuste, SHA-512 es perfecto.

Todavía escucho eso de muchos profesionales de la seguridad, capacitación en seguridad y guías de seguridad actuales.

Utilizar SSL solo para la página de inicio de sesión en lugar de todas las áreas autenticadas de un sitio web.

Solo uno, pero es importante: "La seguridad de la información es un problema de tecnología, que se puede solucionar con tecnología".     

Para evitar que las personas descubran si existen ciertos usuarios en el sistema, ocultando si la contraseña era incorrecta o si el nombre de usuario no era válido durante un intento fallido de inicio de sesión, ... Al mismo tiempo ofrece un formulario de restablecimiento de contraseña que em> does filtra esta información.

"Nuestro sitio web no puede ser pirateado porque estamos usando SSL". Señor, solo hace que sea más fácil de explotar si es vulnerable porque incluso su IDS / IPS queda inutilizado por el flujo de SSL.