The request can be submitted only by the one who paid. An attacker can simply enter parameters in the browser (eg in the address bar) and the request will be processed. Only one idea comes to mind. After payment to the phone (or email), send a confirmation key that the handler will wait for. And where are these keys stored? in the database? and will not the thief get access there?

Advise, maybe there are some ready-made solutions? Thank.

  • What are your perpetrators? use ssl yes? and this ... paranoia is good only when it is schizoid, just paranoia leads to the death of the individual. - zb '

2 answers 2

As I understand it, the user pays asynchronously (confirmation of payment can come immediately and in a day or two), and gets access to the service — it can execute requests many times.

In this case, user authorization is needed: login / password, and optionally a cookie, in order not to log in every time. In the database, store the table of accounts: status (paid?), Subscription expiration date (they did not buy themselves access forever), ip from which they came. When changing the address, you can ask to re-login if the application is not for mobile phones. And only through https work, of course.

Without registration, it is also possible, if you become attached to cookies and ip. The link in the letter "thanks for payment, here is your link" leads to a script that

  1. remembers this visit: date, ip, user-agent;
  2. puts a cookie, on which you can then enjoy the rights of this user.

Once again, everything is https only.

At other times, the user goes directly to the site that checks this cookie, compares it with the user-agent and, maybe, also the IP, and if everything is ok, it serves.

If not ok - you need to follow the link in that letter again and stamp yourself with a cookie.

And once again: everything is only on https !

  • I will probably even easier. The user does not need to login and I don’t have to (I think) remember cookies. 2 functions: 1. Submit an ad 2. Extend an ad (it doesn't matter to me who renews it if it is paid for) Use your scheme anyway? - Radik Kamalov

1) add an additional, hidden field to the form, for example, a hash from the transmitted data, with id in the database, and process only the data with which this hash is correct.

2) if you send the key, then again, it is better to keep in the database, or form it depending on the known parameters that are already in the database, for example, payment time, id, etc.

but in general, you can search for a CSRF (Cross-site request forgery) account

  • on the first. Isn’t the attacker able to see this hash and also send it? - Radik Kamalov
  • one
    Radik hash - in php, for example, the session number in the cookie lies, the session data on the server - the intentional person does not see them, and the client has a token, even if the client intends evil, he cannot do anything but "I am I." - what he paid is determined by authorization in one form or another. And ssl saves traffic from wiretapping, and ssl saves from dude-in-the-middle signed by one of the trusted offices ($ 30 it seems it costs if not 10) - zb '15
  • those. The first method involves the registration-authorization? "and what he paid is determined by authorization in one form or another." create a personal account? - Radik Kamalov