You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
XSS Injection via typing challenge input reflected back in "Word History"
Description
User input is interpreted by the browser unsanitized when entered into the typing challenge. Once the challenge is over and the user opens the "word history" tab, hovering over the mispelled words will cause the browser to interpret the payload as valid injected code. Under current limitations significant code execution cannot be caused due to character limit, however more research should be done to prove impact. This occurs in default settings.
Impact
The impact of the XSS is low/none. At current, only basic injection is possible due to character limitations. The injection is also only client side, and does not seem to be exploitable outside of the local context.
Reproduce.
For a XSS payload, just start typing this "><svg/onclick=alert1`>
Start a new typing challenge
Spell the first word correctly, then immediately after the first word and with no spaces after, terminate the string with ">
Enter payload
Once the timer is complete, select the option to view word history
Hover over the misspelled word, and the payload will execute
Expected behavior
The application should strip out special characters from this field, especially since the typing test does not require any.
Screenshots
Inject Payload
Payload Being Interpreted On Click
HTML Payload
This should effect all client's using the application, but below is my setup
OS: [MacOs]
Browser [Chrome]
Version [90.0.4430.93 (Official Build) (x86_64]
Remediation
In the screenshot below you can see the user input shows up in the input field of the word error div. Special characters here should be escaped.
I'll dig into the source code and see where I can help on thisa
The text was updated successfully, but these errors were encountered:
Not really XSS because this can't be injected by a different website / instance. Word input history is local and local only, and is not sent to the server either.
So, not as dangerous as it sounds but yeah, should be escaped either way.
Not really XSS because this can't be injected by a different website / instance. Word input history is local and local only, and is not sent to the server either.
So, not as dangerous as it sounds but yeah, should be escaped either way.
I was able to get code execution tho using a svg/onclick payload, so this is XSS but there is no impact
tcbutler320
changed the title
Stored Cross Site Scripting (XSS) via Word History
HTML Injection via Word History
May 4, 2021
tcbutler320
changed the title
HTML Injection via Word History
Cross Site Scripting (XSS) via Word History
May 4, 2021
Overview
XSS Injection via typing challenge input reflected back in "Word History"
Description
User input is interpreted by the browser unsanitized when entered into the typing challenge. Once the challenge is over and the user opens the "word history" tab, hovering over the mispelled words will cause the browser to interpret the payload as valid injected code. Under current limitations significant code execution cannot be caused due to character limit, however more research should be done to prove impact. This occurs in default settings.
Impact
The impact of the XSS is low/none. At current, only basic injection is possible due to character limitations. The injection is also only client side, and does not seem to be exploitable outside of the local context.
Reproduce.
Expected behavior
The application should strip out special characters from this field, especially since the typing test does not require any.
Screenshots
Inject Payload
Payload Being Interpreted On Click
HTML Payload
Remediation
In the screenshot below you can see the user input shows up in the input field of the word error div. Special characters here should be escaped.
I'll dig into the source code and see where I can help on thisa
The text was updated successfully, but these errors were encountered: