The 5 Most Common Ways Your Site Will Get Hacked

not-so-easy-buttonAs developers, we should always be concerned about the security of the sites we build.

“…there isn’t an Easy Button that you can press to make your websites automatically secure.”

Unfortunately, there will always be malicious users on the Internet searching for ways to hack websites for their own personal gain, whether that be by obtaining credit card information, usernames and passwords, or email addresses.

Even worse, there isn’t an Easy Button that you can press to make your websites automatically secure.

One of the most important things you can do as a developer is to stay informed on the latest security vulnerabilities and how you can protect your sites.

A great source for staying current is through the Open Web Application Security Project, more commonly referred to as OWASP. Their goal is to drive “visibility and evolution in the safety and security of the world’s software”.

This summer, OWASP released their Top 10 Application Security Risks for 2013. This list is a great starting point for developers concerned about web security, as it helps to identify the most critical security flaws in web applications today.

How important do we think the OWASP Top 10 list is? We have copies of it hanging above the urinals in the men’s room at The Nerdery’s main offices.

Without further ado, here are the top 5 security risks for 2013. You can find the full OWASP Top 10 list, which contains more detailed information and examples, at

1. Injection

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Most web applications that we build store data in a database of some kind, whether its MySQL, PostgreSQL, or Microsoft SQL Server.

In order to get display database-driven data on the screen, we query the data from the database, typically using dynamic parameters included in the URL.

For example, your application might allow users to view a product by specifying the ID in the URL, such as The underlying query that would need to be executed to retrieve the product details might look like select * from products where id = ‘35’.

A developer not aware of SQL injection might write the following code:

$db->execute(“select * from products where id = ‘{$_GET[‘id’]}”);

At first glance, this code appears to be fine, as long as the ID is a number. However, a hacker who knows SQL could pass in a carefully crafted, non-numeric string for an ID that would allow them to execute other SQL statements on the database, such modifying other records or even altering the database schema.

The easy way to avoid this vulnerability is to always sanitize any user inputs in your queries. Almost all modern libraries allow you to do this in one way or another. A more secure query would look like the following code:

$db->execute(“select * from products where id = ?”, array($_GET[‘id’]));

2. Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

Have you ever sat down at a public computer and realized the previous user closed the browser without logging out of the website they were viewing? Since you’re a nice person, you immediately logged them out of the site, right? It’s one thing if the site they were browsing was Facebook, but what if it was their online banking site? Unfortunately, many people might take that opportunity to make themselves a little money without the previous user knowing until it’s too late.

One way developers can try to prevent this type of user error from causing any further damage is by making sure that sessions are set to expire in a reasonable amount of time. Doing this would require users to re-authenticate after they’ve gone inactive, so even if a user forgot to logout, they would be automatically logged out after awhile.

3. Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Just as important as it is to sanitize user inputs, it’s equally important to escape user output. By not escaping user output, a malicious user would be able to execute a client-side script whenever a user views a page that displays their data.

For example, let’s pretend I updated my name in my Facebook account to be “<script>alert(‘Hello’);</script>”. If Facebook didn’t properly escape user output, anytime a friend visited my profile, they would be greeted with an alert popup.

his seems more annoying than anything, a hacker could modify the script to send the user’s browser cookies to a site controlled by the hacker, which could then allow the hacker to take over the user’s account.

Most good frameworks and templating libraries have functions for escaping user output, so this vulnerability can be easily avoided. However, it’s easy to accidentally forget to escape an output, so the key is to make it a habit.

4. Insecure Direct Object References

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

As I previously mentioned, most web applications access resources using parameters specified in the URL. For example, after you log in to your bank’s website, you might be redirected to your account with a URL that looks like From here, you’d be able to pay bills, transfer money, and withdraw money from your account.

What would happen if you changed the ID in the URL from 123 to 456? If the web application doesn’t properly validate that you’re allowed to view account 456, you might be able to withdraw money from someone else’s bank account.

While this seems like the easiest way to “hack” a website and should have been prevented, this is exactly what happened to Citigroup back in 2011. Just by changing URL parameters, a hacker was able to access over 200,000 bank accounts without proper authorization.

Again, the way to avoid this vulnerability is pretty simple. Any time you accept a dynamic parameter to retrieve a resource from the database, you should verify that the current user is authorized to access the resource.

5. Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

If you’re a PHP developer, there’s a decent chance you have phpMyAdmin installed on your server. If so, when was the last time you updated it?

You might be surprised to find out that there have been 42 security updates made to phpMyAdmin in the last three years, including five critical updates. If you haven’t updated your version of phpMyAdmin, your server might be at risk.

It’s important that you always have your software up to date, especially when it comes to security updates.

Published by

Tony Nelson

Tony Nelson

After taking a junior high technology class in 1998 which sparked his interest in programming, Tony is now one of The Nerdery’s experts in PHP, Objective-C, ColdFusion and JavaScript. With his Bachelor of Science in Business Administration from the University of North Dakota, Tony previously worked as an Application Architect before joining The Nerdery as a Developer in 2011. After demonstrating his command of technology and helping launch over 50 projects for Nerdery clients, Tony was promoted to Senior Developer in 2013 where, in addition to his previous responsibilities, he actively mentors his fellow developers and performs code reviews.

2 thoughts on “The 5 Most Common Ways Your Site Will Get Hacked”

Leave a Reply