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: IE, Browsers, 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: Security, Performance
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, Security, Gears
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: JavaScript, Accessibility, Examples, 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?
Thursday, February 7th, 2008
Category: JavaScript, Security
Security should always be a concern when developing client-side applications as time and time again, sites have been compromised by a lack for forethought into how users, especially malicious ones, interact with your site. GNUCitizen.org is an excellent site for staying abreast of new security exploits and the team constantly pushes the boundaries of how to exploit systems in an effort to educate the public and make systems more secure.
GNUCitizen founder pdp just published an article on how to detect malware via the JavaScript global namespace:
Namespace pollution checks are very trivial to perform. The check should be performed from a safer location such as outside of the execution sandbox or somewhere on the top before and after the user input is taken into consideration. The check is very simple really. All that needs to be done is to compare the list of registered objects with the expected list of objects. If they defer, the namespace has been polluted by something. The check can be performed by a function similar to the one discussed by the Atom database over here:
LANGUAGE:
function walkJSON(j, c) {
for (var i in j) {
c(i, j[i]);
if (j[i] instanceof Array || typeof(j[i]) == 'object') {
arguments.callee(j[i], c);
}
}
}
He goes further to explain how malware authors could bypass this check using closures:
LANGUAGE:
(new function (window, document) {
// [evil code here]
})(window, document);
This technique will safely execute malicious code without the need to worry about polluting the whichever namespace, as long as the evil code that is enclosed within the closure does not modify the window or the document objects. DOM manipulation is acceptable since no one is crazy enough to check for DOM changes. The document object is far more complicated and walking its is hard.
So here are some questions for the Ajaxian readers:
- Is this a big issue that merits further attention?
- If so, what can be done to mitigate the risks?
- What are the scenarios in which something like this could occur?
Ajaxian readers are some of the best JavaScript developers out there and I'm positive that collectively, we can determine how high of risk factor this. Either way, it's always good to stay informed and I'm looking forward to seeing more JS security articles from GNUCitizen in the future.
Thursday, January 31st, 2008
Category: JavaScript, Library, Security
Mike Samuel of the Google Caja team (and much more) has a fantastically detailed document on the choices for secure String interpolation in JavaScript.
He spends a lot of time discussing:
There are a large number of examples a long the way:
JAVASCRIPT:
-
-
var ids = [1, 2, 3, 4];
-
var column = 'value';
-
var foo = 'foo';
-
-
open(Template("SELECT $column FROM Table WHERE id IN $ids AND foo LIKE $foo"))
-
// === "SELECT `value` FROM Table WHERE id IN (1, 2, 3, 4) AND foo LIKE 'foo'"
-
Wednesday, January 30th, 2008
Category: Ajax, Security, Book Reviews
Brian Dillard of Agile Ajax has a review of Billy Hoffman's new book "Ajax Security". If you've not picked this book up, you really need to. It's received rave reviews and is quickly becoming the must-have security book for client-side development. As Brian can attest:
The book itself, of course, documents dozens more specific security vulnerabilities - as well as best practices for protecting your application against them. I said it before, and I'll say it again: "Ajax Security" is required reading for any professional software engineer.
Be sure to read Brian's review and be sure to get the book.
Sunday, January 20th, 2008
Category: Security, Widgets
O'Reilly Radar comments on the dangers of remote scripting:
We at O'Reilly just got bit on perl.com, which redirected to a porn site courtesy a piece of remotely-included Javascript. One of our advertisers was using an ads system that required our pages to load Javascript from their site. It only took three things to turn perl.com into porn.com: (1) the advertiser's domain lapsed, (2) the porn company bought it, (3) they replaced the Javascript that we were loading with a small chunk that redirected to the porn site (note that nothing on or about perl.com changed). Our first concern was that we'd been hacked and "run this remote Javascript" inserted from our servers without our knowledge, but that hadn't happened—our change records and RT logs show we've had that Javascript and advertiser since May 2006.
There's nothing especially new about this; the external Javascript model has always been in place, long before Ajax and widgets. Yet, with widgets taking off, more and more users and developers are cutting-and-pasting script tags into their web pages, pulling in code from a wide variety of providers, big and small. How well equipped are publishers to decide which is safe and which is not, and deal with situations like O'Reilly experienced, where someone takes over an expired domain?
Monday, January 14th, 2008
Category: Library, PHP, Security
HTML Purifier 3.0 has been released.
What is HTML Purifier?
HTML Purifier is a standards-compliant HTML filter library written in PHP. HTML Purifier will not only remove all malicious code (better known as XSS) with a thoroughly audited, secure yet permissive whitelist, it will also make sure your documents are standards compliant, something only achievable with a comprehensive knowledge of W3C's specifications.
What's new in 3.0?
Release 3.0.0 is the first release of 2008 and also HTML Purifier's first
PHP 5 only release.
The 2.1 series will still
be supported for bug and security fixes,
but will not get new features. This release a number of
improvements in CSS handling, including the filter
HTMLPurifier_Filter_ExtractStyleBlocks which integrates
HTML Purifier with
CSSTidy for cleaning style sheets
(see the source code file for more information on usage), contains
experimental support for
proprietary CSS properties with %CSS.Proprietary, case-insensitive
CSS properties, and more lenient hexadecimal color codes. Also, all code
has been upgraded to full PHP 5 and is
E_STRICT clean for all versions of PHP 5 (including the
5.0 series, which previously had parse-time errors).
You can run a live demo to see it at work.
Thursday, January 10th, 2008
Category: XmlHttpRequest, Security
John Resig has written up documentation of Cross-Site XMLHttpRequest that discusses the W3C Access Control working draft which Firefox 3 implements.
He gives us a nice example:
In a nutshell, there are two techniques that you can use to achieve your desired cross-site-request result: Specifying a special Access-Control header for your content or including an access-control processing instruction in your XML.
In HTML:
PHP:
-
-
<?php header('Access-Control: allow <*>');
?>
-
<b>John Resig</b>
-
In XML:
XML:
-
-
<?xml version="1.0" encoding="UTF-8"?>
-
<?access-control allow="*"?>
-
<simple><name>John Resig</name></simple>
-
And the XHR code itself isn't different from any other XHR code:
JAVASCRIPT:
-
-
var xhr = new XMLHttpRequest();
-
xhr.open("GET", "http://dev.jquery.com/~john/xdomain/test.php", true);
-
xhr.onreadystatechange = function(){
-
if ( xhr.readyState == 4 ) {
-
if ( xhr.status == 200 ) {
-
document.body.innerHTML = "My Name is: " + xhr.responseText;
-
} else {
-
document.body.innerHTML = "ERROR";
-
}
-
}
-
};
-
xhr.send(null);
-
Some are excited to see the cross domain work, and some are concerned.... e.g.
I agree with Thomas. I never understood the NEED to modify the client security model to allow for this. If this is something the software needs to do, then the developer can implement a proxy on the server side. At least in this way the developer has sole discretion on the connections. Just more to go wrong if you ask me.
-
I'm still under the impression - and correct me if I'm wrong - that all these means are tailored to protect the server and its documents. But I thought the issue was to protect the client!
-
What exactly is the reason we need this? Has anybody here really understood why XMLHttp is currently limited to one host and cannot communicate cross-domain? I really do not understand that. If XMLHttp cannot do this by default, why it is still possible to load scripts and images from other servers? Why can I do exactly the same type of cross-domain communication using Flash, maybe using Silverlight in the future? What is the original reason for this limitation? Is this documented anywhere?
If, as mentioned in the spec, HTTP DELETE is problematic, because it may delete data, why cannot we filter such actions when detecting a cross-domain communication? GET and POST are possible in the same way when submitting simple form. It is even possible to generate these form elements dynamically. And this also works cross-domain. At least these two HTTP methods should be enabled by default to allow cross-domain communication. The open web, as often mentioned by Alex Russell, really needs features comparable with closed source software e.g. Flash or Silverlight.
-
I agree with those saying that this spec is misguided. But bothering users too much is also not good. How are they to know in every case what things mean?
What do you think?
