postMessage XSS in Tesla Payment page

Report details

• Submitted

  25 May 2021 16:20:10 UTC

• Target Location

  *.tesla.com

• Target category

  Web App

• VRT

  Cross-Site Scripting (XSS) > Reflected > Non-Self

• Priority

  P3

• Bug URL

  https://www.tesla.com/ro_ro/model3/design#payment

• Description

  Hey Tesla,

  Trying to do bug bounty until I get enough money to buy a Tesla, I stumbled upon a postMessage XSS in the payment page (available when configuring a Tesla car).

  This vulnerability occurs because the web page at https://www.tesla.com/ro_ro/model3/design#payment registers an "onmessage" event listener which accepts cross-domain messages from any other domain. Neither the source nor the origin of the received message are checked, so any other domain can send messages using the postMessage API.

  Moreover, as shown in the "DOM XSS in form.action.png" attachement, part of the received message (without any additional validation) is used for constructing an auto-submitting form. If the action property of this form is set to a "javascript:" URL, then the JavaScript code specified in it will execute in the security context of www.tesla.com domain.

  Please see the attached video POC and screenshots for more details.

  postMessage XSS vulnerabilities are not very common, but very similar vulnerabilities have also been found in the past. Example of a write-up of such a vulnerability in Facebook.

  In terms of fixing the vulnerability, I recommend taking one or more of the following actions:

  • validating that the URL received in the message object is a valid HTTPS url (and maybe a trusted website, to avoid an open redirect vulnerability);
  • validating the "message.origin" property to be a trusted Tesla domain;
  • validating the "message.source" property to be one of the iframes / tabs which have a business need for communicating with the payment page.

  Please let me know if I can be of help with further details.

  Thank you,
  Daniel Tomescu

• HTTP request

  postMessage payload:
  
  var payload = {
  	"instanceId": 0,
  	"data":"aaaa",
  	"method":"GET",
  	"url":"javascript:alert(`XSS in the context of: ` + origin)",
  	"type": "redirect"
  }

• Extra info

  This type of XSS allows attackers to execute custom JavaScript code from 3rd party websites inside the security context of the web application at https://www.tesla.com/. This allows attackers to gain access to the victim's web session, to their private details stored in their account or even to their payment details, should the user be tricked to input them during the attack.

  I would like to highlight that this type of XSS is bypassing all server-side mitigating controls (user input validation, WAFs etc) because the payload never touches the server. Also, it bypasses client-side protections such as CSP because the XSS payload already executes in a trusted context.

  In my CVSS calculation (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N), I took into account the following:

  • this is a 'network' attack since it can be carried over the internet;
  • the attack complexity is Low since XSS attacks are fairly well understood and the attack can be automated;
  • victim user interaction is required, usually in the form of visiting an attacker-controlled web page;
  • The scope is changed - the attacker gains access from its 3rd party website to www.tesla.com domains through the XSS attack.
  • The confidentiality impact is high - the attacker can leak the victim user's private details (if logged in), payment details etc.
  • The integrity impact is high, since the attacker can fully rewrite the web page at https://www.tesla.com/ro_ro/model3/design#payment through JavaScript in order to serve a completely different purpose; also the attacker can make changes in the victim user's account; I can think of no better phishing page than a genuine Tesla page offering a 99% discount. :)
  • I considered the availability impact to be negligible.