As a web application user, there are a few ways to protect yourselves from XSS attacks.
The first and the most effective solution is to disable all scripting language support in your browser and email reader.
Another recommendation is to use reasonable caution while clicking links in anonymous e-mails and dubious web pages.
Proxy servers can help filter out malicious scripting in HTML. If the application accepts only expected input, then the XSS can be significantly reduced. Web servers should set the character set, and then make sure that the data they insert is free from byte sequences that are special in the specified encoding. This can typically be done by settings in the application server or web server. The server should define the character set in each html page as below.
Web pages with unspecified character-encoding work mostly because most character sets assign the same characters to byte values below 128. Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<. These should be checked.
The above tells the browser what character set should be used to properly display the page. In addition, most servers must also be configured to tell the browser what character set to use when submitting form data back to the server and what character set the server application should use internally. The configuration of each server for character set control is different, but is very important in understanding the process of converting data that has more than one possible representation into a "standard" canonical representation of input data. Filtering special meta characters is also important. HTML defines certain characters as "special", if they have an effect on page formatting.
(HTML body)
"<" introduces a tag.
"&" introduces a character entity.
Some browsers try to correct poorly formatted HTML and treat ">" as if it were "<".
In attributes:
double quotes mark the end of the attribute value.
single quotes mark the end of the attribute value.
"&" introduces a character entity.
(URLs)
Space, tab, and new line denote the end of the URL.
"&" denotes a character entity or separates query string parameters.
Non-ASCII characters (that is, everything above 128 in the ISO-8859-1 encoding) are not allowed in URLs.
The "%" must be filtered from input anywhere parameters encoded with HTTP escape sequences are decoded by server-side code.
Ensuring correct encoding of dynamic output can prevent malicious scripts from being passed to the user. While this is no guarantee of prevention, it can help contain the problem in certain circumstances. The application can make an explicit decision to encode un-trusted data and leave trusted data untouched, thus preserving mark-up content.
The first and the most effective solution is to disable all scripting language support in your browser and email reader.
Another recommendation is to use reasonable caution while clicking links in anonymous e-mails and dubious web pages.
Proxy servers can help filter out malicious scripting in HTML. If the application accepts only expected input, then the XSS can be significantly reduced. Web servers should set the character set, and then make sure that the data they insert is free from byte sequences that are special in the specified encoding. This can typically be done by settings in the application server or web server. The server should define the character set in each html page as below.
Web pages with unspecified character-encoding work mostly because most character sets assign the same characters to byte values below 128. Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<. These should be checked.
The above tells the browser what character set should be used to properly display the page. In addition, most servers must also be configured to tell the browser what character set to use when submitting form data back to the server and what character set the server application should use internally. The configuration of each server for character set control is different, but is very important in understanding the process of converting data that has more than one possible representation into a "standard" canonical representation of input data. Filtering special meta characters is also important. HTML defines certain characters as "special", if they have an effect on page formatting.
(HTML body)
"<" introduces a tag.
"&" introduces a character entity.
Some browsers try to correct poorly formatted HTML and treat ">" as if it were "<".
In attributes:
double quotes mark the end of the attribute value.
single quotes mark the end of the attribute value.
"&" introduces a character entity.
(URLs)
Space, tab, and new line denote the end of the URL.
"&" denotes a character entity or separates query string parameters.
Non-ASCII characters (that is, everything above 128 in the ISO-8859-1 encoding) are not allowed in URLs.
The "%" must be filtered from input anywhere parameters encoded with HTTP escape sequences are decoded by server-side code.
Ensuring correct encoding of dynamic output can prevent malicious scripts from being passed to the user. While this is no guarantee of prevention, it can help contain the problem in certain circumstances. The application can make an explicit decision to encode un-trusted data and leave trusted data untouched, thus preserving mark-up content.
