CWE-79 Improper Neutralization of Input during Web Page Generation (‘Cross-site Scripting’)

CWE-79 IMPROPER NEUTRALIZATION OF INPUT DURING WEB PAGE GENERATION (‘CROSS-SITE SCRIPTING’) 

DESCRIPTION:

Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications.

1. Data enters a Web application through an untrusted source, most frequently a web request.
2. The data is included in dynamic content that is sent to a web user without being validated for malicious content.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may also include HTML, Flash, or any other type of code that the browser may execute. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data, like cookies or other session information, to the attacker, redirecting the victim to web content controlled by the attacker.

Stored and Reflected XSS Attacks

Stored XSS Attacks

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

Reflected XSS Attacks

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable website, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

DOM XSS Attacks

DOM Based XSS (or as it is called in some texts,  is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script.

That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

PROBLEM LOCATION:

– Common Parameter Or Injection Points example  (Customizable Themes & Profiles via CSS,Event or meeting names, URI based, Imported from a 3rd party (think Facebook integration),JSON POST Values (check returning content type),File Upload names, Uploaded files (swf, HTML, ++),Login and Forgot password forms, Custom Error pages,params – ?realparam=1&foo=bar’+alert(/XSS/)+’.

– Popular Sources (document.URL, document.documentURI, location.href, location. Search, location.*, window.name, document. Referrer)

– Popular Sinks (HTML Modification sinks document. Write (element).innerHTML HTML modification to behaviour change (element).src (in certain elements) Execution Related sinks eval setTimout / setInterval execScript )

MITIGATION

Encode all fields when displaying them in the browser. Additionally, ensure that user input is properly filtered especially in the case of special characters. Ensure that cookie properties (such as HttpOnly) and security headers are set accordingly. A web application firewall (WAF) is the most commonly used solution for protection from XSS and web application attacks. Implement Content Security Policy (CSP) header.

GENERAL RESOURCES:

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet 

https://www.owasp.org/index.php/DOM_Based_XSS

https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/xss

GENERAL TOOLS:

1. Burp suite

2. xenotix xss

Owasp Mobile Top 10 M4 – Insecure Authentication

In this post, we are going to discuss the insecure Authentication which holds the Fourth position in Owasp Top 10 mobile Risks. Android apps are facing this vulnerability when the app fails to identify the user, allowing an anonymous user to login and using default login credentials. This category includes session management issues, privacy issues related to authentication, and issues where user identification tokens are compromised. Even if the mobile app uses a weak password policy to simplify entering a password, it suffers from insecure authentication.

To exploit this vulnerability, we have different approaches like attacking activities, Brute-force attack, user enumeration and checking password policy.

Attacking Activities:

In Android apps, everything is activities if you are in login screen it’s an activity if you are in profile screen its other activity so we can able to bypass the authentication by forcing the app to show the profile activity without giving username and password. To exploit activities we need to use a drozer framework which we have already discussed in earlier blogs.

first, we need to know what are the activities are available in insecure bank app for that we need to give the below commands

dz> run app.activity.info -a com.android.insecurebankv2

From the results, we come to know that that are 5 activities which are exported and first two are related to the login process.

 Fig. 1

 Com.android.insecurebankv2.LoginActivity is for login page screen (Fig 1.) and the com.android.insecurebankv2.PostLogin activity (Fig 2) is the screen which triggers when the user logged in. so we need to use the com.android.insecurebankv2.PostLogin activity to bypass the authentication. By using drozer let we start the activity by giving the below commands

dz> run app.activity.start  --component  com.android.insecurebankv2 com.android.insecurebankv2.PostLogin

 Fig 2.

 finally, we have bypassed the login page now we can do the transfer, changing the password or viewing the statement is possible. A brute-force attack is also possible but if the app has any brute-force protection mechanism it makes hard to attack. for example, if the app gets often login request it will block the user and it will restrict the access for a while. and there is another issues like Username Enumeration which occur when a user logged and for the second time when he/she too going login in app it shows the username and also when app gets the correct username and the wrong password that time it may show password of the username is wrong so it will conform us the username, it mostly happens in WordPress logins in web applications.

How to Fix:

• Don’t export unnecessary activities or use permissions when the activity is exported
• Implement two-factor authorization if called for the sensitivity of your application
• Disable anonymous accounts
• Implement strong password policy and don’t store the password in local storage

In this post, we have discussed how to attack activities using the drozer tool, and how the way android apps are vulnerable to owasp’s insecure authentication, and how to fix the vulnerability.