Presta atención porque en este tutorial vas a hallar el resultado que buscas.
Solución:
tl/dr: Si tiene o no una vulnerabilidad XSS reflejada depende del método exacto que use para agregar los datos. Por lo tanto, debe verificar específicamente el método elegido para asegurarse de que sea seguro. Los marcos de JavaScript modernos generalmente se encargan de estas cosas automáticamente, pero jQuery no lo hace, por lo que la atención a los detalles es fundamental.
No tiene que preocuparse específicamente por la interacción entre el sitio 1 y el sitio 2. La razón es que el sitio 2 debe ser seguro de todas formas (usar consultas preparadas, etc.). Un usuario malintencionado no usaría el sitio 1 para atacar el sitio 2 (en este caso), porque si quisiera, podría atacar el sitio 2 directamente.
Entonces, la pregunta principal aquí es si el sitio 1 es vulnerable o no. Para ser claros, la preocupación sería sobre la posibilidad de un ataque XSS reflejado (que es lo que menciona ExecutionByFork en su respuesta). Para dar un ejemplo simple, qué sucede si un usuario visita esta URL:
http://mysite.com?p=">
Si la forma en que agrega el p parámetro a todos los demás enlaces implícitamente trata su contenido como HTML, entonces terminará inyectando un real script etiqueta en la página, ejecutando el javascript de los atacantes en un ataque XSS reflejado clásico.
Así que la pregunta es: ¿añades el p parámetro de una manera que potencialmente trata los datos como HTML (creando una vulnerabilidad), o lo agrega de una manera segura? La respuesta a esa pregunta se reduce a los métodos específicos que utiliza para agregar los datos. Permítanme dar dos ejemplos:
Mayormente seguro: .prop()
Usando el jQuery .prop El método es seguro porque recurre a establecer la propiedad del nodo DOM correspondiente. Al hacerlo de esta manera, no hay oportunidad de escapar del contexto de la propiedad. En esencia, cualquier cosa que envíes al .prop el método sólo será tratado como un string, sin posibilidad de ejecución. Así que código como este es a salvo de un ataque XSS reflejado:
var link = $('a').first();
old_href = link.prop('href');
link.prop('href', old_href + '?p=' + injected_data))
Sin embargo esto no sería seguro si el usuario tuviera el control total de la final href (si, por ejemplo, no agregó, sino que configuró el href basándose exclusivamente en la entrada del usuario). En ese caso, el usuario podría cambiar el enlace para ejecutar javascript así:
http://mysite.com?p=javascript:alert(1)
Lo que causaría una vulnerabilidad para un código como este:
link.prop('href', injected_data))
Mientras agregue datos a algo que ya está allí, esto es imposible. Sin embargo, si la etiqueta href está previamente vacía, puede terminar con una vulnerabilidad (aunque solo se activará si el usuario hace clic en el enlace: no solo al cargar la página).
Por supuesto, incluso esto no garantiza la seguridad, ya que los datos potencialmente maliciosos se esconden en su aplicación para causar problemas. Puedes olvidar que el href ahora contiene datos de usuario, y si algún otro javascript toma el href de un enlace e intenta hacer algo con él, puede causar problemas. Además, tenga en cuenta que estos datos maliciosos pasarán al Sitio 2 cuando alguien haga clic en el enlace, por lo que el Sitio 2 debe protegerse adecuadamente (lo cual fue true antes de todos modos, así que eso no es realmente nada que no supieras).
No es seguro: .replaceWith()
Sin embargo, muchos otros métodos de javascript permitirán que su string ser tratado como HTML, lo que resultará en XSS reflejado. De hecho, probablemente haya más métodos peligrosos que seguros, por lo que probablemente debería verificar que cualquier método que esté usando sea Realmente a salvo. Aún así, por poner un ejemplo, .replaceWith() evaluará su string como HTML. Así que algo como esto sería peligroso:
link = $('a').first();
old_href = link.prop('href');
link.replaceWith('click here');
Su sitio web puede ser vulnerable a un ataque XSS reflejado (depende de cómo establezca ese valor y cómo se interpreten los datos). Por ejemplo, imagina si accedo a la siguiente URL:
mysite.com?p=">Si su sitio convierte esto:
Link
dentro de esto:
Link
Y luego, si el navegador del usuario analiza el HTML actualizado, el malicious_code() se ejecutará inmediatamente en su navegador. Tenga en cuenta que esto es no el único método para realizar XSS. En última instancia, depende de cómo su sitio tome los datos del usuario y los agregue a la href attributeasí que incluso si