Every 3 months I archive my clients’ emails to keep my imap mailbox nice and clean. A couple of weeks ago was that 3 month mark. “Ok, so what’s the big deal?” you may be wondering. Well, I deleted my emails without first checking the archive to make sure they were backed up! The archive was empty!

Even though I’ve had mostly good clients, I still like to keep an archive of all emails for the “just in case” scenario – so I instantly panicked. I use imap for all my email accounts so the first thing was to try and grab the emails off a mail client that hadn’t yet deleted them. After a half hour of trying to get the emails I gave up – it would have taken hours to extract the needed data from the mbox files.

And then – a sudden stroke of genius – I keep backups of my websites… duh! I opened the tar file, went to the mbox folder for my email account, uploaded all of the missing emails back to my server and ta-da – the emails were back. Hooray – thank goodness those backups were good.

The only annoying bug with this “fix” is the timestamps are now off on my email clients. An easy enough problem to fix… but eh… I’m too lazy for that.

So there you go. While it is important to backup your data it is just as important to check your backups! Also, remember that having multiple backups is key!

The way it all works now is like this:

If a site infringes on a copyright, the content owner will send in a complaint, called a DMCA (Digital Mellinium Copyright Act) Notice to the website’s web host to take down the content. The host then (usually) contacts the site owner, sends them the notice, and the owner takes down the content. The owner can appeal the notice and then legal messiness ensues. Basically the ISP (web host) is protected if they follow the rules and forward the notices around. It keeps them out of legal trouble if their customers do something stupid.

Enter the SOPA. The SOPA removes this safe harbor that the ISPs now enjoy and gives the govt (and private parties, to an extent) the right to have a site’s DNS records blocked out. For most people this will make the site appear inaccessible. The only way for the site owner to get it back up is to literally file a lawsuit. All it takes is a simple court order to take down a site – better yet – a court order without a burden of proof.

This is dangerous and gives our govt the rights to block sites the same way Iran, China, and Korea do. This is such a terrible idea that many prominent politicians from both sides are against it!

Please contact your local congressperson and tell them to say “No”!

Back in October Google announced that they would be enabling SSL search by default… at least for Google account owners. What this means is every ounce of information is (at least theoretically *see below) encrypted while it goes over the tubes between Google’s servers and your computer or mobile devices.

Traditionally SSL was only used for high-security sites, such as bank logins, government and corporate portals, and email systems. However, thanks to the yearly increases in server performance, large-scale SSL rollouts is becoming a reality. First it was facebook, then it was twitter, and now Google is joining the party.

While many services such as Banks have used SSL for years, there is huge difference between encrypting something with a few million requests per month vs a few million requests per hour. That extra percent or two of CPU usage for one request really adds up at that scale.

Now with the increased publicity about constant security threats it would not surprise me to start seeing more readily available servers include encryption coprocessors – sort of like what a GPU is for gaming. Many manufacturers have plans to start fabbing such chips, and there are some systems that already include them – but they haven’t really taken off yet. When that starts happening I think the adoption rate of SSL for general-purpose sites (such as Google search) will really skyrocket. One of the big problems now is SSL runs strictly on the CPU… and sure CPUs these days are incredibly fast, but in servers they are usually busy with other tasks – such as running code or fetching a database row or saving something to memcache, etc.

The only other option I could see would be to start putting GPUs into servers. GPUs are actually amazingly fast at encrypting and decrypting data – unfortunately they are also amazingly hot and are nowhere near as efficient as a dedicated encryption processor could be. Personally, I would not want to see what would happen to a server if you could somehow shoehorn a couple of GTX 570s into it… sure it could crunch the hell out of some numbers, but the poor thing would melt. Heck, you could probably fry eggs on it.

I’ll go out on a limb and say in the next 5 years pretty much every server-grade system being produced will include encryption coprocessors (probably coupled with the main CPU), and at least 30% of all traffic will be encrypted, whether it is with SSL or something else.

(*Note: SSL is secure, however, it can be broken. Like every end-to-end solution, it is very possible (albeit difficult) to do a man in the middle attack)

Up until a few days ago I usually stuck with SuPHP – as it was the easiest to setup. However, I got adventurous and tried out the MPM-ITK module – which lets you run a virtual host under a specific username. Unlike SuPHP – ITK will also make apache run as the specified user for everything – static content or dynamic. This will let you close up your public html folders and help keep rogue scripts from editing other users’ files. As an added bonus it also supports other Apache modules, such as Python.

Oh, I almost forgot – it is also fast. Much faster than SuPHP – since it uses the built-in apache module to run php scripts and not a cgi binary. In fact, on my dev box (a custom Intel Atom server) it went from 32 to 75 requests per second for a simple PHP script with ApacheBench (10 concurrent, 500 requests if you’re curious). My production server (the one that hosts this site) went from 100 to 350 for the same script!

While those are artificial benchmarks – the result is undeniable: ITK is faster than SuPHP. While code execution itself is the same – if you get a sudden burst of traffic the speed at which ITK can initialize and load in PHP is much faster than the CGI binary.

So now let’s get into it – how to install, setup, and test MPM-ITK in Ubuntu server:

First off, you have to install the programs:

sudo apt-get install apache2-mpm-itk libapache2-mod-php5

Well, that was easy, no? Now to test it:

cd ~

mkdir public_html

cd public_html

echo "<?php system('/usr/bin/id'); ?>" > test.php

For this example I setup a really simple port-based virtual host:

sudo nano /etc/apache2/sites-enabled/me.conf

Listen 8080


<VirtualHost *:8080>

DocumentRoot /home/your_username/public_html

AssignUserID your_username your_username

</VirtualHost>

Save with ctrl-o and exit with ctrl-x

sudo service apache2 restart

And then load it up in your browser of choice:

If it all went well – it should show your username.

To really test it, simply chmod the file as 600 so it has to be run as the user (or root) to even read it.

chmod 600 ~/public_html/test.php

If it still loads – then you’re all set. MPM-ITK is setup and loading both static and php files as your user.

Now how does it work? The magic line in all of this is “AssignUserID” – in the virtual host declaration. That forces apache to load any files for the host as a specific user and group.

Here’s a few quick reminders about possible security holes and bad practices you may have been ignoring:

URLs

The Flaw

Depending on how your system is setup, URLs can be a huge security hole. Think about it: how often do you validate a requested URL? Of course you don’t need to since firefox and others prevent users from putting evil characters in them such as "…/", right? Wrong! The fact is a black hat will not be using firefox to hack your site. Most of them will use a prebuilt tool or write up a quick HTTP client to get the job done. They can enter all sorts of nefarious characters with that.

The Fix

Validate and sanitize their URLs before routing the request to the appropriate code. Remove any invalid characters and don’t do crap like this:

require($_GET['somestupidvariablesinceimtolazytoproperlycode']);

If you do that, you will get ZERO sympathy if your site gets hacked. K?

Plain Text Config Files

The Flaw

Thankfully this practice is finally starting to die off, but some crappy coders still insist on using plain text files for their script configurations. The files can be viewed right inside the web browser.

The Fix

Use .php, .pl, .cgi, etc files for your configuration. That in and of itself is a massive security boost over using a .ini or .txt file. If for some bizarre reason you have to use plain files you should at least use a .htaccess file to disallow access to the file – or better yet – keep the file outside the site directory.

Login Forms

The Flaw

I’ve worked on at least 3 projects in the past year that had excellent form validation throughout the entire system, but they didn’t validate anything from the login form except for the credentials. Stupid people.

A login form is still a form!

The Fix

In addition to doing the obvious thing of validating their authentication credentials, be sure to validate and sanitize their form data! It still contains user-inputted data, and it cannot be trusted.

User-Agent (And Other Variables)

The Flaw

The user agent is a variable set on the client side to identify their browser. Would you ever think to validate it? Probably not, since apache and others stick them in server variables ($_SERVER, etc); it makes it seem safer. I don’t know of a single web server on the planet that sanitizes user-agent strings. That’s a good thing too – the server mucking with our business is bad for everyone!

The Fix

Once again, don’t trust any client-side data. 20 lines of C code, or even a simple firefox extension, can let a black hat send all sorts of nasty code through client variables like the user-agent, cookies, etc.

From a security standpoint there is no different between:

$query = "select * from users where username=$_GET['username']"

and

$query = "select * from users where username=$_SERVER['HTTP_USER_AGENT']"

They are both insecure. Don’t do it, please!

Being Too Trusting

The Flaw

Hiring freelancers is a great way to get good quality work done for relatively low cost. I used to do quite a bit of freelance PHP work, but lately I’ve been trying to find other sources of income. The one thing that always amazed me while doing development is how trustful some people are. It is one thing if a client knew me via previous work or referrals, but it is an entirely different manner if they are complete strangers. I always found it odd how some people, even before I agreed to do the work, would provide me with file access to their servers to look over things.

Of course I have never once in my entire life done anything malicious with other peoples’ data. Still – I found it odd. It occurred enough that I can’t imagine I’m the only coder out there to have this happen to them.

The Fix

Be more cautious with login data. Only provide it if completely necessary or if the person is 100% trusted. The fact is there are people out there who will purposely screw you over to better themselves. Sad, but true.

Most guides which go over how to disable their spam filter use something like a “to: @” filter and “never send to spam”. This is a huge mistake, and can cause some annoying bugs. For example, with that filter all emails you send will be filtered just like incoming emails (and may show up in the inbox instead of sent), and it doesn’t cover bcc or cc.

Luckily for us gmail lets us use the delivered-to header to filter emails as well. Delivered-to is the final email account where the email was sent, and it will even work for cc and bcc emails. It does not, however, cover emails send through forwarding addresses… but that is easy enough to fix.

• On the main gmail page click “Create new filter”.
• In the “Has the words:” box enter the following: deliveredto:example@gmail.com. Make sure you put your actual email address.
  
• If you have multiple email addresses with that gmail account, or if you use google apps and have email aliases or alias domains, you need to use the “OR” operator: deliveredto:example@gmail.com OR deliveredto:example2@gmail.com OR deliveredto:example3@gmail.com
  
• Click next and then select “Never send it to Spam” and click create.
  

Easy, no? The filter works like this: if the email is sent to one of the entered addresses ( with the to: bcc: or cc: fields) it will never send it to the spam box. The only time this may be a bit quirky is if you email yourself.

Did you like this tip? Leave a comment below!

So that is the point of this article  – to define some nerd jargon in a way that everyone will understand. Some of the definitions are very similar because the terms are very closely related.

DoS – Denial of Service Attack

A DoS is an attack in which one computer or device floods a server with so many requests that it will be unable to respond to legit requests.

DDos  – Distributed Denial of Service Attack

A DDoS is similar to a DoS attack, but instead of one device it is multiple devices (usually hundreds). Sometimes these devices are voluntarily used, sometime they are cloud based services, but most of the time they are zombie computers which are infected with malware. The goal of a DDoS attack is simple: to take down a server or even an entire network.

Adware

Adware is a common type of malware that randomly spams users with ads and popups. These ads may even appear when they are not using a browser. In an infected computer that is running slow, adware is often the culprit.

Virus

Malware that has the ability to both self-replicate and infect a machine with little outside help. Viruses often mutate and change form to avoid malware scanners, and are usually installed via infected programs or documents.

Worm

A subset of a virus, worms have the ability to infect other computers with no user interaction. They abuse security holes to go through the network and attack any vulnerable computers.

Trojan

A trojan [horse] is a piece of software that pretends to be one thing but in reality is another. The MacDefender malware for OS X is a recent highly-publicized form of a trojan horse – it pretends to get rid of viruses but behind the scenes it is fake software that causes popups. Trojans often install other malware.

Rootkit

A rootkit is a piece of software that has the ability to hide itself from process scanners and anti virus software. Rootkits are often used in conjunction with key loggers and spyware to steal user information, or even turn the machine into a zombie computer for a DDoS attack.

Spyware

Malware that tracks user actions, logs their passwords, etc. Spyware is a general term that includes specific software such as keyloggers, but it also covers tracking what processes the user is running, snapping pictures of their desktop, etc.

Keylogger

A piece of spyware that tracks anything the user enters on a machine. They commonly gather usernames, passwords, bank URLs, and email addresses.

Social Engineering

In its basic form social engineering is not something only black-hat hackers do. For example, it would be social engineering to convince a girl to go out with you who may otherwise hate your guts. Sales associate also use social engineering to up-sell to customers.

However, when used for black-hat purposes it can be quite nefarious. A good social engineer can convince someone to give out a password, gain security access, pretend to be an employee, etc. Con men are social engineers.

Phishing

Phishing websites are fake sites that appear to be the real thing. The goal is almost always to gain login credentials to banking sites or email services. Nearly every new browser has a built-in phishing filter that will alert users if they are on a reported fake site.

And that’s it for now. If you can think of anything else to add, please leave a comment!

No Special Characters

Virtually all security experts agree the best way to make a secure password is by using a mixture of alphanumeric characters (A-Z and 0-1) in addition to special characters ( !@%$)&^ ). So why is it so many websites still disallow special characters? It is simply mind boggling.

For starters, if you are properly developing your application, special characters should not matter for data that is going through a hash algorithm (you do hash your passwords, right?) The algorithms only care about bits and bytes – as far as they are concerned an A is no different than a % other than the bit values they represent.

Length Limits

One of the financial sites I use on a regular basis limits passwords to 10 characters. While yes, a 10 character password is a lot better than 90% of the passwords used on a daily basis by most people, it is still insecure. But that is an argument for another day.

My point is, why have such a low limit? I do agree a limit is needed (after all, you don’t need people sending a megabyte of data every time they log in), but the limit can be fairly high. Theoretically a hashed password will always be the same size in the database – whether the original text was “abc” or “123456789012345678901234567890″ – it doesn’t matter. So please, stop it with the annoyingly low limits.

Not Hashing The Passwords

This is just plain stupid. There is no reason in the entire universe to ever store plain-text passwords in your database.

– Once Again –

There is no reason in the entire universe to ever store plain-text passwords in your database.

Get it? It sickens me how many services out there still literally email your password, in plain text, when you use their “forgot my password” function. Just stop it. Please hash the password and if they forget it, have a verification test set up, and if they pass it let them make a new password.

Otherwise you’re just asking for a script-kiddie to cause trouble.

Oh, and do use password salts.

Change Password Fields

One of the best security measures you can put in place is requiring the user to enter their password to change their login name (email/username/whatever) or to change their password. The reason being – what if someone intercepts a cookie?

Without requiring a password they can steal the account very easily. By requiring a password it makes it much more difficult. And that leads me onto my next point…

Cookies

And last but not least is cookies. No – not the edible delicious treats – but those little bits of text that let you store session data.

A login cookie should never have your password (even hashed) in it. When a user logs in an id should be generated – unique to this session – which will be used to identify the user. That id will then be stored in the database and in the cookie and will only be valid for as long as the cookie is valid. Heck, you can even do a mixture of a user id and the session id.

Either way if the cookie gets intercepted a malicious user will still be able to get in – but at least this way their password is safe.

$input = "' or 1='1";


$ret = mysql_query("select * from users where user_name='$user_input'");

In this example the otherwise simple query would fetch all rows in that table. The malicious user could use it to get secure information such as password hashes (which, if they are not salted and are poorly hashed could lead to the actual user passwords).

One other major source of sql injections I have noticed has to do with not properly quoting data you get from the database. What if your code looks like this:

$ret = mysql_query("select * from users where user_id=5");

$row = mysql_fetch_assoc($ret);


//do a bunch of crap

$ret = mysql_query("select * from users where user_name='" .$row['user_name'] . "'");

The top part is pretty simple, it gets the user info for the user with the id of 5. Then lets say your app does a bunch of “crap”, and then for some odd reason you fetch data from the table again but use the user_name column? Again, not a problem, right? Why quote it if the data is from the database?

Well, what if the user name is equal to “‘ or 1=’1″ ? You guessed it – it returns every users’ data.

While this is a bit of a stretch – you’d be surprised how often I see code similar to that in projects that I work on. Heck, I’m even guilty of it. The biggest fault here is not quoting and not sanitizing strings. And lazy coding.

The point of this post is simple: quote ANY data that goes into your query (unless you know for darn sure you don’t need to), and not just user-inputted data. Never trust any data, never. Always validate, always sanitize, and don’t be afraid to show an error 503 page if something seems fishy. It is better to be safe than sorry, especially when you are dealing with user data.

Nothing would be worse than having to send out thousands of emails apologizing for a security breach, knowing full-well it could have been easily avoided.