El autor del material, cuya traducción publicamos hoy, dice que hay muchas razones para estudiar la seguridad web. Por ejemplo, los usuarios del sitio web que están preocupados por el robo de sus datos personales están interesados en problemas de seguridad. La seguridad concierne a los desarrolladores web que buscan aumentar el nivel de protección para sus proyectos. Lo mismo puede decirse de los programadores novatos que buscan trabajo y se preparan para entrevistas. El propósito de este artículo es comprender algunas tecnologías importantes de seguridad web en un lenguaje comprensible. Antes de comenzar a hablar sobre estas tecnologías, a las que generalmente se hace referencia con abreviaturas como CORS, CSP y HSTS, veremos un par de conceptos básicos de seguridad.
Dos conceptos básicos de seguridad web
▍100% de protección es un mito
En el mundo de la seguridad, no existe tal cosa como "100% de protección contra piratería informática". Si alguna vez alguien le cuenta sobre este nivel de protección, tenga en cuenta que está equivocado.
▍Un nivel de protección no es suficiente
Supongamos que alguien cree que al implementar CSP, protegió completamente su proyecto de los ataques XSS. Quizás alguien perciba que la protección absoluta no existe como algo dado, pero pensamientos como el descrito anteriormente pueden visitar a cualquiera. Si hablamos de programadores que decidieron entender los problemas de seguridad, entonces quizás la razón de tales pensamientos es el hecho de que, al escribir el código del programa, operan principalmente con conceptos como "negro" y "blanco", 1 y 0, "verdadero" y "falso". Pero la seguridad no es tan simple.
Tecnologías de seguridad web
Comencemos la discusión sobre seguridad web con tecnología, a la que los desarrolladores suelen prestar atención muy pronto, por ejemplo, al comienzo de su trayectoria profesional. Por cierto, si desea omitir este método de protección, puede encontrar mucha información sobre cómo hacerlo en StackOverflow. Se trata de CORS.
ORSCORS
¿Alguna vez has visto tal error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
Frente a eso, crees que ciertamente no eres el primero con quien sucedió esto. Googleando, descubres que para resolver este problema, es suficiente instalar algún tipo de extensión. Bueno, ¿no es maravilloso? Sin embargo, la tecnología CORS (Cross-Origin Resource Sharing, compartir recursos entre diferentes fuentes) no existe para interferir con los desarrolladores, sino para proteger sus proyectos.
Para comprender cómo CORS protege los proyectos web, primero hablaremos de las cookies, en particular, las cookies utilizadas para autenticar a los usuarios. Estas cookies se utilizan cuando se trabaja con un determinado recurso web para informar al servidor que el usuario ha iniciado sesión. Se envían automáticamente con solicitudes que se ejecutan en el servidor correspondiente.
Supongamos que ha iniciado sesión en su cuenta de Facebook y Facebook usa cookies de autenticación. Al trabajar en Internet, hace clic en el enlace
bit.ly/r43nugi , es redirigido a un sitio web malicioso, por ejemplo, algo así como
superevilwebsite.rocks . El script descargado junto con la página en este sitio realiza una solicitud del cliente a
facebook.com utilizando su cookie de autenticación.
En un mundo sin CORS, un script de
superevilwebsite.rocks podría hacer cambios en secreto en su perfil de FB, podría robar alguna información, con todas las consecuencias resultantes. En un mundo así, podría surgir fácilmente una "epidemia superevilwebsite.rocks", cuando un script que captura la administración de la cuenta del usuario publica un enlace en su página, haciendo clic en el cual los amigos de este usuario "se infectan", y a través de los enlaces publicados en sus páginas, una epidemia finalmente cubre todo Facebook.
Sin embargo, en un mundo donde existe CORS, Facebook solo permitiría solicitudes para modificar los datos de la cuenta de
facebook.com . En otras palabras, la administración del sitio limitaría el intercambio de recursos entre diferentes fuentes.
Aquí puede tener la siguiente pregunta: "¿Pero superevilwebsite.rocks puede simplemente cambiar el encabezado de origen en sus solicitudes y parecerá que provienen de facebook.com?"
Un sitio fraudulento puede intentar hacer esto, pero no tendrá éxito, porque el navegador ignorará dicho encabezado y usará datos reales.
“¿Qué sucede si superevilwebsite.rocks hace una solicitud similar del servidor?”, Pregunta.
En una situación similar, CORS se puede eludir, pero no será útil, ya que, al ejecutar una solicitud del servidor, no será posible transmitir una cookie de autenticación a Facebook. Por lo tanto, el script, para completar con éxito dicha solicitud, debe ejecutarse en el lado del cliente y tener acceso a las cookies almacenadas en el cliente.
▍CSP
Para comprender qué es CSP (Política de seguridad de contenido, Política de protección de contenido), primero debe hablar sobre una de las vulnerabilidades web más comunes. Se trata de XSS (secuencias de comandos entre sitios, secuencias de comandos entre sitios).
Al realizar un ataque XSS, el atacante inyecta un código JavaScript especial en la parte del cliente de un sitio determinado. Podrías pensar: “Bueno, ¿qué hará este guión? ¿Cambiar los colores de los elementos de la página?
Supongamos que alguien integra correctamente su script JS en las páginas del sitio que está visitando. ¿Qué podría hacer un script similar? De hecho, muchas cosas:
- Puede realizar solicitudes HTTP a otros sitios, pretendiendo que las está haciendo.
- Él puede redirigirlo a un sitio que se ve exactamente como aquel en el que inició sesión, pero está diseñado, por ejemplo, para robar credenciales.
- Es capaz de agregar etiquetas
<script> a páginas que contienen algún código JavaScript o están diseñadas para cargar algún tipo de archivo JS. - Puede agregar un elemento
<iframe> a la página, que, por ejemplo, se verá exactamente como los campos para ingresar el nombre y la contraseña para ingresar al sitio. En este caso, estos campos para ingresar dichos datos estarán ocultos.
De hecho, las posibilidades que se abren para que un atacante ejecute con éxito un ataque XSS son infinitas.
La política de protección de contenido intenta evitar esto aplicando las siguientes restricciones:
- Limitaciones sobre lo que se puede abrir en un
<iframe> . - Limitaciones en las que se pueden cargar hojas de estilo.
- Limitaciones sobre qué consultas se pueden realizar.
¿Cómo funciona CSP?
Cuando hace clic en el enlace o ingresa la URL del sitio web en la barra de direcciones del navegador, el navegador realiza una solicitud GET. La solicitud llega al servidor, que pasa un código HTML al navegador junto con los encabezados HTTP. Si está interesado en ver estos encabezados, abra la pestaña Red en las herramientas de desarrollo del navegador y visite varios sitios. El encabezado de respuesta puede verse así:
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Esta es la política de seguridad de contenido de
facebook.com . Conviértalo a un aspecto más legible:
content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Considere las directivas de CSP presentadas aquí:
default-src : prohíbe todo lo que no esté configurado explícitamente.script-src : introduce restricciones en los scripts descargables.style-src : impone restricciones en las hojas de estilo cargadas.connect-src : introduce restricciones en las URL desde las que se pueden cargar recursos mediante interfaces de secuencias de comandos, como fetch , XHR , ajax , etc.
Tenga en cuenta que, de hecho, hay muchas de esas directivas. El navegador lee el encabezado CSP y aplica las reglas apropiadas dentro del archivo HTML cargado. Las directivas configuradas correctamente permiten solo aquellas acciones que son necesarias para el correcto funcionamiento de la página.
Si la página no tiene un encabezado CSP, entonces no se aplican prohibiciones. Los caracteres * en el encabezado CSP son comodines. Tal señal puede ser reemplazada por cualquier cosa, y lo que ocurra será permitido.
▍HTTPS
Seguramente has oído hablar de HTTPS (HTTP Secure). Quizás te hayas encontrado con algo como esto: "¿Por qué debería preocuparme por HTTPS si solo juego en el sitio?" O, tal vez, se te ocurrió la siguiente idea: “Si no tienes HTTPS, entonces esto es una locura. En el patio año 2018! No le creas a nadie que diga que HTTPS puede prescindirse de él ”.
Es posible que haya escuchado que Chrome ahora marca el sitio como inseguro si no usa HTTPS.
La principal diferencia entre HTTPS y HTTP es que, cuando transmiten datos a través de HTTPS, están encriptados, pero cuando transmiten a través de HTTP, no lo están.
¿Por qué vale la pena prestar atención al transferir datos valiosos? La cuestión es que cuando se organiza el intercambio de datos a través de un canal de comunicación inseguro, existe la posibilidad de un ataque MITM (Man In The Middle, un ataque intermedio o un hombre en el medio).
Si usted, sentado en un café, accede a Internet a través de un punto de acceso Wi-Fi abierto, alguien, simplemente, puede pretender ser un enrutador a través del cual pasan todas sus solicitudes y respuestas. Si sus datos no están encriptados, el intermediario puede hacer lo que quiera con ellos. Digamos que puede editar el código HTML, CSS o JavaScript antes de que llegue del servidor en su navegador. Dado lo que ya sabemos sobre los ataques XSS, puede imaginar cuáles podrían ser las consecuencias.
"¿Cómo es esto posible: mi computadora y mi servidor saben cómo cifrar y descifrar los datos que intercambiamos, pero el intermediario malicioso no?", Pregunta. Esto es posible gracias al uso del protocolo SSL (Secure Sockets Layer) y el protocolo TLS (Transport Layer Security) más reciente. TLS reemplazó SSL en 1999 como la tecnología de cifrado utilizada en HTTPS. Una discusión sobre las características de TLS está más allá del alcance de este artículo.
▍HSTS
La tecnología HSTS (HTTP Strict-Transport-Security, el mecanismo de activación forzada de una conexión segura a través del protocolo HTTPS) es bastante simple. Como ejemplo, considere nuevamente el encabezado de Facebook correspondiente:
strict-transport-security: max-age=15552000; preload
Analicémoslo:
max-age establece el tiempo durante el cual el navegador debe obligar al usuario a trabajar con el sitio web a través de HTTPS.preload - para nuestros propósitos esto no es importante.
Este encabezado solo se aplica si está accediendo al sitio usando HTTPS. Si trabaja con el sitio a través de HTTP, este encabezado se ignora. La razón de esto es bastante simple: la comunicación HTTP es tan débil que no se puede confiar en ese encabezado.
Usemos nuevamente el ejemplo de Facebook para demostrar la utilidad práctica del mecanismo HSTS. Suponga que inicia sesión en facebook.com por primera vez y sabe que HTTPS es más seguro que HTTP, por lo que utiliza este enlace:
https://facebook.com . Cuando su navegador recibe el código HTML, también recibe un encabezado que le dice al navegador que debería obligarlo a cambiar a HTTPS cuando realice futuras solicitudes. Después de un mes, alguien le envía un enlace HTTP a Facebook,
http://facebook.com , y usted hace clic en él. Dado que el mes es inferior al período de 15552000 segundos especificado por la directiva de
max-age , el navegador enviará una solicitud a través de HTTPS, evitando un posible ataque MITM.
Resumen
Hoy discutimos algunas tecnologías que se utilizan universalmente para garantizar la seguridad de los proyectos web. Creemos que los problemas de seguridad son muy importantes, ya que conciernen absolutamente a todos los que están conectados a Internet. El tema de la seguridad web es enorme, por lo que no puede decir que, después de leer varios artículos, alguien se convertirá en un experto en este campo o al menos aprenderá lo suficiente como para proteger eficazmente su proyecto web o sus datos personales. Pero, como en cualquier otro campo, el conocimiento en el campo de la seguridad, si existe el deseo de recibirlo, se acumula y su cantidad se convierte gradualmente en calidad. Esperamos que este material haya contribuido a su conocimiento de la seguridad web.
Estimados lectores! ¿Ha encontrado problemas de seguridad inconsistentes de los desarrolladores web?
