Cross-site scripting (XSS) is one the most common ways
hackers attack websites. XSS vulnerabilities permit a malicious user to
XSS is the most common publicly reported security vulnerability, and part of
every hacker’s toolkit.
Reflected XSS attacks are less dangerous than stored XSS attacks,
which cause a persistent problem when users visit a particular page,
but are much more common. Any page that takes a parameter
from a GET or POST request and displays that parameter back to the user in
some fashion is potentially at risk. A page that fails to treat query string
parameters as untrusted content can allow the construction of malicious URLs.
An attacker will spread these malicious URLs in emails, in comments sections,
or in forums. Since the link points at a site the user trusts, they are much
more likely to click on it, not knowing the harm that it will do.
Reflected XSS vulnerabilities are easy to overlook in your code reviews,
since the temptation is to only check code that interacts with the data store.
Be particularly careful to check the following types of pages:
- Search results - does the search criteria get displayed back to the user?
Is it written out in the page title? Are you sure it is being escaped properly?
- Error pages - if you have error messages that complain about invalid inputs,
does the input get escaped properly when it is displayed back to the user? Does
your 404 page mention the path being searched for?
- Form submissions - if a page POSTs data, does any part of the data being
submitted by the form get displayed back to the user? What if the form
submission is rejected – does the error page allow injection of malicious code?
Does an erroneously submitted form get pre-populated with the values previously
Our example hack demonstrated a maliciously crafted
GET request. However, POST requests should be treated with similar caution. If
you don’t protect against cross-site request forgery,
attackers can easily construct malicious POST requests. And even if you
do protect against CSRF, attackers will often use a combination of
vulnerabilities to construct poisoned POST requests.