¿Es + como alternativa a% 20 un vector de ataque?

Solo para referencia: http://host/path?query

El símbolo + es algo problemático en los URI, esto se debe a que se interpreta de manera diferente por diferentes codificadores / decodificadores URI. Se siempre se interpreta como un espacio si aparece en la consulta de la URI (¿todo después de?), Sin embargo, si se interpreta como un espacio si ocurre en la parte ruta de la URI está en el decodificador utilizado.

Su ejemplo usa la sección de ruta, y la respuesta dependerá de qué decodificador esté usando. La mayoría de ellos no descodificarán + al espacio cuando ocurra en la ruta, pero no lo sabrás hasta que pruebes con tu decodificador específico. Este es exactamente el tipo de bypass sanitario desagradable que puede morderlo: P

%20 y + son dos formas diferentes, aunque relacionadas con la codificación de un espacio (0x20):

• %20 es el simple codificación de porcentajes que se utiliza para representar datos que no son ASCII en las URL.
• + se origina en la application / x-www-form-urlencoded codificación de datos , que se basa en el porcentaje de codificación pero utiliza el + para los espacios de codificación.

La última application / x-www-form-urlencoded es la codificación predeterminada de los formularios. Con el método de formulario GET, los datos se agregan simplemente a la URL action del formulario en la parte de consulta . Esta es una convención introducida con HTML.

Por lo tanto, además de la convención de codificación general para las URL, los servidores o aplicaciones web de codificación en porcentaje, que deberían poder procesar solicitudes GET parametrizadas, deben poder decodificar la aplicación / x-www-form-urlencoded también, pero solo para la consulta según la especificación HTML.

Otras partes de la URL, como en su caso, la ruta de la URL , no están sujetas a la La codificación de aplicación / x-www-form-urlencoded de forma predeterminada. Algunos servidores / aplicaciones web también pueden decodificarlo, pero no es un comportamiento estandarizado.

Pero no puedo ver cómo permitir un + en las URL puede generar un riesgo de seguridad, especialmente si se descodifica a un espacio. Hay técnicas de el mencionado "ataque de SQL o JScript" que funciona sin ningún + o espacio en absoluto. Así que supongo que es más bien una lista blanca precligiosa o una lista negra de ciertos caracteres, incluido el + .

+  is an arithmetic operator in the sql language. 

Si su asp.net produce un error también cuando usa esos operadores matemáticos: +, -, /. ¡Entonces podría ser la razón por la que!