I've been reading up a little on XSS. From what I can tell, you could only get stung by this if you don't clean and convert input and output. Is this correct?
From what I can see, so long as you:
- Convert special characters to HTML entities (E.g. PHP's htmlspecialchars()) when you output if it's not HTML
- Make your cookies are HTTP only
To me, this is all just good practice anyway. And the third point should not strictly be required if you have implemented the first two points correctly.
Is it that simple or am I missing something?
It's that simple. Ironically, the most common vulnerabilities are also the easiest to prevent.
Three simple rules:
validate all inputs before you move them from the tainted source they were supplied through. This is worth doing even without any concern about security - there is no point in even attempting to process fields that do not contain something that is valid for what the field is there for.
Keep data and code separate where ever possible. Many forms of attack rely on being able to trick your code into seeing a part of their data as code and running it. If the data is kept separate then that confusion can't happen. For example when accessing mySQL databases use a prepare statement for the SQL code and a bind statement for the data instead of jumbling them together in a query statement.
Where it is not possible to keep the data and code separate then escape any data that might be confused for code - you need to do this anyway in order for the data to be processed correctly even without worrying about security - the one spot in web processing where escaping is most needed is with data to be displayed in the web page where characters such as < and & need to be escaped so that they display correctly and are not confused for part of the HTML of the page.
Both step 1 and step 3 are things that you should be doing anyway even if there were no security concerns whatsoever as without them your code will not work properly. Step 2 is also worth doing because it removes the possibility of many potential errors. With none of these is security the main reason for doing it that way - that the code ends up secure is merely a side effect of having followd good programming practice in the first place.
With properly written code 99.999%+ of all the potential security holes have been removed before you get to the point of looking at your code from a security viewpoint.
The only security issues that I have ever experienced with any web site that I have been involved with is where the code is split across multiple files and one of the files doesn't get updated when the others do with the mismatch in code versions resulting in a security hole - easily fixed by uploading the correct version of the files.
This topic is now closed. New replies are no longer allowed.