2009-12-13 13 views
16

Estoy construyendo una aplicación web donde la interfaz es un motor de búsqueda altamente especializado. La búsqueda se maneja en la URL principal, y el usuario pasa a un subdirectorio cuando hace clic en un resultado de búsqueda para obtener una visualización más detallada. Esta transferencia se realiza como una solicitud GET con la clave primaria que se pasa en la cadena de consulta. Parece que recuerdo haber leído en alguna parte que la exposición de claves primarias al usuario no era una buena idea, así que decidí implementar un cifrado reversible.¿Debería oscurecer los valores de las claves primarias?

Estoy empezando a preguntarme si solo estoy siendo paranoico. La encriptación reversible (base64) probablemente se rompa fácilmente por cualquiera que quiera probar, hace que las URL sean muy feas y también más largas de lo que serían. ¿Debo soltar el cifrado y enviar mis claves principales a la luz?

+0

Gracias a todos por las excelentes respuestas. Para la posteridad, me gustaría hacer algunas observaciones finales. En mi situación particular, la base de datos no contiene secretos, por lo que cambiar la ID en la URL solo llevaría a otra entrada de la base de datos o a un error cuando haya un espacio en la autonumeración porque es posible que haya eliminado un registro. He puesto tanta desinfección en el cuadro de entrada de búsqueda como sé, así que creo que la base de datos es bastante segura. La información es histórica, por lo que cambiará rara vez o nunca, por lo que incluso si alguien lograra destruir la base de datos, podría recuperarla rápidamente sin pérdida. – Scott

Respuesta

22

Lo que estás haciendo es básicamente ofuscación. Una clave principal reversible cifrada (y base64 no cuenta realmente como cifrado) sigue siendo una clave principal.

Lo que estaba leyendo se reduce a esto: generalmente no desea que sus llaves principales tengan ningún tipo de significado fuera del sistema. Esto se denomina clave primaria técnica en lugar de clave primaria natural. Es por eso que puede usar un campo numérico automático para identificación del paciente en lugar de SSN (que se llama clave primaria natural).

Las claves primarias técnicas son generalmente preferidas sobre las claves primarias naturales porque las cosas que parecen constantes cambian y esto puede causar problemas. Incluso los países pueden surgir y dejar de existir.

Si tiene claves técnicas primarias, no desea convertirlas en claves primarias naturales de facto dándoles un significado que de otro modo no tenían. Creo que está bien poner una clave principal en una URL, pero la seguridad es un tema aparte. Si alguien puede cambiar esa URL y obtener acceso a algo a lo que no debería tener acceso, se trata de un problema de seguridad y necesita ser manejado mediante autenticación y autorización.

Algunos argumentarán que nunca deberían ser vistos por los usuarios. No creo que tengas que llegar tan lejos.

+1

+1 Me gustaría volver a votar esto más si pudiera. Ocultar claves principales se trata de disuadir a los usuarios de tratar de extraerles significado, no de seguridad. Las claves técnicas a menudo se llaman claves sustitutivas: http://en.wikipedia.org/wiki/Surrogate_key –

2

Simplemente envíe las claves principales. Siempre que las operaciones de su base de datos estén selladas desde la interfaz del usuario, esto no es un problema.

1

Para sus propósitos (crear un motor de búsqueda), los beneficios de las ventajas de seguridad de cifrar las claves primarias de la base de datos son insignificantes. La codificación de Base64 no es cifrado, es la seguridad a través de la oscuridad y ni siquiera será una aceleración rápida para un atacante.

2

Si está oscureciendo las claves principales por un motivo de seguridad, no lo haga. Eso se llama seguridad por oscuridad y hay una mejor manera. Una vez dicho esto, hay al menos un motivo válido para ocultar claves principales y eso es para evitar que alguien rastree todo su contenido simplemente examinando una cadena de consulta en una URL y determinando que simplemente pueden incrementar el valor de una identificación y desplegar cada registro. Un raspador determinado aún puede descubrir sus medios de oscurecimiento y hacer esto a pesar de sus mejores esfuerzos, pero al menos no lo ha hecho fácil.

3

Si le preocupa que alguien modifique la URL para tratar de ver otros valores, entonces quizás deba considerar la generación de tokens.

Por ejemplo, en lugar de dar al usuario un valor de 'SearchID', les da un SearchToken, que es un largo y único valor psuedo-aleatorio (Read: GUID), que luego se asigna al SearchID internamente.

Por supuesto, también deberá aplicar seguridad de sesión y aún así, ya que incluso una URL única con una ID no secuencial no está protegida contra el rastreo entre su servidor y el usuario.

1

Si está intentando proteger la entrada de consulta de la base de datos solo use consultas parametrizadas. No hay ninguna razón para ocultar claves primarias si son manipuladas por el público.

Cuando ve base64 en la URL, se garantiza que los desarrolladores de ese sitio no saben lo que hacen y que el sitio es vulnerable.

7

Sobre los peligros de exponer su llave principal, querrá leer "autoincrement considered harmful", por Joshua Schachter.

URLs que incluyen un identificador le fallan por tres razones.

La primera es que, dada la dirección URL para algún objeto, se puede averiguar las direcciones URL para los objetos que se crearon alrededor de ella. Esto expone el número de objetos en su base de datos para posibles competidores u otras personas que tal vez no quieren tener esta información (como famoso demostrado por los aliados adivinar los niveles de producción de tanques alemanes examinado los números de serie.)

En segundo lugar, en algún punto un idiota tendrá la idea de escribir un script de shell con un for-loop e intentar buscar cada objeto de su sistema; esto definitivamente no es divertido.

Finalmente, en el caso de los usuarios, permite a las personas obtener algún tipo de jerarquía social . Sea testigo del frecuente secuestro y/o pirateo de de identificaciones ICQ de bajo-dígito de alto prestigio.

+0

Entonces, ¿qué deberíamos hacer? Deje la identificación en la cadena de consulta pero encriptada o use el método POST? ¿O algo más? – Ascendant

1

URL que incluyen un identificador se le dejó abajo por tres razones.

Mal, mal, mal.

Primero: todas las solicitudes deben validarse, independientemente de si se trata de un HTTP GET con una identificación, un POST o una llamada de servicio web.

Segundo: un sitio web hecho correctamente necesita protección contra bots que se basa en el seguimiento de direcciones IP y solicita análisis de frecuencia; ocultar identificadores puede evitar que algunas personas escriban un script de shell para obtener una secuencia de objetos, pero hay otras maneras de explotar un sitio web mediante el uso de un ataque de fuerza bruta de algún tipo.

Tercera: los identificadores de ICQ son valiosos, pero solo porque están relacionados con los usuarios y son los principales medios de identificación del usuario; es un enfoque único para la autenticación de usuarios, no utilizado por ningún otro servicio, programa o sitio web.

Por lo tanto, para concluir ... Sí, debe preocuparse por los rascadores y los ataques DDOS, la protección de datos y un montón de cosas más, pero ocultar identificaciones no resolverá correctamente ninguno de esos problemas.

+2

Brute forzando una clave primaria expuesta, donde un atacante ve valores obviamente secuenciales en uso (como 32110, 32111, 32112) va a ser factible, mientras que la fuerza bruta, por ejemplo, un hash de 64 bits de una ID va a ser intratable. Y tenga en cuenta que el problema del tanque alemán permite a los atacantes obtener información sobre sus sistemas internos solo con ver los ID: en realidad no necesitan solicitar ninguna información, la existencia de los mismos valores de ID les permite inferir cosas como el número de usuarios y tasa de crecimiento No necesitan fuerza bruta para nada. –

0

Cuando necesito un parámetro de cadena de consulta para poder identificar una sola fila en una columna, normalmente agrego una columna GUID a esa tabla y paso el GUID en la cadena de conexión en lugar del valor de la clave primaria.

Cuestiones relacionadas