HTML insertion / potential XSS issue in gopher.

[zcrayfish]

Greetings, if felinks views a gopher resource (e.g. elinks gopher://gopher.zcrayfish.soy/1/irc/test/ ), some characters in the display string such as less-than <, greater-than >, and ampersand & are not properly converted to HTML entities... As a result a malicious gopher server allows felinks to render a page with arbitrary HTML inserted

Additionally, felinks suffers from the same character encoding issue if the -source option is used; pages are not saved with the reserved characters converted to HTML entities from the display string nor the selector field.

[rkd77]

Hi, what other browsers do with such urls?

-source is for 1:1 content, I don't think it is a good idea to change this behavior.

[zcrayfish]

felinks is using what looks to be like an outdated fork of libwww (upstream is unmaintained) to change gopher to HTML, which it then displays and renders (or dumps with the -source option)... Any <, >, and & characters received in the display string field over gopher must be converted to HTML entities. Likewise when the source option is used both the display string and the selector fields containing the said reserved characters must be converted to HTML entities.

As it stands, felinks fails to convert these characters to HTML entities, which means that if the selector is named, for example. <b>This shouldn't be bold text</b>, felinks treats it as HTML instead of just text. (and renders the example in bold)

The -source option does not dump the raw gophermap, it dumps the converted HTML. (this is the same behavior as similar libwww-based browsers, such as lynx... lynx' fork of libwww fixed this issue already)

[rkd77]

If in gopher document replace <javascript> by <script>, then popup was shown (in elinks with SpiderMonkey). < >, & were encoded in plain text. I don't know what to do with links, but they seem to be safe.

[zcrayfish]

From what I can tell, your commits have fully fixed the issues. 👍👍