Preventing Cross Site Scripting… Is it a myth!
I have been associated with understanding of cross site scripting for quite some time now. I have provided quite a few talks and presentation on this subject. Being a secure code reviewer, have found number of xss issues in the code. I have witnessed number of mistakes developers make. I would be interested in sharing some of my perspective about this attack. Since this is quite an old attack I would not be touching on its existence or trying to understand what XSS is! as there a quite a few blogs and sites available. Let’s focus on various prevention techniques and its feasibility. Understand the chosen prevention path is the right path or not.
Cross Site Scripting
XSS is an attack that involves breaking out of a data context and switching into a code context through the use of special characters that are significant in the interpreter being used.
What is data context and code context?
A data context is like
<div>data context</div>. If the attacker's data gets placed into the data context, they might break out like this
<div>data < script>alert("attack")</script> context</div>. Basically switching over to code context.If this basic criteria is understood. Prevention becomes lot easier.
XSS is quite an attack, even though pretty old, still lot of applications are vulnerable to this attack. No doubt it finds a second spot in OWASP top 10. It’s difficult to solve this attack as it’s more to do with the discipline attitude of the person who develops and flexibility from the business side. By discipline I mean by proper sanitization of data.
Challenges with Data-validation
Data validation is proposed common solution for cross site scripting. By data validation we mean filtering special characters from the client request at server side. While input validation is important and should always be performed, it is not a complete solution for injection attacks or cross site scripting. It's better to think of input validation as defense in depth rather than a primary defense. More over server side input validation may not be the right solution for DOM based XSS attacks which happen at the client side.
By Business I mean web applications, which needs special chars. Since special chars are business requirements for most of the web applications. Due to this requirement somehow the special chars finds its way into the application. There are lots of businesses who willingly take risk of allowing bad characters/special chars as some of the chars needs to be accommodated. To find a solution which meets the business needs as well as security needs has become evident.
So, what could be the solution?
A technique called “Escaping” looks promising in meeting business needs as well as security needs. By making escaping as primary defense and data validation as secondary defense an application could achieve a right blend of security for both the needs. By making escaping a primary defense the application can remain much more secure even if special chars are allowed during data validation phase. Escaping technique finds its way whenever untrusted data travels across the application.
What is Untrusted Data?
Untrusted data is input that can be manipulated to contain a web attack payload. Untrusted data is the data which comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. The Data that comes from databases, web services, and other sources are also considered as untrusted data.
Escaping is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter's parser.
Lets not confuse output escaping with the notion of Unicode character encoding, which involves mapping a Unicode character to a sequence of bits. This level of encoding is automatically decoded, and does not defuse attacks.
Escaping Technique simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.
Feasibility of Escaping Technique
Escaping the data could be the right way to go, as a primary defense to cross site scripting. As it takes care of the application from attack even if special chars are introduced. But with escaping as solution there is quite a few challenges. Escaping requires humongous addition to the code. Where ever untrusted data is found it should be escaped. There could be performance concern, which the business would definitely not want to compromise on. Developers discipline plays a major role here as ensuring escaping to all the untrusted data in an enterprise web application is quite a mammoth task. But with all this challenges escaping seems to be the right path for Cross site scripting.
(The Source of some of the above details is from: https://www.owasp.org)
Satish Govindappa is working as secure code reviewer in an organization. A developer turned code reviewer specialized in reviewing code of enterprise J2EE web applications. Satish holds a SCJP, CEH, ECSA certificates and pursuing MS in Cyber law and Cyber Security.