¿Este filtro es lo suficientemente seguro como para mitigar XSS?

Navega tus respuestas
1

Tengo una aplicación que escapa a los siguientes caracteres especiales. 

& < > " '

La aplicación muestra en gran medida los parámetros de solicitud HTTP en toda la aplicación. Los parámetros de solicitud se utilizan en el cuerpo HTML, las etiquetas div, incluso dentro de las etiquetas Javascript <script> . La única defensa en este momento es escapar de estos 5 caracteres especiales.

¿Qué he intentado hasta ahora?

  1. Lea la hoja de trucos OWASP XSS Prevention y la hoja de trucos OWASP Filter Bypass.
  2. Intenté replicar la aplicación en mi sistema local e intenté confundir la aplicación con las cargas útiles de XSS.

Mis preguntas

  1. La hoja de trucos OWASP recomienda escapar & < > " ' / si se usa dentro de las etiquetas HTML. Falta el filtro de mi aplicación y solo se escapa el carácter / . Creo que / es necesario solo si el atributo HTML no está citado. ¿Tengo razón al entender esto?

  2. Diga, tenemos el siguiente código HTML dentro de una página JSP. ¿Se puede omitir esto cuando se escapa & < > " ' / ?
    a. <input type="hidden" name="choice" value="<%= encode(req.getParameter("choice")) %>">
    segundo. <div> <%= encode(req.getParameter("choice")) %> </div>
    do. <script> document.write("<%= encode(req.getParameter("choice")) %>") </script>

Soy muy consciente de que esto no es suficiente, pero probé una lista extensa de cargas útiles XSS y no pude evitar esto. Me parece suficiente escapar de estos 5 caracteres dentro de un contexto HTML.

Apreciaría enormemente si ustedes pudieran exponer sus pensamientos sobre esto. Realmente me encantaría que este filtro se omita.

    
pregunta Haunted 26.06.2017 - 23:38
fuente

3 respuestas

6
  

Realmente me encantaría que se omita este filtro.

Déjame ser el primero en cumplir tu deseo con el %0d%0a payload tan subestimado y olvidado:

Tu código: 

<script> 
// TODO
// document.write("<%= encode(req.getParameter("choice")) %>")
</script>

Solicitud: enlace

Código resultante: 

<script> 
// TODO
// document.write("
alert(1);//")
</script>

Si bien puede pensar que no comentaría dicho código, tenga en cuenta que otros desarrolladores podrían hacerlo (para el propósito de la función de prueba / depuración / desactivación temporal) sin pensar en el agujero de seguridad que puede crear. Para <script> debería codificar %0d%0a en \r\n . Sin embargo, no necesita esta codificación para el elemento html.

    
respondido por el Xavier59 27.06.2017 - 00:02
fuente
2

¿Por qué no confiar en la codificación adecuada? Un ejemplo simple de romper una cadena podría ser: 

<script>var a = "<%=encode(a)%>", b="<%=encode(b)%>";</script>

Con una carga útil de a = \, la primera cadena se extenderá hasta el comienzo de la segunda y el valor de b estará fuera de la cadena. Entonces podemos usar b = -alert (1)); //

También confías en no tener ningún atributo html quoteless (pero a partir de 1. Supongo que lo sabes).

    
respondido por el Erlend 27.06.2017 - 08:18
fuente
0

Sugiero seguir las mejores prácticas (en lugar de escapar de algunos caracteres específicos y usar scriptlets que son una cosa del pasado).

En su caso, ya que está usando JSP, simplemente puede usar la etiqueta <c:out /> que haría que su código sea más legible, estándar y seguro al eliminar cualquier lógica personalizada de listas blancas que pueda haber implementado (ya que actualmente está escapando de 5 personajes elegidos como explicas).

    
respondido por el niilzon 27.06.2017 - 09:52
fuente

Lea otras preguntas en las etiquetas

¿Cómo podemos reforzar la seguridad de nuestro Windows Server 2012 R2 contra el ransomware? [duplicar] Firefox: el certificado no se puede instalar [cerrado]