Tuesday, 28 February 2012

External links & new tabs

This is something I've been reading up on quite a it lately, should links to external websites open in a new tab or not?  There's quite a lot of posts about this already and it is an issue which divides people a lot.


Why open links in new tabs?
New tabs keep users on my site
Some people think that opening an external link in a new tab means that you are giving the user access to an external resource but at the same time they are staying on your website and you're not losing a user / potential client.

I think this line of thinking is flawed, if the user doesn't want to be on your website any longer then they'll just leave anyway and if they did want to be on your site they'd just open links in a new tab or use the browser back button to return to your site.  A common example of this would be a person looking for some information, if you're site has it they'll read it and possibly bookmark it then move on as there won't be any reason to stay, if it didn't have what they wanted then there's no reason for them to be there in the first place.

A new tab is what users expect
This argument I think does have some credibility as I stated above a lot of people think opening a new tab or window will keep users on their site and as such have decided to implement this and have created user expectations.  On the other hand though there are a large number of sites which don't do this and I think the two methods often confuse users and they're not sure what to expect so I'm not sure if most users do actually expect external links to open in a new tab any more.

I have noticed in my personally browsing that more sites are moving to opening in the same tab rather than a new one.  This isn't any thing I can back up with data or references, just something I've noticed and might not actually be true across the web as a whole.

Users should decide
Firstly as a user interface designer you are trying to give the user the best experience they can have using your site, one of the best way of doing this is to give them control.  I don't think they should be given control over every part of your site but the basic browsing behaviour they experience no matter which site they are on such as opening links and using the back & forward buttons they should.  This allows them the option of opening links in new tabs or the same tab, when a user comes to your site they may already have a lot of tabs open and not want another and as such prefer to open the link in the same tab and use their back button.  This is just one example but overall giving the user control in this area will almost always give them the best experience in my opinion.

Even if you really feel that opening the link in a new tab by default is a must because you really think it will keep people on your site in a positive way, you can't.  There's always way around it such as copying the link and pasting it into the address bar or just dragging it into the address bar, although a lot of probably users won't know about these methods all you succeeded in doing to them is annoying them as they cannot do what they wanted.  Is that the kind of experience you want users to have on your site and how you want them to remember it?

Don't forget using the back button isn't that hard for the user and almost all web users know how to use it (the ones who don't probably don't understand what tabs are either).  In modern browsers you even get a drop down from the back button showing a list of previous site they've visited so they won't even need to click it multiple times to find your site again.

Should I never open new tabs & windows?
I wouldn't say it should never be done because it can be useful in the right circumstance.  For example opening PDF documents or large images as both can take some time to load opening it in a new tab or window and allowing the user to continue on your site is useful.  Another example would be on a form or shopping area of a site opening any help facilities that might be associated with it in a new window so they don't lose their data and can view both the help and shopping basket at the same time could be useful.

If you are going to open a new window or tab when the user clicks a link you must make the user aware that this will happen, for example providing a little icon next to the link & stating in the title text of the link that a new window will open.

My opinion
Although this whole post is based around my opinion I have tried to include a few other perspectives a little, I always used to think that clicking a link to an external site should open a new tab or window and you might have noticed on this blog a lot of them do.  When I actually put some thought into it I start to think that this might not be the best method and it would be better to let users decide.  Once I've fully decided which is best I'll change all the links on this site to match what I think but I think I'm going to let you users decide.

Further reading

Thursday, 23 February 2012

HTML5 Canvas 3d?

Introduction
A few people seem a little confused by the HTML5 canvas tag and if it's possible to create 3d elements inside of it, the main reason for this is the getContext("2d") method with the parameter of 2d and logically people think there must be a 3d parameter too.

Is canvas 3d then?
Unfortunately there is only a 2d parameter for the getContext() method and no 3d option but in the future they are planning on adding the 3d parameter.

So I can't use 3d in canvas? :(
Despite what I've stated above it is still possible to have 3d effects using HTML5 canvas but it's just not been standardised by anyone yet, this hasn't stopped browsers from implementing their own methods of 3d.  The main method of doing this seems to be by using WebGL and there are a few HTML5 3d engines / frameworks out already based on this.

Unfortunately I don't really understand enough about the topic to go into any real depth but there are plenty of great examples if you Google around for them.

Should you use it?
Personally I wouldn't build anything that relied on it as only a few browser support it and as it's not standardised so in a few years when a standard does come out parts of what you've made may not work any more.  Personally I plan on building some cool web apps with it in the near future but mainly for the 'cool' factor.

WebGL security
I feel I should mention a bit about security in relation to WebGL in that it has some flaws, can't say I full understand these yet myself either but I've put some links below about them.
Further reading

Tuesday, 14 February 2012

What are CSS em sizes?

Introduction
I thought I'd write a short post about CSS em sizes covering what they are and how to use them, I have just thought recently they're not all that easy to understand without reading about it somewhere which is what's caused me to write this post.

What is an em?
It's a flexible unit of size used in CSS mainly for defining the size of a font, what do I mean by flexible?  Well it changes relative to the font size of its parent, kind of like a pixels size is relative to the DPI settings if that helps.

For example if you had a document with a default text size of 16 pixels (the default for most modern browsers) then 1em = 16px, if the default was 10 pixels then 1em = 10px.  This only changes if the parent has a different font size set, for example if a document has a default font size of 16 pixels but you have a container within it with a font size of 12 pixels then 1em = 12px within that container.

Why are they called ems?
It comes from typography as I understand it, em is is pronounced just like it looks and exactly the same as the letter 'm'.  It is used as a measurement of the width for the letter 'M' within the font, this letter is used because it should be the widest in the alphabet, I guess there might be some strange font out there where this isn't the case though.

Why use ems and not just pixels?
The main reason used to be that if the user wanted to increase the text size within their browser they could not do so with pixel defined sizes but could do it with relative defined sizes such as percentages and ems.  This isn't as much of a problem now as modern browsers all zoom the whole page rather than just making the text bigger, one exception to this is Internet Explorer 8 and below which won't zoom text defined in pixel sizes.  There are also all the older versions of browsers from other vendors which pre-date page zooming which won't magnify text defined in pixels, although I believe those ones are dwindling in number quite rapidly (I don't have any facts to back that statement up).

How to use ems properly
Well firstly declare your default pixel size, I'd recommend 16px as it's a good read able size and I'll put a link to an article about it at the end of this post.  Example code below:

html, body{ font-size: 16px; }

Now lets say you wanted to make your heading 1 tags 24 pixels large you take the target size (24) and divide it by the parent size (16) and that will give you the em number you need to use.  I've written this down a bit more mathematically & given an example below:

target size / parent size = em size

24px / 16px = 1.5em

That's all I'm going to say on this subject for now, have a look around on the net for more information if you're interested but I think this is enough to get going with CSS em sizes.

Further reading

Monday, 13 February 2012

What is character encoding?

Introduction
I thought I'd take a bit of a break from my series on PHP session security and write about character encoding on websites as I've just been reading up on it recently.  I'm not going very in-depth with this subject but have provided links at the bottom to another sites which do. I'll probably write my own detailed post on it one day, it's on my list.

What is character encoding?
It's the method computers use to interpret human languages into a language the computer can understand and store.  For example to store the letter A your computer cannot write it down, it has to store it as a string of 1s and 0s and this has to be the same across all computers otherwise when you send a document from one computer to another the letters would appear different.  There is a bit more to it than that but I'm just trying to keep this quite basic as the specifics shouldn't be to important for understanding what encoding it.

Should I set encoding on my website?
Basically you should set it because if you don't you're reliant on the clients browser working it out correctly (which isn't very easy or 100% accurate) and will depend on their browser, version of the browser and the default languages settings they have set.

What encoding should I use?
This depends a bit on a few things like if your supporting previous applications and which encoding method they used and what languages you need to support but in most situations it's best to use Unicode Transformation Format-8 (UTF-8).  The reason for this is that it is the most common in use today and it interoperates as well as it can with all the other types of encoding out there, well as far as English is concerned anyway unfortunately the interoperability isn't possible for most other languages but it does support any languages you're likely to ever use if it's all in UTF-8.

One quick note as well just to stop any possible confusion with anything else you read UTF-8 it is exactly the same as ISO10646 (RFC 3629).

How do I use the encoding?
This depends on what type of document you're using and how it is being served, I'll be covering what I think are the most common, these are:
  • XHTML served as XML (i.e. properly using XHTML)
  • XHTML served as HTML
  • HTML4 & below
  • HTML5
I'll cover the difference of serving XHTML as XML or as HTML in another post but you'll almost certainly be serving it as HTML, you'd probably already know if you were serving it as XML.

Below is some example code of how to use encoding for your web documents which can be just copy and pasted directly into your documents and it will work, just so you are aware these examples are all for UTF-8.

XHTML served as XML / plain XML
Put this line of code right at the top of your document, even before the doctype declaration.

<?xml version="1.0" encoding="UTF-8"?>

XHTML served as HTML / HTML4 & below
Put this bit of code right at the top of the <head> area in your document.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

HTML5
Put this line of code right at the top of the <head> area in your document.  If you were to use the meta tag used in HTML4 in a HTML5 document to declare the correct character set it would still be valid, the new HTML5 method is just similar.

<meta charset="utf-8" />

Further reading

Saturday, 11 February 2012

PHP session security: Part 5 - Session fixation

Edit 14/01/2013
I've updated the "Secure your server against session fixation," section of this post as I felt I'd missed parts out and it wasn't complete enough.

Introduction
This is another post in my securing PHP session series, this time I'll be covering session fixation.  This is a method used by attackers to set the session id of a legitimate user of your site to what they want it to be so they can impersonate your users.

Brief recap on how PHP sessions work
As explained in a previous post about how PHP session work when a session is made an ID is generated by the server and a file created with the generated id as the name on the server which stores all the session data (such as session variables).  This ID is also set as a cookie value (although there are other methods) with the default name of PHPSESSID (this can be changed) and every time the client makes a request to the server it sends the cookie too.  When the server detects this cookie it checks the session files it has already created and if there is a matching one it'll use the session data from that, if there isn't one it will create a cookie with that ID passed to it and not generate a new ID.

This is all default and most common behaviour for PHP sessions, there are many ways of changing this but this series of articles is concentrating on the default behaviour and how to make it more secure.  I'm also only covering securing PHP session based on using cookies for storage on the client browser because it is the most common and secure method currently in use.

How does session fixation fit into this?
Session fixation is when a hacker some how gains access to some part of the process and manually sets the session ID to one they've generated.  This could be by altering the session ID generation on your server or changing ID stored in the users cookies or a verity of other methods.  How this attack will be performed will depend on your set up and the what they are trying to attack (website, web app etc) and how it works but I'll go into what I consider to be the most common use of PHP session which is a website.  In this scenario it's unlikely your server will have anything altered and far more likely that the cookie on the client is changed or the cookie gets changed while being sent from the client to the server, or vice versa.  This isn't just true for websites but many web applications too.

Now that the hacker has successfully changed the users session ID to one they know, they can set the cookie in their own browser to the one they've changed the clients to and log into your website / web service passing that cookie to your server and in doing so your server will think the hacker is the legitimate user.

This is different to session hijacking (I'll be writing my next post about this) in that session fixation is where the hacker sets the session id to one they'd like but hijacking is when a hacker obtains the session id that's already been set.  The end result is the same, the hacker can impersonate your users but the general thinking / methods behind the attacks are different.

How can this happen?
I can't truly answer this question as I'm no hacker but I can give a very simple example of what can be done, I am sure that there are many other methods of session fixation that I cannot think of, it'd be worth doing a Google search for "How to perform a session fixation attack."

The basic example I can think of is if your server will accept session IDs to be set using any method and not just secure cookies which are set by your server then it's possible that a hacker could send the user to your site via a normal link which also sets the session ID.  When the user clicks the link and is taken to your site, your server will pick up the session ID in the URL and create a session file storing all the session data on the server with the ID set in the link.  This might not be the clearest explanation of what I mean but I can't think of a better way to describe it, I've put an example of the link I've just described below to hopefully make this clearer.

<a href="yoursite.com?PHPSESSID=123456789">Click me!</a>

I hope this helps you understand a little about how these attack take place but do search around for more information as I'm no hacker but I know these vulnerabilities exist.

Secure your server against session fixation
There are probably many methods of securing your server against session fixation and in every application you make it's worth looking into as it'll vary but I suspect for most websites, my upcoming secure PHP login project included, regenerating the session ID should be enough.

Regenerating the session ID is basically exactly what it says, when the user access your site the ID that's passed from their browser to your server is then changed (regenerated) and a new one made which is then sent back to the client browser and stored as a cookie.  This means that even if a hacker changed the session ID cookie on the client browser soon as it's passed to the server it gets changed and the hacker no longer knows what the session ID is.  If there isn't a session ID passed to the server then a new one will have to be generated anyway and as long as the connection is secure it should still prevent session fixation attacks.

I would point out though that this isn't a foul proof method as the client computer could be compromised and as soon as a new cookie is set the attacker gets informed of it but there isn't a huge amount you can do about it because it comes down to the browser manufactures and users themselves to keep their end secure.

There are a couple of methods to try and combat this though, one is the slightly unreliable method which is to hold information about the users machine such as their user-agent and their IP address (others can be included too) and detect changes to them and every time a session ID is used and see if they are the same as previous. If they're not the same then forcing them to re-enter their password should help prevent this, the problem with this of course is that IP address change, are shared between multiple computers and can be spoofed and the browser in use can change which could cause users to have to enter their password in a lot.

Another, probably more useful method is to only allow the user access to parts of the site which don't have any sensitive data on it and making them enter in their password in again every time they try to go to part of the site with more sensitive information in. This in my opinion is the best method in general to be using.

Of course you can always force the user to enter their password every time they enter the website but if you want a 'remember me' kind of link this method wouldn't allow it.

It does depend on how secure you need to make your site / application on what you'd need to do and these are just some options, you'll need to evaluate what will be best for your situation & users each time.

A quite simple method of regenerating the session ID is to use the built in PHP function for this task called session_regenerate_id() which creates a new session ID and keeps all the data from the previous session.  Make sure you set it's parameter to true (it defaults to false) as this will delete the old session file on your server which will stop the old session id from being used again.  I've put an example of the code below:

session_regenerate_id(true);

How often to regenerate the session ID?
This is a bit of a tough question and it does depend on what you're application is using the session data for, but lets say you're using it for a login system (I pick this as I'm currently building one myself).  The consensus seems to be it should regenerated every time the user enters their login details.  They should be entering their login details when they login and every time they try to access more sensitive areas of the site such as a page allowing them to change their password or other personal / sensitive details.

Personally in my secure PHP login project I have been trying to decide between the above or if it should be regenerated on every page load.  I'm not sure but I think regenerating it on every page load would be quite intensive if there were a lot of users (not sure if that's accurate or not) I may add an option in that will allow either method to be used.  I might even have it capable of using both and deciding which to use depending on if a secure connection is in use.  What do you guys think?  Leave a comment with you opinions.

What else can you do?
It's worth doing more research into this as I said before it will depend on your site / application on the best method of securing against this kind of attack, I'm just giving my opinions on the most secure method for what I think are the most common scenarios. Just being aware of this vulnerability while building the site though is a large step towards preventing it as you'll actually start giving it some thought (hopefully).

The only other things I can think of is to make sure your server is set up securely, to only accept session IDs from the client in a secure cookie and to always use a secure connection between the client and server.

Other parts in this series:
Further reading

Thursday, 2 February 2012

PHP session security: Part 4 - Secure connections

Forenote
Before I start on this subject I wanted to apologise for taking so long about writing this new post, I've been pretty ill recently and have only just started to recover, it was nothing major but I felt bad and couldn't concentrate enough to write this.

Introduction
This post is the fourth part in my series about PHP session security and will focus on securing the connection between the client and the server.  I've already covered keeping data secure on the server and the session ID secure on the client browser and as important as they are having a secure connection is also a must to stop anyone finding out what the users session ID is and hijacking it.

What is a secure connection
Background
Generally this was done using a Secure Socket Layer (SSL) connection but more recently this has been superseded by Transport Layer Security (TLS) although it is still referred to as SSL in a lot of places.  TLS isn't a totally new method of securing connections but is more of an evolution / upgrade from SSL, still there have been quite a few changes so they cannot interoperate.

Users can normally identify a secure connection as the URL will start with HTTPS (HyperText Transfer Protocol Secured).    I'll write more about HTTPS, SSL & TLS in another post at a later date but understanding how they work shouldn't be important in securing PHP sessions.

Verified & unverified
There are two main types of TLS, verified and unverified (also referred to as certificated & non-certificated depending on the terminology you're using but they're the same thing).  The main difference between these two is that a verified connection will verify the domain with the client browser so it knows the connection is to the correct site, but in an unverified connection this doesn't happen so the client doesn't know it's connected to the correct site but the connection it self is still secure.  You may have noticed on some secured sites that you get a red warning message on your browser warning you that it cannot verify the TLS / SSL certificate (or words to that effect) and asking you if you want to continue or not, these are sites using an unverified TLS / SSL certificate.

Having a verified connection costs more money but when most people see that the connection is unverified with the red warning message there browser shows they will leave the site instantly, so for sites used by the general public you must have a verified certificate.  Unverified SSL is useful for your own purposes where you'll know that you are connected to the correct domain and just want the connection to be secure, an example of this could be an admin system to your website.

How to make a connection secure
There are two main methods of implementing TLS / SSL which are either to have the connection security and cryptography done in hardware or having it all done in software, most (if not everyone) reading this will want to use software as it's the easier and cheaper method.  The advantage of using hardware is that it's more efficient but it has the downside of being harder to upgrade and costing a lot more, it's only of real world use is on sites that have a large volume of traffic such as Facebook so I'll just be going over the software implementation here.

One thing to keep in mind when using a secure connection is that it does use extra resources on the server which is why you've probably not seen many sites which use a secure connection on every page, just the sensitive ones that require it.  It's worth noting though on smaller sites that aren't using much bandwidth or server resources you probably won't notice the extra resources that the secure connection uses even if you were to implement it throughout the whole site.

One of the best places to start is by contacting your hosting provider and seeing if they can sort it out for you as a lot of them have procedures in place for setting up secure connections and getting certificates which makes the whole process a lot easier and quicker for you, possibly cheaper too.

If you want to actually do all the set up yourself you'll need to have a static IP address and full access to your server.  You'll then need to buy the certificate, there are several places to do this and which is best depends on what exactly you're after and the country you're in so ask around, Google is a good place to start and VeriSign are well known for selling certificates.  After you've purchased the SSL certificate you'll need to install / configure your web server (probably Apache) to use it, getting into the details of that is a bit outside the scope of this post and could do with a post all to itself.  I'd recommend Googling around for it and asking on an online forum for advice, for some reason there doesn't seem to be many tutorials on the subject that I could find.  Hopefully later on I'll get around to writing my own guide to configuring an Apache based server to use TLS / SSL.

Other parts in this series:
Further reading