Stored Cross-Site Scripting (XSS) is one of the major flaw in Web Applications, and it is also one of the difficult form of Cross-Site Scripting to be detected by Automated Scanners. A simple example of Stored XSS is as follows:
-
Consider a Social Networking Site, that allows a registered user to write comments and post images on his/her friends’ wall.
-
If a registered user is able to post a malicious input, e.g. <script> malicious_code() </script>, on the wall of target victim, then malicious_code() would be executed once the victim user visits his/her wall.
-
Another variant of the same vulnerability exist, in case, a registered user is able to upload arbitrary HTML (with javascript) or even ASP/PHP file in place of an image.
The impact of Stored XSS is, sometime, much more than Reflected XSS. For example, in the above scenario, an attacker can target hundreds / millions of users with the same (self-propagating) malicious payload.
Note that, an automated scanner would find it difficult to verify whether the injected malicious payload is actually sanitized properly or not. For example, in the above scenario, an automated scanner, in general, will not have logic to visit the particular page or partial of the page where the malicious input will appear because of various reasons like pagination or no standard way to visit a user profile.
Many web applications have functionality to upload pictures, documents (doc, ppt), exported data (CSV, XML), themes(.thm format) and many other types of files. Such applications are vulnerable to Stored XSS via File Upload and as a result, an attacker can upload a file with malicious content and compromise target victim users.
There are following mistakes that, generally, results into Stored XSS via File Upload
-
Only Client Side Validation: Client side validation of the uploaded files can, mostly, be bypassed using web app proxy (paros / burp). As a result, only client side validation means no validation.
-
Predictable File Location: Sometimes, there is predictable way to construct uploaded file URL. In such cases, if it is possible to upload, say, a PHP file in the place of an image file then it may be possible to directly execute PHP code on the server. One of the common mistake, we have seen, is that vendors append a few digits random number as a suffix to make the filename unique in the system and make it difficult to predict the file URL. However, such an approach can easily bypassed using simple brute-forcing.
-
Weak Server Side Validation: A weak server side validation is often can be bypassed by attackers. For example, if the application should only allow TEXT files to be uploaded, an attacker can upload malicious HTML / PHP / ASP files because of weak server side validation.
Mitigations
-
Server Side Validation: There should be server side validation of the uploaded files based upon the business requirements. Some of the factors that should be considered to validate the input file include file type, file content and file size. There are two main approaches for validation:
-
While list Approach: In this approach only certain types of file and certain content of the file should be allowed.
-
Black List Approach: In this approach, certain types of file and certain content of the file should not be allowed.
-
Sandboxing: All the uploaded files should be stored and retrieved from a different domain and different server, if possible. As a result, even if malicious content of the file is executed, it will have limited privileges.
A more comprehensive list of mitigation strategies can be found here. Stores XSS and similar vulnerabilities can be found readily during security expert analysis phase of penetration testing.
{ 0 comments }
