Password Stealing from HTTPS Login Page & CSRF Protection bypass using Reflected XSS
- What is XSS?
- Types of XSS
- Case study: Password stealing with reflected XSS
- Case study: Cross-Site Request Forgery protection bypass with XSS
1. What is XSS?
Cross-Site Scripting (XSS)
Contributor(s): Jim Manico, Jeff Williams, Dave Wichers, Adar Weidman, Roman, Alan Jex, Andrew Smith, Jeff Knutson…
2. Types of XSS
- Reflected XSS
- Persistent XSS
- DOM-based XSS
A reflected XSS vulnerability happens when the user input from a URL or POST data is reflected on the page without being stored, thus allowing the attacker to inject malicious content. This means that an attacker has to send a crafted, malicious URL or post form to the victim to insert the payload, and the victim will click the link.
Stored Cross-site scripting vulnerabilities happen when the payload is saved, for example in a database, and then is executed when a user opens the page on the web application. Stored cross-site scripting is very dangerous for a number of reasons:
- The payload is not visible for the browser’s XSS filter
- Users might accidentally trigger the payload if they visit the affected page, while a crafted URL or specific form inputs would be required for exploiting reflected XSS.
DOM Based XSS simply means an XSS vulnerability that appears in the DOM (Document Object Model) instead of part of the HTML. In reflective and persistent XSS attacks you can see the vulnerability payload in the response page, but in DOM-based XSS, the HTML source code and the response of the attack will be exactly the same. In other words, the payload cannot be found in the response. It can only be observed on runtime or by investigating the DOM of the page. Basically, the payload remains within the browser.
Cross-Site Scripting Attack vectors
- Password Stealing from HTTP/HTTPS logins/registration web pages.
- Remote Code Execution.
- Keylogger Injection.
- Cross-Site Request Forgery Protection Bypass.
- Browser Hijacking.
- Cookie Stealing — most common.
3. Password Stealing with Reflected XSS
So I have developed a simple website where users can register/login, have access to a simple form/comment page, and account settings where they can update bio and password.
Important note, there is HTTPS/TLS 1.3 implemented so the connection is encrypted.
An attacker can take advantage of this vulnerability and can steal usernames/passwords with reflected XSS.
There are a few steps on how to do it.
In order to steal the password from the HTTPS login/registration page, an attacker should set up a server and domain with SSL/TLS certificate.
An attacker should set up a VPS with a webserver running so he can intercept victim credentials.
I have created an XML HTTP Request for persistence so the victim could try to access the login page multiple times.
An attacker finds a vulnerable web login/registration page and crafts a phishing email with XSS payload injected into the vulnerable web page and sends it to the victim.
This is how the website looks like when a user clicks in the URL from a phishing email. An attacker could make this script shorter to make it even less suspicious or simply can shorten the link.
Below is the web page presented to the user/victim.
Our victim types his email and password and an attacker can read it all in plaintext on his server:
4. CSRF Protection Bypass With XSS
This simple demo is not about how to perform CSRF (Cross-Site Request Forgery) attacks but how to bypass CSRF protection with XSS.
Example of a very basic account settings web page.
CSRF protection/tokens are implemented in session, however, they don’t change with every single HTTP request. This could be considered a bad practice, but the web application is still protected against a traditional CSRF attack.
Anyway, let's take a look at how CSRF tokens work.
So basically the token changes when the user logs in and out from the web page.
Cross-Site Scripting could lead to CSRF if tokens don’t change with every single HTTP request.
An attacker could send a malicious URL to the authenticated victim:
JS script below is where the attacker keeps the payload:
Now the victim clicks on the link and he loses access to his account and the attacker changes his password.
As we can see, it is possible to bypass CRSF tokens with Cross-Site Scripting making XSS equal to CSRF.
5. XSS Mitigations
The most important rules:
- Output Escaping
- Input Validation
- Content Security Policy
- HTTPFlag enabled — This is only against a cookie stealing XSS attack (However, there are some bypass techniques for example Cross-Site Tracing Attack)
Output Escaping examples:
For untrusted string in the context of HTML, do HTML escape, for example:
<h1> Welcome html_escape(untrusted string) </html>
For untrusted string in the context of HTML attribute, do HTML escape and always quote your attributes, either ( ‘ or “ ) never use backticks ( ` ).
<img src=”x” alt=”html_escape(untrusted string)”>
All the untrusted data should be validated against the web application’s logic before processing or moving it into storage. Input validation can prevent XSS in the initial attempt itself.
Content Security Policy
This header is one of the most effective solutions for preventing XSS. It allows us to enforce policies on loading objects and executing them from URLs or contexts.
OWASP Best Practices against XSS