- The Visitor: People just visiting your site.
- The Office: Whether at home, work, or a coffee shop, Internet traffic is routed through some additional devices that can be compromised.
- The Internet: After leaving the home or office, traffic is sent through the Internet itself.
- The Server: Eventually, traffic is routed to a web server. A lot of these are virtualized these days, but they still act like physical computers.
- The Code: The server is then responsible for running code which will generate the page. For us, the code is usually written in PHP.
- The Admin: The last link in the chain is your site administrators.
Each of these six targets are places where websites can be compromised. Each vulnerability goes after different targets as they attempt to find ways to interfere with traffic between you and your visitors.
Most websites use a programming language called SQL to save and search information like user accounts or news articles. PHP code has to be written to generate small pieces of SQL and execute them.
SQL injection is centered around finding weaknesses in the PHP code that generates and executes SQL. Even a minor flaw in this bit of code can let a hacker execute any SQL they want.
SQL Injections are only possible on websites with a flaw in the code that’s responsible for generating or executing SQL.
Hackers are most likely to use SQL injection to dump everything saved in the website. Depending on the site, this could mean user accounts including passwords, account numbers, or even credit card information.
SQL injections are very common. Databases are common and it's very easy to overlook a place where a hacker can inject their own SQL code into the site to do as they wish. Popular CMSs (like Drupal and WordPress) tend to be particularly targeted.
- Avoid storing sensitive information.
- Encrypt (or hash) any sensitive information that must be stored.
- Use a trusted, secure PHP library that will handle generating and executing SQL.
When a visitor types in a URL (say, imarc.net), DNS is responsible figuring out which server hosts the site. Typically, a visitor’s computer first asks the local network about the website’s domain (imarc.net), then the visitor’s Internet provider and eventually a totally different server that is responsible for DNS itself.
When DNS is hijacked, a visitor’s computer is told the website is hosted somewhere else.
DNS hijacking can happen in a few places:
- The visitor might have their DNS hijacked on their computer by some kind of adware or spyware.
- The visitor’s office might have its DNS hijacked, but it's less common.
- Still rarer, the DNS host can be compromised.
When DNS is compromised, visitors are sent to an entirely different website. It might be a page full of ads or even something like a fake version of your site designed to trick users into typing in passwords, credit card information etc.
DNS hijacking is uncommon. They usually require that a visitor install a piece of malicious software themselves.
The simplest solution is to serve your website over HTTPS and use SSL certificates. SSL certificates provide a way for your server to establish and verify its identity to visitors. If your website’s DNS is hijacked, anyone visiting your site will be shown a warning.
Password Brute Force
The most common way hackers break into accounts is through brute forcing passwords. It's simple to automate password attempts, and an attacker can try hundreds or thousands of times per minute. Some hackers will even just scan for popular CMSs (such as WordPress and Drupal) to try to quickly find new targets.
People choose bad passwords. Most automated attacks don’t just try these twenty five, but will try the 10,000 most popular passwords and simple variants of them.
While it’s unlikely they can take the site down, they are most likely capable of defacing the site and perhaps even locking other administrators out. This can be far more damaging than a simple outage.
Brute force attacks on login are common. They are easy to automate, and scanning for login pages can be automated.
Pick good passwords. There’s a variety of policies that can be implemented to try to force people to have good password habits, but people can always choose insecure passwords, leave them on post-its, etc. Education is the most effective preventative; teach your users ways to make good passwords.
Further, especially for shared administrator accounts, make sure the password isn’t only a good one, but change it regularly.
SSH Server Brute Force
We use SSH to securely access and manage all of our servers. Just as passwords can be brute forced to access a website, SSH can also be brute forced. We see this kind of attack on one of our servers on a daily basis.
Just like regular password brute forcing, people often pick weak passwords. While it may seem more likely that your website itself would be attacked, trying to connect via SSH over and over is even easier to automate.
If they succeed they’ll get access to the whole server.
SSH Brute force attacks are very popular. We see these kinds of attacks on a daily basis.
First, our servers automatically detect and block a user if they have a lot failed password attempts. Most of the automated brute force scripts give up even if they’re blocked for a short amount of time. Second, we monitor our servers, so if one server is under particularly heavy load, we are alerted and can investigate.
Third, we use SSH keys. SSH keys work like giant passwords which typically require their own password to access. SSH keys are very hard to break, and are widely used to securely connect users and establish their identity. Consider requiring SSH keys for all server access.
The weakness is inherent in HTML. In a web page, the difference between whether text is executed as code or displayed as text is pretty minor. This is very useful but it also creates some risks.
While this won’t take down your website, attackers can redirect your visitors to their own site or eavesdrop on anything your visitors type into the site – including passwords or credit card information.
Cross-Site Request Forgery (CSRF)
Anytime you visit a site that remembers you, whether it’s remembering that you’ve logged in or what items you have in a cart, your browser is storing some information locally on your PC, phone or tablet. In a Cross-Site Request Forgery, hackers use this information to get your computer to perform an action without your knowledge.
It's difficult for websites to distinguish between what a visitor is doing from what malicious software on the visitor's computer is doing.
A hacker might detect when you sign into a banking site, and then secretly transfer money using your current session.
People looking to take advantage of cross-site request forgeries usually go after large sites, like Gmail, Amazon, or major banks. Most of these exploits must be specifically built for the site they’re targeting.
Because there are many different examples of cross-site request forgeries, each have different solutions. The most common example is generating a unique, one-use code when someone visits your site and then verifying that you got the right code later. This ensures that the visitor performing the action is the visitor looking at the site.
Bugs & Code Vulnerabilities
The website’s code can introduce vulnerabilities. It could be something as minor as a way to reveal who has registered for a given website, or something as serious as a way for attackers to run arbitrary code on the server. Widely used open-source platforms are big targets.
Bugs happen; when developing a custom website, there’s always a risk of introducing vulnerabilities.
Everything from sensitive information to control of the web server itself.
It really depends on the severity of the vulnerability in the code. A large vulnerability may be easier for someone to find and take advantage of, whereas many are hard to find and exploit. The higher profile your website, the more likely it is a hacker will search for code vulnerabilities.
It's important that all code is vetted by a developer before its installed. Third-party plugins can introduce minor bugs that may create vulnerabilities. Popular CMSs like Drupal and WordPress also provide their own security updates which are critical to use.
We recommend managed hosting for both Drupal and WordPress, as the hosting company takes on the responsibility for making sure that sites they are host are updated as quickly as possible.
Server Vulnerabilities (Heartbleed and Shellshock)
Vulnerabilities do show up in the server as well. Heartbleed was a vulnerability in OpenSSL. Shellshock was group of vulnerabilities in bash. While Hearthbleed and Shellshock both gots lots of media coverage, most server vulnerabilities are discovered, reported and patched without any fanfare at all. PHP and Apache regularly release security fixes.
Many servers use the same software. Approximately half of all websites use Apache. Two-thirds run Unix-like operating systems including Linux; the rest run Windows. This means that a vulnerability can affect a huge number of sites.
While some of these exploits might be used to deface a website, they are usually used to gain access to the server itself. Once someone malicious has access to the server, they can do whatever they want with it.
There are whole sites dedicated to spreading information about these kinds of vulnerabilities. They’re discovered fairly regularly, and usually fixed quickly.
It’s important to make sure that your servers are maintained and monitored. All the software used to run a website come out with security patches on a regular basis. It’s important to get them installed quickly, as usually the vulnerability is announced at the same time as the fix.
One of the simplest ways to gain access to a site is to talk your way into it. Hackers may call into one of your providers, posing as someone who works for you and asks for passwords to be reset or emails changed. This is one of the easiest ways to compromise a website, because it takes advantage of people’s good nature to gain access.
The weakness is human nature. It’s easy to want to help someone out and let them bypass policies that establish who should be authorized to ask for something.
Any account with an associated login and password could be given out. Some of the worst examples involve giving out access to the web server or access to control the DNS for a website. With access directly to the web server, a hacker can put anything he wants on the server. With access to DNS, a hacker can change your domain to point to their server instead.
Because this requires a real person to go after a specific company and can’t be automated, it’s not as common as other attacks. However, this is one of the simplest ways people do manage to get into accounts.
Minimize the number of people who have critical access. For example, on all iMarc managed servers, we do not give out any access to non-iMarc employees.
Second, make sure to positively verify an identity if you’re dealing with someone you haven’t before.
HTTP is the protocol used by servers and computers to talk to each other over the network. By itself, HTTP is not secure. Data is not encrypted, even usernames, passwords or credit card numbers.
It’s possible for a hacker to eavesdrop on everything a customer is doing. It’s even simpler to do if the target is using wifi. Effectively, every computer on a wifi network is broadcasting everything it’s doing like a radio station (because wifi is radio).
You cannot rely on wifi security to protect you. Even secured wifi networks are generally regarded as being easy to crack.
The weakness is HTTP. It’s a simple way to transmit data between computers, but it was never meant to be secure.
Information being shown to customers, or information a customer sends to the website, might be captured. This could include passwords or credit card information.
Like other some vulnerabilities in this list, it's rare because it requires a real person to be involved. That said, snooping on wifi networks is very easy, and it tends to happen especially at major events.
Use HTTPS (HTTP over TLS) to encrypt all the traffic between the customer and the web server. There are still more advanced ways around this as well, but this protects against the commonest kinds of eavesdropping. Both the US government and Electronic Frontier Foundation have active campaigns to move people to use HTTPS instead of HTTP too.
HTTP Eavesdropping (as mentioned above) is one kind of man-in-the-middle attack. However, I also want to mention another kind that shows how HTTPS can fail.
HTTPS relies on SSL certificates and certificate authorities (or CAs). Built into browsers is a list of trusted certificate authorities. When connecting to a website, the browser requests a certificate from the web server. The certificate specifies which websites the certificate is valid for, when the certificate expires and which certificate authority can establish it as valid. If everything is good, encrypted communication is established between the web server and the browser. If anything is wrong, the browser shows some kind of warning and may even block you from visiting the site.
Sometimes, this process is interfered with. One way is with software running on your PC: Lenovo pre-installed software from Superfish in late 2014. The software from Superfish introduced a way where invalid SSL certificates would appear valid even when they weren’t.
Man-in-the-middle attacks also can happen at the network level: some corporations run SSL decryption devices on their office networks which intercept SSL internet traffic, decrypt it, examine it and re-encrypt it. Although these are meant to protect the company, if they are not setup properly, these SSL description devices can also hide whether the original site was validated or not.
HTTPS may encrypt all your data, but unless your browser can validate that the certificate is valid, then you still can’t be confident that your data is being sent to the right place.
Any information entered by customers or administrators, including passwords and credit card information.
The most common kind of HTTPS Man-in-the-Middle attacks all happen within the visitor’s computer itself. Without them realizing it, some kind of malicious software can intercept and decrypt information that appears to be secured over HTTPS when it really isn’t.
SSL decryption devices and software like Superfish are inherently risky and should be avoided whenever possible. At minimum, make sure everyone affected knows the risks associated.
Some of our data is coming from firsthand experience as web developers, running hosting for our own sites and our clients. When that wasn't enough, The Web Hacking Incident Database was very helpful. I'd also suggest reading Sophos Security Threat Report, as they have a lot of insights I found interesting.