Since the encoded form is not very useful for humans, I'd sooner remove the URL from the page. As you said, we have access_log. As hesitant as I am to suggest Yet Another Directive, I also agree that this change should be configurable and defaulted to 'Off' for 2.4... no preference on trunk. -- Daniel Ruggeri
On April 12, 2018 6:46:35 AM CDT, Eric Covener <[email protected]> wrote: >Scanners at $dayjob (and reports on security@) frequently report that >built-in error documents suffer from non-xss HTML injection from the >request URL. > >Here are a few options to silencing these scans/reports: > >[ ] remove the URL's >[ ] truncate them >[ ] put them in HTML comments >[ ] use CSS to make some <spoiler>-like tag >[ ] use CSS to make the URL non-selectable/copyable >[ ] base64 encode the URL's and surround with some text that says its >only useful for the webserver administrator. >[ ] use r->the_request or r->unparsed_uri or re-encode the decoded URI >so spaces can't be used. > >I was initially leaning towards the CSS options, but after tinkering >with a spoiler tag you still have something tempting to copy/paste. > >Now I am thinking base64 + html comments is the best. This does make >screenshots of error documents kind of useless, but we still have >access logs. > >We could also make all of this configurable so whatever obfuscates the >URL could provide different methods. > >Any other ideas / preferences? > >-- >Eric Covener >[email protected]
