Dave McDermid » websites http://www.davemcdermid.co.uk Just another WordPress weblog Tue, 19 Jan 2010 00:59:30 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Simple steps for security http://www.davemcdermid.co.uk/2009/06/simple-steps-for-security/ http://www.davemcdermid.co.uk/2009/06/simple-steps-for-security/#comments Wed, 03 Jun 2009 08:52:28 +0000 admin http://www.davemcdermid.co.uk/?p=58 Security is a complicated monster to tackle, so it helps to think about it in really, really basic terms. Stuff comes in, stuff goes out. We have to assume that anything that comes from the user is dangerous, or tainted, and can’t be trusted in any way what so ever. We don’t even know for sure that the user is who they claim to be. Trust no-one. We also have to be 100% sure that anything we send back to the user is safe, un-tainted, and uncompromising. You don’t want to send dodgy scripts to your users, and neither do you want to send back valuable clues to the inner workings of your code. This is not meant to be an all-encompassing guide to preventing attacks, but instead a set of guidelines to writing applications in secure way.

Minimise

The first rule is this. Minimise areas that accept input from the request, and minimise areas that send response. Sanitisation and validation should be the first thing you perform on data received and the last thing before you return it. Following a sensible architecture such as the Model View Controller approach separates data received by the Controller area and data returned to the View. This will make your life far simpler when you start tackling such issues. This applies to all forms of input (form data, querystrings and cookies) and all forms of output (HTML, redirect, file download).

Validate

A commonly overlooked validation is confirming the data has been intensionally sent from the user. There’s nothing to stop a 3rd party website posting to your website, so it doesn’t matter how secure your login form is, the posted data could be coming from any of the dodgy websites your user has open. An easy solution is to use a random key as part of every posted form, unique to the users session. This way you can easily verify the form has been posted from a tightly controlled page you served to your user. It’s not enough to look at referrer headers, because these are easily faked. ASP.Net web forms, to their credit, do this by default.

Use White-lists over Black-lists. Lets say for example you’re validating a phone number, you don’t specifiy every non-digit character you want to remove, you strip everything that isn’t 0-9. A little too obvious? The same applies to the classic script tag. If you start trying to remove every form of <script> tag, you’ll end up playing catch-up against tricks using <img>, <body> and clever encoding. If allowing any kind of HTML through is necessary, you’d better be damned sure who submitted it and who is going to be able to see it.

Storage

So you’ve received your data, it looks pretty good. Whatcha gonna do with it? If it’s heading towards a database, you can’t be too careful. Escape it, or better yet use parameterised queries. If it’s the file system that your data is ending up, put it somewhere sensible. Ideally, this would be somewhere outside of your webroot, or in a protected folder. Whatever happens, you don’t want anything here directly accessible or executable. Just to be sure.

Responses

OK, so we’re sending a response. Just because the data we received passed our tried-and-tested validations doesn’t mean it’s safe to send back to the user. We HTML encode everything, unless absolutely necessary. If it’s plain text, fairly straight forward. If you’re putting suspect data into an HTML attribute, it might be an idea to verfify the format. If you think you’re outputting an SRC or HREF, check it at least looks like a path. If your response happens to be a redirect, double check nothing funny is going on with the URL. If your response is a (serious) error, make it look friendly, but don’t give away exactly what went wrong. If you want to send them a file, attaching it and manually setting the MIME type is more controlled to simply pointing them at the file.

This is not intended as a set of golden rules, rather a few key points to help you think about the code you write. Most new forms of injection and hackery are just clever ways of attacking poor code. Writing sensible code will keep you one step ahead of such attacks.

]]> http://www.davemcdermid.co.uk/2009/06/simple-steps-for-security/feed/ 0 Of Patterns, Probabilities and Palindromes http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/ http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/#comments Mon, 26 Jan 2009 19:53:12 +0000 admin http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/ We discovered an interesting little problem last week. Interesting, that is, if you enjoy Maths a little more than is healthy. I was interested because what seemed to be a random problem when it should have been consistent, turned out just to be a random problem.

So here is what was happening. Our Sitewatcher was randomly showing a few sites returning 404 (page not found) errors. This was curious, because it was requesting the home page, and this page was certainly not missing. As it happens, there is a tiny weeny glitch with a couple of sites in that they will return a 404 code on the home page if the number 404 features in the query-string. This doesn’t happen in normal circumstances, but as cache:false was being used with jQuery, it was appending a random number to the request.

So here is the question. What is the probability of the number 404 occurring in a random 10 digit sequence? Not so trivial. Particularly because the number is itself is a palindrome. It can overlap itself, causing the number to appear as often as 4 times, making the calculation a little tricky.

We reckoned, by rough estimations, for it to be 1 in ~125, but no doubt a serious mathematician can enlighten us.

]]> http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/feed/ 0