provide a way to specify a blocklist of protocols

[robstoll]

following use case:
I want to restrict the protocol in href of <a>. allow everything with the exception of javascript (and all its encoded variants etc.)

currently, one can only either allow all or safelist.

[jhy]

What protocols do you want to support additionally than HTTP and HTTPS? Gopher?

My fundamental concern with blocklists is that it is very easy to forget something -- or the world changes and introduces something -- that will then cause unexpected results. That's why IMO the Cleaner Safelist implementation has proven largely resilient to XSS over time. Only allowing known safe content.

What is the motivating use case here? Are there that many protocols that people are actually using that it is a real chore to add them explicitly, if you know they're safe? Are you confident that in a few years somebody won't add gpt:// as a protocol? Etc.

[robstoll]

I actually totally see your point and usually whitelist is what I use. this time I wasn't able to convince the client otherwise. the client want to be able to use all kind of protocols such as tel, callto, mailto, all kind of ftp etc. the client basically doesn't want to restrict itself to use new protocols in the future -- without the need to adjust the software. So it is rather the opposite, the client would want to use gpt: in the future. The only thing I was able to convince is that javascript needs to be forbidden.

Anyway, I see your concerns and IMO it's OK to keep it that way. Maybe another feature could be helpful which might exist already within jsoup and I did just not find it yet. A way to get the protocol from an href normalized in the sense of all kind of variants of href="javascript:", href=" javascript:", href="java\tscript:" etc. boil down to "javascript"

(side question. if I use addProtocols(..."https") is then something like "//google.com" allowed?)

[jhy]

A way to get the protocol from an href normalized in the sense of all kind of variants of href="javascript:", href=" javascript:", href="java\tscript:" etc. boil down to "javascript"

Yes, node.absUrl(attribute) returns the normalized and absolute URL form, if it can be coerced into one. Some of those forms will not get parsed as a full URL and will return blank, so you could have code that tests for .startswith("javascript") or is .equals(""), and handles the link appropriately.

String html = """
  <a href="  javascript:alert(1)">1</a>
  <a href="javascript:alert(1)">2</a>
  <a href="java\tscript:alert(1)">3</a>
  """;
Document doc = Jsoup.parse(html, "https://example.com/");
Elements links = doc.select("a");
links.forEach(el -> print(el.text() + ": " + el.absUrl("href")));

Gives:

1: 
2: javascript:alert(1)
3: javascript:alert(1)

Note that I'm showing this as an example of using absUrl. I 100% don't recommend trying to defang HTML input by using a blocklist approach. The only sane approach is to use a positive known-good assertion test (as the Cleaner / Safelist does).

The Safelist isSafeTag and isSafeAttribute methods are overridable, so you could extend it to allow any protocol if you want, or perform other extended assertions.

the client basically doesn't want to restrict itself to use new protocols in the future -- without the need to adjust the software

My suggestion would be to make it admin configurable - just pipe in a list of accepted, known safe protocols.

---

if I use addProtocols(..."https") is then something like "//google.com" allowed?

The Safelist.basic already includes https protocols et al. And yes, links that are protocol relative are supported as long as you pass in the baseUri when parsing (either into the clean method or the parse method).

String html = "<a href='//google.com/'>Link</a>";
String clean = Jsoup.clean(html, "https://example.com/", Safelist.basic());
System.out.println(clean);

Produces:

<a href="https://google.com/" rel="nofollow">Link</a>

[robstoll]

My suggestion would be to make it admin configurable - just pipe in a list of accepted, known safe protocols.

was my suggestion as well.
thanks for the suggestions

[jhy]

(The above commit is not related to this issue, and should point to #2074 instead)