example - Formas de evitar SQL Injection Attack & XSS en la aplicación web Java

sql injection java

Question

Estoy escribiendo una clase Java que sería invocada por un filtro de servlet y que comprueba si hay intentos de ataque de inyección y XSS para una aplicación web java basada en Struts. La clase InjectionAttackChecker usa la clase regex & java.util.regex.Pattern para validar la entrada en comparación con los patrones especificados en regex.

Dicho esto, tengo las siguientes preguntas:

1. Qué todos los caracteres especiales y patrones de caracteres (por ejemplo, <>, . , -, <=, ==,> =) deben bloquearse para evitar el ataque de inyección.
2. ¿Existe algún patrón de expresiones regulares que pueda usar como está?
3. Tengo que permitir algunos de los patrones de caracteres especiales en algunos casos específicos, algunos valores de ejemplo (que se permiten) son (se utiliza ''pipe'' | carácter como un separador de diferentes valores) * Atlanta | # 654, BLDG 8 # 501 | Herpes simple: úlcera (s) crónica (s) (> 1 mes de duración) o bronquitis, neumonitis o esofagitis | FUNC & COMP (date_cmp), "NDI & MALKP & HARS_IN (icd10, yes)". ¿Qué estrategia debo adoptar para que el ataque de inyección y el XSS se puedan prevenir, pero permitiendo estos patrones de caracteres?

Espero haber mencionado la pregunta claramente. Pero si no lo hice, me disculpo ya que es solo mi segunda pregunta. Por favor, avíseme si se necesita alguna aclaración.

Answer 1

Aquí hay un artículo bastante extenso sobre ese mismo tema.

Aunque no creo que tengas un Santo Grial aquí. También sugeriría tratar de codificar / decodificar el texto recibido en algunas formas estándar (uuencode, base64)

Answer 2

En función de sus preguntas, supongo que está intentando filtrar los valores incorrectos. Personalmente, creo que este método puede ser muy complejo muy rápidamente y recomendaría valores de codificación como un método alternativo. Aquí hay un artículo de IBM sobre el tema que presenta los pros y los contras de ambos métodos, http://www.ibm.com/developerworks/tivoli/library/s-csscript/ .

Para evitar los ataques de inyección SQL, solo use las declaraciones preparadas en lugar de crear cadenas de SQL.

Answer 3

Si intentas desinfectar todos los datos en la entrada, vas a tener un momento muy difícil. Hay muchos trucos que involucran la codificación de caracteres y que permitirán a las personas eludir tus filtros. Esta lista impresionante es solo una de las miles de cosas que se pueden hacer como inyecciones de SQL. También debe evitar la inyección de HTML, la inyección de JS y, potencialmente, otros. La única forma segura de hacerlo es codificar los datos donde se usan en su aplicación. Codifique todos los resultados que escriba en su sitio web, codifique todos sus parámetros SQL. Tenga especial cuidado con este último, ya que la codificación normal no funcionará para los parámetros de SQL que no sean cadenas, como se explica en ese enlace. Use consultas parametrizadas para estar completamente seguro. También tenga en cuenta que podría teóricamente codificar sus datos en el momento en que el usuario los ingresa y almacenarlos codificados en la base de datos, pero eso solo funciona si siempre va a utilizar los datos de manera que usen ese tipo de codificación (es decir, HTML codificación si solo se usará con HTML; si se usa en SQL, no estará protegido). En parte, esta es la razón por la cual la regla empírica es nunca almacenar datos codificados en la base de datos y codificar siempre el uso.

Answer 4

Validar y enlazar todos los datos es una necesidad. Realice validaciones tanto del lado del cliente como del lado del servidor, ya que el 10% de las personas desactiva el JavaScript en sus navegadores.

Jeff Atwood tiene un buen blog sobre el tema que le da un sabor por su complejidad.

Answer 5

Eche un vistazo al proyecto AntiSamy [www.owasp.org] . Creo que es exactamente lo que quieres; puedes configurar un filtro para bloquear ciertas etiquetas. También proporcionan plantillas de políticas, la política de barras flotantes sería un buen comienzo, luego agregue las etiquetas que necesita.

Además, hay una gran cantidad de conocimiento en el sitio web www.osasp.org sobre cómo proteger su aplicación.

También se debe realizar lo que el usuario ''nemo'' dice sobre el uso de enunciados preparados y codificación.

Answer 6

no filtrar ni bloquear valores

1. debe asegurarse de que al combinar fragmentos de texto realice las conversiones de tipo adecuadas :) es decir: si tiene una pieza una cadena que es de tipo HTML y una cadena que es de tipo TEXTO, debe convertir TEXTO a HTML en lugar de concatenarlos ciegamente. en haskell puedes aplicarlo convenientemente con el sistema de tipos.

Los lenguajes de plantillas html correctos se escaparán de forma predeterminada. si está generando XML / HTML, a veces es mejor usar herramientas DOM que un lenguaje de plantillas. si usa una herramienta DOM, elimina muchos de estos problemas. Desafortunadamente, la herramienta DOM es generalmente una mierda en comparación con la creación de plantillas :)

2. si toma cadenas de tipo HTML de los usuarios, debe desinfectarlas con una biblioteca para eliminar todas las etiquetas / atributos que no sean buenos. hay muchos buenos filtros html en la lista blanca.
3. siempre debes usar consultas parametrizadas. ¡SIEMPRE! si tiene que generar consultas dinámicamente, compórtelas dinámicamente con parámetros. nunca combine cadenas escritas no SQL con cadenas escritas en SQL.