¿Qué exploits web comunes debo conocer?[cerrado]

https://stackoverflow.com/questions/23102

09-06-2019
|

Pregunta

Todavía estoy bastante inexperto en lo que respecta a la programación web; he pasado la mayor parte de mi tiempo en aplicaciones cliente.Así que tengo curiosidad acerca de los exploits comunes que debería temer/probar en mi sitio.

Solución

OWASP mantiene una lista de los 10 mejores ataques web a los que debemos prestar atención, además de un montón de otra información de seguridad útil para el desarrollo web.

Otros consejos

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

Secuencias de comandos entre sitios (XSS)

Las fallas XSS ocurren cada vez que una aplicación toma datos proporcionados por el usuario y los envía a un navegador web sin validar o codificar primero ese contenido.XSS permite a los atacantes ejecutar scripts en el navegador de la víctima que pueden secuestrar sesiones de usuario, alterar sitios web, posiblemente introducir gusanos, etc.

Defectos de inyección

Los fallos de inyección, en particular la inyección 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 remota de archivos (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 de ejecución de archivos maliciosos afectan a PHP, XML y cualquier marco que acepte nombres de archivos o archivos de los usuarios.

Referencia de objeto directo inseguro

Una referencia directa a objeto ocurre cuando un desarrollador expone una referencia a un objeto de implementación interna, 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 entre sitios (CSRF)

Un ataque CSRF obliga al navegador de la víctima que ha iniciado sesión a enviar una solicitud previamente autenticada a una aplicación web vulnerable, lo que luego 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 inadecuado de errores

Las aplicaciones pueden filtrar involuntariamente información sobre su configuración, funcionamiento interno o violar la privacidad a través de una variedad de problemas de la aplicación.Los atacantes utilizan esta debilidad para robar datos confidenciales o realizar ataques más graves.

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 utilizan funciones criptográficas de forma adecuada para proteger datos y credenciales.Los atacantes utilizan datos débilmente protegidos para cometer robo de identidad y otros delitos, como el fraude con tarjetas de crédito.

Comunicaciones inseguras

Con frecuencia, las aplicaciones no logran cifrar el tráfico de red cuando es necesario proteger comunicaciones confidenciales.

No restringir el acceso a la URL

Con frecuencia, una aplicación solo protege funciones confidenciales impidiendo la visualización de enlaces o URL a usuarios no autorizados.Los atacantes pueden utilizar esta debilidad para acceder y realizar operaciones no autorizadas accediendo directamente a esas URL.

El proyecto de seguridad de aplicaciones web abiertas

-Adán

Estos tres son los más importantes:

Todo el mundo dirá "Inyección SQL", porque es la vulnerabilidad que suena más aterradora y la más fácil de entender.Cross-Site Scripting (XSS) ocupará el segundo lugar porque también es fácil de entender.La "validación de entrada deficiente" no es una vulnerabilidad, sino más bien una evaluación de las mejores prácticas de seguridad.

Probemos esto desde una perspectiva diferente.A continuación se muestran características que, cuando se implementan en una aplicación web, probablemente le causarán problemas:

SQL dinámico (por ejemplo, creadores de consultas de UI).A estas alturas, probablemente sepa que la única forma confiable y segura 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 infringen esta regla con más frecuencia 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 "Listas de reproducción inteligentes" similares a iTunes que se ven en los sitios de búsqueda, donde cosas como los operadores de cláusula dónde se pasan directamente al backend.Otra gran piedra a destacar es la clasificación de columnas de tablas, donde verá cosas como DESC expuestas en parámetros HTTP.
Subir archivo.La carga de archivos confunde a la gente porque los nombres de las rutas de los archivos se parecen sospechosamente a las rutas de las URL y porque los servidores web facilitan la implementación de la parte de "descarga" simplemente apuntando las URL a los directorios del sistema de archivos.7 de cada 10 controladores de carga que probamos permiten a los atacantes acceder a archivos arbitrarios en el servidor, porque los desarrolladores de la aplicación asumieron que se aplicaron los mismos permisos a la llamada "open()" del sistema de archivos que se aplican a las consultas.
Almacenamiento de contraseñas.Si su aplicación puede devolverme por correo mi contraseña sin formato cuando la pierdo, fracasará.Existe una única respuesta segura y confiable para el almacenamiento de contraseñas, que es bcrypt;Si estás usando PHP, probablemente quieras PHPpass.
Generación de números aleatorios.Un ataque clásico a aplicaciones web:restablecer la contraseña de otro usuario y, debido a que la aplicación utiliza la función "rand()" del sistema, que no es criptográficamente segura, la contraseña es predecible.Esto también se aplica en cualquier lugar donde se realice criptografía.Lo cual, por cierto, no deberías hacer:Si dependes de criptomonedas en cualquier lugar, es muy probable que seas vulnerable.
Salida dinámica.La gente pone demasiada fe en la validación de entradas.Sus posibilidades de eliminar las entradas del usuario de todos los metacaracteres posibles, especialmente en el mundo real, donde los metacaracteres son partes necesarias de la entrada del usuario, son bajas.Un enfoque mucho mejor es tener un régimen consistente para 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.
Correo electrónico.Muchas aplicaciones implementan algún tipo de capacidad de correo saliente que permite a un atacante crear una cuenta anónima o no utilizar ninguna cuenta para enviar correo electrónico controlado por el atacante a direcciones de correo electrónico arbitrarias.

Más allá de estas características, el error número uno que probablemente cometa en su aplicación es exponer una ID de fila de la base de datos en algún lugar, de modo que el usuario X pueda ver los datos del usuario Y simplemente cambiando un número de "5" a "6".

bool UserCredentialsOK(User user)
{

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

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

NUNCA NUNCA NUNCA (¿mencioné "nunca"?) confíe en la información del usuario que se le pasa desde los elementos del formulario.Si sus datos no se examinan antes de pasarlos a otras capas lógicas de su aplicación, también podría darle las claves de su sitio a un extraño en la calle.

No mencionas en qué plataforma estás, pero si estás en ASP.NET, comienza con el buen Scott Guthrie y su artículo "Consejo/truco:Protéjase contra ataques de inyección SQL".

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

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

La mayoría de la gente aquí ha mencionado la inyección SQL y XSS, que es un poco correcto, pero no se deje engañar: las cosas más importantes de las que debe preocuparse como desarrollador web es la VALIDACIÓN DE ENTRADA, de donde provienen XSS y la inyección SQL.

Por ejemplo, si tiene un campo de formulario que solo acepta números enteros, asegúrese de implementar algo tanto en el lado del cliente como en el del servidor para desinfectar los datos.

Verifique y vuelva a verificar cualquier dato de entrada, especialmente si terminará en una consulta SQL.Sugiero crear una función de escape y envolver con ella todo lo que se incluya en una consulta.Por ejemplo:

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

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

Esta es también una breve presentación 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.

Los más comunes son probablemente los ataques de inyección de bases de datos y los ataques de secuencias de comandos entre sitios;principalmente porque son los más fáciles de lograr (probablemente porque esos son los que los programadores son más vagos).

Puedes ver incluso en este sitio que las cosas más dañinas que cuidarás implican la inyección de código en tu aplicación, por lo que XSS (Cross Site Scripting) y la inyección SQL (sugerencias de (@Patrick) son tus mayores preocupaciones.Básicamente, querrás asegurarte de que, si tu aplicación permite que un usuario inyecte cualquier código, esté regulada y probada para garantizar que solo las cosas que estás seguro de querer permitir (un enlace html, una imagen, etc.) ) se pasan y no se ejecuta nada más.

Inyección SQL.Secuencias de comandos entre sitios.

El uso de procedimientos almacenados y/o consultas parametrizadas contribuirá en gran medida a protegerlo de la inyección de SQL.También hacer 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 integradas.Lo mejor es filtrar la entrada mediante controles de validación y Regex.

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 (OBTENER, PUBLICAR, COOKIE).Tipos de ataques comunes y cómo salvarse:

Ataque de inyección SQL:Utilice consultas preparadas
Secuencias de comandos entre sitios:No envíe datos de usuario al navegador sin filtrar/escapar primero.Esto también incluye los datos de usuario almacenados en la base de datos, que originalmente provenían de los usuarios.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow