¿Existe una guía estándar sobre cómo debería aparecer la entrada desinfectada en el mensaje de error?

Question

¿Existe una guía estándar sobre cómo debería aparecer la entrada desinfectada en el mensaje de error?

#1 de Desthro (3 votos)
#2 de John Deters (1 votos)

0

Digamos que su aplicación web está limpiando la entrada incorrecta y mostrando al usuario cuál fue la entrada incorrecta. Antes de que se implementara XSS Measure, la aplicación web está escupiendo un script malicioso como está. Por ejemplo, valor de dirección errónea: <script>bad script goes here </script>

Ahora, después de una cuidadosa limpieza, la salida podría ser algo como esto. Dirección incorrecta: entrada saneada. Si la entrada fuera, digamos que no es un script como! @ # $ Street, daría como resultado Bad street address:! @ # $

¿Crees que usar word sanitized es demasiado obvio para una cadena de salida que es maliciosa? Me imagino que los usuarios regulares no verán esto. Pero los malos son los únicos que se verán desinfectados. O si la aplicación no dice nada en absoluto si desinfecta la entrada. O debería reemplazar algunas de las etiquetas de script incorrecto con algo diferente. ¿Cuál es la mejor práctica conocida de la industria aquí?

xss

pregunta DoodleKana 20.02.2015 - 23:37

fuente

2 respuestas

1

Como dijo Desthro, un mensaje de error no debe proporcionar demasiada información a un atacante. La práctica recomendada es mostrar un mensaje de error estático que no incluya ninguno de los datos proporcionados por el usuario. Su mensaje de error no debe decir más que sobre "Caracteres no válidos en la dirección de la calle". Si desea ser más útil, podría ser un poco más específico y decirles "La dirección de la calle debe contener solo letras, números y guiones" (o cualquiera que sea su esquema).

Si muestra alguna de las entradas en la salida, se arriesga a la posibilidad de crear algún tipo de ataque XSS inesperado, el tipo que está tratando de evitar. Y le da a sus usuarios legítimos ningún beneficio adicional.

respondido por el John Deters 21.02.2015 - 06:45

fuente

Lea otras preguntas en las etiquetas xss

CSRF es posible si los parámetros no se pasan a través de la cadena de consulta? ¿Es posible que un secuestrador de dominios exitoso use fraudulentamente el certificado emitido al verdadero propietario del nombre de dominio?

score 3 · Accepted Answer

Cualquier mensaje de error no debe proporcionar información al atacante más que su intento no tuvo éxito. Ejemplo: un error de contraseña / nombre de usuario debe decir que el intento fue malo, no si el nombre de usuario fue malo, la contraseña o ambos. Si lo hace, esa información podría ser útil para un atacante en un esfuerzo por eludir sus salvaguardas. Algo en la línea de: "Dirección no válida" o "Dirección no encontrada" en el caso de un campo de Dirección sería más que suficiente. Lo mismo ocurre con cualquier otro campo también.

Ahora, no estoy seguro de por qué volvería a mostrar la información maliciosa a cualquiera que intente insertar un código malicioso en su sistema. Definitivamente revela lo que está sucediendo tras bambalinas, en lugar de ocultar el funcionamiento interno de su sistema al atacante.

Cuanto más vago, mejor.