As a web developer, you and your clients’ websites all fall under your management when developing and maintaining all aspects of the website. In other words, it’s your responsibility to design an attractive, user-friendly, and secure website. Between trends, advice, and shortcuts, the aesthetics and UX of a website has been covered extensively. The security, however, should be so crucial to you and your clients because without security, all that you’ve worked for and built can be destroyed, stolen, or (worst yet) changed.

After the popular Target hack incident, many webmasters have opened their eyes and began looking at the security of their own websites. Here’s a surprising statistic: In 2012, about 86% of all websites had at least one vulnerability. Only 61% of those were patched, and the average time until the issue was resolved was over 6 months.

How secure is your website? What can you do to prevent hackers from waltzing in?

Website Changes

We’ve all been stuck at the debugging process before searching for hours on end to find that one mistake in the code. It’s annoying and takes up way too much time, but it has to be done. When a hacker breaks into a website, they are generally after something, with money and identities topping the target list. On the way out, they don’t leave everything the way it was. No, they will make your life as difficult as possible to get the website back in good condition. So they change stuff, starting with the login. Once you realize all of the changes throughout the website, it may even be worth starting over from a backup and working from there because finding a change as opposed to something missing is like finding a needle in a haystack.

Avoiding All of this Altogether

It’s safe to say you’d rather not deal with any of what’s associated with a website break-in. So, here come the website security basics that every web developer must implement to have a secure website. Some of the topics we’ll discuss include:

  • Securing Logins
  • SQL Injections
  • Open-source Vulnerabilities
  • Cross-site Scripting (XSS)
  • Spam Filters
  • SSL/Credit Card Security

Securing Logins (Don’t skip this one!)

You’ve heard this before: “you need a secure password.” Well, let’s jump slightly further into that. Your administrative logins are the keys to your website. Protecting them should be your priority as a web developer, designer, webmaster, or owner. So the first thing is to not give out administrative logins like candy. Lock down the heart of your website and only give the access to those that need it.

As we all already know, there are two fields to a login: the username and the password. Many web developers assume if the password is secure, they’re fine. When someone recommends you change the default login, they don’t mean change the default password. They said the “login”, meaning both the username and password. I highly recommend changing the username and password to something you can remember but is secure, meaning upper-case, lower-case, numbers, and symbols. Both fields are just as important because if a hacker has just one and not the other, they can’t get in. Don’t ignore your username, and please don’t use the username “admin.” It’s the first username any novice hacker would try.

SQL Injections

If your website uses an SQL (Server Query Language) database (pretty likely), you are vulnerable to SQL injections. Before diving any further, do not think SQL databases are unsecure because, in most cases, they are very secure. The process when using an SQL database for logins consists of:

  1. User input (username, password)
  2. Sending of information to the SQL database
  3. The SQL database checks the data with current information
  4. Data is found to be true or false
  5. Results are returned to the user. If one of the fields comes out false, the login fails. If both are true the login succeeds.

Seems simple enough and it usually is, but an SQL injection manipulates the values of true and false. If the SQL database is set to read simple code like “OR” and “AND”, the hacker can input a simple code into the fields such as test’ OR ‘1=1. There are quite a few variations that can be used to break through this simple login barrier, but this is a simple example. The SQL database will receive the data and read test and determine that it is a false statement…but it doesn’t stop there because it sees the apostrophe (), which in SQL language means the statement is over. Following this “ending” is another statement, though: OR. Then the start of another, indicated by the apostrophe (). It sees the 1=1 as a true statement, and closes the statement on its own. This simple “OR” statement can mean life or death for your website and you should make sure your database does not read them as code or (even better) not at all.

Here’s an example in English: “Yes or no: Are you a human OR dead?” Technically, yes, because you’re a human. The “OR” signifies you only need to meet one requirement, similar to the “If…Else” statements in web coding and scripting.

Extremely poor-coded SQL databases (very rare today) can even be told to dump the table in their response using complicated SQL coding. Oftentimes in multiple “login attempts.”

To prevent SQL injections, the best thing you can do is to use a set of rules where the user’s input is checked for syntax, length, and type. For more information on SQL injections (and a more in-depth look), take a look at Veracode’s article on SQL injections.

Open-Source Vulnerabilities

Open-source tools, such as the ever-popular WordPress, are very useful and easy to use. In fact, you can design an entire website using pre-coded themes and plugins. Unfortunately, we commonly find that security is sacrificed for convenience. All WordPress sites are not unsecure, but some hackers target WordPress websites specifically because of the vulnerabilities.

You’re probably thinking “what vulnerabilities?” Well, this list is from the CVE database, where all vulnerabilities that have been found are noted. One of the downfalls with WordPress is the excessive use of plugins, which in many cases have administrative access to your website. More plugins reaching out to the Web means more chances of a hacker jumping on-board with the stream to come back in. The vast majority of plugin developers are well-aware of the security vulnerabilities of their plugins and fix them quite fast. The same goes with the WordPress team.

To secure yourself from these vulnerabilities, the absolute best thing you can do is have a web developer design your own custom CMS with a security-focus and experience. Custom CMS’ prove to be more difficult to break than a typical WordPress site. However, many business owners prefer WordPress (myself included), in which case your website must be kept up-to-date. If you don’t believe me, take a look at that CVE list and find your version of WordPress and what’s out there waiting to be used. Some vulnerabilities are as recent as 3.3.2 and more are found every day.

Cross-site Scripting (XSS)

Cross-site scripting is when a hacker targets your browser’s cookies to gain sensitive information. Cookies can be used to log in to your website without even knowing the password. That “remember me” button can be deadly after all. They do this through JavaScript fragments that are sent without being validated by your browser via web applications. The user’s browser reads it as acceptable (as the source seems safe), and will allow all access to cookies, including stored passwords.

Prevention on the web server’s end is quite simple: deny all HTTP TRACE requests. If you don’t have access to your web server (it’s managed remotely), then contact the server administrator and ask them to do this for you. On the user’s end, a brilliant plugin called NoScript can prevent these pesky scripts from running automatically on a website. NoScript is a Firefox extension only and is not available for Chrome, Internet Explorer, Opera, or any other browser.

XSS is a serious vulnerability as it has been declared the most frequently found “serious vulnerability,” accounting for almost half (43%) of all of the “serious vulnerabilities” in a 2012 study. If you use NoScript and browse your favorite websites, you’ll notice a XSS alert multiple times. Don’t take XSS vulnerabilities lightly.

Spam Filters

Yes, this basic form of protection can protect you. Ask any cyber security expert and they’ll tell you the end users are the real threat to the organization. People open e-mails all day long and click links just to “see what it is” and end up giving remote access inside of their computer, allowing for keylogging, screen captures, webcam captures, and other scary things that can be used to steal information. These threats mean the hacker can steal your website’s login password just by sending you an e-mail. Spam filters are useful for limiting the number of malicious attempts; however, no spam filter fully removes all malicious e-mails.

To prevent these malicious e-mails, keep your spam filter on and your eyes open. When hovering over a link, most applications (Outlook included) and all browsers will show you where the link goes at the bottom of the window.

SSL and Credit Card Security

Secure Socket Layer (SSL) on a website is 100% required if you run an e-commerce website. Any time credit cards go across your web server, you should use SSL to encrypt and secure the data. To get an SSL certificate, you have to pay a certified company, such as Digicert ($139/yr.). This is a small price to pay for the security of you, your customers, and your pockets. SSL can be used for any website looking to encrypt the traffic between its users and the server, but the articles on a website like Inspiredm.com, as well as the comments on it, do not have any sensitive personal information on them.

Following up with SSL is another credit card protection practice you should be familiar with: discarding credit card information. Unfortunately, you cannot simply drag it into the trash and be done with it. Deleted data is retrievable, even if in pieces. First, do not throw away the drive that contains the credit card information. You should also overwrite the data with other data (not more credit cards, please). Applications are available for permanently deleting the data. If you do not trust the application, then download it and disconnect the system you are “purging” from the Internet and then uninstall all elements of the application. This will prevent any information from being sent to the developers, as the application has no connectivity to do so.

The best thing to do is to delete the data and overwrite the drive in all 0’s at least 2 or 3 times to ensure it’s gone. Government agencies, such as the NSA and DOD will overwrite sensitive data at least 7 or 8 times, and then destroy the hard drives. After the first overwrite it’s rare to find the data recovered, but it is possible. As a test, make a file and delete it permanently by removing it from the Recycle Bin as well. Then download a program called Recuva and see if you can retrieve the file.

Bottom Line

To secure your website, make sure your login is as secured as possible by:

  • Installing a spam filter
  • Keeping your site up-to-date
  • Using strong login information
  • Not clicking unknown links
  • Disabling/Denying all HTTP TRACE requests on the web server
  • Re-writing secure rules to your SQL database

And as always, it’s a good idea to perform a malware scan and vulnerability scan from your hosting provider, if available. Take your website security seriously and double-check your parameters.

Take a look at this infographic on the study back in 2012 on general website security statistics- (also the source for introduction’s statistics: http://www.scmagazine.com/2013-website-security-statistics-report/slideshow/1317/#0)

Author bio: Ryan Gavin is an associate of Ignition72, a Maryland web design agency. He loves finding new websites with great designs and other designers that do their job well and love it. He feels that without a web designer, a website is rarely successful.