You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2018/04/12 11:46:35 UTC
URL's in error pages
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
covener@gmail.com
Re: URL's in error pages
Posted by Jim Jagielski <ji...@jaguNET.com>.
In order of pref I'd say:
o base64 encode the URL's and surround with some text that says its only useful for the webserver administrator.
o remove the URLs
> On Apr 12, 2018, at 7:46 AM, Eric Covener <co...@gmail.com> 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
> covener@gmail.com
Re: URL's in error pages
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 12, 2018 at 1:14 PM, Ruediger Pluem <rp...@apache.org> wrote:
>
> From an ops point of view:
>
> You do not always have an address bar visible with the affected URL. Think of iframes or pop ups without address bars
> and people are bad in providing the exact point of time when the issue happened and hence the access logs are a tedious
> business here on a busy server as a source for determining the issue. So I am for re-encode the decoded URI so spaces
> can't be used.
> I don't like making admins life hard because of not so smart tools or people reporting to security :-)
From an ops point of view...
see access log. I don't see this information as helpful for admin/ops.
Perhaps useful for content creators with no such access. But I'd expect
the vast majority of these are 1) ignored and 2) intentional/malicious
probes.
Re: URL's in error pages
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/12/2018 02:08 PM, Yann Ylavic wrote:
> On Thu, Apr 12, 2018 at 1:46 PM, Eric Covener <co...@gmail.com> wrote:
>>
>> Here are a few options to silencing these scans/reports:
>>
> [X] remove the URL's
>
> The URL is already in the address bar if any screenshot/report matters, IMHO.
>
From an ops point of view:
You do not always have an address bar visible with the affected URL. Think of iframes or pop ups without address bars
and people are bad in providing the exact point of time when the issue happened and hence the access logs are a tedious
business here on a busy server as a source for determining the issue. So I am for re-encode the decoded URI so spaces
can't be used.
I don't like making admins life hard because of not so smart tools or people reporting to security :-)
Regards
Rüdiger
Re: URL's in error pages
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Apr 12, 2018 at 1:46 PM, Eric Covener <co...@gmail.com> wrote:
>
> Here are a few options to silencing these scans/reports:
>
[X] remove the URL's
The URL is already in the address bar if any screenshot/report matters, IMHO.
Re: URL's in error pages
Posted by Luca Toscano <to...@gmail.com>.
2018-04-12 23:52 GMT+02:00 Yann Ylavic <yl...@gmail.com>:
> On Thu, Apr 12, 2018 at 11:18 PM, Eric Covener <co...@gmail.com> wrote:
> > On Thu, Apr 12, 2018 at 8:33 AM, Daniel Ruggeri <DR...@primary.net>
> wrote:
> >> 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.
> >
> > I had intended opt-out for 2.4 :/
> >
> > Others?
>
> +1 for opt-out, I'm fine with any encoding (as well as remove) by default
> too.
>
+1 for opt-out in 2.4 and remove for trunk!
Luca
Re: URL's in error pages
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Apr 12, 2018 at 11:18 PM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Apr 12, 2018 at 8:33 AM, Daniel Ruggeri <DR...@primary.net> wrote:
>> 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.
>
> I had intended opt-out for 2.4 :/
>
> Others?
+1 for opt-out, I'm fine with any encoding (as well as remove) by default too.
Re: URL's in error pages
Posted by Eric Covener <co...@gmail.com>.
On Thu, Apr 12, 2018 at 8:33 AM, Daniel Ruggeri <DR...@primary.net> wrote:
> 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.
I had intended opt-out for 2.4 :/
Others?
Re: URL's in error pages
Posted by Daniel Ruggeri <DR...@primary.net>.
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 <co...@gmail.com> 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
>covener@gmail.com
Re: URL's in error pages
Posted by Nick Kew <ni...@apache.org>.
> On 12 Apr 2018, at 12:46, Eric Covener <co...@gmail.com> 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.
Deja vu there. I’m sure we’ve fixed some such, and done a grep on
the errordocs repo. I guess the continuing flow comes from the
multiplicity of ways we might generate an error page.
> Here are a few options to silencing these scans/reports:
One more: insert an output filter when generating an error page.
Escape URLs and scripts to plain text and highlight them.
OK, it’s an overhead, but error pages are small.
A sysop could of course have the option to disable it.
—
Nick Kew