Exponer sus claves principales (especialmente si son predecibles) es una vulnerabilidad llamada Referencia de objeto directo inseguro.
Al tener una URL (o cualquier otro parámetro proporcionado por el cliente) como esta:
http://www.domain.com/myaccount?userid=12
Le da a sus usuarios finales la oportunidad de jugar con esas variables y pasar los datos que deseen. La contramedida para mitigar esta vulnerabilidad es crear referencias indirectas a objetos en su lugar. Esto puede sonar como un gran cambio, pero no necesariamente tiene que serlo. No tiene que ir y volver a teclear todas sus tablas ni nada, puede hacerlo simplemente siendo inteligente con sus datos mediante el uso de un mapa de referencia indirecta.
Considere esto:tiene un usuario que está realizando una compra en su sitio. Y cuando llega el momento de pagar, se les presenta un menú desplegable con los números de tarjeta de crédito que usted tiene "archivados". Si observa el código del menú desplegable, verá que los números de tarjeta de crédito están asociados con las claves 8055, 9044 y 10099.
El usuario podría ver esto y pensar que se parecen mucho a las claves primarias de incremento automático (el usuario probablemente tenga razón). Así que empieza a probar otras llaves para ver si puede pagar con la tarjeta de otra persona.
Ahora, técnicamente, debe tener un código en el lado del servidor que asegure que la tarjeta seleccionada sea parte de la cuenta del usuario y que pueda usarla. Este es un ejemplo artificial. Por ahora asumiremos que este no es el caso o que este es otro tipo de formulario que quizás no tenga ese tipo de control del lado del servidor.
Entonces, ¿cómo evitamos que el usuario final elija una clave que no debería estar disponible para él?
En lugar de mostrarles una referencia directa al registro en la base de datos, bríndeles una referencia indirecta.
En lugar de colocar las claves DB en el menú desplegable, crearemos una matriz en el servidor y la incluiremos en la sesión del usuario.
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
En el menú desplegable ahora proporcionamos la referencia al índice de la matriz donde se almacena la tarjeta. Entonces, en lugar de ver las claves reales, el usuario final verá los valores 0, 1 y 2, si ven la fuente.
Cuando se envía el formulario, uno de esos valores se transmitirá. Luego sacamos la matriz de la sesión del usuario y usamos el índice para obtener el valor. La clave real nunca ha salido del servidor.
Y el usuario puede pasar diferentes valores durante todo el día si lo desea, pero nunca, jamás, obtendrá un resultado que no sea el de sus propias tarjetas, independientemente del control de acceso del lado del servidor que esté implementado.
Sin embargo, tenga en cuenta que al usar el índice pasado para obtener el valor, si el usuario se mete con él, podría obtener algunas excepciones (ArrayOutOfBounds, InvalidIndex, lo que sea). Así que envuelva esas cosas en un intento/captura para que pueda suprimir esos errores y registrar las fallas para buscar intentos de descifrado.
Espero que esto ayude.
Para leer más acerca de las referencias de objetos directos inseguros, consulte OWASP Top 10. Es el número de riesgo A4. https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
