Fun With Billing Forms and International Debit Cards

by musashi42

Disclaimer: All of the below is for educational purposes and to help when it comes to online payments (of digital goods/bills) which, due to silly formalities, can't be processed if you have a debit card without a U.S. billing address.

The important thing to know when it comes to website-related hacking is how the sites work and the code behind them (which goes for everything).

Knowing PHP and MySQL made this quite an interesting thought experiment mixed with the practical approach.

It was more of a traditional meaning of the word (i.e., forcing a system to do what it's not supposed to do).  I wouldn't have discovered this if I had a debit card that had a U.S.-based billing address (and a lot of money), but I had the one that doesn't and I really didn't want to lose cash on withdrawing the money from the ATM in order to pay my bill and, sadly, the payment form's billing area doesn't have the country drop-down, so I had to think back to my own coding of forms, databases, and tables to see if there was a way around it.

This is where the true insane fun begins.

The typical online payment form consists of the following fields: Card Number, Expiration Details, and Name/CVV.

Then there's the address listed and checked with a radio button that matches the address where the service is installed, but next to it there's an option to enter a different address.  The different address has the usual fields and none of them have a drop-down button.

So, I simply assumed that certain fields weren't being validated (years of having fun and sometimes profiting from XSS discovery/fixing taught me a lot about what fields are less likely to be validated) and the most obvious field in this case was the address field because there are so many addresses (and it was a very lame looking website system, which is odd considering they are a pretty huge and very hated company) that it allowed for entering anything as a billing address in order to match with the billing address listed on my debit card's issuer website (and it can't be edited there, hence why I have to go through these hoops).

I've also learned from this exercise that my debit card's issuer isn't taking State and Country fields into consideration when it comes to validating the billing details.

There are additional requirement for this to work and this is rather simple when it comes to the United States.

It involves finding a state in the U.S. which has the city with the same name as the city from whatever country you are from.  Basically: Paris, France equals Paris, Texas; London, U.K. equals London, MI; Berlin, Germany equals Berlin, OH, and so on - you get the picture.

The ZIP Code on this particular website's online payment system was also lacking validation (I wasn't sure if my debit card's issuer would proceed with the payment if it didn't have a matching ZIP Code, but I didn't test it further in order to avoid them noticing that someone was messing around).

I tried the same technique for another website (also involving paying the bill) and that website didn't accept the address.  But then again, if a GPS device has a database of all of the addresses, or at least most of the addresses, then why wouldn't the same go for the website in question, especially one whose owner/company is extremely rich and equally hated (yes, I'm paying hard earned money to two hated companies - oh well).

I didn't try any reflective XSS attacks because, well, it might have ended up as a stored one and I don't want to shit where I eat, so to speak (and they don't have bug bounty), and considering that they still get the money, I can't classify the billing exploit as a bad thing.

However, I'll probably try this technique on other websites where they are asking for the United States-based address when I want to buy a digital product and avoid losing money by buying a gift debit card.