Override URL encoding when serializing results to HTML

[spassarop]

When serializing results to HTML, URLs are not being encoded when they are on HTML attributes. This could lead to mistakes when validating values. If URLs are HTML-encoded then they would work when rendered and potentially malicious payloads will fail after encoding.

A test case was added (for DOM and SAX) testing this problem.

[davewichers]

Is this method supposed to ALWAYS return an empty string? Seems strange to me.

[spassarop]

It is. On the HTMLSerializer, that function is supposed to returned the URL with escaped quotes and nothing else. I'm reusing printEscaped which does the encoding we want and internally "prints" the result in the XML that is being built. If I return a non-empty string, that string is also "printed" because the call to escapeURI is something like print(escapeURI()). I mentioned this on our emails, it may be explained better there.

[davewichers]

Can you add all the necessary explanation to this code as comments so it stands alone? Otherwise future reviewers will have the same concerns.

[spassarop]

I've done a separate PR with the comment. I tried to push directly to 1.6.4 and had git issues, but I'm kinda in a hurry and wanted to have this solved fast.

[nikowitt]

But doesn't this break links having a query string like

<a href="https://server.com?param=a&param=b">Link</a>
as the server might not know how to handle the query string like
param=a&param=b?

[spassarop]

@nikowitt - Browsers know how to handle it. I've made a simple test:

1. Use AntiSamy to process <a href="http://localhost:9000?a=1&b=2">Some Link</a>. The result was <a href="http://localhost:9000?a=1&amp;b=2" rel="nofollow">Some Link</a>.
2. Created an HTML file with only that link.
3. Started a Python server on port 9000.
4. Opened the file and clicked on the link, on Chrome, Firefox and Edge.

All used the link correctly:

Furthermore, when inspecting the DOM and selecting "Edit as HTML", the original source is the same:

If inspecting without editing, the URL is seen without &. So the server does not know about this encoding stuff at all. Always regarding HTML rendered by browsers of course.

[nikowitt]

I see. I have done my (failing) tests by opening the URL directly, not by using a rendered link. Thanks for pointing this out, we will do some additional testing.

[davewichers]

Note: This pull request for AntiSamy 1.6.4, fixes the issue that has been assigned: CVE-2021-35043.