2

I have a question regarding the element. I know that this element has been deprecated for a long time, but during a penetration test, we inserted the following attack vector into a textarea:

<plaintext onmouseover="(function(){ console.log(document.domain); })();">

Other attack vectors for XSS are blocked, even HTML elements using events.

The framwork used in the frontend is JSF.

I know that plaintext orders browsers to treat the following content as simple text without any formatting, but is it normal that <plaintext> allows XSS?

Has anyone heard of that or has any background information on this behaviour?

3
  • 3
    Can you post a minimal version of the result of the POST request (where the <plaintext> has been inserted, but remove all the irrevelant stuff)? It might help us to understand where the problem comes from. Oct 21 at 15:18
  • 2
    If you receive the log message isn’t that proof enough that you injected JavaScript code in the target origin?
    – eckes
    Oct 22 at 2:20
  • Of course it is a proof. but I wanted to ask the community if this is really a XSS. Maybe plaintext has a desired behaviour like my finding
    – ItFreak
    Oct 22 at 9:22
7

This does not look like a successful XSS attack.

First, the <plaintext> element is not special in this context. It is still supported by browsers, but HTML5 is very flexible and allows you to write any tags. You could probably also add a <foo> tag or a <custom-element> with equivalent effects.

Second, and more importantly, the <textarea> and <title> elements have a special content model (escapable raw text element): they only allow text contents and end with the next </ sequence, though ampersand-escapes still work. Also consider searching through the HTML parsing algorithm to find special handling of the textarea element.

Thus, you have likely inserted normal text content, not a HTML element that participates in the DOM.

A conformant browser will parse the HTML snippet

<textarea>surrounding <foo onmousehover="..."> content</textarea>

as the DOM

HTMLElement "textarea"
 children:
   - #text "surrounding <foo onmousehover="..."> content"

and not as the DOM

HTMLElement "textarea"
  children:
    - #text "surrounding "
    - HTMLElement "plaintext"
        onmousehover: "..."
    - #text " content"

However, this behaviour of the textarea element can sometimes enable confusion that can allow for XSS. An example in the HTML parsing algorithm linked above mentions issues around comments in textarea elements. If an application constructs a DOM and serializes the DOM to HTML document, parsing this document might produce a different DOM. For example:

  • Input DOM:

    HTMLElement "textarea"
    children:
      - #comment "</textarea>"
      - #text "<span onmousehover='...'>content</span"
    
  • HTML serialization:

    <textarea>
      <!--</textarea>--><span onmousehover='...'>content</span>
    </textarea>
    
  • New DOM:

    - HTMLElement "textarea"
        children:
          - #text "<!--"
    - #text "-->"
    - HTMLElement "span"
        onmousehover: "..."
        children:
          - #text "content"
    
3
  • 1
    Thank you for your reply, but I am receiving the documents domain on the console when hovering the inserted plaintext, thats why I asked this question. Thanks for the information, I will check it out
    – ItFreak
    Oct 21 at 14:23
  • 2
    @ItFreak Interesting! I cannot reproduce this using the Firefox or Chrome HTML parsers. Maybe you found a real problem with how Java Server Faces handles these tags, along the lines of the HTML serialization confusion I've outlined in my answer. Looking into the actual HTML produced by the server would be useful.
    – amon
    Oct 21 at 17:04
  • I don't believe an unknown element would ever be treated as text.
    – user253751
    Oct 22 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.