The Internet is ruled by web applications. Many software vendors are shifting away from discrete software packages and implementing their products into web-accessible applications. This reduces the complexity of designing software from the ground up, as web browsers in recent years have begun to offer a vast array of increasingly powerful resources that make building web apps much easier. 
The Open Web Application Security Project (OWASP) is a non-profit organisation committed to staying at the forefront of cybersecurity, in order to increase awareness and educate software vendors on the cyber threats facing the online world today. OWASP offers a great number of helpful resources that are free and open to anyone.
Every few years, OWASP publishes the OWASP Top 10 list – a list of the top 10 threats that web application developers must protect against their web apps from. The list outlines the risks, causes and impacts of the threat, as well as known solutions to the vulnerability.
Here are the OWASP Top 10 web security vulnerabilities:
1. Injection
An injection is a form of attack where an attacker successfully submits invalid data to the application, usually in the form of a command or query from within the application or browser.
The most common injection attack is an SQL injection, in which the attacker is able to execute an SQL database query from within the application or browser. In this scenario, the database should not be accessible from the application and as a result the database will execute and return the query to the attacker, as it is unable to tell whether the application itself is submitting the query as per normal operation, or if a malicious attacker is executing the query remotely.
The primary techniques used to prevent injection attacks, according to OWASP, are keeping data separate from queries and sanitising all inputs from the application. Queries often follow a specific syntax, and if inputted into a text field in the web app, should be very easy to detect and filter.
2. Broken Authentication
Broken authentication simply refers to a web application’s authentication system having weak security features and methods, or even worse, no security at all. Web apps are one of the largest targets for cyber-attacks. As web applications are becoming more popular, the security of these apps is still yet to catch up with web security standards.
One of the most common forms of broken authentication attacks is “credential stuffing”, a practice where attackers will take a list of known passwords, either common or leaked, and use a script to rapidly try each and every combination. If the web app does not limit the number of password attempts entered, then it is only a matter of time before an attacker gains access to one or more accounts.
In order to mitigate broken authentication attacks, developers can utilise many techniques and methods to reduce the attack surface, most of which revolve around password management. When a password is created, it should be checked against the criteria of a strong (or weak) password. The password should never be stored in plaintext and should be hashed (and “salted”, ideally). Multi-factor authentication should also be implemented if appropriate. Finally, authentication techniques should also be utilised such as limiting the number of authentication attempts, as well as secure session tracking.
3. Sensitive Data Exposure
Sensitive data exposure is when an attacker gains unauthorised access and compromises data that should be private, such as confidential personal or corporate information. This data is often then either publicly posted or sold on the black market for profit.
One of the most common causes of this type of attack stems from the use of weak encryption during browsing. Unsecured sessions contain the risk of an attacker intercepting and hijacking a user’s authenticated session, which can then be used to allow unauthorised access to potentially confidential data. Modern web browsers utilise TLS end-to-end encryption between the client and web server. In recent years, TLS has completely superseded the previous SSL standard due to known vulnerabilities. TLS itself has even undergone revisions to patch its own vulnerabilities. If a client or server does not support the latest TLS version, it poses a great risk.
To protect against this type of attack, data should always be secured – both at rest and while in transit. Sensitive data should be encrypted, passwords should be hashed, and up-to-date encryption protocols should be used along with the removal of older and more vulnerable protocols, such as the enforcement of TLS 1.3 or 1.2 over HTTPS.
4. XML External Entities
Many web applications utilise XML in some way for many functions. Applications that parse XML inputs are at risk of attack, where attackers have the ability to input references to “external entities” (hence the name) and process them if the parser is not configured properly. XML external entity (XXE) attacks pose the risk of DOS attack, theft of confidential data and more.
An XML input can be used to inject malicious requests into the parser in a syntax, or form, that the parser would typically expect. A parser that is configured properly should be able to filter any requests that would not typically be found in such an input – quite like input validation methods used to mitigate SQL injection attacks.
Most XML parsers are susceptible to XXE attacks and as such, preventing such an attack should a considerable focus when developing XML-based applications or functions. Disabling external entities completely, where applicable, is recommended. As discussed above, input validation and sanitation should be used wherever inputs are given to an application. Regular testing for XXE vulnerabilities during development and deployment should help to ensure a secure application.
5. Broken Access Control
Most web applications require some kind of user authentication and access control to prevent unauthorised access to certain content and functions. Not all content and functions should be accessible to all users and as such will utilise permissions systems to limit what each user can access. The security of a website’s content is very dependent on these systems. If a mistake was made in the development and maintenance of such a system, an attacker could stumble across a flaw that can give them access to content they otherwise should not be able to, such as administrative tools, or even the personal and private information of other users.
An example of how an attacker could conduct such an attack is if the application does not verify or validate data in an SQL query, then the query could be modified to access almost any information the attacker pleases. They could potentially query the account information of another account, and use this data to gain unauthorised access.
Such an attack can be mitigated in several ways, the first being to ensure that an application’s access control system is a primary focus during development. The “principle of least privilege” should be followed, where a user only has access to the minimum content and functions that are necessary. Input data validation should be implemented as well as monitoring and logging to detect if access controls fail.
6. Security Misconfigurations
Security misconfigurations are a very common mistake, often the result of human error or even laziness. This vulnerability can become present simply when security configurations are overlooked, or even not implemented at all. This can include unsecure authentication methods, default configurations or unpatched software.
Security misconfigurations can occur anywhere in a network, on any platform, at any layer of the application stack. If a misconfiguration is exploited, an attacker can gain access to a large amount of sensitive information, as well as other systems potentially compromising even more data.
To prevent misconfigurations from occurring, it is crucial that configurations are peer-reviewed regularly in the software’s development, QA and production environments. Taking the time to ensure that configurations are correct will greatly reduce attack surfaces. These configurations can include disabling unused functions, dependencies and frameworks, updating default settings, the use of unique administrative passwords in each environment, and regular vulnerability testing at each stage.
7. Cross Site Scripting (XSS)
Cross Site Scripting is a very common attack that can affect a great number of websites. This attack occurs when malicious code or script is added to a web page through a site’s inputs (user comments, form submissions, etc). This content is then propagated to other users as they access the website, and the browser runs the script as if it were legitimate website content.
XSS vulnerabilities can be present for a great number of reasons, depending on the website. One of the most common victims are WordPress websites, which make up a significant number of websites on the Internet. Many WordPress plugins on websites are out-of-date or vulnerable. Unvalidated inputs will allow scripts to be processed, and therefore propagated by the website.
XSS can be prevented in various ways with great success. The use of safer frameworks is a very effective method. Newer scripting frameworks such as React JS and Ruby 3.0 have XSS mitigation techniques built in as standard. Escaping untrusted HTTP request data based on the context in the HTML output will also resolve a great number of XSS vulnerabilities. Another useful strategy is to enable a Content Security Policy (CSP), which is an in-depth mitigation technique against XSS attacks.
8. Insecure Deserialisation
This kind of vulnerability is quite difficult, as off-the-shelf exploits rarely work and must be focused at a particular target or targets, each with different tweaks to the exploit code for it to work. When data is stored or transmitted, the data bits are serialised, or broken apart to be stored in different locations or mediums. Deserialisation is when these bits are restored back into the original object. If this process is insecure, malicious code can be injected to potentially give an attacker access to unauthorised information.
To prevent such an attack, implementing integrity checks of the serialised objects prevents data tampering. Isolating the deserialising process is also a valid strategy as well as monitoring and logging of deserialisation exceptions and failures as an ongoing strategy.
9. Using Components with Known Vulnerabilities
This vulnerability involves using components in a web application that have known security flaws. The majority of known flaws are fixed by vendors quite quickly, but an attacker could easily focus their efforts on finding vulnerabilities in the dependencies used by your application.
The development team may not have the same amount of resources dedicated to tracking such flaws, let alone exploiting them. Criminals have a vested interest in finding ways they can exploit software, and it is a common issue that developers and webmasters cannot keep up with updates.
Continuous monitoring and tracking of dependencies and their flaws are critical to avoiding this security risk. Patching as soon as possible is the best line of defence against possible attacks. As security should be a primary focus in a software development project, spending additional resources on finding vulnerabilities is also very important.
10. Insufficient Logging and Monitoring
A web application could have all the security vulnerabilities discussed in this article secured and protected, however the web app is still at risk without enough logging and monitoring measures in place. Without it, developers can have no way of knowing what is going on with their app or site. An attacker may be attempting a serious attack or have even gained unauthorised access to the application. Without logging and monitoring, web administrators have no way to discover the attack and react quickly and effectively.
Implementing effective monitoring and logging measures against cyber threats is critical to a website’s security. Monitoring enables the possibility of real-time tracking and alarms in the event of strange activity, and audit logs allow administrators to review past activity. Monitoring and logging does not have to be a tedious and laborious task, and with the help of modern tools, is made significantly more streamlined.
Conclusion
As the Internet today relies on web apps for business activities, it is critical that security remains a primary focus during development and production. A successful attack can have dire consequences on not only the vendor, but also customers, which can directly result in lost revenue and future business. Attacks happen every day and are only becoming more commonplace. By utilising the strategies discussed in this article and by OWASP, the web can become a much more secure and safe place and cyber threats much less commonplace.
If your organisation requires further guidance on how you can improve the security of your web app, or your organisation as a whole, Agilient’s consultants can tailor their expert advice on best security practices, techniques and methodologies. If you’d like to learn more, contact us today.
Author: Jack Schofield, Agilient Consultant