1. Stored (Dom-based) Cross-Site Scripting
High risk
| ID | WSTG-INPV-02 |
| Risk | High |
| Required Skill | Low |
| Location | |
| Tools | Burp repeater, Web browser |
Description
It is possible to modify the HTML content of the templates and include an XSS payload within it, which is stored on the server and accessed when users view the page.
Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the website and run within the user’s browser under the privileges of the web application.
Assuming the payload successfully bypasses Cloudflare / WAF (which we were able to do) it is possible to save it. From that point, anyone “previewing” the email would instantly trigger the XSS, in addition to any users using an insecure mail client who received this email.
An attacker with access to the portal can target other users in the same tenant account, running malicious javascript code on their browser targeting to steal cookies, keylogging, etc.
Mitigation
Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.
In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:
- Filter input. At the point where user input is received, filter as strictly as
possible based on what is expected or valid input.
- Encode output. At the point where user-controllable data is output in HTTP
responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
- Content Security Policy. As a last line of defense, you can use Content
Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
2. Credentials Spraying Attack
High risk
| ID | WSTG-BUSL-05 |
| Risk | High |
| Required Skill | Low |
| Location | |
| Tools | Burp Repeater, Burp Intruder, Web browser |
Description
Brute force prevention mechanisms are not effective against credential spraying attacks. This vulnerability mostly affects the fields that are accessible by unauthenticated users as it allows brute-forcing user names or spamming and possibly performing DOS (Denial of Service) attacks.
Many of the problems that applications solve require limits to the number of times a function can be used or action can be executed. Applications must be “smart enough” to not allow the user to exceed their limit on the use of these functions, since in many cases each time the function is used the user may gain some type of benefit that must be accounted for to properly compensate the owner.
It was noticed that on any input fields designed to be used by unauthenticated users (login, registration, and forgotten password) the application tends to prevent brute force attacks after 20 sequent requests. However, if the requests are made each containing different credentials the control does not stop the attacker and permits sending the request an unlimited amount of times.
- We successfully made 1000 requests to with a Password
Spraying attack, using different usernames for each request.
For example, it is possible to abuse the send SMS functionality to send numerous/continuous SMS messages to clients and random people by making thousands of requests for either “new registration” or “forgotten password”, using different phone numbers for each request.
The anti-automation control is ineffective against credential spraying attacks like the one described above. In addition, this could be an inconvenience for both the users/clients (i.e. reputation damage) as well as it will most likely enquire cost to for all the SMS being sent out.
Mitigation
The application should set hard controls to prevent limit abuse. This can be achieved by setting a rate limit for the requests each IP can make per minute, a CAPTCHA on multiple requests in a short amount of time, set a counter limit per user on the back end or database level, as all users should be identified through a session, whichever is better for the business requirement.
3. CloudFront Bypass
Medium risk
| Risk | Medium |
| Required Skill | Low |
| Location | |
| Tools | DnsSpy |
Description
We successfully bypassed CloudFront by finding the IP of the server and requesting it directly.
During the assessment we looked for bypassing Cloudflare and Cloudfront and obtaining the real IP of the web application. We used different online tools for searching the DNS history of the domain. The generated DNS report from DnsSpy leaked important IP addresses and could be seen here .
The results showed the IP address of & . We used this information to bypass the Cloudfront protection, by redirecting all requests to to this IP.
We confirmed the bypass by comparing two responses, one from the IP and another from the actual URL
- Response to URL request contains the following
In addition the scan provided one more IP address that looks like an deprecated web site This application was not behind any WAF and it had references to 2021 in the footer (indicating that it hasn’t been updated recently). This could either be the previous version of the www website, or the new one under development.
With this an attacker can 1. Bypass logging which cloudfront offers 2. Bypass potential WAF rules that cloudfront could be enforcing 3. Potentially bypass any access controls which are placed on traffic coming from cloudfront (and not from anywhere else).
Mitigation
Encapsulate all subdomains to one alias that is behind CloudFront to mitigate this issue.
4. Absence of Rate Limit - Brute Forcing Verification Code
Medium risk
| ID | WSTG-BUSL-05 |
| Risk | Medium |
| Required Skill | Low |
| Location | |
| Tools | Burp intruder |
Description
The 6-digit code used in the reset password functionality is vulnerable to brute-force attacks as it is not invalidated after an unsuccessful attempt.
As part of the email change functionality within the user profile settings, a user can update their email by first making a request to get a code via , and then verifying the ownership of the email by providing a 6-digit verification code which is sent over the email. It was found that this code does not get invalidated after a series of unsuccessful attempts. We were able to brute force the code with over 2,000 requests and reset users password using this code.
Considering the token is valid for 10 minutes (before you can request a new code and try again) it is very likely that an attacker can easily brute-force the code and verify an email address they don’t own or control. This could be used as part of a phishing attack where the user can then attempt to represent an organization that they are actually not a part of (for example having @apple.com email address saying they represent Apple).
Mitigation
It is important to set limits on the usage of functionalities as part of brute force prevention, denial of service protection, enumeration etc.
5. Blocking New Users Registration
High risk
| ID | WSTG-BUSL-07 |
| Risk | High |
| Required Skill | Low |
| Location | |
| Tools | Browser |
Description
Using the registration page logic flaw, any user can potentially block other new users from registering to the site.
The misuse and invalid use of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Validation mechanisms should be implemented in such cases to prevent misuse and restrict unwanted behavior.
There is a logical bug in the registration process of the application. Whenever a user attempts to register, they provide a phone number to which they should receive a code to activate the account. However, it was found that if a phone number is “registered” but never activated, this number can no longer be used to register a new user.
- Attacker registers with random mobile number:
A new user with the same phone number tries to register, but the phone number is blocked by the attacker.
- Server response to user registration request:
This vulnerability can be exploited by innocent users who mistyped their phone numbers potentially blocking the registration of another future user.
The lack of active defenses allows an attacker to perform a Denial of Service attack without any recourse. The application’s owner will thus not know their application is under attack.
Mitigation
The solution is to block the phone number after the activation after the registration process finishes.
6. Access Control - Private Information Leakage
Medium risk
| ID | WSTG-ATHZ-02 |
| Risk | Medium |
| Required Skill | Low |
| Location | |
| Tools | Burp repeater |
Description
Accounts can view private information of others by cycling the numbers of the parameter.
We confirmed that the merchant account we were given can view the information of other accounts. parameter represents the merchants accounts registred in the application. Its value is numeric and the ids are ordered sequentially. By passing any numeric value to this parameter, the user can view the account profile of another merchant thus gaining access to their personal information, resulting an IDOR vulnerability.
This was confirmed to be a vulnerability as the accounts that should be available to our user were given by making a different request.
- A request to an endpoint returning a list of available accounts
Mitigation
Access control should be applied to the merchantid parameter as its available values should be different to each user.
7. Session Management - Session Hijacking
Medium risk
| ID | WSTG-SESS-07 |
| Risk | Medium |
| Required Skill | Medium |
| Tools | Burp |
Description
The session (i.e JWT) token is valid for 24 hours, which is problematic considering the inefficient logout mechanism and the fact it is possible to use the same token more than once resulting in concurrent sessions.
The JWT token is responsible to keep track of the user session and contains a timestamp to limit its validity. The application sets the timestamp of the JWT to 24 hours, making the token and thus the session valid even after the idle timeout is reached.
Another misconfiguration is the unrestricted amount of sessions that can run simultaneously. Although there is control over the maximum amount of concurrent sessions, it is still possible to establish more than one concurrent connection.
Hijacking the session can be done in numerous ways where in the end the attacker possesses the session token and uses it to impersonate a valid user. The timestamp and the concurrent logins limit should make it harder to use these tokens and create new sessions.
Mitigation
JWT timestamps can be updated by the server at any moment and should be as close to the session timeout as possible so no leakage of valid session tokens will accrue. In addition, if no more than one person should use an account, there is no need for multiple sessions running simultaneously. Otherwise, the restrictions should work as intended.
8. Improper Error Handling - Backend Communication Leakage
Informational risk
| ID | WSTG-ERRH-02 |
| Risk | Informational |
| Required Skill | Low |
| Location | |
| Tools | Browser |
Description
Error message with information about a failed request is being shown in the UI.
All types of applications (web apps, web servers, databases, etc.) will generate errors for various reasons. Developers often ignore handling these errors or push away the idea that a user will ever try to trigger an error purposefully (e.g. sending a string where an integer is expected).
During the assessment of the application, we used the XSS finding from the above section and made a further investigation of the “locations” GET parameter. The payload we used was as follows:
In response we got an error message appearing for a short time after clicking the refresh:
The message leak what kind of request is being made on the backend, and appears to have translated to the following GET request:
One of the conclusions of this leakage is that we can see that the connection is made through unsafe HTTP leading us to a new man in the middle attack vector.
Mitigation
Considering that this cluster doesn't appear to be on localhost, but rather a remote service, this cleartext traffic is not advised.
For remediation of the error handling, check out the Proactive Controls C10 and the Error Handling Cheat Sheet.
