AddedBytes.com

LetMeGoogleThatForYou Bookmarklet

dave@addedbytes.com — Sat, 22 Nov 2008 08:07:46 GMT

I'm sure someone must have already done this and I'm just incapable of finding it (despite Googling it myself) but I figured that the only thing missing from the brilliant LetMeGoogleThatForYou was a bookmarklet, so I made one: LetMeGoogleThatForYou. Highlight text, click bookmarklet and voila - patronisation on demand.

Blogging in Business

dave@addedbytes.com — Fri, 14 Nov 2008 10:15:44 GMT

When I started at Active Parity, one of the first things I wanted to do was help the company to get a blog started. They're a great way to show off your knowledge and communicate with clients. My first post over on the new blog is up, and it's on exactly that subject: Blogging in Business - specifically, why businesses should blog and what the potential downsides are. The first of many posts over there, I'm sure!

Writing Secure PHP, Part 4

dave@addedbytes.com — Thu, 11 Sep 2008 13:11:14 GMT

In Writing Secure PHP, Writing Secure PHP, Part 2 and Writing Secure PHP, Part 3 I covered many of the common mistakes PHP developers make, and how to avoid some potential security problems. This article covers some of the more advanced security problems common to PHP on the web.

[Writing Secure PHP is a series. Part 1, Part 2 and Part 3 are currently also available.]

Cross-Site Scripting (XSS)

Cross-site scripting (often abbreviated to XSS) is a form of injection, where an attacker finds a way to have the target site display code they control. In its most basic form, this can be as simple as a site that allows HTML characters in usernames, where someone can specify a username like:

DaveChild<script type="text/javascript" src="http://www.example.com/my_script.js"></script>

Now, whenever someone sees my username on the target site, the script I've added to my username will run. I could potentially use this to grab the person's login information, log their keystrokes - any number of nefarious activities.

As a developer, you can combat this type of attack by encoding or removing HTML characters (watch out for character encoding issues, as outlined next). Even better than stripping out unwanted characters is to allow a whitelist of safe characters in usernames and other fields. Be especially careful with e-commerce sites where you are listing orders in a CMS - an XSS vulnerability may allow an attacker to gain administrative access to your CMS. It is also important to turn off TRACE and TRACK support on the server, as if there is a vulnerability (and always assume that despite your best efforts there will be) these potentially allow an attacker to steal a user's cookie.

As a user you are also vulnerable to this sort of attack, and it is very difficult, at the moment, to make yourself safe against it. Vigilance is key, and to that end I have released a userscript that warns you about third party scripts (for users of GreaseMonkey, Opera or Chrome).

Cross-Site Request Forgery (CSRF)

Despite the similar name, CSRF is unconnected to XSS. CSRF is a form of attack where an authenticated user performs an action on a site without knowing it.

Let's assume that Jack is logged in to his bank, and has a cookie stored on his computer. Each time he sends an HTTP request to the bank (i.e., views a page or an image on a page) his browser sends the cookie along with the request so that the bank knows that it's him making the request.

Jill, meanwhile, runs a different website and has managed to get Jack to visit it. One of the items on the page is in fact loaded from the bank, for example in an iframe. The URL of the iframe or request contains instructions to the bank to transfer money from Jack's account to Jill's. Because the request is coming from Jack's computer, and includes his cookie, the bank assumes it is a legitimate request and the money is transferred.

This type of attack is extremely dangerous and virtually untracable. As a developer, your job is to protect against it, and the best way to do that is to remember Rule Number One: Never, Ever Trust Your Users. No matter how authenticated they are, do not assume every request was intended.

In practical PHP terms, you can combat CSRF with several relatively simple coding habits. Never let the user do anything with a GET request - always use POST. Confirm actions before performing them with a confirmation dialog on a separate page - and make sure both the original action button or link and the confirmation were clicked. Even better, have the user enter information like letters from their password on the confirmation page.

Add a randomly generated token to forms and verify its presence when a request is made. Use frame-breaking JavaScript. Time-out sessions with a short timespan (think minutes, not hours). Encourage the user to log out when they've finished. Check the HTTP_REFERER header (it can be hidden, but is still worth checking as if it is a different domain to that expected it is definitely a CSRF request).

Character Encoding

Character encoding in PHP and associated database systems is worthy of its own series. In any one request, there may be more different character encodings in use than you might think.

For example, a single request and response (uploading a file to a server and writing information to a database) may involve all of the following differently items with different character encodings: the HTTP request headers, post data, PHP's default encoding, the PHP MySQL module, MySQL's default set, the set of each table being used, a file being opened and read, a new file being created and written, the response headers and the response body.

English-speaking developers generally don't have much cause to get embroiled in character encoding issues, and that results in a lot of developers with a serious lack of understanding of how character encodings work and fit together. For those that do have a reason to look at character encodings, usually that interest ends with the setting of the response's character set.

However, character sets are a fundamental part of all web development. English alone can exist in any one of a wide variety of sets, and developers are usually familiar with the most common two: ISO-8859-1 and UTF-8. Fewer are familiar with UCS-2, UTF-16 or windows-1252. Still fewer are familiar with commonly used alternative language sets (e.g, GB2312 for Chinese).

Which, in a very roundabout way, brings me on to the security pitfalls of character encodings. Where data is processed by PHP using one character set, but a database server uses a different character set, a character (or series of characters) deemed safe by PHP may in fact allow SQL injection against the database.

PHP security expert Chris Shiflett has written about this issue and included an example of how it can be exploited to allow SQL injection even where input is sanitized using addslashes().

The solution is to always always use mysql_real_escape_string() rather than addslashes() (or use prepared statements / stored procedures), and to explicitly state character sets at all stages of interaction. Ideally, use the same character set throughout your system (UTF-8 is recommended) and where PHP allows you to specify a character encoding for a function (e.g., htmlspecialchars() or htmlentities()), make use of it.

It's not just SQL that's vulnerable as a result of character encoding bugs. Cross-site scripting is possible even where HTML characters are escaped if character sets are not handled properly. Fortunately, once again that is simple to avoid by properly setting character encodings at all stages of the process and specifying character encoding for functions where possible.

XSS Alarm Userscript

dave@addedbytes.com — Thu, 11 Sep 2008 13:10:57 GMT

Cross-Site Scripting (also known as XSS) is a security concern for any site that allows user input, especially e-commerce stores and anyone using or collecting sensitive personal information. In very basic terms, XSS is when a third party manages to have the target site load and show to a user a script or iframe they control. It allows the attacker to steal cookies, log keystrokes and more.

Unfortunately, while as a developer there is plenty you can do you make your web application secure against XSS, as a customer/user there is very little you can do to keep yourself safe. All you can really do is make sure you don't give out personal details or buy online from anywhere but the most reputable stores. And maybe watch your browser's "loading" bar like a hawk. Or maybe sniff your own HTTP traffic.

No browsers (that I know of) provide any method for prevention of third party scripts or iframes from loading. Let's face it - as long as advertising exists, that's unlikely to change. You can turn all JavaScript off, but that doesn't protect you against iframe-based XSS, and obviously degrades (for the most part) your web experience.

What I wanted was something to warn me when my browser was loading scripts from a third party. (Actually, what I really wanted was something to allow me to decide whether to load them or not.) Once a script from a third party has loaded, it may be too late to do anything - personal information may have already been taken - however, at least in principle, a warning may prevent me giving information to a compromised site.

So I have written a very basic UserScript for users of GreaseMonkey, Opera or Chrome. It pops up a red box with the URLs of any third party scripts or iframes being loaded by a site, unless they are being loaded from a whitelist of domains.

Download

The userscript is hosted on Google Code as part of a new project, addedbytes-userscripts (along with previous userscripts released here). As usual, they are released under a New BSD License.

Usage

If you see the red box (and you will) and you're on a site asking for personal information, glance at the URLs to check there's nothing odd being loaded.

The domains whitelist is based on my own browsing habits - I wanted as few warnings as possible, lest the box become worthless (see a warning box too often and it ceases to warn). I strongly suggest you modify it to reflect the third party scripts loaded by sites you commonly use.

If you want to only use this on SSL connections (so pretty much only when you're checking out of an online shop), add this line to the script after the "@exclude" lines:

// @include https://*

Click the box and it goes away.

Improvements welcome.

Notes

This is not foolproof. There are fairly easy ways, as an attacker, to make sure that the box doesn't appear, or that your URL isn't displayed. It doesn't stop XSS either - just tells you when it might be going on. It's not an excuse for a lack of vigilance.

One problem is and will continue to be getting the balance between whitelisting enough domains (and so keeping the tool useful) and speed (for every domain you add to the exclusion list, every scripts source needs to be checked against that domain). For me, with the list at around 30 whitelisted domains, I see the box on few of the sites I use often and not too much elsewhere. And it's quick. Your mileage may vary however as you and and remove excluded domains to reflect your own browsing habits.

It's been interesting, browsing the web with this on for a few days (especially with no excluded domains). Some sites load a vast number of third party advertising and tracking scripts (Economist.com article pages - 17 scripts, MSN article - 19) in addition to their own JavaScript. Some tracking systems are better than others (loading a script from the host site initially before communicating with the third party). Some companies have an odd system of alternative domains for hosting parts of their site (ebaystatic.com, images-amazon.com).

I can't help but think that as XSS becomes more of a problem, browsers will start to look more at ways of preventing it, which will (inevitably, I would have thought) involve at some point the prevention of third party scripts from loading directly. Which may well lead to people loading third party JavaScript via a hosted script (so instead of having a script with the src attribute pointing to Google to load your AdSense, you'll point your script tag at a JavaScript on your own server which will in turn do the loading from Google - a sort of JS relay to prove the JS is supposed to be there). Some sites will find this easier than others to implement!

Personal Development: To Do

dave@addedbytes.com — Thu, 21 Aug 2008 12:34:54 GMT

On Hacker News, ambition posted a to-do list inspired by / taken from this excellent bit of advice from Chris Wanstrath. Which got me thinking about what I want to work on and with in my spare time.

I've been meaning to organise my side-projects better. Like everyone else, I have lots of ideas and little time to make anything of them. I have a folder packed with projects at 95% completion, sitting there unloved because I got distracted, or found something better to use.

The problem with that is that taking projects to 95% is ultimately demotivating. It breeds guilt, and that's not helpful. And a project at 95% doesn't pay you back for the time you put in to it. You eventually need to release something if you don't want to end up looking back and seeing missed opportunities and wasted time.

In addition to a collection of projects on the go and ideas, there are technical skills I want to develop. I'm learning Python, and Linux server administration. I'm interested in looking into Objective-C and Cocoa. jQuery is great but I need more time with it. My "Dave! Play with PostgreSQL!" post-it is faded it's been on my wall for so long. And I need to stay sharp with the languages and technologies I use day-to-day.

Some fat needs to be trimmed.

I need to leave time for new things, too. Stuff I've not heard of yet. I'm always going to be distracted by shiny new technology. I think that's a good thing. But I want time to experiment and to tinker. If I earmark all my time for projects, I'm not going to suddenly lose interest in web technologies and tools. No, I'd start cutting into time I've promised to other things. Voila - the guilt's back and the schedule's shot. Back to square one.

So I've spent some time thinking about what I really want to get out of the time I spend on personal projects, and come up with a to-do list. I expect this to change over time, and while I don't expect for a second that you, the reader, will have the same goals or that this list itself will be useful to you, I hope if you're in a similar position it helps you to get a handle on things and get back to spending your time doing what you enjoy.

Keep on blogging!
Keep on making cheat sheets!
Move AddedBytes (set up server).
Thin out project folder and pick 2 to work on until finished.
Write a web service.
Write SVN Statistics app in Python (learn Python).
Rewrite site management VB app in Python (learn Python).
Learn Objective-C and Cocoa by writing a Useful Small Mac App (decide on what app!).
Learn a new PHP framework.
Get involved in an open source project.
Update and release more code from AddedBytes.com under open source license.

That should keep me going for a while. Next, I need to flesh out some of those ideas and work out how much time I can put into them.