Why Input Sanitization is Important

Near the beginning of 2015, I stumbled upon a possible vulnerability in the sign in section of a popular domain name registrar. This service offers free domain names in registration intervals from one to twelve months, and can be renewed for a fee. I have no confirmation of the vulnerability in question, as I was not very interested in security at the time, and thus thought nothing of it aside from my password not working; the registrar simply fixed the issue after, looking back now, a startlingly short turnaround time of 2 months, and responded to my password inquiry telling me the password would now work. So kudos to them for the quick resolution!



As some of you may be aware, there is a password that I use (for testing only now) which contains a single apostrophe. This is not an issue for the majority of web applications which properly sanitize user input, however based solely on the incorrect login errors, and the amount of time that it took them to respond to my issue, I can only assume one of two things: someone didn’t implement sanitization, or their database rows simply weren’t long enough for a 12 character password and it cut me off. Which it is for certain, I may never know.

What if?

As I mentioned earlier, I was not very into security at the time, so the thought of exploring further to see if there was an exploitable vector, or writing a PoC never even crossed my mind; but what if it had? Though I am sure that most reading this are fully aware of the implications of improper input controls, let’s dive down the rabbit hole a bit and see what sort of goodies may await.

Threat Model

Login: Assuming I have a password that I know will not function, enumerating valid domains and email addresses through this service would have been trivial.

Backend: If this can be used to leverage SQLi, we can easily view information about other domains/owners, take control of or completely destroy the requesting database in question. Can of course be used to leverage full on RCE and RFI.

Either of these instances could have spelled a million-dollar or more disaster for the registrar in question, and I’m glad they were able to resolve it before a malicious actor noticed.

Conclusion

While the registrar mentioned in this post has long since fixed the issue I’ve written about, it is important to take note of how disastrous the situation could have been and for developers and engineers to audit all code before it is pushed to ensure proper input sanitization, as well as other basic security principles.