Recently in Web Security Category

I've been meaning to do a post on burp for a while, and courtesy of my new years resolution to stop procrastinating, here it is :)

I was thinking of a way to sum up burp, so far the best I've got is "If you're doing web application testing and not using Burp, you're missing out !", it is that useful...

Burp has been around for a while now as one of a group of handy web application proxy tools along with the likes of Web Scarab and Paros. Over time it's developed a huge range of handy features, which make web app. testing a lot more productive.

There's the basics, in terms of intercepting and modifying requests, which all the tools in this category tend to do quite well, but on top of that there's just loads of other things that Burp does.

The Web app scanner is a good targetable way to test for several types of common web app vulnerabilities. As an add-on in the latest beta, there's a wizard which lets you reduce the number of requests that Burps going to make, by removing duplicates and similar requests. If you've used many commercial web app. scanners you'll know that volume of requests generated can be a real problem, so anything that can help bring down the load is useful.

Another stand-out feature of Burp for me, is intruder which lets you pick a specific parameter or set of parameters from a request and easily modify them. As an example pretty much every time I see a URL that looks like request.asp?id=123 , it's going to be worth running burp Intruder over that parameter to see what pops up when you change that value.

One of the things I have found about burp is that it's easy to miss functions that are available and not get the best out of it. Luckily there's a blog which covers a lot of the new features as they come out. Also I need to mention the Burp Tip of the Day series of posts on Cktricky's blog which has loads of good tips on getting more out of Burp.

All the Scotland on Rails videos are now online here courtesy of the nice folks at Engine Yard.

The video for my presentation is here , slides are on slideshare over here

It was the Scotland on Rails 2009 conference on Friday/Saturday of last week. A great couple of days with loads of interesting Ruby and Rails talks (I'm planning more of a recap once the videos are out)

I presented on Web Application Security (slides here), which seemed to go down reasonably well.

One of the main themes of my presentation was that, whilst Rails provides a variety of mechanisms to help developers to create secure applications, it still leaves a lot to the individual to think about, and relies on implementation of the protection that it provides.

One major example of this it Rails default protection mechanism from XSS which is the h() function. This HTML encodes the contents of the argument passed to it. This is an effective defense against XSS but relies on developers to use it consistently, which can be tricky to remember.

There's a couple of potential ways for improving this situation with plugins.

The Safe ERB plugin is designed to help developers by raising an exception when information pulled from an ActiveRecord model is displayed in a view without h() being used.

The other way to approach the problem of XSS is to validate input when it's passed to the application. There are a number of Rails plugins which take this approach including Sanitize Params and XSS Terminate

I had an interesting conversation/debate over on reddit today on the topic of input handling and I thought it was worth posting up.

Essentially there are two approaches handling data in an web applications.

1. Carry out input validation as the data enters your application. This can either be white-list (only allow "known good" data types), or black-list (try to block "known-bad" data types)
2. Carry out output normalization on the data as it leaves your application. Here you look to understand the special or "meta" characters for the type of system or data format that you are outputting to and ensure that the data is encoded or rendered in such a way that it can't have a negative effect on that output system.

So which of these approaches is better? Well my view on that after my discussion is that they both have pros and cons, which need to be considered before making a choice.

Input Validation

Pros: The advantage of white list input validation is that, in a lot of cases, you can relatively easily cut down the number of attacks that will be effective against an application with minimal effort. For example if you're not taking in mark-up (eg, HTML) in any part of your application then stripping or blocking the < and > characters from your input will drastically reduce your exposure to Cross Site Scripting. This is the approach that .NET request validation takes.

Cons:The problem with input validation is, it can never take account of all possibilities. It's impossible to know when you take input into the application, how that data will be used and exactly where it will be processed in future, so there's always a risk that it will miss some class of character which turns out to be important to a given format

Output Normalization

Pros: So essentially the opposite applies. The advantage of output normalization is that it can take into consideration the exact nature of the system that the data is being passed to and can ensure that the data it's passing will not have a negative effect. This kind of approach can be seen in HTML encoding function like h() in Ruby on Rails.

Cons: Essentially for me the major downside here is a practical one. A security control that needs to be implemented many times to be effective is one that is likely to be forgotten and because under ordinary conditions the application is likely to behave perfectly even though the control isn't in place, a developer may well not notice the problem until it's too late. You can see this kind of effect in a lot of web applications. I've seen many cases where the obvious areas of the application (form fields) have been covered for things like Cross Site Scripting, but more obscure areas (drop-downs, cookies, HTTP headers) get missed out, either because the developer forgets, or because they don't realise that those areas of the application are susceptible to attack

So which of these approaches would I recommend..... Well I'm a security person, so I'll say Both for defence in depth!

Beyond that I'd say that Input validation is a great first step and will cut down the practical attacks greatly, but if you're looking for a "perfect" approach then you'll need to add output normalization to the mix...

I'm doing some research at the moment for a presentation I'm doing for the Scotland on Rails conference, later this month. As part of that I've been downloading some sample Rails applications to get an idea of common security issues that I can discuss.

Interestingly on popular applications that I've downloaded so far, I'm 2 for 2 on the exact same problem.

Both of them have XSS vulnerabilities from the user-->admin sides of the site. So the end-user pages have output encoding to restrict XSS but the admin sections don't consistently provide the same protection.

It's also interesting that both applications seem to be relying on output encoding as a defence as opposed to input validation. In my experience the best defence is a combination of the two...

Of course that leads to some potentially nasty exploits around stealing admin credentials from the site in question. Hey looks like I'll have some stuff to talk about anyway :)

1 Raindrop: Understand Web 2.0 Security Issues - As Easy as 2, 1, 3

Very good points made in this post. At the moment the probablw saviour for a lot of transactional sites is that they've been really slow on the bandwagon, so are still running web 1.0 style sites!

That said, the more information that comes out from researchers like Jeremiah Grossman and RSnake the less faith people can really have in the browser security model that most E-Commerce sites rely on.

What's been missing to date is the Slammer or Nimda of the web application hacking world. Without a wide-ranging attack like that, it will continue to be very difficult to convince a lot of businesses to take these threats seriously...

Interesting post from Nitesh dhanjani here pointing out a problem with Gmail contact lists being available to malicious website owners.

Now this only works if you're logged into gmail, but if you've used it recently and not explicitly logged out... then it'll keep you logged in...

Now google should obviously fix this problem, but I think that there is a wider point here. Don't leave yourself logged in to websites and be very wary about what you let your browser manage for you security-wise as it's not very security wise (oh I crack myself up ;o)