Web developers can easily make a wrong assumption in what they place their trust in. You create a web application and test it out to verify it works to spec. It only allows certain functionality, requires fields, and displays the results. The problem comes about when the developers rely on the browser to provide one of the walls to the app’s security. “I don’t need to worry about X because the browser does not allow X.” That might be the case now that the browsers you tested against don’t allow that functionality but what if they introduce it in the future? What if a less popular browser out there behaves differently and doesn’t enforce your constraints?
The option I will use in this article is actually quite popular in popular browsers like Google Chrome and Mozilla Firefox. The ‘inspect element’ feature can be very helpful when you are trying to figure out what HTML and CSS is causing an effect on your website. You can even edit for a live preview, for example, if you want to change the font size, text decoration, or padding of an element. This can open up a lot more variety when it’s not your website and you edit not just the CSS styling elements but the HTML content.
Real Life Example
I use a particular help desk software for its ticket functionality. It is completely free. You can have 1000 technicians (or more) and it is free. It follows the support/fremium model. They will make their money when you pay a subscription for support or if you pay for the add-on items. Despite the fact that it is free, you still need a license for the number of technicians that you will have signing into the software.
My license for 200 technicians was going to expire so I headed over to their web form to request a new license. The problem with the form is that the drop-down to specify the number of technicians is limited to 100 technicians.
With that limitation of the form, I headed to the support site and submitted a message requesting a license for 200 technicians and specified that the form only allowed up to 100 technicians. Helpful as always, Support got back to me with a rambling email that eventually directed me back to the same form I had just visited.
Rather than try to convince Support about their own product, I took matters into my own hands. I simply right-clicked on the Technician drop-down on the form and chose Inspect.
This opens the developer console and showed me the HTML and CSS behind the page’s rendering. This is similar to choosing ‘View page source’ but this allows me to tinker with the code as a live preview. I went through the code until I saw the ‘option’ drop-down code.
Once I found the code, I changed the value of one of the options in the drop down to 250. For kicks and giggles, I changed another line to Marshmallows with a value of Puppies. The value is the part that is actually submitted to the server, so I now had an option that would submit my request for a license of more than 100 technicians.
Once I made the change to the code, it was reflected in the actual webpage above. I visited the drop-down field and saw my new entries of ‘250’ and ‘marshmallows’. I filled out the rest of the form and chose 250 technicians. I submitted the form and I was provided with a download to a license for 250 technicians.
Conclusions
This is a pretty innocent use of the code but it demonstrates that this company could not rely on the browser to enforce their limitation of 100 technicians if they wanted to. Instead, the server would need to apply a little logic to the submission to see if a license should be generated. Just because you code limited options, it does not mean that the browser will honor your wishes.
In another example, I modified the headlines to completely rewrite history. Less innocently, someone might be able to exploit a server taking submissions into an SQL injection attack that will compromise the server, your data, or future visitors.
