swh-web: Fix XSS

Fix XSS vulnerabilities in swh-web

Related #1699 (closed)

---

Migrated from D1442 (view on Phabricator)

Build is green See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/415/ for more details.

Merge request was accepted

approved this merge request

Could you add one (or more) unit test for this?

Merge request was returned for changes

unapproved this merge request

My main issue on that change is that the generated links will not be available anymore in the displayed error message, see output below after your change on that example (https://archive.softwareheritage.org/browse/revision/041f5ea1cf987a4068ef5f39ba0a09be85952064/?origin=https://github.com/git/got):

swh.web.common.exc.NotFoundExc: The Software Heritage archive has a revision with the hash you provided but the origin mentioned in your request appears broken: <a href="https://github.com/git/got">https://github.com/git/got</a>. Please check the URL and try again.

Nevertheless, you can still browse the revision without origin information: <a href="/browse/revision/041f5ea1cf987a4068ef5f39ba0a09be85952064/">/browse/revision/041f5ea1cf987a4068ef5f39ba0a09be85952064/</a>

This makes the navigation more painful as the user will have to copy / paste the link instead of simply clicking on it.

Considering the only vulnerability here is if someone submits an origin url through a save code now request containing <script> tags in it, I think it will be better to filter out that kind of bogus data directly in the common/origin_save.py file.

@anlambert Ok. Will need to rework this, to keep the links working. But, 1- if we filter out directly while saving, it may cause some valid links being rejected. 2- if I use filterXSS, other html tags will still work.

@kalpitk , indeed this is not so easy as it seems to fix any possible XSS injections.

1- if we filter out directly while saving, it may cause some valid links being rejected. Yes, this calls for clever filtering server-side on the submitted origin urls to save into the archive.

2- if I use filterXSS, other html tags will still work. Maybe but at least the harmful tags will be removed so this is not really a big deal IMHO.

We should really add some end to end tests using Selenium in a near future to better detect and prevent XSS vulnerabilities.

• use mark_safe with escape

Build is green See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/421/ for more details.

Looks good. Please address my comment and I will accept the diff.

Merge request was returned for changes

• move mark_safe to _generate_error_page

@anlambert We need to remember to use 'escape' unsafe things, whenever marking some html as safe.

I think, I'll add selenium end-to-end tests in another commit (as per Timeline in my GSoC proposal?)

Build is green See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/422/ for more details.

rebase and squash commits

Build is green See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/424/ for more details.

• Fix XSS in origin/search

Build is green See https://jenkins.softwareheritage.org/job/DWAPPS/job/tox/425/ for more details.