Tuve una auditoría de seguridad en un sitio web en el que he estado trabajando. La auditoría mostró que uno de mis parámetros, llamado backurl, no estaba lo suficientemente protegido en mi archivo jsp. Esta url se coloca dentro del href de un botón, botón que permite al usuario volver a la página anterior.
Entonces lo que hice fue protegerlo usando la librería owasp, con la función "forHTMLAttribute". Da algo como esto:
<a class="float_left button" href="${e:forHtmlAttribute(param.backUrl)}">Retour</a>Sin embargo, una segunda auditoría mostró que al reemplazar el valor del parámetro por:
javascript:eval(document%5b%27location%27%5d%5b%27hash%27%5d.substring(1))#alert(1234)Se ejecutaría el código javascript y se mostraría la alerta, solo al hacer clic en el botón.
Dijeron que algo que podía hacer era codificar el valor del nombre de host delante de la URL, pero realmente no entiendo cómo esto ayudaría a resolver el problema. Siento que no importa lo que haga, resolver una vulnerabilidad XSS solo creará una nueva.
Puede alguien ayudarme con esto? Para entender lo que está pasando y dónde mirar al menos.
Muchas gracias.
Como dijo @Pointy, el problema es más fundamental aquí. Aceptar entradas que no son de confianza y representarlas como un enlace palabra por palabra (o como texto) es un problema de seguridad , incluso si escapas de él. Por ejemplo, si permite login?msg=Password+incorrect y así es como maneja los mensajes de retransmisión, tiene un problema. Puedo crear un sitio con: <a href="https://sutterlin.com/login?msg=Give+rzwitserloot+some+cash+to+unlock+admin+privileges">Click for cute kittens!</a> y usted ve por qué esto es un problema.
La solución real es no aceptar información potencialmente contaminada, punto (¡no importa si se escapa!), si esa información termina siendo presentada sin el contexto circundante de que está contaminada. Por ejemplo, tome Twitter. El nombre de usuario y el tweet están potencialmente contaminados. Esto no es gran cosa porque los usuarios de Twitter se dan cuenta debido al diseño del sitio web que estás viendo en lo que escribió un rando. Si alguien tuitea '¡Si transfieres 5 dólares a la cuenta de Jack Dorsey en 12345678, te dará un logo azul de Twitter!', hay una expectativa razonable de que los usuarios del sitio deben no ser idiotas y confiar en él.
El "haga clic aquí para ir a la página anterior" de su sitio web no es así. No puede esperar razonablemente que los usuarios de su sitio se detengan en ese botón, verifiquen la barra de estado de su navegador y lo descubran.
Por lo tanto, todo el principio es incorrecto. Simplemente no puedes hacerlo de esta manera, punto.
Sus alternativas son tres:
En lugar de permitir que la propiedad 'enlace anterior' sea un parámetro de URL, debe estar en la sesión. Los sitios web funcionan con sesiones, generalmente. Puede almacenar lo que quiera en ellos, en el servidor (el código del controlador HTTP toma manualmente, por ejemplo, la cookie y la usa para buscar información en el servidor para ese usuario haciendo una búsqueda, o se ejecuta en un marco que solo proporciona un HttpSession- objeto de estilo, que funciona exactamente de esa manera).
Si realmente quiere hacer lo imposible, puede incluirlo como un blob firmado. Esto es creativo, pero realmente no iría allí.
Un truco rápido: ¿Qué pasa si simplemente incluyes <a href="javascript:history.back()">Click to go back</a> como un enlace estático en tu página web?