Did I “hack” a major online website. You could call it that. If using the browser’s built-in developer tools to change an element id so that I could submit my order… well, then, yes. I “hacked” the site so I could buy something….
“Refresh your cache” and other tall tales
I was helping someone I know sign up for a service through a major online website. The process was, well, long, as there were several different options and a number of hoops to jump through. However, upon getting to the page where they could accept their agreements and submit the order, the site blocked us.
The problem was pretty evident to me: there were 6 different checkboxes that were required to accept various terms, conditions, and agreements. Two of those checkbox elements had the same text. When I clicked on the second of the two matching checkboxes, it selected (or unselected) the first instance, and not the second. I hit F12 and looked at the HTML source. Sure enough, those two instances shared the same name and id attribute values.
In an effort to be a good citizen, I reached out through the chat window to see if they could resolve this problem on their side. There answers were “Delete your cache,” “close and reopen your browser,” and, my favorite, “restart the entire process.” At this point in the day, I had to leave the house, so I figured I would try again later.
Second Attempt
For my second attempt, I used the private browsing mode, which should alleviate cookies and other cache values. I went through the process again, and the same issue presented it self on the submit screen.
Technical Support tried to get me to go to the Sales department, but it was after hours, and I was getting a little frustrated. So I opened the Developer Tools in the browser and examined the checkbox elements.
This is where things got weird. It turns out, for the name and id attributes, they were using the actual page text value for those. I’ve NEVER seen a site which uses the user text to populate the id attribute. That generally seems like bad practice. But, what do I know? The best part is, the developer tools window gave me a warning because there were two checkboxes with the same aria and label values.
My “Hack”
Since I couldn’t check the second instance of the duplicate, the submit button was not enabled. My “hack” was to use the developer tools to modify the name and id values to be unique, which I did by just adding an extra space somewhere in the value. Once I did that, I was able to check the second checkbox, which then enabled the Submit button, and I was able to proceed in placing the order.
Let me be VERY clear: I modified the client HTML so that I was able to accept all the terms of the service being ordered, and then submitted said order. There was no malicious activity: I got nothing for free (no additional services or deals) and the same action would have been undertaken by picking up the phone and calling a salesperson.
With this in mind, I will be reporting this to the vendor so that they may correct their software.
Validate your input!!!
For all the web developers out there: validate your client input. The rise of Single Page Applications (SPAs) that run in Javascript on the client have blinded us to the need to handle all incoming data as if it could be different than what we expect. We just assume the user will click through what we give them. But the F12 Developer Tools built in to modern browsers give everyone the ability to change the HTML on your page. Sure, I did it so I could submit my order without talking to a human being. But malicious actors could use that functionality for far more nefarious purposes.
Leave a Reply