vitmalina / w2ui

UI widgets for modern apps. Data table, forms, toolbars, sidebar, tabs, tooltips, popups. All under 120kb (gzipped).
http://w2ui.com
MIT License
2.64k stars 730 forks source link

Angle brackets in the w2grid (XSS) #2467

Closed dv1x3r closed 8 months ago

dv1x3r commented 10 months ago

The initial XSS issue was mentioned some time ago in the #996

Short description The w2grid component is vulnerable to non-sanitized text (XSS attack). This also leads to a UX issue when it is impossible to inline edit or view values with angle brackets (not everything is HTML).

What is current behaviour

  1. In case the field value is <item not available>, then it will be shown as a blank cell.
  2. In case the field value is <script>alert(42)</script>, then it will be shown as a blank cell, and the script will be executed.
  3. In case a user types <script>alert(42)</script> into the search prompt, it will be executed. (not that critical, but nice to fix)

What is desired behaviour

  1. It will be shown as <item not available>.
  2. It will be shown as <script>alert(42)</script>, and the script won't be executed.
  3. The script won't be executed

Link to jsfidle with sample code jsfidle example

Steps to reproduce or sample

  1. Create a w2grid component with an inline editable text field.
  2. Enter <item not available> into the inline editor.

Not everything is html, and there could be cases when the REST API returns infected data. For a general-purpose grid, it is necessary to output values as text, not as HTML.

As a workaround, use the following render function for text fields: render: row => w2utils.encodeTags(row.field). And do NOT allow inline editing for text fields if your users may use angle brackets.

Please let me know if I can help with this problem, and if a PR would be welcomed.

vitmalina commented 8 months ago

Thank you for bring it to my attention. Yes, historically w2ui allowed unsanitized HTML content. If you would like to provide PR with fixes in the places where you find it, it would be great. But I think it could be quite a few places and it would be difficult to fix all with certainty.

I have played with another approach recently and I think it is a more guaranteed solution to fix XSS problems, which is Content Security Policy (CSP). As of version 2.0 of w2ui, it will support strict CSP policy where all inline JS is disabled. This way even if there are inline scripts, they will not be executed by the browser. This was a big effort to support strict CSP, as earlier version of w2ui relied on inline event, such as onmouseenter="w2ui.grid.showTooltip()", etc.

You can read up more on CSP, but here is the policy that w2ui will be fine with

<meta http-equiv="Content-Security-Policy" content="script-src 'none'; style-src 'unsafe-inline';">

Please note, then inline styles are still used. However, I do not see much security issues with them.

dv1x3r commented 8 months ago

In my solution I made the following one-liner, and use render: 'safe' for all my text fields: w2utils.formatters['safe'] = value => w2utils.encodeTags(value)

I also see, that now it also works with inline editable text fields (it is possible to use \<text> as a value). So I will close this issue.