¿Qué caracteres no son seguros en las cadenas de consulta?

Question

I necesidad de prevenir los caracteres que causen vulnerablities en la url

Mi muestra url http://localhost/add.aspx?id=4;req=4

Por favor dar la lista de caracteres que necesito bloque.

Estoy usando la página web ASP.net. Estoy vinculando la información de la base de datos del servidor sql.

sólo quiero una lista de los personajes de mantenerse alejado de los hackers para introducir cadenas no deseados en la url

Answer 1

Dependiendo de lo que la tecnología que está utilizando, hay generalmente es una función incorporada que manejará esto por usted.

ASP.NET (VB) & Classic ASP

myUrl = Server.UrlEncode(myUrl) 

ASP.NET (C#)

myUrl = Server.UrlEncode(myUrl); 

PHP

$myUrl = urlencode($myurl); 

---

Si simplemente desea eliminar los caracteres inseguros, necesitará una expresión regular. RFC 1738 define qué caracteres son inseguros para las direcciones URL:

inseguro:

Los personajes pueden ser peligroso para un número de razones . El espacio
personaje es inseguro porque espacios significativos pueden desaparecer y
espacios insignificantes pueden introducirse cuando las direcciones URL se transcriben o
composición tipográfica o sometidos al tratamiento de los programas de procesamiento de textos. Los caracteres "<" y ">" no son seguros porque se utilizan como los delimitadores
alrededor de las URL en texto libre; la marca de comillas ("" ") se utiliza para
delimitan las direcciones URL en algunos sistemas. El carácter '#' es peligroso y debe
siempre ser codificado ya que se utiliza en World Wide Web y en otros
sistemas para delimitar una URL de un fragmento/identificador de ancla que podría seguirlo. El carácter "%" es inseguro porque se usa para
codificaciones de otros caracteres.Otros caracteres no son seguros porque se conoce que
puertas de enlace y otros agentes de transporte modifican a veces dichos caracteres . Estos caracteres son "{", "}", "|", "\", "^", "~", "[", "]", y "` ".

Answer 2

http://en.wikipedia.org/wiki/Query_string#URL_encoding

Ver también: http://tools.ietf.org/html/rfc3986#section-2.2

Answer 3

I necesidad de prevenir los caracteres que causen vulnerablities

Bueno, por supuesto que necesidad cifrar la URL, ya que las respuestas han dicho. Pero ¿no La codificación URL causa vulnerabilidades? Bueno, normalmente no directamente; en su mayoría, hace que su aplicación se rompa cuando ingresan caracteres inesperados.

Si estamos hablando de web '' vulnerabilidades, los más comunes hoy en día son:

1. del lado del servidor code injection, comprometiendo su servidor
2. SQL injection, comprometiendo su base de datos de inyección
3. HTML, permitiendo ataques cross-site scripting (XSS) contra sus usuarios
4. Acciones no validadas, permitiendo cross-site request forgery (XSRF) ataques contra sus usuarios

Estos son en orden decreciente de seriedad y creciente. (Afortunadamente, pocos autores de sitios web son lo suficientemente estúpidos como para pasar la entrada del usuario al sistema() en estos días, pero las vulnerabilidades XSS y XSRF abundan).

Cada una de estas vulnerabilidades requiere que comprenda el problema subyacente y lo haga deliberadamente . No existe una lista mágica de "cadenas que debe bloquear" que protegerán su aplicación si se muestra ingenua respecto a la seguridad. Hay son algunos complementos que hacen cosas como bloquear la secuencia de comandos '< script' cuando se envían, pero lo único que le dan es una falsa sensación de seguridad, ya que solo pueden detectar algunos casos comunes y suelen ser fáciles de codificar alrededor.

También detendrán las cadenas enviadas cuando realmente las desee. Por ejemplo, algunos (estúpidos) autores de PHP rechazan todos los apóstrofos entrantes como un intento de frenar la inyección SQL; El resultado es que no se puede llamar "O'Reilly". D'oh. No bloquear codificar correctamente

Por ejemplo, para proteger contra la inyección de SQL, asegúrese de que SQL escape de cualquier cadena con la que realice consultas (o use consultas parametrizadas para hacer esto automáticamente); para proteger contra la inyección de HTML, codifica HTML todas las cadenas de texto que generes en la página (o usa un esquema de plantillas/MVC que lo hará automáticamente).

Mi muestra url http://localhost/add.aspx?id=4;req=4

¿Se supone que ser algo malo con esa URL? Es válido separar dos parámetros de consulta con un ';' en lugar del más común '&', pero lamentablemente todavía muchos frameworks web comunes no entienden esta sintaxis (incluidos Java Servlet y ASP.NET). Entonces tendría que ir con 'id = 4 & req = 4' - o, si realmente quería que fuera un parámetro único con un punto y coma literal, 'id = 4% 3Breq% 3D4'.

Answer 4

escribí esto, para las direcciones URL bonitas, pero su supuesto no completa

""", ',', ·,,, *, @,, =,;,:?.,, /, +, &, $, <,>, #,%, {, (,),}, |, \, ^, ~, [,], -, -, - ',, "

y luego yo traducir "espacios" y los espacios se repiten para "-"

lo mejor es hacerlo o combinarla con expresiones reqular reputación negativa