In over 20 years of conducting penetration testing, there have only been a handful of times where no issues were identified during a test engagement. So, whether it is a critical vulnerability, low risk issue or a minor misconfiguration, if you’re conducting a security assessment on a web application, the chances are, something will be uncovered.
Issues identified during testing are often unique to the application under investigation. Take for example a Cross-Site Scripting (XSS) issue. On one application, it may only impact the threat actor, and on another, all-application users could be affected. As such, a different risk would be present despite both being vulnerable to the same issue. In this case, providing general advice on ‘how to fix an XSS issue’ would potentially do more harm than good.
When it comes to critical and high-risk issues, there are several types of issues that are found time and time again. Preventing issues will always be challenging, however, there are steps that could be adopted to reduce occurrences and limit their potentially negative effects. So, with that in mind, we thought it would be useful to look at some common issues identified on the OWASP Top 10 Web Application Security Risks and regularly identified throughout our testing, at a high level, to help improve awareness and highlight the potential impact if a threat actor was able to successfully exploit them.
Access Control Vulnerabilities
Modern applications often have incredibly complex access control requirements. This is particularly true of cloud-based Software-as-a-Service (SaaS) products, where there are often multiple roles providing granular access to different functionality, which is described as “vertical access control”.
There is also the concept of “horizontal access control” where users have access to some data resources, but not others. For example, a user may have the “project manager” role on one project, and the “contributor” role on another. Within a project there may be many sub-resources, such as sprints, tasks and issues – all with their own database IDs.
In this situation, correctly enforcing permissions can quickly become complex, and we frequently find that applications fail to so adequately, resulting in high-risk access control vulnerabilities. In addition, we sometimes find mechanisms such as parameter encryption which attempt to improve the security of access control, but often subtle access control vulnerabilities remain.
Cross-Site Scripting (XSS)
Awareness of XSS amongst developers is generally good, and modern web development frameworks contain defences against XSS out of the box. However, it remains a common issue we find.
One problem is that a typical application contains dozens of injection points, and every one of them needs to be secured – it only takes one undefended injection point to enable a threat actor to conduct a malicious exploit. As mentioned earlier, modern frameworks contain defences out of the box such as automatic escaping, which gives protection in most instances, but this is not comprehensive.
Examples that we come across include:
- Use of untrusted data within a dangerous context – Often frameworks provide automatic escaping that is effective in most contexts, resulting in developers not needing to think about it. However, some contexts, such as within <script> tags need additional escaping to safely use untrusted data.
- Disabling of automatic escaping for presentation reasons – An application may have good reason to turn off automatic escaping for a particular piece of data, such as providing dynamic styling information. However, if untrusted data is used within this, escaping must be done manually.
- Allowing users to use a safe subset of HTML – Sometimes an application wants to allow use of basic formatting features, such as bold and italic, within messages. Constructing a filter that allows safe tags, but filters out dangerous tags, is extremely difficult. Almost all attempts by developers to create such a system has flaws that result in cross-site scripting vulnerabilities. However, there are libraries that have been designed to do this and can be used safely.
- Using unsafe interfaces for HTML generation – This is often an issue with client-side JavaScript, resulting in a variation of cross-site scripting called DOM-based cross-site scripting. For example, the jQuery library has functions that allow HTML to be created safely using untrusted data. However, it also has functions that are dangerous to call with untrusted data – and often developers incorrectly use these functions when they should use a safer alternative.
Successfully using XSS to bypass defences could allow malicious threats to execute malicious payloads. Attacks could then be carried out from within the application context, which would increase the chances of user interaction, as it would appear from a trusted domain.
Potential attack vectors a threat actor would look to leverage from XSS would include, but not limited to, phishing, keylogging, and if suitably positioned, access to sensitive session data that could be replayed to obtain further unauthorised access. All which would result in the confidentiality of information being negatively impacted and could have a knock-on effect with integrity of data, or the availability of accounts.
SQL Injection (SQLi)
Web applications have large quantities of information sourced from backend databases. These databases are implemented to help reduce and tailor the amount of, and what, sensitive information is returned to application users. SQLi awareness is relatively high as it has been a common attack vector for threat actors for a long time, however it remains an issue that is commonly found during web application testing.
Data is returned to the application using SQL queries, however, if best practice is not followed, risks are introduced. A threat actor would scour the application, looking to negate the logic and to perform malicious queries. Automated tools exist to help increase the efficiency of this attack and can be easily adopted by the threat actor.
As this attack vector would not look to target other application users there is no prerequisite of waiting for interaction, rather, the attack can be carried out when the attacker determines it suitable, such as the middle of the night, when incident response teams could not react in an such a timely manner.
Eliminating SQLi risk entirely, like all vulnerabilities, is not possible. Despite this, preventative measures can be used, and if implemented during the development stage, can negate the chances of the issues making it to a production environment.
Preventative measures can include, but are not limited to:
- Parameterised statements – Parameterised statement queries should be the default approach adopted by developers, helping limit the chances of injection. When parameterised statement queries are used, SQL statements would need to be defined as code and then passed to the statements as required. This should allow the application to differentiate between what is code and what is user supplied, behaving in a mature manner which means input from the threat actor isn’t executed.
- Input sanitisation – All user input should be treated as malicious and escaped, validated, and sanitised when passed to the server.
- Disabling unnecessary stored procedures – Stored procedures are available by default, but aren’t always enabled, and help assist with database admin and functionality. Although they help assist database administration, there are some that can be used to perform malicious actions. Examples of these include “xp_cmdshell” and “sp_execute_external_script”. These would enable a threat actor to carry out system commands that could result in remote access to the underlying infrastructure and could then be used to move around the internal environment, obtaining further confidential data.
- Ensure the database is not running as a privileged user – As it is not always possible to ensure the application is completely secure to SQLi, best practice, as always, is to run the service with an account that is not Database Admin (DBA). By doing so, if a threat actor was able to exploit this, they should have limited functionality.
If a threat actor were able to successfully identify, and exploit, an injection point they would obtain SQL Injection. From here, the threat actor would look to enumerate the database, obtaining confidential information such as usernames, passwords, sensitive personally identifiable information, or card details.
This information could be sold by the threat actor to further malicious parties, or used to blackmail the organisation, both of which would result in financial gain. In addition, a threat actor may look to restrict access to the application, or user accounts, by deleting records. This would have a knock effect to the availability.
Confidence in your web application security
Undertaking regular penetration testing will help improve your application’s security posture. No matter what is identified, it is our job to help you fully understand the issues, outline the associated risks, and advise you on how to best remediate, or mitigate, the vulnerabilities.
So, whether you are looking to test a web application before it goes live or need to undertake testing as part of your internal security processes, our web application testing service is here to provide you with the confidence you, your clients, and your stakeholders require. The confidence that your web applications are as secure as possible.
