Mucho, o muy pocos, dependiendo de lo que esté usando. Así que consideremos algunos (no todos, definitivamente no es una lista exhaustiva):
- Ataques de inyección : esta es más una vulnerabilidad del lado del servidor, pero asegúrese de que el servidor no confíe ciegamente en la entrada del lado del cliente, y especialmente no la coloque directamente en consultas SQL u otros. XKCD lo puso muy bien en este cómic: https://xkcd.com/327/
- Man in the Middle Attacks : este es un grupo completo de ataques (usado en combinación con XSRF, XSS por lo general), pero todo se reduce a que alguien esté husmeando en las solicitudes que su navegador hace al servidor. A partir de ahí, puede decidir
- Vuelva a reproducir la solicitud POST que realizó para transferir dinero a su cuenta, pero cámbiela para que apunte a su cuenta. (Ataque estándar basado en XSRF). Para evitar esto, asegúrese de que las solicitudes GET no cambien el estado de la base de datos y de que la mayoría de las solicitudes POST basadas en FORMULARIO validen un campo oculto secreto para garantizar que la persona que recibió el formulario sea quien lo envíe. Consulte la guía OWASP aquí para obtener más detalles: https://www.owasp.org/index.php/…
- Detenga la respuesta del servidor en el medio e inyecte sus propios scripts en la página web que el servidor estaba enviando. ¡Entonces se podría ejecutar JS malicioso para capturar sus datos personales, sus pulsaciones de teclas, su vida ! Para evitarlo, asegúrese de que sus solicitudes al servidor se realicen solo a través de HTTPS (aunque en tiempos recientes, ¡incluso eso podría no ser suficiente!)
- Capture su nombre de usuario y contraseña de la página de inicio de sesión del usuario, o los detalles de su tarjeta de crédito. Una vez más, HTTPS evita que las personas (al menos hipotéticamente) fisgoneen y lean los datos de su solicitud POST.
- Inyección, revisitada : el otro tipo de ataques de inyección en el lado del cliente proviene del Contenido generado por el usuario. ¿Alguna vez ha tenido un sitio web en el que el usuario pueda escribir HTML / CSS / JS, y usted tiene que representarlo? ¿Como un cliente de correo electrónico, por ejemplo? Esto lo deja abierto a permitir que los usuarios escriban código HTML / JS malicioso y que su aplicación web lo procese, y causar problemas importantes. Desinfecte sus entradas HTML / CSS / JS antes de renderizarlas a ciegas. Los mismos StackOverflow han estado luchando con esto durante siglos: http://blog.stackoverflow.com/20…
- Fugas de datos confidenciales : los datos son el rey y son más propensos a filtrarse a las personas equivocadas. Hay dos lugares donde puede filtrar esto, y múltiples formas de filtrar esto. Puede filtrar datos confidenciales a través del cable (use HTTPS para evitar esto), o puede filtrarlos almacenándolos en el lugar equivocado del cliente. ¿Dónde está el lugar correcto para almacenar datos confidenciales en el cliente que solicita? No donde !
¿Pero qué hay de las formas en que puede filtrar esto? Asegure sus puntos finales. Asegúrese de que solo los usuarios autenticados (que usen el protocolo https adecuado y las cookies seguras, solo http o tokens seguros) puedan acceder a la información, y no dependa de la protección del lado del cliente para evitar el acceso a los datos. Si puedo hacer una solicitud GET para obtener datos sin ser autenticado, ¡no es seguro!
Segundo, asegúrese de que las respuestas que devuelva también sean seguras y desinfectadas. Considere un caso de uso simple: proporciona un buen mensaje de error al iniciar sesión si el nombre de usuario no es válido. Bueno, ahora puedo usar esa información para descubrir qué nombres de usuario son válidos e inválidos, y luego tratar de adivinar su contraseña.
- ¿Qué es lo más complicado que has hecho con Zapier?
- ¿Qué es una aplicación web?
- ¿Por qué las personas usan IFTTT? Hice una cuenta pero no estoy seguro de por qué debería quedarme.
- ¿Cuánto tiempo le tomaría a un principiante de programación aprender a escribir una aplicación de una sola página con backend?
- ¿Cuáles son algunas ideas para una aplicación web para mi proyecto de último año?
- Componentes inseguros : con seguridad, es como una cadena. El eslabón más débil de la cadena es donde se rompe, y es lo mismo con las aplicaciones web. Todo lo que necesita es utilizar un componente inseguro, desactualizado o simplemente defectuoso que, al comprometerlo, deja vulnerable a todo su sistema. Así que asegúrese de usar componentes validados, actualizados y seguros (WordPress, ¡lo estoy mirando!)
Eso es todo lo que pude sacar de la cabeza en un sprint de 20 minutos 🙂 Más si el tiempo lo permite o la gente quiere información adicional
