This blog will demonstrate how a hacker could harvest credentials of the main application of an organization by taking advantage of the autofill features implemented in modern browsers and password manager tools and bypassing the CSP restrictions. 

Overall Structure of the Organization

The organization has two main applications, the first one https://control.example.org, which is the main application acting as a central dashboard for its customers.   One feature under this application allows its customers to upload sanitized HTML files as a template into a S3 bucket . The S3 bucket is behind AWS CloudFront and the CloudFront is CNAME to cdn.example.org for performance and scalability reasons.

The following diagrams illustrate how these two applications work. 

XSS exploitation is not possible due to sanitization and CSP header

As the application allows users supplied HTML template through the control panel https://control.example.org  and then render it under the https://cdn.exampe.com/my_user_id/template1, the first thought was to check whether XSS is possible. However, after spending some time on  discovering potential XSS vulnerabilities and exploiting them, it turns out this method did not work as expected due to the following  implementation to prevent XSS exploitation.

User input Sanitization Implemented under control.example.org

The user input sanitization seems to be very robust after numerous with different payloads. It seems that only these DOM elements <div >,<form>, <input>,<image> and <a>  are allowed to be added in the user’s supplied HTML template whereas all the event handlers are filtered out.

The following template  seems to be able to pass the sanitization method and is able to be stored and rendered  under the browser when opening https://cdn.exampe.com/{user_id}/template1 

However, the Content-Security-Policy header implemented under cdn.example.org is blocking the execution of these JavaScripts.

Strict Content-Security-Policy is present under cdn.example.org

The cdn.example.org where users supplied HTML template has the below Content-Security-Policy added by AWS Lambda@Edge in order to prevent potential XSS exploitation 

Content-Security-Policy: img-src ‘self’; script-src ‘self’; style-src ‘self’; object-src ‘none’;base-uri ‘self’;report-uri /csp report

Since the Content-Security-Policy does not allow inline JavaScript when rendering the page under a modern browser, the template containing inline JavaScript uploaded could not be used to launch XSS exploitation. 

Even though launching XSS exploitation seems not feasible at this moment due to the restrictions, we could explore other potential exploitation methods. 

Take advantage of autofill feature to steal user credentials

Most modern browsers and password managers have Autofill features enabled by default to bring a faster sign in, billing information and other user experiences. It means, the browser or password managers will save these user inputs and populate them and autofill them next time for you. 

The feature is convenient but with a tradeoff for security. There are a couple of cavities in the feature. One big problem is that the Autofill feature will pull saved credentials from its sibling subdomains and autofill them into forms located under other subdomains.

For example, users login to the https://control.example.org and click Save passwords pop ups in the browser during login. The saved username/password will be pulled from the browsers and autofill into the Login form again next time when users open the login page under https://control.example.org. 

Now, users created a similar Login Form (same names for the input fields) on a sibling subdomain https://cdn.example.org, the browser will pull the save password for control.example.com and autofill it under the Login form under https://cdn.example.org.  That sounds quite scary if an attacker could control another subdomain or is able to manipulate some pages in the subdomains.

With that said, if we modify our templates with the following content and upload it to https://cdn.example.org and open uploaded template https://cdn.exampe.com/{my_user_id}/template2 under your browser, the login form will be auto filled with the username and password saved earlier for  https://control.example.org. 

From an attacker’s perspective, once the username and password are auto filled into a Login Form they control, they could steal these credentials by modifying the action attribute in the Login form to receive the credentials once users click the Signin button if auto submit is not enabled. 

You make it an even converter by applying a Clickjacking exploiting where your trigger user clicks the Signin button.

Conclusion

Autofill feature provided by password managers and browsers is a convenient feature with security tradeoff.  Especially, when your website has potential XSS vulnerabilities or there are many subdomains under your organization, you need to pay extra attention to manage the subdomains. For end users, if possible you could turn off autofill password features to prevent password stealing.