The setJavaScriptEnabled(true) method, allowing the execution of JavaScript code, is called for an instance of the WebView class (designed to download and display HTML pages). This behavior is prohibited by default. A setJavaScriptEnabled(true) call can contribute to the success of cross-site scripting (XSS) attacks. Among the possible consequences of such an attack there is the loss of confidentiality of application data, such as user session data.

Cross-site scripting is one of the most common types of attacks on web applications. XSS-attacks take the seventh place in the “OWASP Top 10 2017” list of ten most significant web application vulnerabilities. In the mobile application vulnerabilities “OWASP Top 10 Mobile Risks 2014” ranking, client side injection attacks, which include some XSS-attack, take the seventh place.

The main phase of any XSS-attack is an imperceptible for the victim execution of a malicious code in the context of the vulnerable application. For this purpose, the functionality of the client application (browser) is used that allows to automatically execute scripts embedded in web page code. In most cases, these malicious scripts are implemented in JavaScript. Thus, the setJavaScriptEnabled(true) call is one of the necessary conditions for an XSS attack.

Consequences of an XSS attack vary from violations of application functionality to complete loss of user data confidentiality. The malicious code can steal cookies during the XSS-attack, which gives an attacker the ability to make requests to the server on behalf of the user.

OWASP proposes the following classification of XSS-attacks.

Server type XSS attacks occur when data from an untrusted source is included into the response returned by the server. The source of such data can be both user input and server database (where it had been previously injected by an attacker who exploited vulnerabilities in the server-side application).

Client type XSS attacks occur when the raw data from the user input contains code that changes the Document Object Model (DOM) of the web page received from the server. The source of such data can be both the DOM and the data received from the server (e.g., in response to an AJAX-request).

The typical server type attack scenario:

Unchecked data, usually from the HTTP-request, get into the server part of the application.
The server dynamically generates a web page that contains the unchecked data.
In the process of generating a web page, server does not prevent the inclusion of an executable code that can be executed in the client (browser), such as JavaScript code language, HTML-tags, HTML-attributes, Flash, ActiveX, etc., in the page code.
The victim’s client application displays the web page that contains the malicious code embedded using the help of data from an untrusted source.
Since malicious code is embedded in the web page coming from the known server, the client part of the application (browser) executes it with the rights specified for the application.
This violates same-origin policy, according to which the code from the one source must not get an access to resources from another source.

Client type attacks are executed in a similar way with the only difference that the malicious code is injected during the phase of the client application work with the document object model received from the server.

In the context of Android applications attention must be payed vulnerabilities that lead to DOM-based XSS attacks (a subset of client type XSS attacks). The difference between this type of attack and traditional XSS attacks is that in the case of DOM-based XSS malicious code is not sent to the server. Therefore, the server means of protection, such as escaping special characters in the output of the server application, in this case are useless.

Android : Unsafe internal storage (SharedPreferences)

DerScanner Severity Score

Do you want to fix Android : Unsafe internal storage (SharedPreferences) in your application?

See also