<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Dave McDermid &#187; programming</title>
	<atom:link href="http://www.davemcdermid.co.uk/tag/programming/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.davemcdermid.co.uk</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Tue, 19 Jan 2010 00:59:30 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Simple steps for security</title>
		<link>http://www.davemcdermid.co.uk/2009/06/simple-steps-for-security/</link>
		<comments>http://www.davemcdermid.co.uk/2009/06/simple-steps-for-security/#comments</comments>
		<pubDate>Wed, 03 Jun 2009 08:52:28 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Web programming]]></category>
		<category><![CDATA[programming]]></category>
		<category><![CDATA[security]]></category>
		<category><![CDATA[websites]]></category>

		<guid isPermaLink="false">http://www.davemcdermid.co.uk/?p=58</guid>
		<description><![CDATA[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 [...]]]></description>
			<content:encoded><![CDATA[<p>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.</p>
<h4>Minimise</h4>
<p>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).</p>
<h4>Validate</h4>
<p>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.</p>
<p>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 &lt;script&gt; tag, you’ll end up playing catch-up against tricks using &lt;img&gt;, &lt;body&gt; 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.</p>
<h4>Storage</h4>
<p>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.</p>
<h4>Responses</h4>
<p>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.</p>
<p>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.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davemcdermid.co.uk/2009/06/simple-steps-for-security/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Ask yourself why</title>
		<link>http://www.davemcdermid.co.uk/2009/03/ask-yourself-why/</link>
		<comments>http://www.davemcdermid.co.uk/2009/03/ask-yourself-why/#comments</comments>
		<pubDate>Wed, 04 Mar 2009 22:45:09 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Musings]]></category>
		<category><![CDATA[programming]]></category>

		<guid isPermaLink="false">http://www.davemcdermid.co.uk/?p=47</guid>
		<description><![CDATA[When it comes to writing really helpful comments in code, the only important question is why. It&#8217;s all too easy to make a quick note of what or how the block of code may work, but usually this ain&#8217;t too tricky to figure out. Coming back to old code, it&#8217;s the though process behind the [...]]]></description>
			<content:encoded><![CDATA[<p>When it comes to writing really helpful comments in code, the only important question is why. It&#8217;s all too easy to make a quick note of what or how the block of code may work, but usually this ain&#8217;t too tricky to figure out. Coming back to old code, it&#8217;s the though process behind the logic that you wish you understood.</p>
<p>Whether it&#8217;s Style sheets, javascript or .Net, at some point in the development decisions require thinking outside the box, or working in a counter intuitive way to solve a weird problem. This is the snippet of understanding that needs to be captured to ensure the next time the code is looked at, it makes a little more sense.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davemcdermid.co.uk/2009/03/ask-yourself-why/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>A conflict of objectives</title>
		<link>http://www.davemcdermid.co.uk/2009/02/a-conflict-of-objectives/</link>
		<comments>http://www.davemcdermid.co.uk/2009/02/a-conflict-of-objectives/#comments</comments>
		<pubDate>Sun, 15 Feb 2009 18:19:28 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Musings]]></category>
		<category><![CDATA[programming]]></category>
		<category><![CDATA[team]]></category>

		<guid isPermaLink="false">http://www.davemcdermid.co.uk/?p=45</guid>
		<description><![CDATA[During particularly tight projects, particularly those for valued clients or high profile websites, there is often a tension between the project manager and the developer. This is my experience, anyway. The reason for this is pretty straight forward, and understanding this is key to a productive relationship. The project managers objective is to make the [...]]]></description>
			<content:encoded><![CDATA[<p>During particularly tight projects, particularly those for valued clients or high profile websites, there is often a tension between the project manager and the developer. This is my experience, anyway. The reason for this is pretty straight forward, and understanding this is key to a productive relationship. The project managers objective is to make the client happy. For them, this means keeping the developer focussed and on track to complete the work within the time allocated. For the developer the objective is less clear. On the one hand they must keep their project manager happy, by producing work the client will like, even be excited about. On the other hand, they have a responsibility to produce good, clean, manageable code.</p>
<p>The favoured approach is far too often the quick and dirty solution that gets the work done and paid for with a healthy margin. This is great until the project is revisited, and invariably it will. As average solution on top of average solution builds up, there comes a point when something breaks and there is no easy fix. Often, there is nothing the developer would rather do than scrap a bunch of code and rebuild it from the ground up. This is invariably time consuming, and frightening for the poor sod who&#8217;s job it is to test it all. There is also the consideration of who swallows the cost of this, as the client / project manager won&#8217;t see the immediate benefit of this kind of work, making it hard to justify.</p>
<p>The dangerous middle ground is the point at which trivial tasks become time consuming with unexpected repercussions and legacy code wrecks havoc with a beautiful solution. This guarantees stress for all involved and can strike fear into the heart of anyone threatened with involvement in the project.</p>
<p>So, what&#8217;s the solution? I had the first half of this post all planned out in my head, but now I&#8217;m kinda winging it. One solution is progressive deprecation. The strategy here is when tasked with implementing a new feature for project, to decide not only what needs to be built to fulfil the requirements, but what existing parts can be made redundant in the process. The process of evolution within a project critically must involve replacing old code with new, rather than just adding to what exists.</p>
<p>There is understandably a fear shared between the PM and the developer for work that stretches the scope of a job. At the end of the day, it boils down to the developer&#8217;s responsibility to look after his work. The projects I feel really good about are the ones where I&#8217;ve left the code in a better state than when I started. Often it&#8217;s tricky to convey this achievement to a PM, who is generally only interested in things that they can show off to the client.</p>
<p>This is where peer review among developers really comes into it&#8217;s own. I know from personal experience I write better code and make better technical decisions when part of a team. This is natural, it taps into the desire to show off and prove your worth to colleagues and when harnessed correctly can be powerful.</p>
<p>Thanks for reading, would be interested to hear your thoughts..</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davemcdermid.co.uk/2009/02/a-conflict-of-objectives/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Of Patterns, Probabilities and Palindromes</title>
		<link>http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/</link>
		<comments>http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/#comments</comments>
		<pubDate>Mon, 26 Jan 2009 19:53:12 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Musings]]></category>
		<category><![CDATA[maths]]></category>
		<category><![CDATA[probability]]></category>
		<category><![CDATA[programming]]></category>
		<category><![CDATA[websites]]></category>

		<guid isPermaLink="false">http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/</guid>
		<description><![CDATA[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 [...]]]></description>
			<content:encoded><![CDATA[<p>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.</p>
<p>So here is what was happening. Our <a href="http://www.davemcdermid.co.uk/2009/01/air-time/">Sitewatcher</a> 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&#8217;t happen in normal circumstances, but as <a href="http://docs.jquery.com/Ajax/jQuery.ajax#options">cache:false</a> was being used with jQuery, it was appending a random number to the request.</p>
<p>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.</p>
<p>We reckoned, by rough estimations, for it to be 1 in ~125, but no doubt a serious mathematician can enlighten us.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.davemcdermid.co.uk/2009/01/of-patterns-probabilities-and-palindromes/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>AIR time</title>
		<link>http://www.davemcdermid.co.uk/2009/01/air-time/</link>
		<comments>http://www.davemcdermid.co.uk/2009/01/air-time/#comments</comments>
		<pubDate>Mon, 05 Jan 2009 22:00:05 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Headscape]]></category>
		<category><![CDATA[AIR]]></category>
		<category><![CDATA[programming]]></category>

		<guid isPermaLink="false">http://www.davemcdermid.co.uk/?p=37</guid>
		<description><![CDATA[Christmas eve. Work was off to a slow start, hindered first by the office Wii, then by table football, and it was only 9.30am. While the rest of the company was at home winding down and preparing for Christmas, Craig &#38; I decided to spend our last few hours on a side project, an Adobe [...]]]></description>
			<content:encoded><![CDATA[<p>Christmas eve. Work was off to a slow start, hindered first by the office Wii, then by table football, and it was only 9.30am. While the rest of the company was at home winding down and preparing for Christmas, <a href="http://cargowire.net/">Craig</a> &amp; I decided to spend our last few hours on a side project, an <a href="http://www.adobe.com/air/">Adobe AIR</a> app. We&#8217;re the life and soul of Headscape, there&#8217;s no doubt.</p>
<p>Although I&#8217;d delved into the world of AIR before, I hadn&#8217;t really had a proper reason to create something. Our idea was simple, a site watcher. All it had to do was fire off requests to various sites and check the response code. Easy. We could build this with HTML and Javascript no problem. Throw in <a href="http://jquery.com/">JQuery</a> and you&#8217;re laughing.</p>
<p>The great thing about writing for AIr is that you&#8217;re coding for one rendering engine, and it&#8217;s webkit. This means writing webkit specific CSS rules completely guilt free. Rounded corners and RGBA can make your design pretty without many images. JQuery&#8217;s AJAX library is fantastic, it takes the pain out of requests and helps the code stay clean and readable. Within an hour we had a simple app running.</p>
<p>So we kept going. Using a plugin for JQuery the list became sortable, and the list of sites to watch was imported from an XML file. We created a private twitter account to keep a history of changes, and allow notifications via any standard twitter client. We also added a notification window so the app could be run in the background.</p>
<p>The experience was quite enjoyable, and relatively pain free. The only minor annoyances are having to develop CSS / JS without Firebug, but we managed. <a href="http://aptana.com/">Aptana</a> studio made for a competent IDE, and it&#8217;s code assistance is handy. Would definitely recommend giving it a whirl if you&#8217;re at all interested.</p>
<p>The AIR app is now available to download form <a href="http://boagworld.com/technology/our_first_air_app/">Boagworld.com</a>: <a href="http://www.boagworld.com/downloads/sitewatcher.air">Download site watcher AIR application</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.davemcdermid.co.uk/2009/01/air-time/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>
