Programmers are lazy. Especially when it comes to protecting their program. Yesterday I came across a nice example of laziness.

Let’s say you buy an online service somewhere through paypal. Like for example a site which will submit your article to hundreds of other websites. But you have to pay each time you submit a new article.

How can you bypass this? Well first, you’ll have to pay for 1 article just to see how the system works and verifies purchases. So what I did was input my article in the form, pay with paypal and see how my article was being published on all the other websites.

In the background I had been logging all headers and responses with Live Http Headers. After I submitted the form, I was being redirected to a file called paypal.php which saves the article and redirects to paypal. In the post redirect to paypal the owner of the site naturally sends along an ID to the saved article so that when I paid it will know what my article is.

So I paid and was redirected to a page confirming my payment (/cgi-bin/paid.pl) with the following post parameters sent from paypal to the confirmation page:

So naturally, I captured this and tried the following:

Which the paid.pl gladly accepted and started with distributing my article.

So after that I tried inputting another article in the form, get redirected to paypal. I did not pay, but instead captured the Invoice ID and changed it in the postdata in the code below.

The mistake that paid.pl made was not using the paypal API to verify if the payment was in fact completed. Instead, it simply looked at one of the parameters, presumable payment_status and just assumed the payment was completed.

So modifying parameters and then sending them to a payment verification system might sometimes work if the programmer was too lazy to use the paypal API.

Ofcourse you could use FireFox’s Tamper data as well to do this kind of stuff.