Ataques de validación de entrada
La validación de entrada se realiza para reducir los datos malignos que pueden entrar en el sistema. Este método no es la principal prevención de XSS. Estos datos se cubren en la codificación de salida y hojas de datos relacionados.
From Wikipedia, the free encyclopedia
La validación de entrada se realiza para reducir los datos malignos que pueden entrar en el sistema. Este método no es la principal prevención de XSS (Inyección de SQL). Estos datos se cubren en la codificación de salida y hojas de datos relacionados.
Siempre se recomienda evitar ataques lo antes posible en el proceso de la solicitud del usuario (atacante). La validación de entrada se puede utilizar para detectar intrusiones no autorizadas antes de que sea procesada por la aplicación. Los desarrolladores realizan con frecuencia la validación de listas negras para intentar detectar caracteres de ataque y patrones como el carácter, la cadena 1 = 1 o la etiqueta <script>, pero este es un enfoque masivo defectuoso, ya que es típicamente trivial para un atacante evitar ser atrapado por estos filtros. Además, estos filtros frecuentemente impiden la entrada autorizada cuando el carácter está siendo filtrado. Para obtener más información sobre la evasión de filtros XSS, consulte la hoja de trucos XSS Filter Evasion.
La validación de la lista blanca es apropiada para todos los campos de entrada proporcionados por el usuario. Esta implica definir exactamente qué es autorizado, y por definición, todo lo demás no está autorizado. Si se trata de datos bien estructurados, como fechas, números de seguridad social, códigos postales, direcciones de correo electrónico, etc., el desarrollador debería ser capaz de definir un patrón de validación muy fuerte, normalmente basado en expresiones regulares, para validar dicha entrada. Si el campo de entrada proviene de un conjunto fijo de opciones, como una lista desplegable o botones de radio, la entrada debe coincidir exactamente con uno de los valores ofrecidos al usuario en primer lugar. Los campos más difíciles de validar son los llamados campos de texto libre, como entradas de blog. Sin embargo, incluso esos tipos de campos pueden ser validados hasta cierto punto. Por ejemplo, puede excluir al menos todos los caracteres no imprimibles (excepto el espacio en blanco aceptable, por ejemplo, CR, LF, tabulación, espacio) y definir una longitud máxima para el campo de entrada.
En resumen, la validación de entrada:
- Se aplicará a todos los datos de entrada, como mínimo.
- Debe definir el conjunto de caracteres permitidos para ser aceptado.
- Debe definir una longitud mínima y máxima para los datos. (por ejemplo, {1,25})
Ejemplos de expresiones regulares de lista blanca
Validando un archivo comprimido en ZIP (5 dígitos + 4 opcionales):
^\d{5}(-\d{4})?$
Validando una selección en un menú desplegable:
^(AA|AE|AP|AL|AK|AS|AZ|AR|CA|CO|CT|DE|DC|FM|FL|GA|GU| HI|ID|IL|IN|IA|KS|KY|LA|ME|MH|MD|MA|MI|MN|MS|MO|MT|NE| NV|NH|NJ|NM|NY|NC|ND|MP|OH|OK|OR|PW|PA|PR|RI|SC|SD|TN| TX|UT|VT|VI|VA|WA|WV|WI|WY)$
Ejemplo de uso de Java Regex
Ejemplo validando el parámetro “zip” usando una expresión regular.
private static final Pattern zipPattern = Pattern.compile("^\d{5}(-\d{4})?$");
public void doPost( HttpServletRequest request, HttpServletResponse response) {
try {
String zipCode = request.getParameter( "zip" );
if ( !zipPattern.matcher( zipCode ).matches() {
throw new YourValidationException( "Improper zipcode format." );
}
.. do what you want here, after its been validated ..
} catch(YourValidationException e ) {
response.sendError( response.SC_BAD_REQUEST, e.getMessage() );
}
}
Algunos validadores de listas blancas también han sido predefinidos en varios paquetes de código abierto que se pueden aprovechar. Por ejemplo:
Lado de cliente vs validación de lado de servidor
Tenga en cuenta que cualquier validación de entrada de JavaScript realizada en el cliente puede ser anulada por un atacante que deshabilita JavaScript o usa un proxy web. Asegúrese de que cualquier validación de entrada realizada en el cliente también se realiza en el servidor.
Validación de contenido de usuario enriquecido
Es muy difícil validar contenido enriquecido enviado por un usuario. Para obtener más información, se puede consultar la hoja de Sanitizing HTML Markup with a Library Designed for the Job.
Prevención de XSS y política de seguridad de contenido
- Todos los datos de usuario controlados deben codificarse cuando se devuelvan en la página html para evitar la ejecución de datos maliciosos (por ejemplo, XSS). Por ejemplo, & lt; script & gt; Sería devuelto como & amp; lt; script & amp; gt;
- El tipo de codificación es específico para el contexto de la página donde se insertan los datos controlados por el usuario. Por ejemplo, la codificación de entidad HTML es apropiada para los datos colocados en el cuerpo HTML. Sin embargo, los datos de usuario colocados en un script necesitarían una codificación de salida específica para JavaScript.
Información detallada sobre la prevención XSS aquí: Hoja de trucos de prevención de XSS de OWASP
