Contact us
Blog
Subscribe

2023 Retrospective: Web and Mobile Application Security

by Peter Magnusson, Emilie Barse 2024-04-05

Robust application security is crucial to safeguard data and ensure compliance with regulation as well as adherence to industry best practice. For your business, it is vital to protect against emerging threats, maintain customer trust, ensure operational continuity, and to avoid potentially severe financial and reputational damages associated with data breaches and regulatory non-compliance. Application penetration testing is an important verification mechanism with insight into an app's security posture by identifying vulnerabilities and appsec risks, providing advice on mitigation strategies, verifying fixes and making a statement of the current state of security in an app.

In 2023, Assured performed a wide range of application penetration tests for Web, Mobile and APIs. We tested:

  • Web applications for several different platforms and frameworks;
  • Mobile applications for both iOS and Android devices;
  • Mobile applications for Android Automotive specifically; and
  • Backend APIs (without a human user interface).

This blog post summarizes the trends in terms of common security issues and vulnerabilities that we have observed in our web, mobile, API application penetration tests during 2023. Additionally, we will offer recommendations for mitigation to address and prevent these vulnerabilities with the goal to provide insights and tools necessary to strengthen your appsec posture.

In our previous blog post, we showcase our 2023 retrospective on IT infrastructure and Active Directory security. In the next and final part of this series, we will address our 2023 retrospective on Automotive security.

Table of Contents

The distribution of severity ratings in our penetration tests of 2023

First of all we want to address severity rating statistics. Normally, we employ the frameworks of OWASP Risk Rating or CVSS (3.1 or 4.0) to assess risk for an identified vulnerability. It is important to note that our risk rating is based on our (limited) knowledge and insight into the business case of the customer and details of the app itself, and a proper risk rating is best performed by the recipient of our pentest report. At the same time, we have many years of experience doing what we do, so our assumptions and assessments are (mostly) valid.

The pie chart below demonstrates the distribution of risk severity ratings of observations from our penetration test reports of 2023, classified from Critical (highest risk) via High, Medium and Low to Note (a noteworthy observation, not necessarily a vulnerability). 70 percent were classified as Medium or Low, which is normal. In the following sections we will present a breakdown of the risk severity ratings.

Risk rating distribution, web and mobile application penetration tests

Breakdown of Critical findings

Critical often reflects system/data compromise from an attacker with no access or very limited access. High impact and high likelihood is how it is defined within OWASP Risk Rating (informal method).

Critical findings were about 2% of total findings reported by us in 2023. I.e. the Critical findings constitue a low percentage of the number of findings.

What type of findings were rated Critical?

  • Access control issues which lead to compromise of system, super user, administrators.
  • Information leakage in which very sensitive data is made public.
  • Injection vulnerabilities like command injection, SQL injection; these vulnerabilities are becoming rare, but when found they are often Critical issues.

Breakdown of High severity findings

High severity reflects a serious finding where some mitigating factors exist that makes it less than Critical. High impact but medium likelihood (or medium impact, high likelihood) is how it is defined within OWASP Risk Rating (informal method).

High severity findings were about 10% of findings reported by us in 2023.

What types of findings were rated High?

  • Access control
  • Information leakage
  • Vulnerable and outdated components,
  • Cryptographic issues
  • User interaction problems, content spoofing etc,
  • Insecure deserialization,
  • Secrets management issues, and
  • File upload issues.

Breakdown of Medium and Low severity findings

Medium and low severity findings reflect vulnerabilities with lower risk rating, being further mitigated.

Medium findings were about 34% of the findings reported by us in 2023, and low findings were about 36%.

What type of findings were rated Medium or Low? Well, a little bit of everything. The same type of problems reflected in Critical and High severity findings were also rated Medium and Low when there were mitigating factors. Here we also find:

  • Cross Site Scripting (XSS),
  • Denial of Service,
  • Logging issues,
  • Input validation errors,
  • (Mobile) Insecure binary protections or security configuration,
  • Error handling issues, and some
  • Uncategorized/Miscellaneous findings.

Breakdown of Note/Informational findings

Notes and informational only findings are used for a couple of different purposes.

OWASP Risk Rating categorizes low impact, low likelihood findings as "Note". So, an almost fully mitigated vulnerability is assigned Note.

Note is also used to communicate defense in depth improvements. For example:

  • A lack of Content Security Policy (CSP) and similar security-related response headers might be assigned Note status, if the target web application is determined to have no identified Cross Site Scripting (XSS) vulnerabilities. Similarly, remarks on an application keeping sensitive data in JavaScript LocalStorage, but where no vulnerability showing that it can be easily stolen is identified.
  • Cryptographic bugs or misconfiguration that have no real world impact might be assigned Note; e.g. your certificate is technically wrong, but there's no impact as far as we can see; or, the client is advised to use more randomness/entropy, but in full context this appears not exploitable.
  • An application should reject OpenID Connect idToken sent as Access Token, but it passes through security filters - only to later crash in application code. So, it is arguably vulnerable but not really, as long as it keeps crashing in this way.

Categorization of findings

In this section we summarize the categorization of findings in our penetration tests of 2023.

Please note that categorizing application vulnerabilities is a challenge. We decided to assign each vulnerability a single category, the one which seemed most applicable. Many vulnerabilities could have been counted against multiple categories. For example, an OAuth/JWT verification error could be considered Access control, Input validation error, Insecure design, Cryptography - but we thought it was most clear to list it as Access control. Several such decisions are made, so keep in mind the slight bias from us who performed the classification.

We also include OWASP Top 10 and OWASP Mobile Top 10 mapping to help relate our categories to popular web/mobile security standards.

Distribution of finding categories, web and mobile application penetration tests

Access control and similar findings

Access control, Secrets Management, Information Leakage together made up about 49% of our findings.

Injections and similar findings

Input validation errors, file upload issues, command injection, SQL injection, insecure deserialization and similar issues made up about 15% of our findings.

  • Input validation errors ( 9% ). Remarks on input / data validation problems. This category only includes findings that did not directly correspond to a specific class of attacks, i.e. indirectly several Access control findings (and findings in other categories) also are input validation problems but not counted here. Some of these findings map to OWASP Top 10 A04:2021 – Insecure Design ("Reliance on Untrusted Inputs in a Security Decision"), while others may be more quality / defense in depth remarks.

  • File upload issue ( 3% ). Maps to OWASP Top 10 A04:2021 – Insecure Design.

  • Cross Site Scripting ( 2% ). Script/JavaScript injection into web pages. Maps to OWASP Top 10 A03:2021 – Injection.

  • Injection ( 1% ). Includes Command injection, SQL injection and similar vulnerabilities. Excluded from this category is Cross Site Scripting which we counted separately. Excluded from this category were also Path Traversal, Server Side Request Forgery, and Insecure Direct Object Reference which we counted under Access control. Maps to OWASP Top 10 A03:2021 – Injection.

  • Insecure deserialization ( 1% ). Maps to OWASP Top 10 A08:2021 – Software and Data Integrity Failures.

Vulnerable and outdated components

Cryptography

Miscellaneous findings

Miscellaneous findings such as HTTP headers, insecure binary/config, Logging issues, User interaction problems, Denial of Service, Error Handling etc made up 23% of our findings. This category also included uncategorized findings (6%) that did not easily match another category based on title.

The key areas of concern in web and mobile application, API security

In this section we will further discuss the common vulnerabilities identified in our penetration tests of 2023.

Access Control

Access control determines if you can or cannot access functions in an application. Access control vulnerabilities is the broad category of access controls failing to control access. OWASP rates this as the top vulnerability, OWASP Top 10 A01:2021 – Broken Access Control.

Among the access control issues we found were:

  • JSON Web Token (JWT) verification issues
  • Server Side Request Forgery issues
  • Insecure Direct Object References (IDOR) issues
  • Backend for Frontend (BFF) implementation vulnerabilities (such as Server Side Request Forgery, path traversal).
  • Amazon Cognito custom attributes issues

How do you solve broken access control issues? Consider taking help from libraries, frameworks that can deal with some of access control - for example JWT/OAuth may be easier to let third party code deal with instead of inventing your own authorization code. Test access control very carefully, and inspect configuration and code. Beware that there is no easy solution for Access Control issues, it is such a broad category with so many different problems and solutions.

Later in this post, we ahve added an entire section dedicated to access control to try to give more detailed advice!

Secrets management

Avoiding or limiting client-side secrets is one important part of secret management, as end users and attackers usually can extract secrets from clients (mobile app, web browser, etc.).

We have seen several cases of mobile applications with privileged credentials to backend services bundled within the application, for example:

  • API keys
  • Access tokens
  • Client certificates (with private keys included)

We've also seen clients downloading secrets and credentials from backend servers. For some web applications the credentials were provided in JavaScript configuration files consumed from server upon startup.

Secrets stored in Firebase Remote Config were also observed. This can be considered equivalent to client-side secrets since anyone with access to the application can fetch the Remote Config parameters.

We have also seen secrets and credentials stored in code repositories, accessible to developers.

Applications often store user credentials such as OAuth Refresh Token in JavaScript LocalStorage, which can be exfiltrated in Cross Site Scripting (XSS) attacks. Backend For Frontend (BFF) pattern and Service Worker highlighted by Best Current Practice: OAuth 2.0 for Browser-Based Apps (IETF-Draft) could be more secure alternatives, making the storage less accessible to attackers.

Cross Site Scripting (XSS)

We find fewer cross-site scripting (XSS) vulnerabilities than previous years, even if we still see some.

Better frameworks and programming support may be why this class of vulnerabilities appears to decline in prevalence. In many cases, frameworks such as React and Angular properly encodes HTML output and prevents unsafe data from being executed as code (unless specifically instructed to handle data insecurely).

In some applications we find only very basic filtering of input strings, like encoding HTML angular brackets (<, >). Such weak filtering may be possible to attack, depending on where the data is emitted in the page; see OWASP XSS Filter Evasion Cheat Sheet

Content spoofing, user interface manipulation and phishing

We have had a couple of cases where input strings were included in the web application user interface or in outgoing emails. By carefully selecting values of free-text fields shown to users, for example username, we can mess with the user experience.

We could cause the web site to create convincing phishing popups and emails, making the web application very hard to comprehend for users. In an example attack we could cause popups like <Web site name> invites you to .... making it very hard for users to understand the popup originates from a malicious user, not the web site itself.

We also utilized homograph / homoglyph characters and Right to Left (RTL) characters to make the user experience even more confusing.

This is very interesting as we see Cross-Site Scripting (XSS) technical vulnerabilities being less common, but where more subtle less technical user interface vulnerabilities enabling Content Spoofing and phishing remain.

You really need to study good user interface design when you allow users to collaborate and affect eachother!

Some recommendations on dealing with content spoofing vulnerabilities:

  • Be aware that communication between web site users are a phishing vector.
  • Clearly separate user-input from web site text dialog. Consider font-face and other visual clues to make it clear to user what is dialog text and what is (potentially malicious) user-input.
  • Consider rules for how Unicode characters may be intermixed within a word.
  • Review OWASP Content Spoofing.
  • Review WASC-12 Content Spoofing.

More on common Access Control issues

Access Token and JWT verification issues

We found several OAuth Access Token and JSON Web Token (JWT) verification errors:

  • Access token with missing expiry time, valid forever.
  • Access token verification failing to verify issuer, expiry time or signature; or, accepting the none algorithm.

Depending on the specifics, these bugs enable requests to API endpoints with expired tokens, or sometimes even allow unauthorized access with spoofed access tokens.

We also see ineffective logout, where users cannot logout due to design errors enabling attackers to reuse exfiltrated OAuth tokens long after user logout. Some applications only throw away tokens instead of actually logging them out. Some resource servers and API endpoints do not introspect token status, or cache token status for a long time, so the token still works after a presumed logout.

We recommend to check JWT verification solutions towards JWT verification guidelines:

Inconsistent authorization checks

We saw instances of inconsistent authorization checks, such as access control missing on specific API endpoints. Often the most commonly utilized endpoints, like user info or stored company data, have properly implemented access control. But, access controls were missing on other endpoints, such as file upload.

We recommend:

  • try to implement authorization consistently, and
  • try to identify code and endpoints which do not implement standard authorization checks.

Insecure Direct Object References (IDOR)

We found Insecure Direct Object Reference (IDOR) vulnerabilities.

We noted object identifiers being sequential numbers, or short "random" numbers, enabling enumeration and IDOR-attacks.

To address IDOR vulnerabilties, we recommend:

Amazon Cognito custom attributes used insecurely

We found Amazon Cognito custom attributes and user pool configuration issues. Applications used user-updatable custom attributes for application decisions. Security impact of user updating their own custom attributes was highly application specific. In some instances we identified serious vulnerabilities, in other cases it was much more limited.

A common vulnerable pattern was noted among a couple of unrelated applications:

  • Data is stored in Cognito custom attribute.
  • Data used for some decision, e.g. authorization check.
  • Data is writable by user using Cognito UpdateUserAttributes API endpoint.

To implement Amazon Cognito configuration securely, we recommend:

  • Carefully consider what custom attributes are used for.
  • Review if the attribute is intended to be Mutable or not.
  • Review what applications and scopes are allowed to write to the different user attributes.
  • Review Cognito: User pool attributes for more information on user attributes.

Backend for Frontend (BFF) implementation vulnerabilities

The Backend For Frontend (BFF) proxy pattern is becoming quite common. BFF is very similar to the API Gateway pattern.

The BFF handles all communication with OAuth authorization servers, resource servers and API endpoints. A single page application (SPA) is usually used to interact with the BFF. This creates a single remote server-side origin and removes a lot of Cross-Origin Resource Sharing (CORS) dependencies.

BFF use-cases we see:

  • OAuth: reduce token exfiltration threats, reduce security responsibilities in the front-end.
  • Third party APIs: BFF used only for proxying requests to third party APIs.

Some important BFF aspects for secure operation to consider:

  • Cross-Site Request Forgery (CSRF) protection
  • Cookie security. BFF tokens should consider e.g. SameSite policies carefully for a good security vs usability trade-off.
  • API routing. Which internal APIs to expose needs to be limited, unless not all backend APIs are mature enough to be exposed to the internet.

Backend For Frontend (BFF) for OAuth is used for enhancing security, to protect against token exfiltration attacks. The BFF acts as the OAuth client, and does not share access token nor refresh token with the web application. The web application needs only to deal with a single origin, and avoids storing tokens in the browser.

We have seen security problems in implementations of the BFF, such as:

  • request path traversal using ../../; reaching internal APIs through the BFF, which were not meant to be exposed by the BFF.
  • detailed error messages with sensitive information from the backend API reaching the user client.

This underscores the importance of careful implementation when adding new components to the architecture.

We have observed instances where BFF was introduced to harden the application, but the BFF created additional weaknesses due to insecure implementations, deviating from best practices.

To deal with Backend For Frontend (BFF) security according to best practice, we recommend:

  • Review Best Current Practice: OAuth 2.0 for Browser-Based Apps (IETF-Draft) describes many Backend for Frontend (BFF) security considerations.
  • Ensure BFF routing only exposes mature endpoint that are intended to be internet-accessible.
  • Ensure BFF routing is not subject to path traversal ../../ attacks.
  • Ensure Cross-Site Request Forgery (CSRF) protection and Cookie security is sufficient.

A summary of recommendations and good practice

Defend against basic implementation bugs

Several of the identified Critical and High severity vulnerabilities have been around for some time. The same advice and training that has been provided for decades would have protected against these.

Most of the bugs are basic source - sink problems that in theory should be identified in peer code reviews and Static Code Analysis (SCA);

  • A source is a piece of untrustworthy data, such as user input.
  • A sink is a dangerous function such as SQL interpreter, command execution, file access or remote HTTP call or similar.
  • Data tainted by a dangerous source must not flow directly into the sink.

A great defense is to remove unsafe sinks and replace them with safe functions that do not execute input. Several languages and framework offer safe programming functions, e.g:

Using these safe programming functions that removes classes of threats are recommended.

Another defense is input validation. Do not allow dangerous data to flow through the application. The recommended rule for input is to limit their content to what is necessary for the application.

There are two input validation strategies:

  • Allow-list input validation: only allow expected length, character sets, and form/schematics. Allow-list is great when the data problem is well defined and constrained, and preferred when applicable.
  • Block-list input validation: explicitly reject data when it contains dangerous characters. For example, throwing errors if ../../ is detected in when concatenating a filename or URI.

Where applicable, use an allow-list that that only accepts known good / expected inputs. Where allow-lists cannot be used, reject characters that are known to have unwanted effects in the underlying API.

In a large complex code base it could make sense to do both types of input validation; Do a allow-list input validation close to the source data enters the application. Do a block-list input validation close in utility functions close to the sink, where input is being executed.

Verify your configuration and integrations for authentication and authorization

More and more applications are built by glueing together different technologies, such as Amazon Cognito, Amazon Lambda, OAuth, BFF etc. This glue offloads a lot of development but becomes security critical, and you must evaluate it carefully. Everything that deals with critical security decisions, such as authentication and authorization integrations, needs to be bug free.

  • Double check the assumptions. Read all the manual for all security configurations.
  • Perform peer review of security code, configurations and integrations. Developers likely can find many security bugs in peer reviews now instead of waiting for penetration testers (or malicious attackers) finding them later.
  • If the development was hurried and new technologies were added faster than they were understood.

Pretty small programming errors, configuration errors and misunderstandings can have severe impact.

Look out for user interface issues including content spoofing and phishing attack vectors

Cross-Site Scripting (XSS) fixes may be insufficient. XSS vulnerabilities often are simple to find, sometimes even by automated tools, many user interface issues are more subtle.

As XSS vulnerabilities become rarer we instead see more Content Spoofing vulnerabilities and similar user interface issues. Some phishing / content spoofing attacks rely on HTML injection, but in some cases just cleverly changing text is enough to interfere with the user experience

Maybe we fixed the very technical vulnerability but left the underlying "bad user interface" problems behind unfixed?

The more modern and user-interactive applications become, the more interesting content spoofing attacks become. The ability for one user to cleverly mess with the user experience of another user is really interesting to us as tester/attackers, and put a lot of responsibility on users to spot attacks.

Good user interface design, or restricting how users can interact, are the main defences.

For penetration testers and attackers, user interface problems are kind of promising. Even if all classical technical flaws magically were gone tomorrow, there will always be weird subtle security bugs giving us work for years to come.

Food for thoughts: will artificial intelligence within the next few years become able to find subtle user interface issues?

TL;DR: Recap, takeaways and summary

  • Access control is a major area of concern with many issues.
  • Injection and similar is a major area of concern.
  • Many bugs are the same bugs we have seen for decades are still an issue.
  • Defend with safe functions such parameterized queries and HTML encoding methods.
  • Defend with input validation.
  • Find bugs and misconfiguration with tooling, such Static Code Analysis (SCA).
  • Find bugs and misconfiguration with peer reviews.
  • Authentication and authorization integrations, configuration and code should be prioritized in quality assurance and security reviews.

Our team of senior security experts at Assured brings years of experience in web and mobile application penetration testing. If you have any questions or if you are interested in our services, don't hesitate to contact us!

Your Friendliest Adversary Assured.

Blog

Exploiting insecure GKE (Google Kubernetes Engine) defaults

This blog post will guide you through an attack chain exploiting insecure defaults in GKE, and explain how to harden a Kubernetes cluster to reduce the risk of compromise.

Blog

2023 Retrospective: Automotive Security

A 2023 retrospective by Assured Security Consultants on automotive security engagements, challenges and trends. We discuss security issues observed and the implications of cyber security regulations on the automotive industry. We provide an overview of the state of automotive cyber security and recommendations for improving automotive security based on our findings.

Blog

2023 Retrospective: IT Infrastructure and Active Directory Security

A 2023 retrospective by Assured Security Consultants on security assessments conducted, highlighting key IT infrastructure and Active Directory vulnerabilities, the impact of new regulations, and strategies for a more secure future.

More blog posts

Services

Penetration test

Adversary simulation

Code review

Threat Landscape Assessment (TLA)

Advisory

Training

Threat & Risk

Areas

Application Security

Mobile App Security

Infrastructure

Automotive Security

Embedded Security

Cryptography

 

About Assured

Careers

Publications

Blog

 

© 2023 Assured AB