I know it’s obvious, but we tend to forget it and happen to expect technology to be secure just like that, from the very moment of its conception in inventor’s mind. The sad reality is that even technologies designed to provide better security happen to be insecure themselves. The trouble is, as it seems, that it’s considerably difficult to see all the possible weaknesses from the very beginning, especially when functionality is a lot more of a concern then the security.

So, just face it — once we develop a brand new technology it nearly always has fundamental flaws (think web scripting and all the SQL injections, XSS (Cross Site Scripting), etc.) It was essentially the same with coding “normal” applications — it’s been full of buffer overruns, integer overflows, format string vulnerabilities, etc. But then, after something like ten years, ideas like sandboxing or managed code caught on and seem to be doing a fairly good job. Interpreted languages with high level of abstraction in managing memory started to become efficient enough to be of any use. Programmers learned how to properly use standard APIs. And finally the trouble with memory management slowly started to be less and less painful.

Adding it to the fact that the new and much easier to exploit vulnerabilities emerged, everybody slowly turn their back to the old good buffer overruns and such. Instead we have XSS, CSRF (Cross Site Request Forgery), SQL Injections and the family.

But what will happen to it in time? Of course, it will slowly become harder to exploit. Smarter web developers already started using robust frameworks reducing the possibility of introducing web-era vulnerabilities into their code. The world slowly learns how to use web IDS/IPS systems. And generally, we get more and more secure every day.

But what will happen next? Some brand new, shiny technology everyone sooo wants to use will pop-up, no doubt about it. And we’ll have the same trouble again. Unless of course the security gets designed into the technology from the very beginning (not likely to happen, unfortunately) or unless we let it mature before running an internet banking site on it. It won’t be cutting edge then anymore — true, but isn’t it better that someone else flies the plane the first time?

So, here is the trade-off — you either wait for enough people to get burnt while trying out the new toy before you put your hands on it, or you are the one that others watch getting burnt. It’s always like that, I’m afraid. And I think the best advice here is to know how much you are risking before you decide either way.

Let’s talk a bit about session riding also referred to as Cross Site Request Forgery (XSRF). It seems to be as common of a vulnerability as it is underestimated in terms of a risk it poses to the data kept in and processed by the application.

The general idea behind the attack is to execute certain command in a legitimate user’s authentication context, thus saving the trouble of hacking into an application the hard way. It’s all about convincing a user, preferably with the highest access privileges possible, to enter a maliciously forged URI or webpage while their session in the vulnerable application is active (i.e. they are logged-in and have a valid session cookie).

As a supplement to my recent post on XSRF and to kind of give a complete picture — if there is a lot of money on stake, or if we are paranoid (which is not so good, but not too bad either) we can always decide to use an additional, independent channel when authorising extra-sensitive operations.

Even better, this kind of approach should prove useful defending against most of the attacks that aim to overcome authorisation controls in order to gain unauthorised access to sensitive data or to perform an unauthorised operation, like, say, wire-transfer all your money to a bank account somewhere over in Caymans.

You may ask, how is it that we are sure about the additional channel’s security. Well, it would be great if we could be sure about it, but usually we can’t. But it’s not the point. The point here is that an additional separate — and verified! — channel makes it much more difficult for an attacker to perform their malicious activities, as they need to take over both of them in order to succeed (say, intercept an SMS message and inject their own in its place — although doable, it takes a lot of effort and money). Think of it as a way of re-authenticating before a security-critical task, but performed out of bound.

And, of course, it’s not aiming on being so bulletproof that having all the money in the world would not be enough to overcome it. It’s just to much of an effort and, after all, there are easier targets out there, so why bother.

On the other side though, it’s an additional burden for a user, so, I think what is most important here, is to know when to apply this kind of a control and when it’s too much.

I’ve just translated the slides that I used during the talk about web security that I gave together with Borys Łącki at the first ISSA Polska meeting in Wrocław into English.

Have fun!