These damn incremental identifiers

    As a programmer who participated in the development of payment systems, I have repeatedly had to analyze various payment services that store personal data of clients for vulnerabilities and I constantly encounter one very common problem. The name of this problem is incremental identifiers.

    Example No. 1.
    The site of the largest aggregator of payment methods in Russia, serves the leader in online games. After paying for the order, it redirects the client to the URL of the form aggregator-domain/ok.php?payment_id=123456, which in turn redirects to the online game website with the address of the form (decoded for readability) online-game-domain/shop/?...amount=32.86...¤cy=RUB...&user=user_email@gmail.com...&item_name=1 день премиум аккаунта...
    Going through the parameter values payment_id, we can see the logins of users in the online game, the purchases they made, their amount.



    Example No. 2.
    On one of the actively advertised online sites for issuing online loans after filling out a form with personal data, the result of the generated application was issued by a link of the form domain/confirmation?clientId=12345where, with a GET request, they returned, in addition to everything, name, address of residence, tax identification number.
    These data had to be transferred to the client to form an invoice for payment through the bank cash desk. But if we sort through the parameter values clientId, we received personal data of other clients.



    Example No. 3.
    Online banking of one of the largest banks in the country. When forming a regular payment, he was assigned an incremental identifier and by POST request to the address of the form domain/calendar_event.phpwith the parameterid=12345detailed information about the created regular payment was returned, including the name of the user, card numbers, payment amount, purpose, regularity. And again, when the id parameter was changed to a greater or lesser extent, we got access to the private information of other clients.



    Example No. 4.
    Pretty popular chat for sites. The account had settings, history of dialogs, administration of operators, etc.
    The session identifier looked like sessionID=”12345|6749476c44696255216a6148516d5e33”
    where the first part is the company identifier, the second is the user identifier.
    As a result, when changing the first identifier, we ended up in the admin panel of a completely alien company. Having gained access to the account, we had the opportunity to add operators and conduct dialogue with customers on behalf of the campaign.



    Conclusion:
    In the above examples, due to programmer errors, there was a potential for personal data leakage. This is a great price for the convenience of using an integer identifier.
    What to do? Use a token. An arbitrary string of even a small length will protect you from busting and mass theft of information. After all, you cannot protect yourself from programmer errors, and code that is built on the use of incremental identifiers will have to be constantly monitored by

    P.S.
    I agree with the comments and add from myself:
    The use of the token is suitable only as an additional level of security, full protection should be implemented in the application architecture through a system of rights and access.

    Also popular now: