A3 Cross-Site Scripting
Cross-site scripting flaws can be difficult to identify and remove from a web application. The best practice to search for flaws is to perform an intense code review and search for all places where user input through a HTTP request could possibly make its way into the HTML output.
Code reviewer needs to closely review.
1. That untrusted data is not transmitted in the same HTTP responses as HTML or JavaScript.
2. When data is transmitted from the server to the client, untrusted data must be properly encoded in JSON format and the HTTP response MUST have a Content-Type of application/json. Do not assume data from the server is safe. Best practice is to always check data.
3. When introduced into the DOM, untrusted data MUST be introduced using one of the following APIs: a. Node.textContent b. document.createTextNode c. Element.setAttribute (second parameter only) Code reviewer should also be aware of the HTML tags (such as <img src..> <iframe...> <bgsound src ...>) that can be used to transmit malicious JavaScript.
In Asp.net Use Microsft’s Anti-XSS library
.NET ASPX
1. On ASPX .Net pages code review should check to make sure web config file does not turn off page validation.
2. .Net framework 4.0 does not allow page validation to be turned off. Hence if the programmer wants to turn off page validation the developer will need to regress back to 2.0 validation mode.
3. Code reviewer needs to make sure page validation is never turned off on anywhere and if it is understand why and the risks it opens the organization to.
PHP
There are two scenarios when it comes to XSS, each one to be mitigated accordingly
If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.
Instead of this, you should use a template engine that applies HTML escaping by default
• Don't have a trusted section in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.
• HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)
• The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.
• Not every PHP installation has a working mhash extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256
• Not every PHP installation has a working mcrypt extension, and without it you can't do AES. Do check if you need it.
Note: These are Highlighted Points from Owasp Secure code Review Guide.
Cross-site scripting flaws can be difficult to identify and remove from a web application. The best practice to search for flaws is to perform an intense code review and search for all places where user input through a HTTP request could possibly make its way into the HTML output.
Code reviewer needs to closely review.
1. That untrusted data is not transmitted in the same HTTP responses as HTML or JavaScript.
2. When data is transmitted from the server to the client, untrusted data must be properly encoded in JSON format and the HTTP response MUST have a Content-Type of application/json. Do not assume data from the server is safe. Best practice is to always check data.
3. When introduced into the DOM, untrusted data MUST be introduced using one of the following APIs: a. Node.textContent b. document.createTextNode c. Element.setAttribute (second parameter only) Code reviewer should also be aware of the HTML tags (such as <img src..> <iframe...> <bgsound src ...>) that can be used to transmit malicious JavaScript.
In Asp.net Use Microsft’s Anti-XSS library
.NET ASPX
1. On ASPX .Net pages code review should check to make sure web config file does not turn off page validation.
2. .Net framework 4.0 does not allow page validation to be turned off. Hence if the programmer wants to turn off page validation the developer will need to regress back to 2.0 validation mode.
3. Code reviewer needs to make sure page validation is never turned off on anywhere and if it is understand why and the risks it opens the organization to.
PHP
There are two scenarios when it comes to XSS, each one to be mitigated accordingly
If you are using standard PHP for templating, or `echo` etc., then you can mitigate XSS in this case by applying 'htmlspecialchars' to the data, or the following function (which is essentially a more convenient wrapper around 'htmlspecialchars'). However, this is not recommended. The problem is that you have to remember to apply it every time, and if you forget once, you have an XSS vulnerability. Methodologies that are insecure by default must be treated as insecure.
Instead of this, you should use a template engine that applies HTML escaping by default
• Don't have a trusted section in any web application. Many developers tend to leave admin areas out of XSS mitigation, but most intruders are interested in admin cookies and XSS. Remove every instance of echo, print, and printf from your application and replace them with a secure template engine.
• HTTP-Only cookies are a very good practice, for a near future when every browser is compatible. Start using them now. (See PHP.ini configuration for best practice)
• The function declared above, only works for valid HTML syntax. If you put your Element Attributes without quotation, you're doomed. Go for valid HTML.
• Not every PHP installation has a working mhash extension, so if you need to do hashing, check it before using it. Otherwise you can't do SHA-256
• Not every PHP installation has a working mcrypt extension, and without it you can't do AES. Do check if you need it.
Note: These are Highlighted Points from Owasp Secure code Review Guide.
