sorted by: recent | see : popular

Content Tagged with security + Ajax

Passpack notified me about their new library to support Host-Proof Hosting (HPH) development (touched on earlier). The library allows anyone to set up HPH on their own infrastructure. It's mostly a browser-side library powered by JQuery, focused on transferring encrypted data, and there's also some sample server-side PHP code.

I think the most important part of HPH is that it provides users with real-world data privacy, it's not just a theory, it works now. I'd love to see the pattern get some traction with SaaS providers, but it's not the most obvious system to implement. To this avail, we've just released an MIT/LGPL library for creating Host-Proof Hosting applications: http://code.google.com/p/passpack/

Host-Proof Hosting is the pattern whereby the server knows nothing about the user's data, because the browser ensures it's kept encrypted each time it goes over the wire. It's been practiced in the real world for a couple of years now, but has received some extra attention lately. Clipperz, a Passpack competitor, recently mentioned interest from Richard Stallman in its advocacy for "zero knowledge web applications".

In their response to Clipperz, Passpack expressed a more pragmatic view:

The Zero Knowledge Web Application as-is, is a theory. This is not to say that there couldn’t be a future where it might become a credible solution for privacy, but until that happens, it is inappropriate to ask people to trust a theory with just too many inconsistencies.

Updated after clarification from Passpack - the library is for any server infrastructure, not an API to communicate specifically with Passpack's servers. They say such an API is on the radar.

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.