¿El uso de GUID para las ID hace que las ID sean impredecibles?

Supongamos que está utilizando técnicas de tokenización / cifrado suficientes para cumplir con las PCI DSS.

No, estamos ante un problema abstracto en el que alguien puede predecir un valor. El factor de riesgo es que si el valor se puede adivinar o sigue un patrón conocido, se podría eliminar a voluntad.

La cuestión del GUID es irrelevante, porque el vector de ataque sigue siendo un ataque de fuerza bruta. Si bien conocer el patrón o los algoritmos utilizados para crear su identificación única puede ciertamente ayudar a reducir las posibilidades de un ataque más limitado del diccionario, el conocimiento de las identificaciones con anticipación no es necesario para eliminar registros de manera indiscriminada.

Usted aborda el problema implementando controles adicionales. Primero, si esto está en una base de datos, tiene suficientes registros y transacciones en su lugar.

En el camino para realizar la eliminación, debe haber controles adicionales en su lugar. Comencemos por el lado del usuario: si el registro está asociado con el usuario, solo el usuario debe tener la capacidad de eliminar sus propios registros. Si el usuario no está autenticado o no posee los registros, no permita que el proceso de eliminación continúe. ¿El usuario necesita proporcionar una autorización especial? ¿Hay otra variable establecida en la base de datos o en una sesión para permitir la eliminación (por ejemplo, deben autorizar antes de que se lleve a cabo la acción?) Si existe un riesgo suficiente, puede implementar una confirmación fuera de banda, como el envío de una Mensaje SMS o tal vez una confirmación por correo electrónico es aceptable. En este escenario, es probable que exista un riesgo bajo si un usuario borra a sabiendas sus propios registros de tarjetas de crédito porque puede ingresarlos nuevamente más tarde.

Si tiene controles sólidos de autenticación, autorización y transacción, limitará la capacidad de eliminar valores de forma indiscriminada, incluso si se conocen.

Como precaución adicional, es posible que desee implementar algoritmos de detección de ataques y heurísticas. Por ejemplo, limite el número de eliminaciones de la misma dirección IP por día. Revertir transacciones si hay demasiadas eliminaciones en un día dado considerando patrones de eliminación normales, etc.

Suena a partir de su descripción que se está ejecutando un sencillo comando POST. Me aseguraría de que esto solo suceda si hay TLS / SSL, el usuario está autenticado, hay un token CSRF en la solicitud, etc. Me aseguraría de que todos Las eliminaciones se registran y se pueden revertir. Ya que la eliminación no resultaría en una exposición, también puede confiar en una notificación posterior a la acción a los usuarios, "Confirmamos que eliminó su tarjeta de crédito registrada. Si no lo hizo, comuníquese con nosotros inmediatamente", etc. / p>     

Un GUID es una secuencia de 128 bits, que sigue un formato específico y reglas de generación que tienen como objetivo garantizar singularidad . Esto no es lo mismo que imprevisibilidad . Entre los 5 métodos de generación estándar (llamados "versiones"), solo la versión 4 puede decir que es impredecible, y solo en la medida en que usa un PRNG criptográficamente seguro ; bajo estas condiciones, obtiene 122 bits aleatorios, lo cual es suficiente para la mayoría de los propósitos que requieren imprevisibilidad.

Por lo tanto, el método exacto que usa para producir su GUID es muy importante.

Parece que el riesgo del que estás hablando es lo que comúnmente se conoce como falsificación de solicitudes entre sitios ( "CSRF"). Existen mecanismos comunes y bien probados para abordar esta clase de vulnerabilidad y, a menudo, incluso las bibliotecas prefabricadas que puede incluir en su código (¡y muchos marcos tienen la protección CSRF incorporada!).

Una vez que haya agregado la protección CSRF a su aplicación, no importa la ID que haya asociado con el registro; Usted podría simplemente numerarlos secuencialmente como lo hacemos el resto de nosotros.

Además, tenga en cuenta que si bien ha notado la posible vulnerabilidad en esta página en particular, es probable que haya docenas de otras ubicaciones en su código donde se aplican las mismas advertencias. Lo mejor es tratarlos todos de una vez con una única solución compartida que intentar limpiar cada formulario individualmente.

Y para responder a su pregunta original: no . Los GUID son solo un formato para identificadores presumiblemente únicos. De dónde viene esa identificación depende de la implementación. Existen varios mecanismos diferentes de uso común para generar nuevos GUID, algunos de ellos son predecibles y otros menos. Pero por lo general no son números aleatorios con sonido criptográfico.

No, por favor no hagas esto !! Si su asignación aleatoria se basa en un factor predecible como el tiempo (es decir, pseudoaleatorio), o si existe algún otro tipo de error / fuga de información que permita que se pueda resolver. En su lugar, asegúrese de que el usuario autorizado esté autenticado antes de permitir que se ejecuten dichas consultas.

O mejor aún, no almacene las tarjetas de crédito usted mismo, confíe en un tercero como PayPal para realizar dicho procesamiento financiero en su nombre.