The last year has seen large scale data breaches in companies such as Three Mobile, Tesco Bank and Sports Direct.
These breaches normally occur due to a hole existing somewhere in the system, allowing unauthorised access. On some occasions, companies don’t even know they have been compromised until months down the line, by which time it is too late and data has been harvested.
Although we hear about these high profile attacks on the news, the scale of the issue is sometimes not apparent. It is not just large companies that are at risk; if you have a web presence, then by proxy you are open to being attacked.
Kaspersky, a multinational cyber security firm, track attacks around the world. The below globe shows just how large the problem is.
Therefore it is a clear that an often overlooked aspect of the QA process is security, and more specifically, are there any areas of a site that can be compromised?
This is where PEN (“penetration”) testing comes into play. It is basically a way of looking for any areas that can be exploited by hackers, including the site code, servers, SSL certificates and any other infrastructure.
Normally this is done by an automated system, but it can also be run manually by a human. The automated process involves running sophisticated tools which are capable of trying to gain entry by multiple means. The human angle takes a more hands on approach and looks for more obvious weak spots. Companies that perform PEN tests often employ ex-hackers (or ethical hackers), and as such have a wealth of knowledge on how to break into a site.
At the end of the process, a report is generated detailing any issues found, and rating them on a severity scale. Anything flagged as major should be fixed as a priority.
It’s worth noting that it’s not always possible to fix everything that is found within a PEN test. This is due to a variety of factors, such as hosting limitations, requirements from 3rd party libraries and so forth. Ultimately it comes down to a risk assessment, and this very much depends on the company that owns the site and the actual purpose of the system being tested.
5 common flaws
Below are some frequent issues that a PEN test will find, and how to fix them. This part of the article is technical in nature as we are going to delve into the underlying architecture.
This article focuses on a ASP.NET site hosted in IIS, but the ideas can be transposed into other systems and platforms.
I am making the assumption that your site has an SSL certificate installed. Not only is this important for security, but it is becoming more and more relevant in a search engine context.
Cookie security
In an ASP.NET context, cookies are used to store authentication tokens among other things. Whilst this data is encrypted, a talented hacker, under certain circumstances, could exploit a cookie that isn’t also secured. Therefore, PEN tests will flag if a cookie isn’t set as secure by using SSL.
Furthermore, in some instances, it is possible to access a cookie client side, which can again be exploited by a hacker via XSS (see below for more on this).
Thankfully there are two attributes that can be added into the web.config:
<httpCookies httpOnlyCookies="false" requireSSL="false" />
XSS
Cross site scripting (XSS) is the process of injecting malicious client-side scripts via the front end of a website, which run malicious code.
As an extreme example, take the following URL:
http://www.oldskoolxssexample.com/?productid=123
This is a common way of accessing a product via a query string; ?productid. The issue comes if the code doesn’t check the type of the value passed, in this case, an integer. So a hacker could write something like:
http://www.oldskoolxssexample.com/?productid=”DELETE FROM DATABASE…” http://www.oldskoolxssexample.com/?productid=”<script>Random javascript code</script>”
This can be alleviated by checking the type and using parameterised queries (or just using an ORM).
Another example that a PEN test will check for is whether data that is submitted to the site is properly encoded. Imagine the scenario of a contact form; if the data isn’t encoded properly upon submission it is possible for hackers to enter Javascript code or similar. This can be set by using the following method:
HttpContext.Current.Server.HtmlEncode
Antivirus
This seems like an obvious one, but it is surprising how many servers do not include any virus protection software. So the first step is to install some if you haven’t already.
One way that a PEN test will evaluate that the software is actually working is by uploading a (fake) infected file, normally via a file upload control on the site. The file is fake in that there is an industry standard file known as EICAR that can be used in testing situations.
The antivirus software on the server should disallow the upload, and quarantine the file. You can test this yourself by uploading the EICAR file yourself.
Outdated security protocols
SSL certificates, along with the underlying cryptographic technology, are constantly evolving. What was considered watertight a few years ago may no longer be the case. Servers come with support for multiple protocols by default, and if you haven’t delved into the settings it is likely that they are all still enabled. This poses a risk, and will be flagged by a PEN test.
The reason is that some old protocols have known flaws, and can therefore be exploited. A good example of this is the POODLE attack from 2014.
The following protocols should be disabled:
- SSL 2.0
- SSL 3.0
Whether you need to disable TLS protocols (1.0, 1.1, 1.2) depends on how up to date your server is. COMODO have a tool which can be used to check if your site is immune to current vulnerabilities:
https://sslanalyzer.comodoca.com/
Disabling the protocols requires delving into the registry, which shouldn’t be done lightly (and without a backup!). Details can be found at https://support.microsoft.com/en-gb/help/187498/how-to-disable-pct-1.0,-ssl-2.0,-ssl-3.0,-or-tls-1.0-in-internet-information-services
Admin system
Unless your site is completely flat HTML, it is likely you have some kind of administration system that you login to to manage the site. This could be a CMS, an ecommerce system or a plethora of other admin portals.
By default, these tend to be publicly accessible. For example, if the URL is /admin/, it is likely that anyone can go navigate to this and see the login screen. Granted, they would still need login details to access it, but just by seeing getting this far is an inherent security risk. A hacker could attempt a brute force attack or could try to exploit it in other ways.
The simplest solution for this it to IP restrict this portion of the system, creating a whitelist of IP addresses that are allowed to access the system.
Unfortunately, it is not always possible to fix this issue due to the nature of how some CMS packages work, so this comes down to a risk assessment as mentioned previously.
Time saving
Hopefully, if you implement these fixes prior to the PEN testing taking place it will save you time in the long run and will reduce the need for costly re-runs.
If you need help organising a PEN test, or have been PEN tested and are unsure of the results, please get in touch so we can help.
We will be happy to take your call: 0114 279 7779 or email on hello@quba.co.uk
Get more of this by subscribing to our regular newsletter