Security Vulnerability Notification | OBB-1583403 | Important

[min2ha]

A security researcher reported a security vulnerability affecting www.webarchive.org.uk website via Open Bug Bounty coordinated and responsible disclosure program: https://www.openbugbounty.org/reports/1583403/

Following ISO/IEC 29147 standard guidelines, we verified the vulnerability's existence prior to notifying you. Please contact the security researcher directly for technical details of the vulnerability. The researcher may also help remediate the vulnerability if you need any assistance. If you received this notification by error, please accept our apologizes and forward it to your IT security team or a person in charge of your website security.

[nicolabingham]

Thanks @min2ha what is the action here? Do we need to reach out to BL security?

[anjackson]

More details have been published now, and it's a simple case of failing to properly escape the query string when showing it in the results page.

Fortunately, this site does not have anything sensitive that can be accessed via XSS. However, it should still a potentially dangerous error and should be dealt with before any additional capabilities are added to the site.

[min2ha]

To prevent an XSS attack we will use XSS filter. The logic below:

In general, we should strip malicious code from headers, parameters, and bodies for every request.

[anjackson]

Er, I thought we just needed to escape the query string when printing it into the results page?

EDIT I mean filtering the input is good as well, if we can distinguish bad strings from valid queries, but I think we need to escape the output too.

[min2ha]

Thanks @anjackson for your thoughts.

So we want to avoid any extra delay or overhead on processing of query string. In general we have two options:

1. Long term solution - aka Systematic approach: prevent XSS attacks by using both Spring Security features and a custom XSS filter. (affects headers, parameters, and bodies for every request)
2. Short term solution (or specific case solution) - Sanitize the input/result by removing suspicious tags:

   public static String sanitize(String string) {
   return string
    .replaceAll("(?i)<script.*?>.*?</script.*?>", "")   // case 1
    .replaceAll("(?i)<.*?javascript:.*?>.*?</.*?>", "") // case 2
    .replaceAll("(?i)<.*?\\s+on.*?>.*?</.*?>", "");     // case 3
   }

[anjackson]

Yes, the two-step sounds fine. Note that web frameworks have usually utility functions for this kind of thing, so you may as well use HtmlUtils.htmlEscape rather than rolling your own.

[min2ha]

Ready to test on Dev server.

[anjackson]

The original report appears to have disappeared now! However, I can test it with this query:

https://www.webarchive.org.uk/en/ukwa/search?text=%3Ch1%20style=%27color:red%27%3EHello%3C%2Fh1%3E&search_location=full_text&reset_filters=false&content_type=Web+Page

i.e. I've patched a big red header into the page. But on DEV this is now escaped correctly...

https://dev.webarchive.org.uk/en/ukwa/search?text=%3Ch1%20style=%27color:red%27%3EHello%3C%2Fh1%3E&search_location=full_text&reset_filters=false&content_type=Web+Page