Why doesn't Java have a built-in HTMLEncode function??
With security vulnerabilities like Cross-Site Scripting (XSS) luring around since so many years, I am wondering why hasn't Java yet come up with its own function for Encoding chars which are malicious.
Developers have to rely on either writing their own functions to encode characters to prevent XSS or use Open-Source libraries available to encode.
I believe 'Sun' ... sorry...'Oracle' should think of having this simple thing built-in.
What say folks?
Showing posts with label XSS. Show all posts
Showing posts with label XSS. Show all posts
Friday, August 28, 2009
Thursday, October 25, 2007
Mitigating XSS Attacks in ASP.NET Apps
Most of the security analyst must be finding it difficult to completely eradicate chances of Cross Site Scripting Attacks. As far as Microsoft ASP.NET platform goes, it does provide a directive called ValidateRequest to check for input containing malicious code.
This directive was present since .NET 1.1 version. However, I find several cases where the application team deviates from having this directive set to true for some business reasons. For eg. there is a rich text box in the web page which must allow any kind of input data. If ValidateRequest is configured for this web page or for the application as a whole, it will throw HttpRequestValidationException before the input is even processed by your code.
So we started recommending that you must use output validation i.e HTMLEncode all data echoed back on web page. You could also use the new Microsoft Anti-XSS library.
In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios. However, even with ValidateRequest turned on, it MUST not be regarded as a full proof solution to mitigate XSS.
Useful resources:
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
http://msdn2.microsoft.com/en-us/library/system.web.httprequestvalidationexception(vs.80).aspx
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
Cheers.
This directive was present since .NET 1.1 version. However, I find several cases where the application team deviates from having this directive set to true for some business reasons. For eg. there is a rich text box in the web page which must allow any kind of input data. If ValidateRequest is configured for this web page or for the application as a whole, it will throw HttpRequestValidationException before the input is even processed by your code.
So we started recommending that you must use output validation i.e HTMLEncode all data echoed back on web page. You could also use the new Microsoft Anti-XSS library.
In conclusion, ValidateRequest should be turned on if it does not block valid user scenarios. However, even with ValidateRequest turned on, it MUST not be regarded as a full proof solution to mitigate XSS.
Useful resources:
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
http://msdn2.microsoft.com/en-us/library/system.web.httprequestvalidationexception(vs.80).aspx
http://msdn2.microsoft.com/en-us/library/ms998274.aspx
Cheers.
Subscribe to:
Posts (Atom)