security - ¿Qué exploits web comunes debería conocer?

testing

Question

Todavía estoy bastante verde cuando se trata de programación web, he pasado la mayor parte del tiempo en aplicaciones cliente. Así que tengo curiosidad acerca de los exploits comunes que debería temer / probar en mi sitio.

Answer 1

ATAQUES DE INYECCIÓN SQL. Son fáciles de evitar, pero demasiado comunes.

NUNCA SIEMPRE (¿mencioné "alguna vez"?) Confío en la información del usuario que le pasaron desde los elementos del formulario. Si sus datos no son revisados ​​antes de pasarlos a otras capas lógicas de su aplicación, también podría entregar las claves de su sitio a un extraño en la calle.

No mencionas en qué plataforma estás pero si en ASP.NET comienzas con el buen viejo Scott Guthrie y su artículo " Sugerencia / truco: Guardia contra los ataques de inyección SQL ".

Después de eso, debe considerar qué tipo de datos permitirá que los usuarios envíen y, finalmente, salgan de su base de datos. Si permite que se inserte HTML y luego se presente, está abierto para ataques de Cross Site Scripting (conocidos como XSS).

Esos son los dos que me vienen a la mente, pero nuestro propio Jeff Atwood tuvo un buen artículo en Coding Horror con una reseña del libro " 19 pecados capitales de la seguridad del software ".

Answer 2

El uso de procedimientos almacenados y / o consultas parametrizadas será de gran ayuda para protegerlo de la inyección sql. Además, NO haga que su aplicación web acceda a la base de datos como sa o dbo - configure una cuenta de usuario estándar y establezca los permisos.

AS para XSS (cross-site scripting) ASP.NET tiene algunas protecciones incorporadas. Lo mejor es filtrar la entrada usando controles de validación y Regex.

Answer 3

Esta es también una pequeña presentación breve sobre seguridad realizada por uno de los principales desarrolladores de wordpress.

Seguridad en wordpress

cubre todos los problemas básicos de seguridad en las aplicaciones web.

Answer 4

Estos tres son los más importantes:

• Falsificación de solicitudes cruzadas
• Cross Site Scripting
• inyección SQL

Answer 5

Estoy publicando la lista abreviada de OWASP Top 2007 aquí para que la gente no tenga que mirar a otro enlace y en caso de que la fuente se caiga.

Cross Site Scripting (XSS)

• Las fallas XSS ocurren cada vez que una aplicación toma los datos suministrados por el usuario y los envía a un navegador web sin primero validar o codificar ese contenido. XSS permite a los atacantes ejecutar secuencias de comandos en el navegador de la víctima, lo que puede secuestrar las sesiones de los usuarios, desfigurar los sitios web, posiblemente introducir gusanos, etc.

Defectos de inyección

• Las fallas de inyección, particularmente la inyección de SQL, son comunes en las aplicaciones web. La inyección ocurre cuando los datos proporcionados por el usuario se envían a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante engañan al intérprete para que ejecute comandos no deseados o cambie datos.

Ejecución de archivos maliciosos

• El código vulnerable a la inclusión de archivos remotos (RFI) permite a los atacantes incluir código y datos hostiles, lo que resulta en ataques devastadores, como el compromiso total del servidor. Los ataques maliciosos de ejecución de archivos afectan a PHP, XML y cualquier marco que acepte nombres de archivos o archivos de usuarios.

Referencia insegura de objeto directo

• Una referencia de objeto directa ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, como un archivo, directorio, registro de base de datos o clave, como una URL o parámetro de formulario. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin autorización.

Falsificación de solicitudes cruzadas (CSRF)

• Un ataque CSRF obliga al navegador de una víctima registrada a enviar una solicitud autenticada previamente a una aplicación web vulnerable, lo que obliga al navegador de la víctima a realizar una acción hostil en beneficio del atacante. CSRF puede ser tan poderoso como la aplicación web que ataca.

Fuga de información y manejo incorrecto de errores

• Las aplicaciones pueden, de manera involuntaria, filtrar información sobre su configuración, funcionamiento interno o violar la privacidad a través de una variedad de problemas de aplicación. Los atacantes usan esta debilidad para robar información sensible o realizar ataques más serios.

Autenticación rota y gestión de sesiones

• Las credenciales de cuenta y los tokens de sesión a menudo no están protegidos adecuadamente. Los atacantes comprometen contraseñas, claves o tokens de autenticación para asumir las identidades de otros usuarios.

Almacenamiento criptográfico inseguro

• Las aplicaciones web rara vez usan funciones criptográficas de forma adecuada para proteger los datos y las credenciales. Los atacantes usan datos débilmente protegidos para realizar el robo de identidad y otros delitos, como el fraude con tarjetas de crédito.

Comunicaciones inseguras

• Con frecuencia, las aplicaciones no cifran el tráfico de red cuando es necesario para proteger las comunicaciones confidenciales.

Error al restringir el acceso a la URL

• Con frecuencia, una aplicación solo protege la funcionalidad sensible al impedir la visualización de enlaces o URL a usuarios no autorizados. Los atacantes pueden usar esta debilidad para acceder y realizar operaciones no autorizadas accediendo a esas URL directamente.

El proyecto de seguridad de aplicaciones web abiertas

-Adán

Answer 6

Inyección SQL. Cross Site Scripting.

Answer 7

La mayoría de las personas mencionaron SQL Injection y XSS, lo que es correcto, pero no se dejen engañar: las cosas más importantes de las que debe preocuparse, ya que un desarrollador web es INPUT VALIDATION, de donde provienen las inyecciones de XSS y SQL.

Por ejemplo, si tiene un campo de formulario que solo aceptará enteros, asegúrese de implementar algo en el lado del cliente Y en el lado del servidor para desinfectar los datos.

Verifique y compruebe dos veces cualquier dato de entrada, especialmente si va a terminar en una consulta SQL. Sugiero construir una función de escaner y envolverla con todo lo que vaya a una consulta. Por ejemplo:

$query = "SELECT field1, field2 FROM table1 WHERE field1 = ''" . myescapefunc($userinput) . "''";

Del mismo modo, si va a mostrar cualquier información ingresada por el usuario en una página web, asegúrese de haber eliminado cualquier etiqueta <script> o cualquier otra cosa que pueda dar como resultado la ejecución de Javascript (como onLoad = onMouseOver = etc. atributos en las etiquetas )

Answer 8

Los más comunes son probablemente los ataques de inyección de base de datos y los ataques de scripting entre sitios; principalmente porque esos son los más fáciles de lograr (eso es probable porque esos son los programadores más perezosos).

Answer 9

No soy un experto, pero por lo que he aprendido hasta ahora, la regla de oro es no confiar en ningún dato del usuario (GET, POST, COOKIE). Tipos de ataque comunes y cómo salvarse:

1. Ataque de inyección SQL : utilice consultas preparadas
2. Cross Site Scripting : no envíe datos de usuario al navegador sin filtrar / escapar primero. Esto también incluye datos de usuario almacenados en la base de datos, que originalmente provenía de los usuarios.

Answer 10

Todo el mundo va a decir "Inyección de SQL", porque es la vulnerabilidad que suena más aterradora y la más fácil de entender. Cross-Site Scripting (XSS) va a quedar en segundo lugar, porque también es fácil de entender. "Pobre validación de entrada" no es una vulnerabilidad, sino más bien una evaluación de una mejor práctica de seguridad.

Probemos esto desde una perspectiva diferente. Estas son las características que, cuando se implementan en una aplicación web, es probable que lo arruinen:

• SQL dinámico (por ejemplo, constructores de consultas UI). Por ahora, probablemente sepa que la única manera segura y confiable de usar SQL en una aplicación web es usar consultas parametrizadas, donde vincula explícitamente cada parámetro de la consulta a una variable. Los lugares donde veo que las aplicaciones web rompen con más frecuencia esta regla es cuando la entrada maliciosa no es un parámetro obvio (como un nombre), sino más bien un atributo de consulta. Un ejemplo obvio son los creadores de consultas de "lista de reproducción inteligente" similar a iTunes que se ven en los sitios de búsqueda, donde los elementos como los operadores de cláusula-lugar se pasan directamente al servidor. Otra gran roca para cambiar son los tipos de columna de tabla, donde verá cosas como DESC expuesto en los parámetros de HTTP.

• Subir archivo. La carga de archivos molesta a las personas porque los nombres de las rutas de archivos se parecen sospechosamente a los nombres de las rutas URL, y porque los servidores web facilitan la implementación de la parte de "descarga" simplemente apuntando las URL a los directorios en el sistema de archivos. 7 de cada 10 gestores de carga que probamos permiten a los atacantes acceder a archivos arbitrarios en el servidor, porque los desarrolladores de la aplicación supusieron que se aplicaron los mismos permisos a la llamada "open ()" del sistema de archivos que se aplican a las consultas.

• Almacenamiento de contraseña. Si su aplicación puede enviarme por correo mi contraseña sin procesar cuando la pierda, usted falla. Existe una única respuesta segura y confiable para el almacenamiento de contraseñas, que es bcrypt; si usas PHP, probablemente quieras PHPpass.

• Generación aleatoria de números Un ataque clásico a las aplicaciones web: restablece la contraseña de otro usuario y, como la aplicación usa la función "rand ()" del sistema, que no es muy segura, la contraseña es predecible. Esto también se aplica en cualquier lugar donde estés haciendo criptografía. Lo cual, dicho sea de paso, no deberías estar haciendo: si confías en crypto en cualquier lugar, muy probablemente seas vulnerable.

• Salida dinámica. La gente pone mucha fe en la validación de entrada. Sus posibilidades de depurar las entradas de usuario de todos los metacaracteres posibles, especialmente en el mundo real, donde los metacaracteres son partes necesarias de la entrada del usuario, son bajos. Un enfoque mucho mejor es tener un régimen consistente de filtrar los resultados de la base de datos y transformarlos en entidades HTML, como quot, gt y lt. Rails hará esto por usted automáticamente.

• Email. Muchas aplicaciones implementan algún tipo de capacidad de correo saliente que permite a un atacante crear una cuenta anónima o no usar ninguna cuenta para enviar correos electrónicos controlados por atacantes a direcciones de correo electrónico arbitrarias.

Más allá de estas características, el error # 1 que probablemente cometerá en su aplicación es exponer una identificación de fila de la base de datos en alguna parte, de modo que el usuario X pueda ver los datos para el usuario Y simplemente cambiando un número de "5" a "6".

Answer 11

Usted puede ver incluso en este sitio que las cosas más dañinas que estará cuidando implican la inyección de código en su aplicación, por lo que XSS (Cross Site Scripting) y la inyección SQL (sugerencias de @ Patrick) son sus mayores preocupaciones. Básicamente, querrá asegurarse de que si su aplicación permite a un usuario inyectar cualquier código, está regulado y probado para asegurarse de que solo las cosas que está seguro que desea permitir (un enlace html, imagen, etc. ) se pasan, y no se ejecuta nada más.

Answer 12

OWASP mantiene una lista de los 10 principales ataques web para ver, además de una tonelada de otra información de seguridad útil para el desarrollo web.

Answer 13

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}