¿Mejores prácticas en el uso de querystring en ASP.NET?

Question

He estado buscando alguna guía de mejores prácticas cuando uso QueryString en ASP.NET y realmente no he encontrado ninguna.

he encontrado un artículo de optimización útil: http://dotnetperls.com/querystring

pero estoy más interesado en contestar las siguientes preguntas: reglas

• caso? ¿Todo en minúsculas? ¿Caso Pascal? ¿El caso de Carmel?
  • Mi preferencia personal es minúscula, pero la consistencia es más importante.
• ¿Evita los caracteres especiales en los nombres de los parámetros?
• ¿Deberían ofuscarse los parámetros y valores por razones de seguridad?

etc ...

Cualquier más directrices sería apreciada!

Answer 1

Lo que está en su cadena de consulta es visible y modificable por el usuario final. Esto significa que tienen el potencial de cambiarlo para ver o acceder a los datos que no deberían, o para influir en el comportamiento de su sitio/aplicación. Por lo tanto, huelga decir que no confías en nada en la cadena de consulta, y verifica todo antes de usarlo. Cuando lo verifique, no verifique que sea incorrecto con él (podría ser una lista infinita), en su lugar verifique que sea correcto. Si incluso uno de sus cheques falla, debe descartar los datos de la cadena de consulta o tratarlos como sospechosos. Si ha cifrado o codificado los datos en la cadena de consulta, aún puede tener efectos secundarios no deseados si el usuario se equivoca y confía ciegamente en ello, incluso si los cambios del usuario no tenían sentido debido a la codificación.

El único enfoque que tomo al almacenar datos confidenciales en la cadena de consulta es no hacerlo; en su lugar, almacenaré el lado sensible del servidor de datos (en la sesión, caché o una tabla en la base de datos) y luego tendré una clave generada aleatoriamente (generalmente un GUID) en la cadena de consulta para identificarla, para que la URL se vea de esta manera:

http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3 

es bastante difícil de fuerza bruta un GUID y las posibilidades de una colisión GUID son infinitesimalmente pequeña, así que si los líos usuario final con la cadena de consulta a continuación, que terminan siendo nada.

Este enfoque también funciona bien cuando necesito almacenar muchas cosas y la cadena de consulta comienza a ser demasiado larga; los datos que necesitan ser rastreados se pueden guardar en un objeto que luego se almacena en la sesión o caché, y una vez más GUID se usa como su clave.

Answer 2

Mis 5 centavos:

si usted tiene una página que se puede llamar a otras personas, como

http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3 

entonces usted no quiere que ellos experimentan problemas cuando escriben mal la K en secretKey al no hacerlo una letra mayúscula.

Así que aquí mis reglas:

1. hacerlo todo en minúsculas. Nunca mayúsculas, porque hay algunas letras pequeñas que no tienen una letra mayúscula correspondiente, como la doble s alemana.

2. QueryString["mykey"].ToLower().Equals("73FA4A5A85A44C75ABB5E323569628D3") es una mala idea, porque QueryString["mykey"] podría ser NULL (referencia de excepción NULL).

3. No hay cosas complicadas como string.IsNullOrEmpty() if else if object.equals(querykey, "comparison"). Simplemente use StringComparer.OrdinalIgnoreCase.Equals(key, "73FA4A5A85A44C75ABB5E323569628D3"), esto funciona en NULL, devuelve falso, no se necesita verificación null/emtpy adicional.

Answer 3

Creo que no hay mejor respuesta entre slugster y Stefan. Lo mejor es hacer ambas referencias a guids y usar minúsculas, por lo que el ejemplo anterior realmente leería http://myurl.com/mypage.aspx?secretkey=73fa4a5a85a44c75abb5e323569628d3