Diseño y seguridad de API: ¿por qué ocultar identificadores internos?

Question

He oído a algunas personas decir que nunca debe exponer sus identificaciones internas al mundo exterior (por ejemplo, una clave primaria autoincremento).

Algunos sugieren tener algún tipo de columna uuid que utilice en su lugar para las búsquedas.

Me pregunto realmente por qué esto sería sugerido y si es realmente importante.

Usar un uuid es básicamente ofuscar la identificación. ¿Cuál es el punto de? Lo único que se me ocurre es que los números enteros de autoincremento obviamente señalan el orden de mis objetos db. ¿Importa si un usuario externo sabe que una cosa se creó antes/después de otra?

¿O es puramente que ofuscar los identificadores evitaría "adivinar" diferentes operaciones en objetos específicos?

¿Es esto un problema que debería tener en cuenta al diseñar una API externa?

Answer 1

Cualquier información que proporcione a un usuario malintencionado sobre su aplicación y su diseño puede y será utilizada en contra de su aplicación. Uno de los problemas que enfrentamos en la seguridad de las aplicaciones (web) es que las decisiones de diseño aparentemente inocuas tomadas en la infancia de un proyecto se convierten en talones de Aquiles cuando el proyecto se agranda. Dejando un conjeturas atacante tomar decisiones informadas sobre el ordenamiento de las entidades puede volver en tu contra en lo que sigue, formas un tanto sin relación:

1. El ID de la entidad será inevitablemente pasa como un parámetro en algún momento de su aplicación . Esto dará lugar a que los hackers eventualmente puedan alimentar los argumentos de su aplicación a los que normalmente no deberían tener acceso. Personalmente, pude ver los detalles del pedido (en un sitio de un minorista muy popular) que no tuve que ver en mi empresa, como un argumento de URL no menos. Simplemente alimenté los números secuenciales de la aplicación de mi propia orden legítima.

2. Conocer los límites o, al menos, la progresión de los valores de campo de la clave primaria es un forraje inestimable para los ataques de inyección SQL, cuyo alcance no puedo abarcar aquí.

3. Los valores clave se utilizan no solo en los sistemas RDBMS, sino también en otros sistemas de asignación de valores-clave. Imagine si el orden de las cookies JSESSION_ID podría predeterminarse o adivinarse. Todo el mundo con pulgares oponibles reproducirá sesiones en aplicaciones web.

Y muchos más que estoy seguro que otras personas aquí se le ocurrirán.

El equipo SEAL 6 no significa necesariamente que haya 6 equipos de sellos. Solo mantiene al enemigo adivinando. Y el tiempo dedicado a adivinar por un potencial atacante es más dinero en su bolsillo de cualquier forma que lo corte.

Answer 2

Al igual que con muchos problemas de seguridad, es una respuesta sutil: kolossus ofrece una buena visión general.

Ayuda a comprender cómo un atacante podría comprometer su API y cuántas violaciones de seguridad se producen.

La mayoría de las infracciones de seguridad son causadas por errores o descuidos, y los atacantes las buscan. Un atacante que está tratando de poner en peligro su API primero intentará recopilar información al respecto, ya que es una API, presumiblemente usted publica documentación de uso detallada.Un atacante utilizará este documento y probará muchas formas diferentes de hacer que su sitio se cuelgue (y por lo tanto exponga más información, si tiene suerte), o reaccionará de maneras que no anticipó.

Tienes que asumir que el atacante tiene mucho tiempo, y guionará su ataque para probar cada avenida, como un ladrón con tiempo infinito, que recorre tu casa probando cada puerta y ventana, con una cerradura que aprende de cada intento.

Por lo tanto, si su API expone un método como getUserInfo(userid), y el ID de usuario es un número entero, el atacante escribirá un script para iterar de 0 hacia arriba para averiguar cuántos usuarios tiene. Intentarán números negativos, y max(INT) + 1. Su aplicación podría perder información en todos esos casos y, si el desarrollador olvidó manejar ciertos errores, puede exponer más datos de los que esperaba.

Si su API incluye lógica para restringir el acceso a ciertos datos, p. Ej. puede ejecutar getUserInfo para los usuarios de su lista de amigos: el atacante puede tener suerte con algunos números debido a un error o un descuido, y sabrá que la información que está obteniendo se relaciona con un usuario válido, para que pueda construya un modelo de la forma en que su aplicación está diseñada. Es el equivalente a un ladrón sabiendo que todos sus cerrojos provienen de un solo fabricante, por lo que solo necesitan traer esa cerradura.

Por sí mismo, esto no puede ser una ventaja para el atacante, pero hace que su vida sea un poco más fácil.

Dado el esfuerzo de usar UUID u otro identificador sin sentido, es probable que valga la pena dificultar las cosas al atacante. No es la consideración más importante, por supuesto, probablemente no constituya las 5 mejores cosas que debes hacer para proteger tu API de los atacantes, pero ayuda.

Answer 3

Excelentes respuestas, voy a agregar otra razón de por qué no desea exponer su ID auto incrementado interno.
Como empresa competitiva, puedo instrumentar fácilmente cuántos nuevos usuarios/pedidos/etc. obtiene cada semana/día/hora. Solo necesito crear un usuario y/o pedido y restar el nuevo ID de lo que obtuve la última vez.
Así que no solo por razones de seguridad, también es por motivos comerciales.