First, a few words about XSS
You know about cross-site scripting (XSS). It's an attack that injects malicious
code into a vulnerable application such that the code executes in the victim's
application viewer and, therefore, with the victim's session privileges. In most
cases, the viewer is a web browser and the malicious code is written in JavaScript.
(XSS won over the arguably more correct abbreviation "CSS" because of confusions
with an unrelated term Cascading Style Sheets.)
In theory, the victim's viewer could be another application, rather than a web browser. Imagine a vulnerable website that accepts code as input from the attacker and, without properly filtering on input or output, incorporates the code into a spreadsheet that the victim views in Excel. If the attacker could find a way to supply code that Excel will execute, then we have an instance where an XSS attack targeted a non-web browser. I suppose we could call this a cross-application cross-site scripting (XAXSS) attack. (I wouldn't want to suggest the abbreviation "CAXSS" because then people could confuse it with the term Computer Assisted X-ray Screening System.)
XSS has been discussed for a while. Even though the mechanisms of such attacks are
well-understood, XSS vulnerabilities continue to plague many web-based applications.
SecurityFix mentioned a number of popular sites that have had XSS holes.
Now, a few words about XSRF/CSRF
An attack mechanism that is not as well-known, but is also very effective in targeting
web applications is Cross-Site Request Forgeries (CSRF). (It's sometimes abbreviated
as XSRF, although I prefer CSRF acronym, despite the potential for confusing it with
the acronym for Canadian Sex Research Forum.) I wasn't as familiar with CSRF
techniques as I should have been until I came across the Matasano Chargen
posting, which pointed to Jeremiah Grossman's blog, which led me to Chris Shiflett's
write-up.
A CSRF attack takes advantage of the web application's ability to act according to the
HTTP command it receives from the user. Most web applications do that by design, of
course. The trick in a CSRF attack is to get the victim's browser to submit the
command of attacker's choice. The victim could receive a link to the targeted web
application. The link would contain a GET request, which would cause the application
to take action when the victim clicks on the link.
For example, clicking on the following link would cause the victim's Google.com
preferences to be reset to Irish language:
http://www.google.com/setprefs?hl=ga
This link, crafted by Dwayne Litzenberger, takes advantage of a XSRF weakness in
Google.com's handling of user preferences. There are many ways in which the victim
or his browser can be tricked into "clicking" on a link like this. For instance,
the link could be embedded in a concealed iframe of the website the victim is
visiting (as Google Blogoscoped pointed out), or it could be embedded into an
img tag on the malicious site. [Update: I simplified the link from its original
version per Adrian's advice.]
By submitting the request, the user will command the application to take the
appropriate action. If the user is already logged in to the vulnerable application,
the action could be taken behind the scenes without the victim's knowledge. For
instance, a vulnerable banking site could be tricked into transferring the the
victim's money out of his account.
Not only GET requests can be used as CSRF attack vectors. POST requests can be
used as well; the task would be a bit more complicated than with GET requests,
but JavaScript can help implement such an attack without much difficulty.
Update: ISC reader Adrian wrote us to point out that he uses CSRF as a way of
punishing script kiddies poking around his web server. Referring to the Google.com
CSRF link mentioned above, he said, "I use it in my apache httpd.conf, as follows:
RedirectMatch .(php|phtml|phps|php3)$
http://www.google.com/setprefs?hl=xx-klingon
That teaches them to try to access non-existent php files on my webserver
..not that automated bots would follow redirects...but I occasionally catch
some odd fish too "
How to mitigate CSRF risks?
As a web application developer, you can prevent CSRF vulnerabilities by using
some difficult-to-predict token that a proper request needs to include, in
addition to the session ID that the browser submits automatically via a cookie.
The token could be embedded in the form that the application generates for the
user. A CSRF link provided by the attacker would not include the token, and
would be invalidated.
Alex Stamos commented on the use of such tokens in response to the Matasano
Chargen posting on CSRF:
The token you want to add to protect against XSRF really doesn't have a different
function than a cookie. The real problem is that there is no such thing as a browser
security model, only a cobbled together set of rules written by the developers that
championed features inside of Netscape in 1997. The root issue isn't the assertion
made by the cookie, it's that some idiot said "Let's make sure the browser
automatically attaches cookies to cross-domain script tags and iFrame POSTs.
That would be awesome!"
So we're back to hidden fields in forms and big blobs of crypto in GET parameters
along with entropic and protected cookies...
Other ways of mitigating CSRF risks include the use of CAPCHA to check whether
the request to an important page was submitted by a human before executing it,
keeping the session time-out short, and not relying on cookie-based mechanisms
for managing session IDs.
As a user of web applications, consider logging out of sensitive websites, rather
than keeping yourself logged in while multi-tasking and browsing the web.
Disabling scripting support in your web browser might help to some extent, especially
against attacks on POST-driven AJAX application that might be vulnerable to CSRF
attacks. However, there are plenty of GET-based CSRF flaws that could be exploited
without the use of JavaScript.
For additional information about CSRF, please see Chris Shiflett's write-up, the
Cross Site Reference Forgery paper by Jesse Burns, and the Session Riding paper
by Thomas Schreiber. (Session Riding is another term for CSRF attacks.)
Update: ISC reader Adam shared this CSRF war story with us: "I created a webpage
where students could vote for next homecoming king and queen. I used HTTP-Auth to
ensure only students could vote (and only vote once). But the 'submit' page used GET
data to process votes. One creative candidate sent an email to a campus mailing
list that appeared to be a standard 'click here to cast your ballot' message. But the
link he used was to the 'submit' page (with his name in GET statement). So when
someone would click on the link in their email, they would prompted by the
HTTP-Auth and then be greeted by a 'thank you for voting' page. I let you guess
who won..."
0 comments:
Post a Comment