Joe Walker - ajax tag

Web Application Security

Mon, 29 Oct 2007 11:00:51 GMT

A few people asked for slides and links from the security talk from The Ajax Experience last week:

| View | Upload your own

General Links:

OWASP: Open Web App Security Project
Security Resources from the OpenAjax Alliance Wiki
Mozilla on Same-Origin Policy

XSS:

Introductions from: Wikipedia and Apache
Cheat Sheet: Long list of XSS vectors from RSnake
Explanation of DOM Based XSS
Explanation of Samy is my Hero worm
Fairly old FAQ at CGI Security
List of XSS holes in popular web applications

CSRF:

Introduction from: Wikipedia and here
Article by Chris Shiflett and CSRF Redirector test tool
CSRF FAQ at CGI Security
Array constructor overriding and setter overriding
A solution: SameRefererOnly
Protecting a JSON or JavaScript Service

Blogs:

The Hardware of Tomorrow Versus the Platform of Tomorrow

Tue, 23 Jan 2007 20:48:33 GMT

It seems to me that there is a problem. The OS/platform of tomorrow is not designed to make good use of the hardware of tomorrow.

The Hardware of Tomorrow

In 2003 the hardware race was about GHz, and the clock wars. AMD and Intel competed on their clock speed, and people checked off clock speed advances against Moore's Law. In 2006 the battle lines began to be re-drawn around cores rather than clocks; Dual Core became the norm for new processors, and the next generations of chips from both AMD and Intel will be steadily increasing the number of cores. Intel and AMD have slightly different strategies, Intel is going for more generalized processing units, AMD (having bought ATI) are choosing to make their processing units more specialized.

So the hardware of tomorrow is going to work best with software that encourages multi-threading. Java's memory model and util.concurrency make it technically strong, and Billy Newport thinks that framework developers will need to alter their APIs to take advantage of the threads. He's probably right, but I suspect that to do a proper job, we're really going to need a language that builds multi-threading in at a lower level, leaving the compiler with the job of creating multiple execution paths. However that's not going to be quick.

Cringley 2007 Prediction 5:
AMD and Intel continue to beat the crap out of each other with customers gaining but wondering why there is no software that supports those new 8-way processors, as both compilers and third-party developers fail to keep up.

Knowing this, Cringley's 2007, prediction #5, is a bit of a no-brainer.

Today, even just dual cores, one core spends a lot of time idle. Anyone spending any time waiting for javac to do it's work will be wishing it did a better job of using more than one processor. The "multi-threaded is hard" problem is one of the things killing the PS3 now. The PS3's cell processors seem to be too advanced for most of the games manufacturers right now.

So if the hardware of tomorrow is going multi-threaded, what about the platform that developers use to write software?

The Platform of Tomorrow

I don't think we are in for any radical changes in platforms in the next few years. We'll continue to have a mix of Windows on the corporate desktop, Linux in the server room, and MacOS for developers, and arty types, and none of them being the primary development platform, which will continue to be the web.

The web is the default place to develop new software these days. If you need raw speed, hardware access, 3D, off-line usage or top-quality OS integration, you'll use something else, but for everything else there's the web.

The problem is that web-browsers are a step backwards as far as multi-threading goes. In Javascript there is no such thing as a new thread, and worse than that, the entire platform (i.e. a browser) runs a single JavaScript thread. If a script in one window goes into a tight loop, or runs some synchronous Ajax then the browser HTML display freezes.

So are the any solutions?

Adding thread primitives to Javascript might technically possible, but it seems to me to be impractical; the single-threaded assumption is built fairly deeply into many applications.
It might be possible for browser manufacturers to create a thread per domain. I don't see how this could cause problems, but I'll admit that I have a suspicion that I'm overlooking something. If it does work then it might be possible to allow developers to create new threads by dynamically creating iframes in other domains and having some safe way to communicate between them.
There is a Javascript pre-compiler called Narrative JavaScript that looks like it might be of some use: it contains a spawn() method to start a new thread of execution. It's written in Javascript so you can deliver the pre-compiler to the browser or deliver the output. However until there is support for something like this at a language level that can exploit newer hardware, it doesn't solve the problem.

The solution that I'd like to see is a language emerging that pushes the job of creating threads to the compiler, that runs on the JVM, and that is available in all browsers. I think I can safely predict that this is not going to happen any time soon though.

So maybe the biggest challenge to Ajax is that compared to desktop applications they are going to look slower and slower as other platforms are quicker to embrace tomorrows hardware.

The 4 States of Ajax Adoption

Wed, 20 Sep 2006 18:14:36 GMT

So the 4 states of Ajax adoption are as follows ...

1. Denial

Usually accompanied with an explanation like "Java Applets are better", or "Javascript makes your website inaccessible to blind people". (Generally I don't buy either argument although I can see a diminishing case for WebStart).

2. Progressive Enhancement

Means taking an existing JavaScript free website and adding some tweaks. It's a conservative approach that won't worry or annoy anyone, but it won't turn any heads either. The BBC, Wikipedia and EBay all use this approach because it's a safe thing to do with a big website.

3. Second Site

The problem with progressive enhancement is that it treats the minority noscript case first. The second site approach provides the best it can for the majority and for the minority too. Google, Yahoo and Amazon create far more advanced systems with this approach. It's likely to cost a bit more, but you're probably going to get a much better site out of it.

4. Accessible JavaScript

The full on approach tries to create accessible sites, but only when JavaScript is turned on. Microsoft's live.com, YouTube and some Google sites do this, and there are some UIs for which there is little choice. Anyone fancy creating office type functionallity without JavaScript?

You can work up the tree, starting out small and getting bigger, and the good news from a DWR point of view is that it can help you each step of the way. DWR is good for small tweaks and a more full on style.

What's your prefered approach?

2 articles on Reverse Ajax

Tue, 05 Sep 2006 13:52:00 GMT

I came across a nice intro to Reverse Ajax with a whole set of simple graphics to explain the interaction.

The blog entry is on the curiously named gmapsdotnetcontrol blog, and we go through the classic and Ajax models (JJG style) with polling and comet before getting to the piggyback model:

And finally the Full Monty Reverse Ajax

For me Reverse Ajax is not so much about the technology on how we get the message to the browser, but more about the programmers interface.

DWR gives you a dead simple set of APIs that dynamically generate Javascript and send the Javascript to one or many browsers asynchronously.

The DWR Chat example has to be the simplest code to do chat anywhere. The full source can be seen through fisheye, but the core goes like this:

WebContext wctx = WebContextFactory.get();
String currentPage = wctx.getCurrentPage();

// Find all the browsers on the current page:
Collection sessions = wctx.getScriptSessionsByPage(currentPage);
DwrUtil utilAll = new DwrUtil(sessions);

// Manipulate all the browsers to repopulate the message list
utilAll.removeAllOptions("chatlog");
utilAll.addOptions("chatlog", messages, "text");

Wikipedia

The other article is based on this one at Wikipedia and they are both based on Jon's original article.

Improving the quality of conference talks

Mon, 21 Aug 2006 10:49:25 GMT

The feedback from techies after my talks is often "Less Powerpoint, more IDE", and also that people get more out of a talk the more they can get involved.

So here is my (evolving) plan for how to deliver some killer talks for The Ajax Experience in October.

I like live coding. It's always a bit seat of your pants, but it's honest and open and the risk that the speaker is taking keeps the audience interested: "Can they pull it off".

So the experiment is taking this up a level. The plan is to run a CVS/SVN server and check-in the code I'm writing. I'm also planning on live coding an interactive application so people with a network connection can both use the app we write and can also check-out the code for themselves.

And while we are at it, why not allow the audience to check code in as well?

What do you think? Could it work? Would you come? Odds on me messing it up?

Also what sort of Ajax / DWR application should we write? It needs to be interactive and fairly simple. Any suggestions?