Application Development

Operations

If you have to SSH into your servers, then your automation has failed.

The last time I had an actionable alert from CloudWatch was about a year ago...

Billing

Security

S3

I've found them to be about as reliable as a large government department...

EC2/VPC

I've had it happen, it sucks, learn from my mistake!

ELB

ElastiCache

RDS

CloudWatch

Auto-Scaling

IAM

Route53

Elastic MapReduce

Miscellaneous Tips

Parting Words

What's the impact to you if your password is leaked?

1. Someone will have access to that service's account, including all information you've stored with that service (email, address, security questions, etc).
2. If you use the same password in other places, those accounts are all compromised and you've given them access to everything stored with those services too.

Protecting against sites that don't securely store your password.

1. Never use the same password on more than one site. Ever.
2. Always use the most complex password you can that fits with the site's password requirements.
3. Never put information on your account that the company doesn't absolutely need. (Use fake information if it's "required" but they don't really need it. An online store doesn't need to know my date of birth, mother's maiden name, etc.)
4. Regularly purge expired/irrelevant information from your accounts.
5. (Optional) Use a different email address for every service you sign up for.

1. Never use the same password on more than one site.

2. Always use the most complex password you can.

cat /dev/urandom | tr -cd "[:graph:]" | head -c ${1:-100}; echo 

3. Never put information on your account that the site doesn't absolutely need.

4. Regularly purge expired/irrelevant information from your accounts.

5. Use a different email address for every account you sign up for.

1. If a website leaks your email address to spammers, you can very easily add a filter to mark those emails as SPAM.
2. If you receive an email claiming to be from a certain website, but which wasn't sent to your special alias, you can be sure it's a phishing attempt.
3. If an online account is broken into, and your email grabbed, it will be useless for logging into any other website since you will be using a different email.

How is all of this stuff going to actually help me?

1. Someone will have access to that service's account, including the limited information you've stored with that service.

Afterthought: How did we get into this mess?

Hardware

> lspci | grep 'VGA'
00:02.0 VGA compatible controller: Intel Corporation Device 0116 (rev 09)

> sudo update-pciids
Downloaded daily snapshot dated ...
> lspci | grep 'VGA'
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

New Graphics Drivers

sudo add-apt-repository ppa:glasen/intel-driver
sudo apt-get update
sudo apt-get upgrade

Section "Device" 
    Identifier "card0" 
    Driver "intel" 
EndSection

sudo apt-get install linux-image-generic-lts-backport-natty linux-headers-generic-lts-backport-natty

Hardware

> lspci | grep 'Ethernet\|Network'
00:19.0 Ethernet controller: Intel Corporation Device 1503 (rev 04)
02:00.0 Network controller: Intel Corporation Device 0091 (rev 34)

> sudo update-pciids
Downloaded daily snapshot dated ...
> lspci | grep 'Ethernet\|Network'
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6230 (rev 34)

Fixing eth0

tar -xvf e1000e-1.9.5.tar.gz
cd e10001e-1.9.5
sudo make install
sudo modprobe -r e1000e; sudo modprobe e1000e

> lsmod | grep e1000e
e1000e                158424  0

Fixing wlan0

tar -vxf iwlwifi-6000g2b-ucode-18.168.6.1.tgz 
cd iwlwifi-6000g2b-ucode-18.168.6.1/
sudo cp iwlwifi-6000g2b-6.ucode /lib/firmware/
sudo modprobe -r iwlagn
sudo modprobe iwlagn

sudo apt-get install linux-backports-modules-wireless-lucid-generic

> lsmod | grep iwl
iwlagn                272480  0 
iwlcore               167474  1 iwlagn
mac80211              298255  2 iwlagn,iwlcore
cfg80211              182202  3 iwlagn,iwlcore,mac80211

sudo apt-get install linux-image-generic-lts-backport-natty linux-headers-generic-lts-backport-natty

1. Always regenerate a session ID (SID) when elevating privileges or changing between HTTP and HTTPS.

User M: Visits the website, and has a session ID assigned to them. They either look at the GET parameters (?sid=xxxxx) or at the headers (Set-Cookie: sid=xxxxx) to determine their session ID. Once they have the ID, they craft either a direct link using the GET parameters (http://example.com/?sid=xxxxx) or they construct a non-direct link which will add the relevant headers. This link is then sent to User V.

User V: Gets an email from User M which says "Hey, check out your new look banking account! http://example.com/?sid=xxxxx" Since the link looks legitimate (example.com is the real URL) then the user clicks the link confident it's not a scam. They then login with their account.

User M: Since this user already had the same session or already knows the SID, they will now be logged in to the site as if they are user V. If you regenerate the SID, then this wouldn't be possible since user M would no longer know the correct SID.

session_regenerate_id(true);

2. Check for suspicious activity and immediately destroy any suspect session.

If ($_SESSION['_USER_IP'] != $_SERVER['REMOTE_ADDR']
    || $_SESSION['_USER_AGENT'] != $_SERVER['HTTP_USER_AGENT'])
{
    session_unset(); // Same as $_SESSION = array();
    session_destroy();
    session_start();
    session_regenerate_id(true);
    Log::create("Possible session hijacking attempt.", Log::NOTIFY_ADMIN)
    Auth::getCurrentUser()->reAuthenticate(Auth::SESSION_SUSPICIOUS);
}

$_SESSION['_USER_IP']    = $_SERVER['REMOTE_ADDR'];
$_SESSION['_USER_AGENT'] = $_SERVER['HTTP_USER_AGENT'];

If ($_SESSION['_USER_LOOSE_IP'] != long2ip(ip2long($_SERVER['REMOTE_ADDR']) 
                                           & ip2long("255.255.0.0"))
    || $_SESSION['_USER_AGENT'] != $_SERVER['HTTP_USER_AGENT']
    || $_SESSION['_USER_ACCEPT'] != $_SERVER['HTTP_ACCEPT']
    || $_SESSION['_USER_ACCEPT_ENCODING'] != $_SERVER['HTTP_ACCEPT_ENCODING']
    || $_SESSION['_USER_ACCEPT_LANG'] != $_SERVER['HTTP_ACCEPT_LANGUAGE']
    || $_SESSION['_USER_ACCEPT_CHARSET'] != $_SERVER['HTTP_ACCEPT_CHARSET'])
{
    // Destroy and start a new session
    session_unset(); // Same as $_SESSION = array();
    session_destroy(); // Destroy session on disk
    session_start();
    session_regenerate_id(true);

    // Log for attention of admin
    Log::create("Possible session hijacking attempt.", Log::NOTIFY_ADMIN)

    // Flag that the user needs to re-authenticate before continuing.
    Auth::getCurrentUser()->reAuthenticate(Auth::SESSION_SUSPICIOUS);
}

// Store these values into the session so I can check on subsequent requests.
$_SESSION['_USER_AGENT']           = $_SERVER['HTTP_USER_AGENT'];
$_SESSION['_USER_ACCEPT']          = $_SERVER['HTTP_ACCEPT'];
$_SESSION['_USER_ACCEPT_ENCODING'] = $_SERVER['HTTP_ACCEPT_ENCODING'];
$_SESSION['_USER_ACCEPT_LANG']     = $_SERVER['HTTP_ACCEPT_LANGUAGE'];
$_SESSION['_USER_ACCEPT_CHARSET']  = $_SERVER['HTTP_ACCEPT_CHARSET'];

// Only use the first two blocks of the IP (loose IP check). Use a
// netmask of 255.255.0.0 to get the first two blocks only.
$_SESSION['_USER_LOOSE_IP'] = long2ip(ip2long($_SERVER['REMOTE_ADDR']) 
                                      & ip2long("255.255.0.0"));

3. Store all session information server-side, never store anything except the SID in the client-side cookie.

// Manually set the cookie
setcookie("sid",                // Name
          session_id(),         // Value
          strtotime("+1 hour"), // Expiry
          "/",                  // Path
          ".wblinks.com",       // Domain
          true,                 // HTTPS Only
          true);                // HTTP Only

// Or, in php.ini
session.cookie_lifetime = "3600";      // Expiry
session.cookie_httponly = "1";         // HTTP Only
session.cookie_secure = "1";           // HTTPS Only
session.cookie_domain = ".wblinks.com" // Domain

// Then session_start will use the above config.
session_start();

4. Confirm SIDs aren't from an external source, and verify the session was generated by your server.

If (!isset($_SESSION['MY_SERVER_GENERATED_THIS_SESSION']))
{
    session_unset(); 
    session_destroy();
    session_start();
    session_regenerate_id(true);
}

$_SESSION['MY_SERVER_GENERATED_THIS_SESSION'] = true;

5. Don't append the SID to URLs as a GET parameter.

6. Expire sessions on the server side, don't rely on cookie expiration to end a user session.

$_SESSION['_USER_LAST_ACTIVITY'] = time();

$_SESSION['SESSION_START_TIME'] = time();

if ($_SESSION['SESSION_START_TIME'] < (strtotime("-1 hour"))
    || $_SESSION['_USER_LAST_ACTIVITY'] < (strtotime("-20 mins")))
{
    session_unset();
    session_destroy();
    Auth::getCurrentUser()->reAuthenticate(Auth::SESSION_EXPIRED);
}

7. Use long and unpredictable session IDs.

session_start();
session_regenerate_id(true);

8. Properly sanitize user input before setting headers with them.

$nextPage = Sanitizer::sanitize($_GET['next_page']);
header("Location: $nextPage");

http://example.com/?next_page=login%0d%0aSet-Cookie:%20sessionID%3d12345678

?next_page=login\r\nSet-Cookie: sessionID=12345678

Location: login
Set-Cookie: sessionID=12345678

9. When a user logs out, destroy their session explicitly on the server.

session_unset(); 
session_destroy();
session_start();
session_regenerate_id(true);

unset($_COOKIE);
// This will only remove it from the superglobal and will do nothing to
// the actual client-side cookie.

setcookie("sid", "", 0);
// 0 sets the expiry time to when the browser is closed and doesn't 
// immediately expire it. Don't use 0!

setcookie("sid", "", strtotime("-1 hour"));
// Sets the expiry to one hour in the past right?
// In server time yes, but cookies are stored on the client in their
// local timezone, so depending on where that is, it may not expire for a
// few more hours!

setcookie("sid", "", 1);

10. Check your session configuration.

11. Force users to re-authenticate on any destructive or critical actions.

Auth::getCurrentUser()->reAuthenticate(Auth::ACTION_SENSITIVE_CRITICAL);

Summary

1. Always regenerate a session ID (SID) when elevating privileges or changing between HTTP and HTTPS.
2. Check for suspicious activity and immediately destroy any suspect session.
3. Store all session information server-side, never store anything except the SID in the client-side cookie.
4. Confirm SIDs aren't from an external source, and verify the session was generated by your server.
5. Don't append the SID to URLs as a GET parameter.
6. Expire sessions on the server side, don't rely on cookie expiration to end a user session.
7. Use long and unpredictable session IDs.
8. Properly sanitize user input before setting headers with them.
9. When a user logs out, destroy their session explicitly on the server.
10. Check your session configuration.
11. Force users to re-authenticate on any destructive or critical actions.

What is XSRF?

I thought I'd make a comment on your site. Check out this cool image!
<img src='http://example.com/delete_my_account.php" />

The Wrong Way To Protect Against XSRF

<?php
$url = parse_url($_SERVER['HTTP_REFERER']);
if ($url['host'] != "wblinks.com")
{
    die("You're not coming from my site. Possible XSRF attack");
}

The Right Way To Protect Against XSRF

$_config['csrf_token_lifetime'] = "15 mins"; // How long the tokens should last.

// Generates a nonce, by base64 encoding some random binary data.
public static function generateNonce($length = 20)
{
    return substr(base64_encode(openssl_random_pseudo_bytes(1000)), 0, $length);
}

// Generate a new XSRF token and store it in the user's session.
public static function getXSRFToken()
{
    $nonce          = Auth::generateNonce();
    $tokens         = Session::get("_xsrf");
    $tokens[$nonce] = strtotime("+".$_config['csrf_token_lifetime']);
    Session::set("_xsrf", $tokens);
    return $nonce;
}

// This will determine if an fkey is valid
private static function validateXSRFToken($xsrf)
{
    $tokens = Session::get("_xsrf");
    if ($tokens == null) { return false; } // Sanity check

    // Check that the fkey exists, and time has not expired
    foreach ($tokens as $key => $expires)
    {
        // Remove any tokens that have expired.
        if (time() > $expires)
        {
            unset($tokens[$key]); Session::set("_xsrf", $tokens);
            continue;
        }
    
        // If key matches and isn't expired, we can use it.
        if ($key == $xsrf  && time() <= $expires)
        {
            // Key is good, remove it from use
            unset($tokens[$key]); Session::set("_xsrf", $tokens);
            return true;
        }
    }
    return false;
}  

// Creates the form input to use
public static function getXSRFFormInput()
{
    return "<input type=\"hidden\" name=\"fkey\" value=\"".Auth::getXSRFToken()."\" />";
}

<form action="do_something.php" method="POST">
    <fieldset>
        <?php echo Auth::getXSRFFormInput(); ?>
        <input ... />
    </fieldset>
</form>

<input type="hidden" name="fkey" value="3748ab53cf129d536eca" />";

$_SESSION['_xsrf'] array(1) => 
{
    ["3748ab53cf129d536eca"] => int(1275675864)
}

if (count($_POST) > 0)
{
    if (!Auth::validateXSRFToken($_POST["fkey"]))
    {
        Log::create("XSRF", "Possible XSRF attack", LOG::NOTIFY, LOG::NOTIFY_ADMIN);

        // Inform user that why things broke and how to fix it.
        Notification::set("Your session token expired. Please refresh and try again (don't use the back button).", NotificationType::ERROR);

        // Redirect back to whichever page they came from.
        header("Location:".Session::getReferer()); exit();
    }
}

Why an Array of Tokens?

1. The token must be tied to a specific users' session, it should not be site-wide!
2. The token should have some sort of expiry time.
3. The token must be invalidated once it's been used.

Why only POST?

POST Refresh

Final Thoughts

A story of woe

Why do we use "www." anyway?

To "www." or not to "www."?

What if the site uses cookies?

Microreasons

Summary

1. Make your site work both including and excluding the "www.".
2. Since including the "www." is social convention, you should make sure that users are sent to the same place if they include it or not, they shouldn't be sent to a different site if they miss off the "www." as that will just confuse matters.
3. Pick one URL to use as the main destination, and redirect the other URL(s) to it. This way, all of the URLs to your site should stay consistent.
4. Use a 301 redirect as this tells search engines that it's a permanent redirect and that both URLs are actually for the same thing. This should preserve your rankings and keep things consistent.
5. If you want to use a cookieless subdomain for static data, then you need to use the "www." for your main site
6. If possible with your domain structure (some websites use subdomains for other things, and that's fine) also try to make "w.domain.com" and "ww.domain.com" point to the main site. This will catch anyone who makes a typo. It takes very little time to setup and can save someone even a few seconds of grief when they realise their typing mistake.

function connect()
{
    global $DB_CONFIG;
    
    if ($this->getHandle() != null) return; // Already connected

    $pdo_string = 'mysql:dbname='.$DB_CONFIG['database'].';host='.$DB_CONFIG['hostname'];
    
    try
    {
        Log::create("DB","Connecting to ".$pdo_string." as ".$DB_CONFIG['username'], Log::INFO);
        
        $this->_handle = new PDO($pdo_string, $DB_CONFIG['username'], $DB_CONFIG['password']);
        $this->getHandle()->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    }
    catch (PDOException $e)
    {
        Log::create("DB","Exception caught while connecting. ".$e->getMessage(),
                    Log::ERROR,
                    Log::NOTIFY_ADMIN);
        header("Location: /dbdown/");
    }
    Log::create("DB","Connected to database", Log::INFO);
}

    $this->getHandle()->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
}
catch (PDOException $e)
{
    Log::create("DB","Exception caught while connecting. ".$e->getMessage(),
                Log::ERROR,
                Log::NOTIFY_ADMIN);
    header("Location: /dbdown/");
}

I won't name and shame where this screenshot comes from, but it's from a product that's live, out there in the wild and worryingly also deals with money (and I should point out, not associated to anything I've worked on).

All The Hard Work, For Nothing

1. If a user requests a password reset, generate a new password and send it to the email address on file.
2. Get the user to verify who they are by validating some information you have stored under their account. First line of address, day and month of birth, etc. Email them with a confirmation link so that you can verify they have access to the email account on file. That confirmation link then sends them to a page where the user can set a new password.
3. Security questions. Get them to fill in some security questions when creating their account, then we can just use that!

The Wrong Way

1. What is your mother's maiden name?
2. What is your mother's middle name?
3. What was the name of your first pet?
4. What was the name of your first school?

The Better Way

Q. 2X4B?
A. 523P

Q. My password is "iamawesome"?

Don't Force Your Users To Create Security Questions

Adding Salt - Security Question Answers Are Passwords!

Combination Lock

Special Case

Get To The Point!

1. Don't force a certain set of questions on the user. Let them chose their own question.
2. Don't force a user to fill in the questions as mandatory. If the user doesn't want to, they shouldn't have to. Of course, feel free to ridicule the user if they then forget their password, but it was at least the user's choice.
3. Hash the answer, salt the hash, and strengthen it before storing.
4. Don't rely purely on a security question response. Confirm the users email somehow and then send them straight to a page where they can set a new password. Avoid generating and sending a new password via email.
5. If the user doesn't have access to the email, or can't remember the question answer, don't use an automated process. Get another human involved to verify who the person is.

The Rotating Password

"You must change your password every x days"

The Ridiculous Restriction

Your password must be at least 6-8 characters long, contain uppercase and lowercase letters, and have at least two digits, but not for the first two characters. Oh, and it shouldn't contain the name of a species of dog.

The Giveaway

"You cannot use that password because another user already has it"

The Normalizer

"Your password cannot contain special characters, only normal letters and numbers"

The Length Restriction

Your password cannot be longer than 16 chars.

So what are the lessons?

1. Don't resitrct what can go into a password, whether it's a max length or strange characters.
2. Don't force a users password to follow a certain pattern.
3. Don't force a user to change their password every x days unless you really have to.
   
4. Store your passwords securely (strengthened, salted hashes).
   

<ul>
	<li>SOME OPTION</li>
	<li>ANOTHER OPTION</li>
</ul>

ul li {
	text-transform: lowercase;
}

<ul>
	<li>Some Option</li>
	<li>Another Option</li>
</ul>

Everyone Uses JavaScript

Progressive Enhancement vs Graceful Degredation

1. Build the foundations, making sure it's a solid base. Then add each floor one by one.
2. Build all of the floors right to the top, then go back and make sure the base is strong enough for people to walk around on the bottom floor.

You're a Hypocrite!

1. To make a site work without JavaScript takes very little effort. Compared to the effort required to make a site work in IE6, which normally takes double the time as you have to build two sites. One to work in IE6, and one to work in everything else.
2. There is no excuse for someone to be using IE6 exclusively. It's heavily outdated, and I'm betting most people's kettle's are actually newer than IE6. JavaScript on the other hand has legitimate reasons to be turned off. Security, speed, text browser, mobile browser, accessibility.
3. Making your site work in IE6 only benefits people who use IE6. Making your site work without JavaScript has several other advantages. If you accidentally introduce a JavaScript bug or the JavaScript fails to load correctly, your site is resilient and won't be crippled, as it will still work without JavaScript. Search Engines generally can't follow JavaScript links, so making them work without JavaScript means search engines will be able to index your site better, etc
4. As new browsers come out, they may introduce inconsistencies in the way JavaScript works. Being able to fallback to a non-JavaScript solution means you don't have to immediately spend time and effort getting it to work in new browsers. Once you've made the site work in IE6 and put the effort in, that's it, it's never going to be useful for anything else.

Stop Waffling and Get to The Good Stuff

<a href="javascript:addToBasket()">Buy Item</a>

<a href="buyitem.php?item=awesomestuff" onlick="addToBasket()">Buy Item</a>

The Better Way

<a href="buyitem.php?item=awesomestuff" id="buyitem-awesomestuff" class="buyitem">Buy This</a>

$(document).ready(function()
{
    $("a.buyitem").click(
        function()
        {
            var url = "buyitem.php?item=" + $(this).attr("id").substring(8);
            $.get(url,
                  "",
                  function(val) { alert("Item added to cart"); },
                  "text"
            );    
            
            return false;  // So we don't follow the normal link.  
        }
    );
});

Final Thoughts

The Wrong Way

The Better Way

$password_hash = hash("sha256", "iamawesome");
// 4aa4029d0d0265c566c934de4f5e0a36496c59c54b6df8a72d9c52bdf0c1a0e8

$user_entered = hash("sha256", $_POST['password']);
return ($user_entered == $password_from_db);

The Even Better Way

$salted_hash = hash($password . $random_salt);

$salted_hash = hash(hash($password) . $random_salt);
$salted_hash = hash(hash($password) . hash($random_salt));
// ...etc

$salted_hash = hash($random_salt . $sitewide_salt . $password);

Slow It Down

$iterations = 100000;
$salted_hash = hash($random_salt . $sitewide_salt . $password);
for ($i = 0; $i < $iterations; $i++)
{
    $salted_hash = hash($random_salt . $sidewide_salt . $salted_hash);
}

The Even Better Than The Even Better Way

<link rel="stylesheet" type="text/css" media="print" href="print.css"/>

#header,
#menu,
#additional-content   {
    display: none !important;
}

a[href]:after {
    content: " (" attr(href) ") ";
}

.blog-post {
    page-break-before: always;
}

Using presentational names for ID's

Using spacer.gif files

Clearing

Page Ordering