¿Cuándo es mejor Desinfectar la Entrada del Usuario?

Desinfecto mis datos de usuario como Radu...

1. Primer lado del cliente usando expresiones regulares y tomando el control sobre los caracteres permitidos ingrese en campos de formulario dados usando javascript o jQuery vinculados a eventos, como onChange o OnBlur, que elimina cualquier entrada no permitida antes de que pueda ser presentar. Sin embargo, darse cuenta de que esto realmente solo tiene el efecto de permitir que los los usuarios en el saber, que los datos se va a comprobar lado del servidor, así. Es más una advertencia que cualquier protección real.

2. Segundo, y rara vez veo esto hecho en estos días más, que el primer cheque es done del lado del servidor es verificar la ubicación de donde se envía el formulario. Al permitir solo el envío de formularios desde una página que haya designado como válida ubicación, puede matar el script INCLUSO antes de haber leído en cualquier dato. Conceder, eso en sí mismo es insuficiente, ya que un buen hacker con su propio servidor puede 'falsificar' tanto el dominio como la dirección IP a hacer que parezca a su guión que está llegando desde una ubicación de formulario válida.

3. A continuación, y ni siquiera debería tener que decir esto, pero siempre, y quiero decir SIEMPRE, corre tus scripts en modo mancha. Esto te obliga a no ser perezoso, y a ser diligente sobre paso número 4.

4. Desinfectar los datos del usuario tan pronto como sea posible utilizando expresiones regulares bien formadas apropiadas para los datos que se esperan de cualquier campo dado en el formulario. No tomes atajos como el infame cuerno mágico del unicornio para soplar a través de sus cheques mancha... o también puede desactivar la comprobación de manchas en primer lugar para todo lo bueno servirá para su seguridad. Eso es como darle a un psicópata un cuchillo afilado, su garganta, y diciendo 'Usted realmente no me hará daño con que va a usted".

   Y aquí es donde difiero que la mayoría de los demás en este cuarto paso, ya que solo desinfecto los datos de usuario que voy a utilizar realmente de una manera que puede presentar un seguridad riesgo, como cualquier llamada al sistema, asignaciones a otras variables, o cualquier escritura a almacenar datos. Si solo estoy utilizando los datos introducidos por un usuario para hacer una comparación con los datos He almacenado en el sistema yo mismo (por lo tanto, sabiendo que los datos míos están seguros), entonces no me molesto en desinfectar los datos del usuario, ya que nunca voy a hacerlo de una manera eso se presenta como un problema de seguridad. Por ejemplo, tome una entrada de nombre de usuario como ejemplo. Utilizo el nombre de usuario introducido por el usuario solo para comprobarlo contra un partido en mi base de datos, y si es true, después de eso utilizo los datos de la base de datos para realizar todas las demás funciones que podría llamar para que en el script, sabiendo que es seguro, y nunca utilice los datos de los usuarios de nuevo después de eso.

5. Por último, es filtrar todos los intentos de auto-envíos por los robots en estos días, con un sistema de 'autenticación humana', como Captcha. Esto es lo suficientemente importante en estos días que me tomé el tiempo para escribir mi propio esquema de 'autenticación humana' que utiliza fotografías y una entrada para que el' humano ' ingrese lo que ve en la imagen. Hice esto porque He encontrado que los sistemas de tipo Captcha realmente molestan a los usuarios (se puede decir por su ojos entrecerrados por tratar de descifrar las letras distorsionadas... por lo general más y otra vez). Esto es especialmente importante para scripts que usan SendMail o SMTP para el correo electrónico, ya que estos son los favoritos para sus hambrientos robots de spam.

Para terminar, se lo explicaré a mi esposa... su servidor es como un club nocturno popular, y cuantos más gorilas tenga, menos problemas tendrá en el club nocturno. Tengo dos gorilas fuera de la puerta (validación del lado del cliente y autenticación humana), un gorila justo dentro de la puerta (verificando la ubicación válida de envío de formularios... 'Es que realmente usted en este ID'), y varios gorilas más en cerca de la puerta (funcionamiento modo mancha y el uso de buenas expresiones regulares para comprobar el datos del usuario).

Sé que esto es un post, pero me pareció lo suficientemente importante para cualquier persona que puede leerlo después de mi visita aquí para darse cuenta de su no es 'bala mágica' cuando se trata de seguridad, y se necesita todo esto trabajando en conjunción entre sí para hacer que sus datos proporcionados por el usuario seguro. El solo uso de uno o dos de estos métodos es prácticamente inútil, ya que su poder solo existe cuando todos se unen.

O en resumen, como solía decir mi madre... "Mejor prevenir que curar".

Desafortunadamente, casi ninguno de los participantes entiende claramente de qué están hablando. Literalmente. Solo @Kibbee logró hacerlo recto.

Este tema trata sobre la desinfección. Pero la verdad es que una cosa como la ampliamente denominada "desinfección de propósito general" de la que todos están tan ansiosos de hablar es simplemente no existe.

Hay un trillón de medios diferentes, cada uno requiere su propio formato de datos distinto. Además-incluso un solo medio requiere un formato diferente para sus partes. Digamos que el formato HTML es inútil para javascript incrustado en la página HTML. O bien, el formato de cadena es inútil para los números en la consulta SQL.

De hecho, tal "desinfección tan pronto como sea posible", como se sugiere en la mayoría de las respuestas votadas, es simplemente imposible. Como uno simplemente no puede decir en qué cierto medio o parte del medio se utilizarán los datos. Digamos, nos estamos preparando para defender de " sql-inyección", escapando de todo lo que se mueve. Pero whoops! - algunos campos obligatorios no se rellenaron y tenemos que rellenar los datos de nuevo en el formulario en lugar de la base de datos... con todas las barras añadidas.

Por otro lado, escapamos diligentemente toda la "entrada del usuario"... pero en la consulta sql no tenemos comillas a su alrededor, ya que es un número o identificador. Y ninguna "desinfección" nos ayudó.

En tercer lugar-de acuerdo, hicimos nuestro mejor esfuerzo para desinfectar el terrible, indigno de confianza y desdeñado "usuario entrada"... pero en algún proceso interno utilizamos estos mismos datos sin ningún formato (¡ya lo hicimos lo mejor que pudimos!)- y whoops! tienen inyección de segunda orden en todo su esplendor.

Así que, desde el punto de vista del uso de la vida real, la única forma adecuada sería

• formateo, no cualquier "desinfección"
• justo antes de usar
• según ciertas reglas del medio
• e incluso siguiendo las subreglas requeridas para las diferentes partes de este medio.

Depende del tipo de desinfección que esté haciendo.

Para protegerse contra la inyección SQL, no haga nada a los datos en sí. Solo tiene que utilizar declaraciones preparadas, y de esa manera, usted no tiene que preocuparse por jugar con los datos que el usuario introducido, y que afecta negativamente a su lógica. Hay que desinfectar un poco, para asegurarse de que los números son números, y las fechas son fechas, ya que todo es una cadena ya que proviene de la solicitud, pero no intente hacer ninguna comprobación para hacer cosas como bloquear palabras clave o cualquier cosa.

Para protegerse contra ataques XSS, probablemente sería más fácil corregir los datos antes de que se almacenen. Sin embargo, como otros mencionaron, a veces es bueno tener una copia prístina de exactamente lo que el usuario ingresó, porque una vez que lo cambias, se pierde para siempre. Es casi una lástima que no hay una forma a prueba de tontos para asegurarse de que la aplicación solo saca HTML desinfectado de la manera en que puede asegurarse de que no se ve atrapado por la inyección SQL mediante el uso de preparado consulta.

Temprano es bueno, definitivamente antes de tratar de analizarlo. Cualquier cosa que vaya a generar más tarde, o especialmente pasar a otros componentes (por ejemplo, shell, SQL, etc.) debe ser desinfectada.

Pero no exageres, por ejemplo, las contraseñas se hash antes de almacenarlas (¿verdad?). Las funciones Hash pueden aceptar datos binarios arbitrarios. Y nunca imprimirás una contraseña (¿verdad?). Por lo tanto, no analice las contraseñas y no las desinfecte.

También, asegúrese de que usted está haciendo la desinfección desde un proceso de confianza - JavaScript / cualquier cosa del lado del cliente es peor que la seguridad inútil / integridad-sabio. (Sin embargo, podría proporcionar una mejor experiencia de usuario para fallar temprano, solo hazlo en ambos lugares.)

Lo más importante es ser siempre consistente cuando se escapa. La doble desinfección accidental es patética y no desinfectar es peligroso.

Para SQL, solo asegúrese de que su biblioteca de acceso a la base de datos admita variables de enlace que escapan automáticamente a los valores. Cualquiera que concatene manualmente la entrada del usuario en cadenas SQL debería saberlo mejor.

Para HTML, prefiero escapar en el último momento posible. Si destruye la entrada del usuario, nunca podrá recuperarla, y si hacen una error que pueden editar y corregir más tarde. Si destruyes su entrada original, se ha ido para siempre.

Perl tiene una opción de mancha que considera toda la entrada del usuario "manchada" hasta que se comprueba con una expresión regular. Los datos contaminados se pueden usar y transmitir, pero contaminan cualquier dato con el que entren en contacto hasta que no estén contaminados. Por ejemplo, si la entrada del usuario se añade a otra cadena, la nueva cadena también está contaminada. Básicamente, cualquier expresión que contenga valores contaminados generará un resultado contaminado.

Los datos contaminados pueden lanzarse a voluntad (datos contaminados a medida que avanzan), pero tan pronto como es utilizado por un comando que tiene efecto en el mundo exterior, el script perl falla. Así que si utilizo datos contaminados para crear un archivo, construir un comando de shell, cambiar el directorio de trabajo, etc, Perl fallará con un error de seguridad.

No soy consciente de otro lenguaje que tenga algo como "mancha", pero usarlo ha sido muy revelador. Es increíble lo rápido que los datos contaminados se propagan si no los mantienes de inmediato. Cosas que natural y normal para un programador, como establecer una variable basada en los datos del usuario o abrir un archivo, parece peligroso y arriesgado con la contaminación activada. Así que la mejor estrategia para hacer las cosas es no manchar tan pronto como usted consigue algunos datos desde el exterior.

Y sospecho que esa es la mejor manera también en otros idiomas: validar los datos de usuario de inmediato para que los errores y los agujeros de seguridad no puedan propagarse demasiado lejos. Además, debería ser más fácil auditar el código de agujeros de seguridad si los agujeros potenciales están en un solo lugar. Y nunca puede predecir qué datos se utilizarán con qué propósito más adelante.

Mi opinión es desinfectar la entrada del usuario tan pronto como sea posible del lado del cliente y del lado del servidor, lo estoy haciendo así

1. (lado del cliente), permite al usuario introduzca solo claves específicas en el campo.
2. (lado del cliente), cuando el usuario vaya al siguiente campo usando onblur, pruebe la entrada que ingresó contra una expresión regular, y observe al usuario si algo no es bueno.
3. (lado del servidor), pruebe la entrada de nuevo, si el campo debe ser INTEGER compruebe que (en PHP se puede utilizar is_numeric() ), si el campo tiene un formato bien conocido cotejarlo con una expresión regular, todo otros (como comentarios de texto), solo escapar de ellos. Si hay algo sospechoso, detenga la ejecución del script y devuelva un aviso al usuario de que los datos que introdujo no son válidos.

Si algo realmente parece un posible ataque, el script me envía un correo y un SMS, para que pueda comprobarlo y prevenirlo lo antes posible, solo necesito comprobar el registro donde estoy registrando todas las entradas del usuario, y los pasos que el script realizó antes de aceptar la entrada o rechazarlo.

Limpie los datos antes de almacenarlos. Generalmente no debería preformar NINGUNA acción SQL sin limpiar primero la entrada. No quieres someterte a un ataque de inyección SQL.

Sigo estas reglas básicas.

1. Solo hacer la modificación de acciones SQL, tales como, INSERTAR, ACTUALIZAR, ELIMINAR a través de POST. Nunca LO CONSEGUIRÁS.
2. Escapar de todo.
3. Si está esperando que la entrada del usuario sea algo, asegúrese de verificar que es ese algo. Para ejemplo, usted está solicitando un número, a continuación, asegúrese de que es un número. Utilice validaciones.
4. Usa filtros. Limpiar personajes no deseados.

Los usuarios son malos!

Bueno, tal vez no siempre, pero mi enfoque es siempre sanatizar inmediatamente para garantizar que nada arriesgado se acerque a mi backend.

El beneficio adicional es que puede proporcionar retroalimentación al usuario si desinfecta en el punto de entrada.

Supongamos que todos los usuarios son maliciosos. Desinfecte todas las entradas tan pronto como sea posible. Punto.

Desinfecto mis datos justo antes de procesarlos. Es posible que tenga que tomar los campos de Nombre y Apellido y concatenar en un tercer campo que se inserta en la base de datos. Voy a desinfectar la entrada incluso antes de hacer la concatenación para no obtener ningún tipo de procesamiento o errores de inserción. Cuanto antes mejor. Incluso el uso de Javascript en el front-end (en una configuración web) es ideal porque eso ocurrirá sin que ningún dato vaya al servidor para empezar.

El la parte aterradora es que es posible que incluso desee comenzar a desinfectar los datos que salen de su base de datos también. La reciente oleada de ataques de inyección SQL de ASPRox que han estado circulando son doblemente letales porque infectarán todas las tablas de bases de datos en una base de datos dada. Si su base de datos está alojada en algún lugar donde hay varias cuentas alojadas en la misma base de datos, sus datos se corrompen debido a un error de otra persona, pero ahora se ha unido a las filas de alojamiento de malware para sus visitantes debido a que no es culpa tuya.

Seguro que esto hace mucho trabajo por adelantado, pero si los datos son críticos, entonces es una inversión digna.

Me parece que limpiarlo inmediatamente tiene dos ventajas. Uno, puede validarlo y proporcionar comentarios al usuario. Dos, no tiene que preocuparse por consumir los datos en otros lugares.

La entrada del usuario siempre debe tratarse como maliciosa antes de llegar a las capas inferiores de la aplicación. Siempre maneje la entrada de desinfección tan pronto como sea posible y no debe, por ningún motivo, almacenarse en su base de datos antes de verificar la intención maliciosa.