On December 15, 2011 6:31 , Saeedahmed Subedar
<saeedahmed.sube...@birlasunlife.com> wrote:
I have a web application on Apache Http Server over SSL. Isn’t
application level cross-site scripting taken care of since requests
and responses are encrypted in SSL?
No. From https://www.owasp.org/index.php/XSS
Cross-Site Scripting attacks are a type of injection problem, in which
malicious scripts are injected into the otherwise benign and trusted
web sites. Cross-site scripting (XSS) attacks occur when an attacker
uses a web application to send malicious code, generally in the form
of a browser side script, to a different end user. [...] The end
user’s browser has no way to know that the script should not be
trusted, and will execute the script. Because it thinks the script
came from a trusted source, the malicious script can access any
cookies, session tokens, or other sensitive information retained by
your browser and used with that site.
As an example, let's say you are running a blog on your web server, and
that the blog fails to properly sanitize comments left by readers before
storing them in its database. A malicious user could then provide
JavaScript code in a comment they leave; this JavaScript would be run in
the web browser of any user who viewed the comment, performing some bad
action that is advantageous to the attacker -- for example, serving ads
for black-market pharmaceuticals, or sending the user to a malicious web
site that attempts to take over the user's computer using
vulnerabilities in Flash, Adobe PDF Reader, or other web browser plugins.
Using SSL between the malicious user's computer and the web server
running the blog will not stop the malicious user from providing
JavaScript code in their comment.
Using SSL between the web server an other user's computers will not stop
the malicious JavaScript code in the comment from being served to the
user, nor will it stop the malicious JavaScript from being executed by
the user's web browser.
In short, encryption is completely irrelevant to cross-site scripting
attacks.
To protect against cross-site scripting, you need to make sure that any
input provided by any user can never be executed in any situation. You
need to filter out, disallow, or render harmless from user-provided
content any JavaScript, HTML, CSS, and anything else that web browsers
can interpret and act upon. The main ways of doing this are by encoding
user input so that it is not interpreted by web broswers -- for example,
replacing '<' with '<' in user conent that appears in places where it
could be interpreted as HTML (this is not sufficient by itself, though,
many more things would need to be encoded too) -- or stripping out
things that could be executed (for example, if you are asking the user
to provide a numeric date, then remove from the input anything that is
not a number, a slash, or a dash). For a proper list of what you really
need to do to protect against cross-site scripting, see
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
I hope this helps.
--
Mark Montague
m...@catseye.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
