Tag Archives: security

WhiteHat to Host Webinar—Beyond the Breach: Insights Into the Hidden Cost of a Web Security Breach

On Wednesday, September 12, at 11:00 AM PT, join WhiteHat Security’s Gillis Jones as he shares his research into the real financial implications of a website hack. On his journey through the business-side of Web security, Gillis uncovered bleak realities including discrepancies in accounting practices; a lack of consistent disclosure policies to address Web hacks; and gross under-reporting of financial losses once a breach is disclosed.

Gillis will also share cost-analysis formulas he developed while researching website breaches, as well as the specific costs of a breach in each of these areas:

Personnel
Technical, Infrastructure & Immediate Losses of Income
Compliance
Damaged, Destroyed or Stolen Hardware
Customer Turnover & Loss of Customer Trust
“Customer Management” After the Breach
Fines & Lawsuits
Public Relations “Damage Control”

To register for the webinar, please visit this link: https://reg.whitehatsec.com/forms/WEBINARbreach0912

Session Cookie Secure Flag Java

2 Replies

What is it and why should I care?
Session cookies (or, to Java folks, the cookie containing the JSESSIONID) are the cookies used to perform session management for Web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier is maintained server-side along with any session-scoped data related to that session id. Because cookies are transmitted on every request, they are the most common mechanism used for session management in Web applications.

The secure flag is an additional flag that you can set on a cookie to instruct the browser to send this cookie ONLY when on encrypted HTTPS transmissions (i.e. NEVER send the cookie on unencrypted HTTP transmissions). This ensures that your session cookie is not visible to an attacker in, for instance, a man-in-the-middle (MITM) attack. While a secure flag is not the complete solution to secure session management, it is an important step in providing the security required.

What should I do about it?
The resolution here is quite simple. You must add the secure flag to your session cookie (and preferably to all cookies, because any requests to your site should be HTTPS, if possible).

Here’s an example of how a session cookie might look without the secure flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;

And now, how the same session cookie would look with the secure flag:

Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; secure;

Not much to it. Obviously, you can do this manually, but if you’re working in a Java Servlet 3.0 or newer environment, a simple configuration setting in the web.xml will take care of this for you. You should add the snippet below to your web.xml.

<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>

As you can see, resolving this issue is quite simple. It should be on everyone’s //TODO list.

References
———–
http://blog.mozilla.com/webappsec/2011/03/31/enabling-browser-security-in-web-applications/

http://michael-coates.blogspot.com/2011/03/enabling-browser-security-in-web.html

https://www.owasp.org/index.php/SecureFlag

Session Fixation Prevention in Java

Cross-Site Request…Framing?

4 Replies

I admit, the title of this post is deliberately misleading. It’s really about Cross-Site Request Forgery (CSRF), but it does involve framing − just not the kind that you might be expecting.

Before jumping into the meat of things, let’s start off with an appetizer: What is Cross-Site Request Forgery? Rather than give you the “textbook” definition, I’ll just dive right into a real-world example.

Let’s say you visit http://www.news.test, and there is a logo on the homepage. Let’s also say that the logo is hosted at this address: http://images.example.com/newsLogo.jpg

When your browser loads the page at http://www.news.test, it’s likely you’ll see an image tag similar to the following: <img src=”http://images.example.com/newsLogo.jpg” />. When your browser renders that image, it must first place a request to images.example.com in order to retrieve the newsLogo.jpg resource. There’s certainly no harm in this, but for the sake of argument, we can confidently conclude that the www.news.test website forced your browser to place a request to images.example.com without your knowledge or explicit consent. Right?

Now, let’s suppose you visit http://www.news.test again, but this time there is an image tag that looks like this: <img src=”http://yourbanksite.example.org/transferMoney.php?toEmail=attacker@attacker.example.net&amount=99999.00″ />. As in the example above, when your browser loads the page at www.news.test and attempts to render the image tag, it is going to place a request to http://yourbanksite.example.org/transferMoney.php?toEmail=attacker@attacker.example.net&amount=99999.00. Your browser will place the malicious request without your knowledge, and if you are authenticated to yourbanksite.example.org when you visit www.news.test − assuming the yourbanksite.example.org web application is not protecting against a CSRF attack − your life savings and kid’s college fund will be gone in a flash.

This kind of attack succeeds because of a flaw in how the Internet inherently works. When your browser places a request to another site, any cookies that exist for that site are sent along with that request. Since authentication is typically handled through cookies, and your cookies are sent along with the malicious yourbanksite.example.org request, the yourbanksite.example.org application is going to see the request, recognize it as coming from an authenticated user (you), and thus honor/process the request.

There are more things to consider in this type of attack, but for the scope of this post, that’s all you really need to know now. While a CSRF attack is typically used to exploit an application that the victim is authenticated to, for the sake of what I’ll be discussing below, I’m more interested in the fact that a CSRF attack can be leveraged to force a victim’s browser to place arbitrary requests.

For additional reading material on CSRF, see this post on WhiteHat’s stance on CSRF, and the Web Application Security Consortium’s page on CSRF.

Ok… appetizer digested? Now for the main course…

Information is everything. It’s power. Privacy within Web applications, especially social media applications, is a war zone because information is such a profitable and appealing target. The smallest pieces of information − or *mis*information − in the wrong hands can cost you your identity, your job, or even your freedom.

Wherever there is a massive data flow of information, there is inevitably going to be monitoring and tracking. From advertising networks, to law enforcement organizations, to intelligence agencies, there is no shortage of people who are interested in obtaining information about you. I’m not just talking about your personal information, such as name, address, and phone number; I’m also referring to your browsing history, your social network engagements, and the kind of content you publish to, and consume from, “the cloud”.

Imagine your spouse or your boss opening up your browser’s history. Would you be concerned about what he/she sees? Or perhaps the FBI confiscates your computer without warning. Would you be worried about what they’d find? Hopefully, the answer to both of those questions is “No”. But what if there was enough incriminating browser activity that you lose your job? Or a warrant is issued for your arrest? Or you even get labeled an “enemy combatant”?

Sounds kind of absurd, right? Well, how else would you explain your Google searches for “homemade explosives” and “President Obama upcoming trips”? Or your visits to underground child sex trafficking sites? Or your posts made to pro-Al Qaeda message forums? It would seem like you’ve been up to a whole lot of no good!

You may protest, “I would never do such things!” My point is that through the use of Cross-Site Request Forgery, an attacker can populate your browser’s history with all kinds of unpleasant Web traffic. Not to mention that the requests would actually be originating from, and traveling through, your home or office network. In fact, if you are lured to a malicious page and stay on it for more than a brief period of time (perhaps to watch an interesting 10-minute video), an attacker can simulate real, human behavior by spacing out the incriminating requests so the traffic resembles that of someone actually clicking on links and spending time on questionable pages (rather than have all malicious requests placed in rapid succession).

“But wait,” you say, “isn’t there a way to distinguish CSRF traffic from legitimate user traffic?” Well, the malicious requests will likely have a ‘Referer’ header set to the URL of the page where the attacks originated from, such as: “Referer: http://attacker.example.com/csrfattack.php”; however, consider the following:

1. The ‘Referer’ header is not tracked in your browser’s history, so that won’t help you in court.
2. Although I’d need to actually research how much detail is tracked by ISPs, government agencies, etc., I suspect that the ‘Referer’ is among the lesser-tracked items. Besides, even if ‘Referer’ is tracked, an investigation would still be required to determine that the traffic was spoofed, and that’s a headache all on its own.
3. It may be possible to spoof the ‘Referer’ header by exploiting flaws in common technologies such as Java or Flash.
4. It is trivial to strip the ‘Referer’ altogether (kudos to Jeremiah Grossman for the tip).

The bottom line is, falling victim to this kind of CSRF attack can, at the very least, be an enormous inconvenience and a hassle to clear up. At its worst, being framed in this way − even if you’re eventually shown to be innocent − could destroy your reputation, your marriage, your career. False accusations can tarnish even the most innocent person’s reputation, especially if that person is a prominent figure and the media gets involved.

We live in an amazing age where information − and especially “news” − spreads like wildfire. With social media apps connecting billions of people worldwide − I’m thinking of Twitter in particular − breaking news can hit your cell phone before it even crosses a news anchor’s desk. If a celebrity, politician, or other public figure were to be targeted by this type of CSRF attack, his or her life could become exceedingly complicated − very quickly.

Consider the upcoming 2012 election: Such an attack could be just what a candidate needs to derail an opponent’s campaign progress. By the time the victim could prove the allegations false, the election could be long over!

Our world is rapidly changing, and each new generation becomes even more submerged in the technological realm than the one before. The more immersed in technology we become as a society, the more sophisticated and damaging attacks on our privacy and personal information will become. For example, it’s only a matter of time before hackers start getting into your fridge.

How long have you been reading this post? Five, maybe ten minutes? Did you switch over to another tab for a while half-way through? Or maybe you got up for a bit to get some food? Better check your browser history… you never know when − or from where − a CSRF attack might originate…

My First CSRF

3 Replies

My First Cross-Site Request Forgery Experience

A while back I was sifting through the posts of my friends on one of today’s popular social networking sites when I saw an odd video called “baby elephant giving birth” – or something to that effect – posted by several of my friends. This tingled my security-spidey senses. I knew something wasn’t legit, but I didn’t know exactly what. I decided to get on an old desktop I rarely use to check it out.

This is what happened: I click the link and am warned that I’m leaving the safety of socialnetworksite.com. The video opens in a new tab and begins to play. I close the tab and return to my profile to see that I had now posted “baby elephant giving birth” for all of my friends to see. I was a victim of CSRF.

How This Happened

When I originally logged into socialnetworksite.com, it stored my authenticated session within a cookie, and from then on the site would use that cookie to ensure that I am authorized. When I left socialnetworksite.com and loaded the new page, evilsite.example.com, a piece of script was embedded on the evilsite.example.com page that executed upon loading. That script contained a POST request to socialnetworksite.com that posted the baby elephant video to my profile. Because the POST request is sent from my browser, the server checked my browser’s cookies to make sure that I was authorized to make that request, and I was.

How to Protect Against This Occurring as a Developer

The most common and effective form of CSRF protection is with a randomly generated token that is assigned to the beginning of each session and that expires at the end of the active session. You can also generate and expire CSRF tokens for each POST. Some sites use the Viewstate property in ASP.Net sites, but because a Viewstate just records the input data of a form, you can potentially guess what those inputs would be. Granted that a Viewstate is better than no protection at all, a randomly generated CSRF Token is just as easy to implement and much more effective.

Note: If there is Cross-Site Scripting on the same site, the token used is irrelevant, because the attacker can grab the token from your cookies and make whatever authenticated requests he chooses.

How to Avoid This Occurring as a User

Never click on untrusted or unfamiliar links. Make sure that any sensitive web sites you access – your email, banking accounts, etc. – are done in their own browser and kept separate from any other Web surfing.

For a description of how WhiteHat Security detects CSRF, check out Arian Evan’s blog at https://blog.whitehatsec.com/tag/csrf/.

So even though my example of CRSF was relatively harmless, the attack could have just as easily been directed towards a banking website to transfer money. Let’s say I open a link from an email, while currently having an active session at “bigbank.com”.

For transferring money, bigbank.com may have a form that looks something like this on its website:

<form name=”legitForm” action=”/transfer.php” method=”POST”>
<b>From account:<input name="transferFrom" value="" type="text">
<br>To account:<input name="transferTo" value="" type="text">

<br>Amount: <input name=”amount” value=”" type=”text
<span><input name=”transfer” value=”Transfer” type=”submit”></span>

</form>

When you fill out and submit the legitForm, the browser sends a POST request to the server that looks something like this:

POST /transfer.php HTTP/1.1
Host: bigbank.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Cookie: PHPSESSID=htg1assvnhfegbsnafgd9ie9m1; username=JoeS; minshare=1;
Content-Type: application/x-www-form-urlencoded
Content-Length: 69

transferFrom=111222&transferTo=111333&amount=1.00&transfer=Transfer

Neither of the previous codes is relevant to the user, but they DO give the attacker the structure to build his own evil POST request containing his account information. The attacker embeds the following code onto his website that you clicked on:

This code automatically creates and sends a POST request when the webpage is loaded. Not only does it not require any user action other than loading the website; there is also no indication to the user that a request was ever sent.

Now here’s another example, but using a “change password request,” instead. Let’s say I open a link from an email, while currently having an active session at “bigbank.com”. Most likely, bigbank.com’s website will have a “Change User’s Password” form that looks something like this:

<form name=”changePass” action=”/changePassword.php” method=”POST”>
<b>New Password: <input name="newPass" value="" type="text">
<br>Confirm Pasword:<input name="confirmPass" value="" type="text">

</form>

When you fill out and submit the valid changePass form, the browser sends a POST request that will look similar to this to the server:

newPass=iloveyou&confirmPass=iloveyou&passChange=”Change”

Again, while neither of the previous codes is relevant to the user, they DO give the attacker the structure to build his own evil POST request containing the information he wants to submit. The attacker embeds the following code onto his website that you clicked on; then, when the page loads, the code executes:

This code automatically creates and sends a POST request when the webpage is loaded. And, as in the example above, not only is no user action required other than loading the website, there is no indication to the user that a request was ever sent.

The Anywhere Internet and the Nowhere Security

1 Reply

It used to be that if you wanted to do something on the computer, you’d boot up your PC or Mac and open a piece of installed software to go about your business.

Those were the simple times.

Now though, with the explosion of Internet-connected smartphones and software-as-a-service, the hardware-based operating system and all the protections that come with it have gone out the door. Firewalls, antivirus software, and heavily secured system coding have all been rendered useless as applications delivered through the Web to your mobile device or computer have become the new operating systems. In the past six months, we have seen literally hundreds of breaches affecting hundred of millions of consumers. From your local bank to three-letter government agencies, all have had Web-facing presences that were epically breached.

This shift in computing and the consumption of software has also shifted the perceptions of who and how online security is to be handled. Where before, your safety was assumed to be coming from the operating system and a handful of third-party AV solutions, now it is up to the expert coding of those writing the applications we dutifully use. As these applications have become increasingly powerful and linked to all of our devices, our personal data has moved to the Internet with them, meaning, theoretically, that anyone with Internet access could potentially steal that information.

The mobile paradigm brings a new problem of insecurity as well, as not only is your data accessible via the Internet on your device, but you can physically lose a cell phone much more easily than a computer. So now your data can be either digitally or physically stolen and it’s up to developers to make sure that any digital information remains safe from being compromised.

The rise of the application as the de facto way to function today means that there is a huge burden placed on the companies who normally just provided operating systems.

The 3:00 A.M. Incident Response Phone Call − A Success Story

2 Replies

It’s 3:00 A.M., and you receive the dreaded IR phone call. Your CSO is demanding an immediate response to an attack on your company’s resources. Dreary and lethargic, you stumble out of bed and VPN into your network. You pull up your centralized log management and see that there have been literally thousands of requests to your website in the span of time that typically sees between 50 and 100 requests. You feel your heart rate pick up, your palms get damp….

You’re under attack.

You begin rummaging through your network changelogs for the past twenty-four hours, attempting to see if there have been any major changes to the infrastructure or major software roll-outs across the network. But you find there have been no network changes, and no previously unvetted software updates have been pushed. “Damn,” you mutter to yourself, “if only the problem were that easy to identify….”

Your fingers flash across the keyboard in a rush as your Chief of the Network Operations Center floods your instant messenger with requests for updates.

C-NOC: “I guess since you’re up at this ungodly hour, CSO has you running IR for the breach?”

Me@3: “Yeah, any word from the network side? Hopefully we’re not seeing any data exfiltration from internal, right?”

C-NOC: “No, just a metric ton of smtp requests coming from the log management…. What alert controls did you have in place in case of an attack?”

Me@3: ”Crap, sorry John, guess I forgot to put the alert mail cap in place…wait a second, I have to go, John. I totally forgot to check one of the most obvious things!”

C-NOC: ”Ha, you forgot to check the WAF? Noob “

{C-NOC John has disconnected}

You have to love an environment where even the most severe problems result in good-hearted ribbing between colleagues.

You quickly surf to the URL where your WAF typically resides, and find the elegant interface filled with thousands of requests, which appear to be the result of someone running a fuzzer against the account information pages. It seems as if someone is attempting to SQLmap to iterate through all possible injections.

You laugh maniacally to yourself and lean back in your office chair, thoroughly satisfied with your department’s preparations for this very problem. Just three weeks ago, you completed the transition from raw user interaction with the SQL database to a more secure parameterized transaction. As you pour yourself a bowl of cereal, you begin mentally drafting the incident report to your boss.

It’s going to be a good day.

Our Process — How We Do What We Do and Why

2 Replies

A while back I published what became an extremely popular post, looking behind the scenes at WhiteHat Sentinel’s backend infrastructure. On display were massive database storage clusters, high-end virtualization chassis, super fast ethernet backplanes, fat pipes to the internet, near complete system redundancy, round-the-clock physical security, and so on. Seriously cool stuff that, at the time, was to support the 2,000 websites under WhiteHat Sentinel subscription where we performed weekly vulnerability assessments.

Today, only seven months later, that number has nearly doubled to 4,000. A level of success we’re very proud of. I guess we’re doing something right, because no one else, consultancy or SaaS provider, comes anywhere close. This is not said to brag or show off, but to underscore that scalability is a critical part of solving one of the many Web security challenges many companies face, and an area we focus on daily at WhiteHat.

To meet the demand we scaled up basically everything. Sentinel now peaks at over 800 concurrent scans, sends roughly 300 million HTTP requests per month, a subset of which are 3.85 million security checks sent each week, resulting in around 185 thousand potential vulnerabilities that our Threat Research Center (TRC) processes each day (Verified, False-Positives, and Duplicates), and collectively generate 6TBs of data per week. This system of epic proportions has taken millions in R&D and years of effort by many of the top minds in Web security to build.

Clearly Sentinel is not some off-the-shelf, toy, commercial desktop scanner. Nor is it a consultant body shop hiding behind a curtain. Sentinel is a true enterprise class vulnerability assessment platform, leveraging a vast knowledge-base of Web security intelligence.

This is important because a large number of corporations have hundreds, even thousands of websites each, that all need to be protected. Being able to achieve the aforementioned figures, without sacrificing assessment quality, requires not only seriously advanced automation technology, but development of a completely new process of performing website vulnerability assessments. As a security pro and vendor who values transparency, this process, our secret sauce, something radically different than anything else out there, deserves to be better explained.

As a basis for comparison, the typical one-off consultant assessment/pen-test is conducted by a single person using an ad hoc methodology, with one vulnerability scan, and one website at a time. Generally, high-end consultants are be capable of thoroughly assessing roughly twenty websites in a year, each a single time. An annual ratio of 20:1 (assessment to people).

To start off, our highly acclaimed and fast growing Threat Research Center is the department responsible for service delivery. At over 40 people strong, the entire team is located at WhiteHat headquarters in Santa Clara, California. All daily TRC workload is coordinated via a special software-based workflow management system, named “Console,” we purpose-built to shuttle millions of discreet tasks across hundreds/thousands of websites that need to be completed.

Work units include initial scan set-ups, configuring the ideal assessment schedule, URL rule creation, form training, security check customization, business logic flaw testing, vulnerability verification, findings review meetings, customer support, etc. Each of these work units is able to be handled by any available TRC expert, or team of experts, who specialize and are proficient in a specific area of Web security, that might take place during different stages of the assessment process. Once everything is finished, every follow-on assessment becomes automated.

That is the real paradigm buster, a technology-driven website vulnerability assessment process capable of overcoming the arcane one-person-one-assessment-at-a-time model that stifles scalability. It’s as if the efficiency of Henry Ford’s assembly line met the speed of a NASCAR pit crew — this model dramatically decreases man hours necessary per assessment, leverages the available skills of the TRC, and delivers consistently over time. No other technology can do this.

As a long time Web security pro, to see such a symphony of innovation come together is really a sight to behold. And if there is any question about quality, we expect Sentinel PE testing coverage to meet or exceed that of any consultancy anywhere in the world. That is, no vulnerability that exposes the website or users to a real risk of compromise should be missed.

Let’s get down to brass tacks. If all tasks were to be combined, a single member of TRC could effectively perform ongoing vulnerability assessments on 100 websites a year. At 100:1, Sentinel PE is 5x more efficient than the traditional consulting model. Certainly impressive, but this is an apples to oranges comparison. The “100” in the 100:1 ratio is websites NOT assessments like the earlier cited 20:1 consultant ratio. The vast majority of Sentinel customer websites receive weekly assessments, not annual one-time one-offs. So the more accurate calculation would equal 5200:1 (52 weeks). Sentinel also comes in varied flavors of coverage. SE and BE measure in at 220:1 and 400:1 websites to TRC members respectively.

The customer experience perspective

Whenever a new customer website is added to WhiteHat Sentinel, a series of assessment tasks are generated by the system and automatically delegated via a proprietary backend workflow management system — “Console.” Each task is picked up and completed by either a scanner technology component or a member of our Threat Research Center (TRC) — our team of Web security experts responsible for all service delivery.

Scanner tasks include logging-in to acquire session cookies, site crawling, locating forms that need valid data, customizing attack injections, vulnerability identification, etc. Tasks requiring some amount of hands-on work are scan tuning, vulnerability verification, custom test creation, filling out forms with valid data, business logic testing, etc. After every task has been completed and instrumented into Sentinel, a comprehensive assessment can be performed each week in a fully automated fashion, or by whatever frequency the customer preferrers. No additional manual labor is necessary unless a particular website change flags someone in the TRC.

This entire collection of tasks, all of which must be completed when a new website is added to Sentinel, is a process we call “on-boarding.” From start to finish, the full upfront on-boarding process normally takes between 1 – 3 weeks and 2 – 3 scans.

From there, there are people in the TRC purely dedicated to monitoring nearly hundreds of running scans and troubleshooting anything that looks out of place on an ongoing basis. Another team is tasked to simply verify hundreds of thousands of potential scanner flagged vulnerabilities each week such as Cross-Site Scripting, SQL Injection, Information Leakage, and dozens of others. Verified results, also known as false-positive removal, is one of the things our customers say they like best about Sentinel because it means many thousands of findings they didn’t have to waste their time on.

Yet another team’s job is to configure forms with valid data, and marking which are safe for testing. All this diversification of labor frees up time for those who are proficient in business logic flaw testing, allowing them to focus on issues such as Insufficient Authentication, Insufficient Authorization, Abuse of Functionality, and so on. Contrast everything you’ve read so far with a consultant engagement that amounts to a Word or PDF report.

At this point you may be wondering if website size and client-side technology complexity cause us any headaches. The answer is not so much anymore. Over the last seven years we’ve seen and had to adapt to just about every crazy, confusing, and just plain silly website technology implementation the Web has to offer — of which there are painfully many. Then of course we’ve had to add support for Flash, Ajax, Silverlight, JavaScript, Applets, Active X, (broken) HTML(5), CAPTCHAs, etc.

The three most important points here are:

1) Sentinel has been successfully deployed on about 99% of websites we’ve seen. 2) Multi-million page sites are handled regularly without much fanfare. 3) Most boutique consultancies assess maybe a few dozen websites each year. We call this Monday through Friday.

Any questions?

Are 20% of Developers Responsible for 80% of the Vulnerabilities?

14 Replies

That’s the question I recently posed in a twitter exchange with @securityninja and @manicode. For those unfamiliar with the Pareto principle, also known as the 80/20 rule, is where roughly 80% of the effects come from 20% of the causes. This Pareto principle phenomenon can be seen in economics, agriculture, land ownership, and so on. I think it may also apply to developers and software security — particularly software vulnerabilities.

Personal experience would have most of us agreeing that not all developers are equally productive. We’ve all seen where a few developers generate way more useful code in a given amount of time than others. If this be the case, then it may stand to reason that the opposite could be true — where a few developers are responsible for a bulk of the shoddy vulnerable code. Think about it, when vulnerabilities are introduced, are they fairly evenly attributable across the developer population or clumped together within a smaller group?

The answer, backed up by data, would have a profound affect on general software security guidance. It would to more efficiently allocate security resources in developer training, standardized framework controls, software testing, personnel retention, etc. Unfortunately very few people in the industry might have the data to answer this question authoritatively, and then only from within their own organization. Off the top of my head I can only think that Adobe, Google, or Microsoft might have such data handy, but they’ve never published or discussed it.

In the meantime I think we’d all benefit from hearing some personal anecdotes. From your experience, are 20% of developers responsible for 80% of the vulnerabilities?

Flash + 307 Redirect = Game Over

2 Replies

A vulnerability for Ruby on Rails was recently patched [http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails].

Why the Patch Was Necessary

The default CSRF prevention built into RAILS has two components: (1) a custom HTTP Header, and (2) a CSRF token in the post body. The default was designed so that only one, rather than both, of the components was required in a request. Modern browser security typically makes this a fairly secure method, because JavaScript cannot create custom HTTP Headers and then have them sent across domains. However, a researcher from Google found a way to exploit this issue by using “certain combinations of browser plugins and HTTP redirects.” Because of this discovery, the new patch for Ruby on Rails now requires both components to be in the request, preventing exploitation.

How the Vulnerability Bypassed the Default CSRF Security

A hidden flash file on a website automatically sent the following request:

http://www.attacker.com/redirect.php?status=307&url=http://www.victim.com

Flash allowed the site where the file was running to specify POST data and additional headers. But before sending the request, Flash checked the site’s crossdomain.xml file. Attackers then set up their cross domain.xml files as follows:

http://www.attacker.com/crossdomain.xml

<?xml version=”1.0″ encoding=”UTF-8″?>

<cross-domain-policy>

<allow-access-from domain=”*”/>

<allow-http-request-headers-from domain=”*” headers=”*”/>

</cross-domain-policy>

Based on this, the Flash file understood that it then had permission to send additional header information with its request, and proceeded to send the request with extra headers to

[http://www.attacker.com/redirect.php?status=307&url=http://www.victim.com].

The attacker site returned a 307 redirect. The 307 is like a 302 redirect, but also allows the forwarding of POST data. The Flash application, realizing that the data was going to another Web server, attempted to retrieve the crossdomain.xml file for www.victim.com. Unfortunately, it appears that in certain circumstances, Flash will IGNORE the crossdomain.xml file for victim.com, and rely instead on the original crossdomain.xml file at www.attacker.com. After a confirmation message that would confuse most users, the Flash application sent a new request:

POST / HTTP/1.1

Host: www.victim.com

…

X-Header: test=data;

Cookie: abc=123

Content-Length: 9

post=body

We see here that the POST request was sent to www.victim.com, along with the additional headers and the POST body. This clearly illustrates that Web server frameworks can no longer rely solely on the implied security of additional HTTP Request Headers to prevent CSRF.

Breakdown of the Vulnerability

Mac – Flash Player 10,2,154,12Chrome 9.0.597.94 302 Redirect GET Request, with headers

Chrome 9.0.597.94 307 Redirect Not Sent

Safari 5.0.3 (6533.19.4) 302 Redirect GET Request, with headers

Safari 5.0.3 (6533.19.4) 307 Redirect POST Request, with headers (No Confirmation)

FireFox 3.6.10 302 Redirect GET Request, no headers

FireFox 3.6.10 307 Redirect POST Request, with headers

FireFox 4 beta 8 no bueno

Windows XP – Flash Player 10.2.152.26

FireFox 3.6.10 302 Redirect GET Request, no headers

FireFox 3.6.10 307 Redirect POST Request, with headers

IE 7 no bueno

IE 8 no bueno