After having run thousands of scans on Hackmetrix we can finally say we officially know the 10 most common vulnerabilities we’ve found across every site we scanned.
The purpose of the article is to be a source of information for users who have found any of these on their sites, to encourage site owners to check their online properties for any of these, and to provide a line or two on how to fix them wherever possible.
If you’re not sure how to check your site for any of the vulnerabilities mentioned here, then a free Hackmetrix account could be a good start. It only takes a minute to sign up and you’ll have your first report in just a couple hours.
As time goes by we’ll also be expanding on each of these with more in-depth guides explaining each of these issues and how to solve them.
Let’s get to it!
- Absence of Anti-CSRF Tokens – Risk: Low
Our most frequently found vulnerability is (luckily?) not a high risk one. Cross Site Request Forgery (CSRF), is a type of attack that tricks a user’s browser into performing an unwanted action on a trusted site where the user is authenticated, and it works even if the user doesn’t have that site open at the time.
This works because of the trusting nature of web browsers. A browser doesn’t check to see if an outgoing request is going out from a specific domain, and so in a similar way you might be able to tweet or check an Instagram post from an external website, a more ill-meaning site could use an open session in one of those sites to post, or take some other action, on your account without you ever noticing.
For example, let’s say you regularly check Twitter and so your session on that site remains open (an open session is what makes it possible for you to open a new tab and go to twitter.com and see your feed without having to log in every time). While you’re checking your friends’ tweets you click on a very enticing link to a questionnaire to find out what kind of fast food you are. Irresistible.
That questionnaire though, holds hidden and nefarious intentions, and as soon as you click a button on it to see the results it takes advantage of your open session on Twitter to tweet on your behalf a link to itself and follow a bunch of unknown accounts. This without you ever consenting, or finding out until you look at your own feed.
Now take that and imagine it being used on, instead of Twitter, a bank account. CSRF is a common problem, and one of the ways it can be prevented is by using Anti-CSRF Tokens.
Using an anti-CSRF token would mean that each time a website loads it includes a unique string of characters, then when a request is made (in our example that would be each time you try perform some action on Twitter), the server expects to receive that same token back, and if it doesn’t then it will refuse to perform the action requested. You can see then why it’s highly recommended to implement an Anti-CSRF Token, and why not doing so is considered a vulnerability.
- Source Code Disclosure – Risk: High
A source code disclosure is exactly what it sounds like, a vulnerability that allows attackers to have access to an application’s source code.
Giving an attacker access to your source code is like giving a robber the blueprints to a bank. They can take time to read through it, understand the logic of your application and any flaws it might have, database structures, and that way prepare for an attack.
This vulnerability is also particularly risky because developers sometimes have a bad habit of leaving sensitive information such as database credentials as a comment in the source code, so in that case not only will a perpetrator understand your app enough to attack it better, they could also immediately export your user’s personal information.
Quick actions to remedy this vulnerability are to make sure all files on the server are needed to run the application. If they are and they are not meant to be public, then change their permissions so they can’t be accessed by public users, if they’re not needed then remove them from the server altogether.
- Backup File Disclosure – Risk: Medium
Similarly to a Source Code Disclosure, a Backup File Disclosure lets public users see content that should be private.
Backups can include very sensitive information such as password files or a full application’s source code. Even if the code has been updated since, it gives attackers insight into the logic of the application and, in the case of database backups, very concrete information about the app and it’s users.
If you ran a scan and this came up as a vulnerability, then an easy way to prevent it is to not store backups on production servers. Nothing is safer than for sensitive data to not be there in the first place.
- SQL Injection – Risk: High
SQL injections are too common, and about as old as SQL itself. Although there are different types of SQL injections, this vulnerability is about an attacker being able to execute SQL queries on a server that they do not have authorized access to.
SQL injections have been consistently listed as the most common and widely exploited vulnerabilities, and it’s one of the most dangerous issues you can find on your web app as it compromises data confidentiality and integrity.
As there are different type of SQL injections, attackers can also take advantage of a vulnerability of this kind in a variety of ways. Some examples could be sending queries directly in a URL or in forms where user input isn’t put through proper validation.
Once a query is successfully submitted and processed then what can be done is totally up to the attacker, this could be things like inserting users, assigning admin privileges, or exporting any table on your database.
Securing your site against SQL injections can be extensive work, but some basic steps you can take is to make sure you restrict access to the least amount of users possible and give them only the necessary privileges – this certainly means you shouldn’t just connect as ‘root’ every time. You can also make sure that URL parameters and user input is handled properly so that any terms that may be related to database queries are ignored.
We’ll review preventing SQL injections in a later article with a more technical and hands on approach.
- Integer Overflow Error – Risk: Medium
Integer overflows happen when a mathematical operation on an integer makes it greater than the maximum size of the integer type used to store it. What usually will happen in this case is that the integer will “wrap around” the maximum value and start again at the minimum value.
To put this in simpler terms, although not very technical: let’s imagine you’re storing student’s grades in a database where 0 is the lowest possible grade and 10 is the highest. If a student had a 10 on your database and you tried adding one more point, an integer overflow error could occur because nothing over 10 is allowed. This would case the grade to wrap around and be stored as a 0.
Attackers can take advantage of these conditions to manipulate variables in a way that wasn’t originally intended. Picture these scenarios:
- When calculating a purchase order total, an integer overflow could allow the total to shift from a positive value to a negative one. This would end up giving money to the customer, in addition to their purchases, when the transaction is completed.
- Withdrawing 1 dollar from an account with a balance of 0 could cause an integer underflow and yield a new balance of 4,294,967,295.
- A very large positive number in a bank transfer could be cast as a signed integer by a back-end system. In such case, the interpreted value could become a negative number and reverse the flow of money – from a victim’s account into the attacker’s
- HTTP Parameter Override (HTTP Parameter Pollution) – Risk: Medium
HTTP parameter pollution is a vulnerability that was long overlooked for its simplicity. It consists of exploiting the way the server behaves once it receives parameters in a request, specifically several parameters with the same name.
Different web servers handle a request with two or more request parameters with the same name but with different values, and their behaviours vary wildly. An attacker could for example build a URL that, when visited, will modify or override parameters of URLs in the response
This would result in the site having an unexpected behavior, if it were a contact form for example, parameter pollution could be used to deliver submissions to the wrong recipient.
- HSTS Missing From HTTPS Server – Risk: Low
HSTS stands for HTTP Strict Transport Security, and it’s a mechanism that allows web servers to declare that all interaction between them and web browsers should be through HTTPS and never through the insecure HTTP protocol.
The lack of HSTS allows downgrade attacks, SSL-stripping man-in-the-middle attacks, and weakens cookie-hijacking protections.
This means that not having HSTS enabled can open a door for attackers to downgrade HTTPS sites to HTTP, where all requests go out in plain text format and they can sniff out traffic and steal credentials and private information from users.
- Web Application Cookies Not Marked Secure – Risk: Low
When cookies aren’t marked as secure they can be freely sent over HTTP, making them readable in plain text by attackers performing, for example, a man in the middle attack.
Think of a user’s session cookie being in plain text and intercepted, then an attacker could impersonate that user and hijack their session.
The fix for this is to mark all cookies in the application as secure, however, it really is only important when they relate to authentication or carry any personal information.
- Directory Browsing – Risk: Medium
This vulnerability is pretty self explanatory, but it occurs when the server responds with a list of files in the target directory, making attackers able to browse files on the server. While the severity of this vulnerability is completely dependant on how sensitive the information on your server is, it’s generally a good idea to disable directory listing unless it’s the intended functionality.
- Web Application Cookies Not Marked HttpOnly – Risk: Low
HttpOnly is a flag that is added to cookies to make sure that they can only be accessed through HTTP requests, and not through client-side scripting.
This means that while a session cookie could be sent through a POST request, for example, you wouldn’t be able to access it in Javascript at all.
This helps mitigate the risk of a Cross-Site Scripting attack being used to steal session cookies to impersonate the user, since that type of attack would necessarily need to use Javascript.
Similarly to them not being marked secure, this is specifically important when cookies contain session or personal information, and otherwise might not be a priority.
So what if I find one of these?
Although it would be awesome that you didn’t, chances are you’ll find at least one of these on your site; it’s very hard to cover every possible security hole.
In the coming months we’ll dive deeper into the vulnerabilities that Hackmetrix scans for, with more detailed explanations of the problems involved and how to fix them.
If you are worried your site might be compromised and would like to take action right away, you can sign up for a free Hackmetrix account right here. Every Hackmetrix scan gives you a report with descriptions of all vulnerabilities found and easy to follow instructions on how to solve them.