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
Looking at this recent commit, I wondered why only links and images should be specially treated for html entities; what specific forms of XSS are prevented by that?
The wiki in its current form allows for HTML to be entered as far as my tests are concerned; entering
<script>alert('Hello');</script>
on a page brings up an alert box...
Doesn't the htmlentities handling need to happen earlier (on $inText at the start of toHTML)? The one happening right before the end of toHTML doesn't do anything ($inText isn't used anymore after that), and would break the previously inserted images/links etc. anyway...
I've tried a fix in my fork: codeling@77cb75d
and it seems to at least prevent the simple XSS shown above.
The text was updated successfully, but these errors were encountered:
In 3cdc651, the script will now replace those with empty strings.
Sorry for reviving an old topic. But the linked solution will still not prevent inserting script tags that have attributes or whitespace, e.g. <script type="text/javsscript">alert('Hello');</script >; I dimly remember having read somewhere that a "blacklisting" approach is not recommended for XSS prevention, as it's often easy to work around.
Looking at this recent commit, I wondered why only links and images should be specially treated for html entities; what specific forms of XSS are prevented by that?
The wiki in its current form allows for HTML to be entered as far as my tests are concerned; entering
on a page brings up an alert box...
Doesn't the
htmlentities
handling need to happen earlier (on$inText
at the start oftoHTML
)? The one happening right before the end oftoHTML
doesn't do anything ($inText
isn't used anymore after that), and would break the previously inserted images/links etc. anyway...I've tried a fix in my fork: codeling@77cb75d
and it seems to at least prevent the simple XSS shown above.
The text was updated successfully, but these errors were encountered: