sorted by: recent | see : popular

Content Tagged with front + Security

Jeremiah Grossman, our go to guy for Web security issues, recently write an interesting piece about how security gets bolted on, and slowly subsumed into the platform:

Whether improving ease-of-use, adding new developer APIs, or enhancing security – Web browser features are driven by market share. That’s all there is to it. Product managers perform a delicate balancing act of attracting new users while trying not to “break the Web” or negatively impact their experience. Some vendors attempt an über secure design - Opus Palladianum as an example, but few use it. Others opt for usability over security, such as Internet Explorer 6, which almost everyone used and was exploited as a result. Then, somewhere in the middle, is fan-favorite Firefox. The bottom line is that any highly necessary and desirable security feature that inhibits market adoption likely won’t go into a release candidate of a major vendor. Better to be insecure and adopted instead of secure and obscure.

Fortunately, the major browser vendors have had security on the brain lately, which is a welcome change. Their new attitude might reflect the realization that a more secure product could in fact increase market share. The online environment is clearly more hostile than ever, as attackers mercilessly target browsers with exploits requiring no user intervention. One need only to look at this year’s massive SQL Injection attacks that infected more than one million Web pages, including those belonging to DHS, U.N., Sony, and others. The drive-by-download malware had just one goal - compromise the browser - with no interest in looting the potentially valuable data on the sites. Of course, we still have the garden-variety phishing sites out there. This leads to questions regarding the benefits of end-user education. Users are fed up. So let’s analyze what the Mozilla and Microsoft camps have done in response.

Buffer overflows and other memory corruption issues in the most recent browsers are declining, plus the disclosure-to-patch timeline is trending properly. Firefox 3 and Internet Explorer 7 now offer URL blacklists that block phishing sites and other pages known to be delivering malware. These features are reportedly a little shaky, but it’s clearly better considering there was nothing in place before. Firefox 3 provides additional visibility into the owners of SSL certificates and make it more challenging to blindly accept those that are invalid or self-signed. IE 7 offers a nice red/green anti-phishing toolbar that works with EV-SSL to help users steer clear of dangerous websites. Overall, excellent progress has been made from where we were just a couple years ago, but before the vendors start patting themselves on the back, there’s also some bad news.

If you ask the average Web security expert if they think the typical user is able to protect themselves online and avoid getting hacked, the answer will be an unqualified “no”. While browser vendors are addressing a small slice of a long-standing problem, most people are not aware of the remaining risks of a default install of the latest version of Firefox or Internet Explorer. When visiting any Web page, the site owner is easily able to ascertain what websites you’ve visited (CSS color hacks) or places you’re logged-in (JavaScript errors / IMG loading behavior). They can also automatically exploit your online bank, social network, and webmail accounts (XSS). Additionally, the browser could be instructed to hack devices on the intranet, including DSL routers and printers. And, if that’s not enough, they could turn you into a felon by forcing requests to illegal content or hack other sites (CSRF). The list goes on, but DNS-rebinding attacks get a little scary even for me, and it’s not like we haven’t known of these issues for years.

Bill Zeller and Ed Felten have published a report on Cross-Site Request Forgery attacks on popular Web sites:

We found four major vulnerabilities on four different sites. These vulnerabilities include what we believe is the first CSRF vulnerability that allows the transfer of funds from a financial institution. We contacted all the sites involved and gave them ample time to correct these issues. Three of these sites have fixed the vulnerabilities listed below, one has not.

CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.

The chaps share deatils on the following attacks:

1. ING Direct (ingdirect.com)

Status: Fixed

We found a vulnerability on ING's website that allowed additional accounts to be created on behalf of an arbitrary user. We were also able to transfer funds out of users' bank accounts. We believe this is the first CSRF vulnerability to allow the transfer of funds from a financial institution. Specific details are described in our paper.

2. YouTube (youtube.com)

Status: Fixed

We discovered CSRF vulnerabilities in nearly every action a user could perform on YouTube. An attacker could have added videos to a user's "Favorites," added himself to a user's "Friend" or "Family" list, sent arbitrary messages on the user's behalf, flagged videos as inappropriate, automatically shared a video with a user's contacts, subscribed a user to a "channel" (a set of videos published by one person or group) and added videos to a user's "QuickList" (a list of videos a user intends to watch at a later point). Specific details are described in our paper.

3. MetaFilter (metafilter.com)

Status: Fixed

A vulnerability existed on Metafilter that allowed an attacker to take control of a user's account. A forged request could be used to set a user's email address to the attacker's address. A second forged request could then be used to activate the "Forgot Password" action, which would send the user's password to the attacker's email address. Specific details are described in our paper.

(MetaFilter fixed this vulnerability in less than two days. We appreciate the fact that MetaFilter contacted us to let us know the problem had been fixed.)

4. The New York Times (nytimes.com)

Status: Not Fixed. We contacted the New York Times in September, 2007. As of September 24, 2008, this vulnerability still exists.

A vulnerability in the New York Time's website allows an attacker to find out the email address of an arbitrary user. This takes advantage of the NYTimes's "Email This" feature, which allows a user to send an email about a story to an arbitrary user. This emails contains the logged-in user's email address. An attacker can forge a request to active the "Email This" feature while setting his email address as the recipient. When a user visit's the attacker's page, an email will be sent to the attacker's email address containing the user's email address. This attack can be used for identification (e.g., finding the email addresses of all users who visit an attacker's site) or for spam. This attack is particularly dangerous because of the large number of users who have NYTimes' accounts and because the NYTimes keeps users logged in for over a year.

Also, TimesPeople, a social networking site launched by the New York Times on September 23, 2008, is also vulnerable to CSRF attacks. We hope the New York Times will decide to fix these vulnerabilities now that they have been made public.

And, what about mitigation?

Our paper provides recommendations for preventing these attacks. We provide a server-side plugin for the PHP MVC framework Code Igniter that can completely prevent CSRF. We also provide a client-side Firefox extension that can protect users from certain types of CSRF attacks (non-GET request attacks).

Simon Willison is talking about Ajax vulnerabilities at @media Ajax.

The main thing to worry about is users injecting Javascript - cross-site scripting (XSS). Other vulerabilities people used to talk about - trusting user input and checking for SQL injection attacks - are boring/easy.

If I have an XSS hole, I can steal your users' cookies and log in as them, show a fake phishing page, embed malware, etc. And any service your site provides, I can perform it as if I was one of your users.

Reflected XSS - I embed my JS in a link to your site and trick your user to follow it.
Persistent XSS - I get my XSS onto your site's database (e.g. by adding it to a forum).

Examples of XSS from facebook, youtube, google groups, live search. See xssed.com - sites that were xss'd.

Preventing XSS

Use a tool that escapes everything on output. Better than escaping on input because you miss out on stuff.

IE8 has an XSS filter - if scary Javascript in the URL matches that in the page, it's blocked. But as developers, we have to assume older/other browsers.

httpOnly cookies also not so useful because many attacks don't rely on attacker seeing cookie.

HTML sanitisation. MySpace and LiveJournal have tried to do it and been XSS'd (samy is my hero). Must be really careful because many libraries have at least one hole. UTF-7 hole which Google's 404 page suffered.

CSS is also vulnerable. HTC in IE and XBL in Mozilla - both vectors for Javascript attacks.

Cross-site Request Forgery (CSRF)

Happens if you have unRESTful links. app.example.com/delete.php?id=1 But what if you're RESTful and use POSTs, are you safe? No. Page B can present you with a form that submits to Page A. The form doesn't even have to be visible - hide it and write some Javascript to submit the form when the user loads the page. Was used to get users to silently digg the page you're on. Worse, was used in GMail to set filters so mail would be redirect to the evil guys.

To prevent CSRF:
- Could check HTTP Referrer, but that's notoriously unreliable. e.g. there are virus protectors that strip the outgoing referrer headers, as well as FF extensions etc.

So the bettter solution it to embed crumbs (tokens). Embed an impossible-to-guess crumb in the form, and check the crumb each time you accept the form. Crumb is specific to the user and could be a cookie value, in the simplest case. Ideally, on every request and living for a short time (e.g. one hour). Must ensure crumb doesn't leak.

Another solution with Ajax - X-Requested-By: XMLHttpRequest tells you its an XHR call, which means it came from the same domain. So if you see this, no need for the crumb check.

Plugins:

crossdomain.xml. Used by Flash to control which services can be acessed. There are various tricks will bypass it.

The PDF hole. Jan 2007 - turned out Adobe PDF readers could execute any Javascript. So Yahoo! employees for example were told to delete every PDF on the server - because having any PDF file made the whole site vulnerable.

Securing JSON

"JSONP rocks!" See Simon's web services - http://json-tinyurl.appspot.com, http://json-time.appspot.com, http://json-head.appspot.com.

JSONP is great, but only for public data.

Google Contacts exposed contact data as JSON. If malicious pages makes a JSON call for that data, and you're logged in, it will get your contact info.

But even regular JSON is vulnerable. Possible to redefine array constructor so that when JSON arrives in the browser, malicious code is executed. So JSON should look like: /* { "json" : "goes here" } */ to ensure it's not executed. (Joe Walker makes a comment at the end of the talk that it's safer to use while (true) or throw an exception - the JSON content itself might contain a closing "*/".)

Stay informed:

• http://planet-websecurty.org/feed
• http://simonwillison.net/tags/secrurity/
• http://www.owasp.org

Wes Biggs has posted on Xsstc, his cross-site scripting solution that uses CSS to hide the data:

It turns out CSS leaks data in a very subtle way. Properties set by an external stylesheet (that is, one that is loaded using a LINK REL="STYLESHEET" tag) are used to style the elements of the host page, and at runtime the page can introspect itself to see what styles have been applied. Most of these tend to be strictly prescribed data, such as background colours for block elements, or some multiple choice items, like left/center/right alignment for text. While you could conceivably come up with a binary (or ternary) system based on that, it would be a pretty nasty job to try to make those into a general-purpose data channel. Fortunately, there are a few places where CSS lets you specify essentially free-text attributes: image URLs.

To make this work, the server has to dynamically send out simple CSS data, with info encoded into it... e.g. note the 'Hello World'

To tie into the data, you just need to exec away via:

You can see the test page to see it at work. An interesting hole indeed....

What if you could encode a Jar file as an image and trick the browser to run it? This is what Ben Lorica reported from a black hat briefing webinar:

During a recent webinar to promote the upcoming Black Hat briefings in Las Vegas, a group of hackers announced the creation of a hybrid file that can potentially bypass a browser's same origin policy. They created a GIF file that also happens to be a JAR file ( a "GIFAR" file). Once uploaded onto a web site, and assuming the web server runs a JVM, it allows one to run a malicious java applet on someone else's web server.

Details were not provided, since the hackers claim that Sun is still working on a patch. For more on hybrid (image) files as attack vectors, go to minute 41:23 of the webinar.

Michal Zalewski, of Google, has released ratproxy, a tool to test your Web application against attacks such as XSS and XSRF:

Ratproxy is a semi-automated, largely passive web application security audit tool. It is meant to complement active crawlers and manual proxies more commonly used for this task, and is optimized specifically for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments. The approach taken with ratproxy offers several important advantages over more traditional methods:

• No risk of disruptions. In the default operating mode, tool does not generate a high volume of attack-simulating traffic, and as such may be safely employed against production systems at will, for all types of ad hoc, post-release audits. Active scanners may trigger DoS conditions or persistent XSSes, and hence are poorly suited for live platforms.

• Low effort, high yield. Compared to active scanners or fully manual proxy-based testing, ratproxy assessments take very little time or bandwidth to run, and proceed in an intuitive, distraction-free manner - yet provide a good insight into the inner workings of a product, and the potential security vulnerabilities therein. They also afford a consistent and predictable coverage of user-accessible features.

• Preserved control flow of human interaction. By silently following the browser, the coverage in locations protected by nonces, during other operations valid only under certain circumstances, or during dynamic events such as cross-domain Referer data disclosure, is greatly enhanced. Brute-force crawlers and fuzzers usually have no way to explore these areas in a reliable manner.

• WYSIWYG data on script behavior. Javascript interfaces and event handlers are explored precisely to a degree they are used in the browser, with no need for complex guesswork or simulations. Active scanners often have a significant difficulty exploring JSON responses, XMLHttpRequest() behavior, UI-triggered event data flow, and the like.

• Easy process integration. The proxy can be transparently integrated into an existing manual security testing or interface QA processes without introducing a significant setup or operator training overhead.

What about other solutions?

There are numerous alternative proxy tools meant to aid security auditors - most notably WebScarab, Paros, Burp, ProxMon, and Pantera. Stick with whatever suits your needs, as long as you get the data you need in the format you like.

That said, ratproxy is there for a reason. It is designed specifically to deliver concise reports that focus on prioritized issues of clear relevance to contemporary web 2.0 applications, and to do so in a hands-off, repeatable manner. It should not overwhelm you with raw HTTP traffic dumps, and it goes far beyond simply providing a framework to tamper with the application by hand.

Ratproxy implements a number of fairly advanced and unique checks based on our experience with these applications, as well as all the related browser quirks and content handling oddities. It features a sophisticated content-sniffing functionality capable of distinguishing between stylesheets and Javascript code snippets, supports SSL man-in-the-middle, on the fly Flash ActionScript? decompilation, and even offers an option to confirm high-likelihood flaw candidates with very lightweight, a built-in active testing module.

Last but not least, if you are undecided, the proxy may be easily chained with third-party security testing proxies of your choice.

There is a thread going on secure cross domain requests. Microsoft came out with a paper saying that the W3C standard isn't secure, and pushing the Microsoft XDR spec:

A few proposals and implementations exist like XDomainRequest in IE8, JSONRequest and the W3C’s Web Applications Working Group’s Cross Site XMLHttpRequest (CS-XHR) draft specification, which combines an Access control framework with XMLHttpRequest or other features. While XDomainRequest is focused on enabling anonymous access of third party public data, Cross Site XMLHttpRequest has added functionality and consequently enables a broader set of scenarios that may appeal to the developer who may choose to use cross domain authentication and access control among other features. As can be expected with securing a large cross section of cross domain scenarios, a number of concerns have been identified with the CS-XHR draft by the web development community, the IE team members and members of the Web Apps Working Group. For a list of our recent feedback on security on CS-XHR and our take on important security principles in cross domain, please read our Security Whitepaper on Cross Domain. The paper also covers best practices and guidance for developers who will choose to build on the current draft if it’s supported by a future browser.

The community quickly jumped on this in the comments, and beyond.

Anne van Kesteren said:

After half a year of waiting Microsoft finally posted their feedback on Access Control for Cross-Site Requests and specifically the way XMLHttpRequest Level 2 works with that. Microsoft blogged about this event. I suggest people read this rebuttal from Jonas on the paper Microsoft published. To be clear, while the specifications are not entirely finalized nobody has so far put forward a viable attack scenario that does not already apply when these technologies are not supported by user agents.

(Related: Working group fun and “Concerns” raised about W3C Access Control spec have been little more than FUD.)

As linked from Anne, Jonas posted nice feedback:

I'll start with a mini FAQ to avoid repeating myself below:

Why is the PEP in the client rather than the server?

In order to protect legacy servers some of the enforcement will have to live in the client. We can't expect existing legacy servers to all of a sudden enforce something that they haven't before.

In fact, even XDR using client side PEP. It's the client that looks for the XDomainRequest header and denies the webpage access to the data if the header is not there.

In fact, Access-Control does allow full PEP on the server if it so chooses by providing an "Origin" header.

Is Access-Control designed with "Security by design"

Yes. In many ways. For example Access-Control does not allow any requests to be sent to the server that aren't already possible today, unless the server explicitly asks to receive them.

Additionally Access-Control sets up a safe way to transfer private data. This prevents sites from having to invent their own which risks them inventing something less safe.

Thirdly, Access-Control integrates well with the existing HTTP architecture of the web by supporting REST apis and the Content-Type header. This allows existing security infrastructure to inspect and understand Access-Control requests properly.

What about DNS rebinding attacks.

Even with DNS rebinding attacks Access-Control is designed not to allow any requests which are not possible already in todays web platform as implemented in all major browsers.

Especially the last point is something that seems to have been misunderstood at Microsoft. It is not the case that DNS rebinding attacks affect Access-Control any different than it affects the rest of the web platform.

Jeremiah Grossman took a fresh look at crossdomain.xml usage and decided to see which top domains had lenient policies in their files, which is now published and updated.

Why is this important?

This week I took a renewed interest in crossdomain.xml. For those unfamiliar this is Flash’s opt-in policy file that extends the same-origin policy to include more sites in the circle of trust. Normally client-side code (JavaScript, Flash, Java, etc.) is limited to reading data only from the website (hostname) in which it was loaded. Attempting to read data from other domains is met with security exceptions.

With crossdomain.xml a site owner may configure a policy to stating which off-domain sites are allowed to read its data (or parts thereof) and the client, Flash in this case, is responsible for enforcement. This feature paves the way for more rich client-side applications. Crossdomain.xml policies are also extremely flexible allowing websites to be defined by IP, domain, subdomain, or everyone (*) under the sun. And this is one area where we potentially run into trouble.

When a hostname is included in the circle of trust you allow them to read all data on the site that the user has access to, this includes any (authenticated) content and (session) cookies. So should a malicious attacker or website owner gain control of a website in the circle of trust (via a server hack or XSS), then they feasibly can compromise user data off that domain. This could easily leads to privacy violations, account takeovers, theft of sensitive data, and bypassing of CSRF protections (grabbing the key ahead of time).

With this understood I was curious just how many prominent websites are actively using crossdomain.xml and generally how they are configured. For sampling I combined the “www” hostnames of fortune 500 with the Global Alexa 500. Of the 961 unique websites in all (and keeping the results to myself for now)…

Do you type the same way consistently? Say, if you put in your username and password?

Marcus Westin has created a little jQuery plugin that measures a finger print based on your typing style, Fingerprint.

Easy to use:

This automatically injects hidden fields with names 'timestamp-down' and 'timestamp-up' for the respective timestamps. On submit, these values get sent to the server, separated by commas.

If you want the value arrays instead, you can just pass in a function to receive the timestamps - this function automatically gets called when the form is submitted.

The is a proof of concept library. I would love to see the analysis on how close the fingerprints are for people, especially on various keyboards (e.g. if they are on their laptop versus desktop).

Cool idea Marcus!