Top 10 Web Application Vulnerabilities

Cyber intrusions and data breaches are costly interruptions to business, both in terms of clean-up and reputational damage. A recent study by IBM and Ponemon institute reports:

• The average cost of a data breach is US$3.86 million, US$1.99 million in Australia
• Each record stolen costing US$148 and US$108 in Australia
• There is a 27.9% chance of recurring breaches over 2 years

Web applications are the public front of businesses and often give the first impression of a company. Web portals offer many functions to customers and business partners such as forums and login pages. It is these places that defences are probed for weaknesses that give away more information to build into an exploit. 

To help secure web interfaces, the Open Web Application Security Project (OWASP) lists the top 10 most frequent web application vulnerabilities.

Vulnerability Briefs

The Top 10 vulnerabilities are explained below.

1. Command Injection

This is where some form of underlying infrastructure is passed command by the web page as input to functions. The command languages that can be injected include SQL, C#, HTML. PHP, LDAP and Operating System commands.

Command Injection can happen where users of the website can enter data, a forum port or visitors log or contact details, or a login with a username and password. The ways to protect against injection are:

• Use safe APIs and parameterised queries, such as SQL prepared statement
• Sanitize input to prevent unwanted characters

2. Broken authentication

Authentication is broken when someone accesses information using another person’s details. This can be through stolen session details, passwords or secret keys. The more advanced vulnerabilities surround ending sessions when a user logs out or leaves the app site.

Best practices are:

• Multifactor Authentication
• Logged-in Session idle timeouts
• Using secured cookies
• Session isolation

3. Sensitive data exposure

Sensitive data displayed or entered into a web application can be exposed by the use of weak or no encryption ciphers or standards. Sensitive data may also be gleaned from caches by hacking techniques, for example some banking applications disable screenshots to protect sensitive information.

Countermeasures include:

• Ensure data is encrypted both in transit and at rest
• Use secure transport protocols, for example TLS 1.2, encryption ciphers and long secret key lengths
• Disable caching of sensitive data

4. XML External Entities (XXE)

XXE attacks can be used to steal data, execute code and generally perform malicious tasks. XXE is where the attacker can upload an XML file which then executes malicious actions against the web application code and/or dependencies.

Sometimes websites will ask for Excel files to be translated into XML for upload. In such cases, the XML needs to be sanitised before being parsed by the web application.

Methods to prevent XXE are:

• Avoid serialisation of sensitive data
• Implement server-side whitelists to prevent malicious XML upload
• Protect the web application with a Web Application Firewall that can detect and block XXE
• Review code for potential vulnerabilities

5. Broken Access Control

Broken access controls allow users unauthorised access to resources, for example restricted pages or databases or directories within the web application.

A common way access controls are broken is when user restrictions are performed only on the client UI. These restrictions may be bypassed, and the user then has full rights to access all of the web application.

Best practices to preserve Access Controls:

• Force re-login after a password change
• Use restrictions on resources on the server
• Use role-based authentication for access to resources
• Terminate sessions after logout, invalidate cookies and tokens associated with the finished session

6. Security Misconfigurations

Configuration of the application server, Database and database server, proxy servers and load balancers need to be secured in line with security policy and best practices. Developers are focused on providing the functionality of the application, rather than on making it secure. Security vulnerabilities are then found by experts as part of a security review, or by hackers trying to exploit the application.

Examples include:

• Being able to list directories in the web server, a configuration item normally turned on by default in many webservers but provides to much access
• The web application providing product and version details – again, a feature provided by default by the webserver

Best practice to reduce misconfigurations are:

• As part of the development process, review security of applications, operating systems and hardware
• Ensure default configurations are changed
• Only install the features needed for the application to work – using a minimal footprint approach will help
• Periodically review the security of the application and environment as new threats and vulnerabilities are always being discovered

7. Cross Site Scripting (XSS)

XSS is where untrusted input to a web application is parsed and run by the application. The untrusted input can be scripts that are then executed in the users browser to deface pages or steal users data.

There are three (3) types of cross site scripting attacks:

• Reflected

Reflected XXS attacks are executed as soon as they are entered. An example is a java script entered into a search field – as soon as the search is executed the java script is processed. The java scripts can be modified to steal data and deface website.

• Stored

Stored XXS attacks are when user input is stored on the webpage executed when the page loads. An example is webpage where user comments are stored and displayed. Malicious code is entered in as a comment, and that code is run whenever the page is loaded by visitors to the comment page.

• DOM-based

DOM-based XSS attacks differ from reflected and stored XSS attacks as they are client-side attacks. In a DOM-based XSS attack the “DOM environment” modified in the client browser so that the original client-side script runs in an “unexpected” manner.

Countermeasures:

• Encode the output and quote, or escape, untrusted characters. For example < has a different meaning in HTML to \<.
• Enabling Content-Security-policy (CSP) in the webserver

8. Insecure Deserialization

Applications that store data on the client may be relying on the client to provide serialization services. It is possible the client may not handle the serialization properly. This vulnerability is hard to exploit, however it is possible. An example is altering a cookie to give unauthorised privileges.

Best practices:

• Encrypt the data depending on serialization
• Run deserialization process with least privilege

9. Using Components with Known Vulnerabilities

An application is only as secure as the weakest part. Using, often unknowingly, components with known vulnerabilities provide an easy way to compromise the application. Examples of components with known vulnerabilities are: an older vulnerable PHP version, an out of date Linux operating system kernel, missing patches from Windows or an older vulnerable version of JQuery.

In general, older software and hardware have had more time for vulnerabilities to be discovered and also lack updates to address discovered vulnerabilities.

Best practices to avoid having known vulnerable components:

• Implement a patching regime
• Know the components in an application, and components of re-used elements, and monitor forums or CERT for listed vulnerabilities and patches or workarounds

10. Insufficient logging and monitoring

With the above points secured, other types of attacks are possible. Undetected successful attacks may over time gain persistence in the environment. Monitoring and log analysis prevent successful attacks from becoming a foothold in the environment.

Attackers may:

• Use brute force to try and guess passwords, resulting in many login failures from a particular source
• Try and flood the webserver with requests to exhaust resources resulting in a Denial of Service, or several other more sophisticated attacks
• Use junk traffic to obscure their attacks
• Cause unusual levels of network traffic for the time of day

Best practices are:

• Monitor network traffic levels and analyse logs 24/7 for unusual activity
• Establish effective security incident response procedures, and rehearse the procedures

Businesses using web applications need to assess and mitigate the risks associated with those web applications. Agilient has experienced consultants to assist in securing web application vulnerabilities. Follow our LinkedIn page for all the latest security updates, and Contact Us to see how we can assist your business.