1

When im doing a penitent, I noticed the application takes the user input and put it in a tag. When I used the string of '';!--"<XSS>=&{()}, I noticed the returned output (when viewing in page source) is '';!--"&lt;XSS&gt;=&amp;{()},. I think that means only < and > and & are encoded.

Another instance I found is user input is reflected in a html attribute of title="USER INPUT". In this context, however, only " and & are filtered.

I'm having some trouble with coming up a payload that will demonstrate the XSS possibility. Any suggestions? So far I've tried url encoding; however, its still encoded when viewing in source

Improve this question
3
  • is there any place where user input is included in an HTML attribute, in a HTML comment, or in a script? If so, you could inject arbitrary content thanks to unescaped characters. Otherwise, this escaping looks pretty solid – no XSS here.
    – amon
    Oct 19, 2021 at 21:28
  • Actually yes - I found a user input being used in the title attribute of a dev block. The issue is that they seem to be filtering on "context", so for this instance they are blocking the " and & characters and nothing else lol.
    – Bryan
    Oct 19, 2021 at 21:36
  • @Bryan In other words, they're doing exactly what you're supposed to do for XSS prevention. This question seems like a duplicate of multiple ones that show up in the "Related" sidebar, generally all with the same conclusion: you can try bypassing the encoding (e.g. using Unicode characters that are not the prohibited ones but that some libraries might convert to the prohibited ones, potentially after the escaping pass) but if you can't bypass it, then there's no vulnerability and nothing to "demonstrate" except that the developer did it right.
    – CBHacking
    Apr 27 at 0:35

1 Answer 1

Reset to default
0

Because the < character is escaped, you cannot start any elements.

But because quotes '" are not escaped, you could potentially break out of a HTML attribute and then do something.

For example, given this HTML structure:

<div title="YOUR_CONTENT">...</div>

You might be able to inject an event handler or other attributes:

<div title="" onclick="alert('pwned')">...</div>

But careful: some HTML template engines use context-sensitive escaping: they might escape different characters in a text context than in an attribute context. If such proper escaping is used, you won't be able to find an XSS vulnerability.

Indeed, the minimum characters that must be escaped in different contexts are:

context dangerous characters
normal content <, &
attribute name="value" ", &
attribute name='value' ', &
comments --
CDATA ]]>

plus special handling of <style> and <script> element contents, plus non-HTML injection in attributes e.g. that contain URLs.

Since you indicate that at least these dangerous characters are escaped in each context where user-provided data is shown, the application seems to be safe from XSS attacks.

Improve this answer
3
  • Would I include this in a finding? Relying on HTML template engines for context-sensitive escaping seem to be the minimal of what they should do. Is there a better way to handle user-input to prevent XSS? I want my recommendation to focus on future development of the platform.
    – Bryan
    Oct 19, 2021 at 21:57
  • @Bryan What? No. This is the best possible way to prevent XSS. Escaping in the template engine is good, and template engines with context-sensitive escaping are state of the art. Other techniques against injection attacks like stripping out “dangerous” characters are usually completely broken.
    – amon
    Oct 19, 2021 at 22:00
  • Good to know! Thank you! I definitely understand XSS a bit more now :)
    – Bryan
    Oct 19, 2021 at 22:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .