Further XSS fixes in link attrs (#703)#705
Conversation
|
Nice work, unfortunately the fuzzer found another bypass on this new branch 😅 Input: ">`)Output: <p><img src="code><A B="
" onerror="alert(origin)"></code" alt="" /></p> |
Issue was a while loop comparison. We did `orig != text` but assigned `orig = text` at the end of the loop, where it should have been at the start, before any transformations take place
Managed to fix this. Turns out we were hashing the code and spans, and we were meant to unhash them again in the URL encoding, but the while loop was incorrect, and didn't properly recursively unhash everything. |
|
Another bypass 😅 Input: ">`Output: <p>">`" alt="x" /></p> |
Another fix. That one was smuggling the XSS through link definitions, so I've changed the |
|
Took a few minutes more than usual this time, but fuzzer pulled through again on the latest commit: Input: - [x]
1. - [x]
___
[x](`")}<img src="x`" onerror="alert(origin)">
___Output: <ul>
<li>[x]
<ol>
<li><ul>
<li>[x]</li>
</ul></li>
</ol></li>
</ul>
<hr />
[x](`")}<img src="x`" onerror="alert(origin)">
<hr /> |
Further fixes for #703, specifically the follow up issues raised in this comment: #703 (comment)
Issue 1:
For some reason html encoded colons function as normal colons in hrefs, so
javascript:alert()is equal tojavascript:alert().Fixed this by checking for these sequences alongside colons.
Issue 2:
The safe_href regex we use allows for URL domains with ports. This was intended for links like
localhost:880/abcdefbut could be abused by making the JS look like a domain with a port, like so:Issue 3:
This used some quirky markdown in a image title attr to escape the link. Fixed by hashing the title attr to prevent reprocessing, much like we do with
alt=