Wednesday, July 9th, 2008
Category: Library
, Security
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.
Friday, July 4th, 2008
Category: Security
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.
Thursday, July 3rd, 2008
Category: IE, Security
The IE8 team has created a blitz on its blog with a slew of posts on security. There is a ton of great stuff here, and is well worth going into detail on each post:
IE8 and Trustworthy Browsing
At first they set the scene:
This blog post frames our approach in IE8 for delivering trustworthy browsing. The topic is complicated enough that some context and even history (before we go into any particular feature) is important, and so some readers may find this post a bit basic as it’s written for a wide audience. In previous posts here, we’ve written about IE8 for developers: the work in standards support, developer tools, script performance, and more. In future posts, we’ll write about IE8 for end-users (beyond the benefits of improved performance, activities, and Web Slices). This post starts a series about trustworthy browsing, a topic important for developers and end-users and everyone on the web. By setting the context and motivation with this post, the next posts that dive into the details of IE8 will build on this foundation.
Trustworthy refers to one of our overall goals: provide the most secure and most reliable browser that respects user choice and keeps users in control of their machine and their information. For reference, Microsoft’s framework for Trustworthy Computing in general spans four areas: security, privacy, reliability, and business practices.
IE8 Security Part III: SmartScreen® Filter
For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks over a million phishing attacks weekly) to develop the SmartScreen® Filter, a replacement that improves upon the Phishing Filter in a number of important ways:
- Improved user interface
- Faster performance
- New heuristics & enhanced telemetry
- Anti-Malware support
- Improved Group Policy support
IE8 Security Part IV: The XSS Filter
The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.
With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification.
IE8 Security Part V: Comprehensive Protection
As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.
Category: Security
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:
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.
Friday, June 27th, 2008
Category: Security, XmlHttpRequest
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.
Thursday, June 12th, 2008
Category: Security
The TLS Report is a new site that Benjamin Black has put together to watch over the security of major sites on the internet.
There have been services that watch the top sites for various statistics, but not security. The best and worst list has some surprises, namely:
- Best: UBS.com, good to see a bank up there; openid.ee, good to see an OpenID provider; worldofwarcraft.com, real-time and secure
- Worst: wachovia.com, bad to see a bank down there; usmap.cnet.navy.mi, a .mil will scare anyone; cpscontractor.nih.gov, ditto for a .gov.
Of course, there are already lots of arguments over the minutia. A really nice service though!
Thursday, May 22nd, 2008
Category: Security
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)…
Tuesday, May 13th, 2008
Category: Security
Sometimes it is interesting to see that knowledge from the 10,000 B.C. period of web development can be used in new ways to create - to play it safely - interesting ideas.
Each window in a browser has a name property which became pretty much useless when we stopped using pop-up windows and tried to make them communicate with each other by name.
Thomas Frank, however wrote a small library that uses window.name to store session variables without having to resort to cookies and his research seems to prove that you can store up to two megabytes of data in window.name. As this property is available across page reloads it is a sort of session, but as the comments show the security aspects of it are just scary:
There is a cross domain flag in sessvars, but although it defaults to false, this just sees to that you don’t get any other sites window.name garbage inside your sessvars by mistake. The actual data you set will be available for other scripts on other domains to look at – and also to anyone able to type javascript:alert(window.name) in the browser’s address bar
Thursday, April 17th, 2008
Category: JavaScript, Security
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:
JAVASCRIPT:
-
-
$('#form').fingerprint();
-
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.
JAVASCRIPT:
-
-
$('#form').fingerprint(function(timeStamps){
-
// .. process the timespamps here
-
});
-
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!
Thursday, April 10th, 2008
Category: Browsers, IE, Security
Microsoft has put out a set of security updates, and one of them is discussed in a post IE8 Security Part I: DEP/NX Memory Protection.
Over the next several weeks, we’ll blog in greater detail about some of the security improvements in Beta 1, such as the new Safety Filter, greater control over ActiveX controls, and new AJAX features for safer mashups (XDomainRequest and XDM). This is not a complete list of our security investments for the release; we will have more to talk about during future milestones.
Internet Explorer 8 security features target three major sources of security exploits: social engineering, Web server, and browser-based vulnerabilities. This post will cover IE8 Data Execution Prevention (DEP), a feature that mitigates browser-based vulnerabilities.
Eric then goes into detail on DEP:
Internet Explorer 7 on Windows Vista introduced an off-by-default Internet Control Panel option to “Enable memory protection to help mitigate online attacks.†This option is also referred to as Data Execution Prevention (DEP) or No-Execute (NX).
We have enabled this option by default for Internet Explorer 8 on Windows Server 2008 and Windows Vista SP1 and later.
DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. No additional user interaction is required to provide this protection, and no new prompts are introduced.
They also posted about:
Monday, April 7th, 2008
Category: Browsers, Firefox, Security
It seems to make sense to add crypto helpers to the browser, for use by us, the humble JavaScript developer. I have called out to this in the past and people bring it up often on various lists.
Brad Neuberg found that Gecko actually has built-in crypt primitives via window.crypto!
Mozilla defines a special JavaScript object to allow web pages access to certain cryptographic related services. These services are a balance between the functionality web pages need, and the requirement to protect users from malicious web sites. Most of these services are available via the JavaScript window object as window.crypto. For instance, to obtain a ten byte random number using the cryptographic engine, simply call:
JAVASCRIPT:
-
-
var myrandom = window.crypto.random(10);
-
Services are provided to enable: smart card events, generating certificate requests, importing user certs, generating random numbers, logging out of your tokens, and signing text.
Monday, March 31st, 2008
Category: Performance, Security
Douglas Crockford would like to see a hash= attribute to aid security and performance:
Any HTML tag that accepts a src= or href= attribute should also be allowed to take a hash= attribute. The value of a hash attribute would be the base 32 encoding of the SHA of the object that would be retrieved. This does a couple of useful things.
First, it gives us confidence that the file that we receive is the one that we asked for, that it was not replaced or tampered with in transit.
Second, browsers can cache by hash code. If the cache contains a file that matches the requested hash=, then there is no need to go to the network regardless of the url. This would improve the performance of Ajax libraries because you would only have to download the library once for all of the sites you visit, even if every site links to its own copy.
Thursday, March 20th, 2008
Category: Browsers, Gears, Security
Originally posted on my personal tech blog
When I was looking over Brad Neuberg’s Paper Airplane thought experiment I noticed the single sign on feature, where you login to the browser, and then you are done.
I realized that this is what I actually want. Having one signon via OpenID is really nice. It allows me to plug in “http://almaer.com†as my identifier. However, I always have to go around finding the OpenID option (if it exists) and put that in.
What I really want is for the browser to do that work for me. If a site groks OpenID the browser should be able to pass that over without having me intervene at all. It could hide the entire login process if we came up with a microformat to let all sides know what is going on.
It would be a breath of fresh air to be able to jump through sites leaving comments on blogs, and checking out my todo list, all without me once having to actually login.
I wonder if a Gear could be made with a complementary microformat / server side handshake that could then give us single sign-on in all of the browsers.
As Brian McCallister suggests:
HTML:
-
-
<link rel="openid-auth" href="..." />
-
Does this make any sense? Would you like the browser to handle all of this for you? I would.
Friday, February 29th, 2008
Category: JavaScript, Security
Malte Ubl has put together a library called xssinterface (somewhat scary name) that uses postMessage when available, and tries work-arounds when not, to give you cross domain JavaScript access.
How it works
For Browsers that support it, we use the postMessage() interface.
For all other browsers, we use the following mechanism:
All sites that participate in the cross domain calls must provide an html file (cookie_setter.html) that is provided by this library that enables other domains to place certain cookie under the domain of the site.
The library uses this mechanism to place cookies on the target domain that are then read and evaluated by the target page.
Pages must explicitly grant access to their domain by setting a security token cookie under a domain that is allowed to access the callbacks.
As a caller you say:
JAVASCRIPT:
-
-
function sayHello() {
-
var caller = new XSSInterface.Caller("www.two.com","/cookie_setter.html","channel1");
-
caller.call("hello", "Hello World")
-
}
-
As the listener:
JAVASCRIPT:
-
-
window.onload = function () {
-
window.xssListener = new XSSInterface.Listener("1234567890","channel1");
-
window.xssListener.allowDomain("www.one.com", "/cookie_setter.html");
-
window.xssListener.registerCallback("hello", function (msg) {alert(msg)} )
-
window.xssListener.startEventLoop()
-
}
-
It would be nice if the library used cross domain workers if Gears is installed.
Wednesday, February 13th, 2008
Category: Accessibility, Examples, JavaScript, Security, Unobtrusive JS
I've just come across a solution for badges on web sites that makes it terribly easy for implementers. The idea is that the implementer could add a badge wherever they want in an HTML document, choose the look and feel and add a message to be shown. The implementation code is the following:
HTML:
-
-
<script src="badge.js" size="small" skin="blue">Brandname
</script>
-
The badge script then replaces the script node with the badge using the settings defined for each script include. Clever, right? Well, almost. Security concerns and invalid HTML aside (the attributes - content inside a script is valid and should be ignored according to the W3C when a src attribute is present) there are many more issues with this:
- you need to loop through all script nodes, read the info and create the correct badge - this can get slow
- the badge.js script gets called over and over again, even if it is only needed once (granted, it will be cached)
- every script inside a body makes the rendering engine stop, pull the src and try to execute either that or the content of the node - this makes for terrible performance.
I've written up an example of how the above works and three alternative solutions that work around these issues.
What do you think? Should the ease of implementation be the success factor or the performance for the end user?
