Fighting Code Injection
Seems like I’ve been reading a lot about code injection vulnerabilities on Web sites. Of course, we all know about the Paris Hilton fiasco where a hacker was able to access her photos via the T-Mobile Web site. So for the sake of conversation, here’s what I do to prevent code injection:
- Double Validation – validate data input on the client side using JavaScript as well as on the server side. The server side validation is necessary in case the user turns off JavaScript.
- Referrer Checking – any page or process that accepts input from an HTML form should check its referrer to be sure it is receiving data from a trusted source. In some cases, it’s simple enough just to ensure it’s from the same domain; in others, you may want to be sure it comes from a particular page.
- Verify GET or POST – some languages, such as JSP, use a single method to get data regardless of the method used to submit it (
request.getParameter()
). If you know the data should be submitted using a POST, make sure that’s where it came from when processing it. - Remove HTML Tags by Default – there’s no reason to not strip HTML tags from input by default. Most of the time, there’s no need for it. It is only special cases (such as e-mails or message board postings) where HTML may need to be allowed.
- Never Echo – this is the golden rule to avoid code injection. Never take an input value and output it directly to a Web page. You should always “scrub” the data (validate, strip HTML, etc.) before using it in output.
In general, I’ve found that these approaches take care of a lot of code injection vulnerabilities. If anyone has any other ideas, please feel free to add them.