[squid-users] Squid and ufdbGuard, display blocked URL on client browser address bar

[Amos Jeffries]

On 10/07/2015 10:31 p.m., Marcus Kool wrote:
> 
> 
> On 07/10/2015 12:54 AM, Amos Jeffries wrote:
>> On 10/07/2015 9:51 a.m., David Touzeau wrote:
>>> Hi ikna
>>>
>>> This can be done, but you need to forget the ufdbgclient and create
>>> yourself a new one that is able to connect to the ufdbguard server in
>>> order to get ufdbguard results.
>>> In this case, you have with your code to replace the  OK status=302
>>> url="" sent by ufdbguard server by OK rewrite-url=""
>>>
>>> Then the address bar will be not changed.
>>>
>>> If you need an example, you will find it after installing this open
>>> source software :
>>> http://sourceforge.net/projects/artica-squid/files/ISO/proxy-appliances/
>>>
>>
>> Thats not what he is asking for though.
>>
>> He is asking to change the page *content*. By only altering the URL
>> request-line on the received message.
>>
>> The answer is to change what the http://10.1.1.142/sgerror.php script
>> does. So it displays the url= parameter instead of its own full URL.
> 
> Ikna contacted me yesterday and I have sent the same answer yesterday
> directly without notifying the list.
> 
> The issue is basically that URL redirectors usually send an HTML 302
> redirection code to redirect a blocked URL to an error page.
> squidGuard and ufdbGuard use by default the 302 code.
> 
> Ikna has, however, a 404 code which behaves differrent and likes to know
> how to configure ufdbGuard to send a 404 code.  This is the same as with
> squidGuard:
>    redirect "404:<some-URL>"


Squid only accepts RFC defined redirection status codes for redirection
(301, 302, 303, 307, 308). Any other status gets passed through as if
the helper indicated no-change.

In HTTP 4xx messages have an optional body/payload. A Location:<url>
header has no defined meaning and is ignored by browsers.

So the equivalent deny_info uses 4xx:file where the file will be sent as
error message payload.

> 
>> IMPORTANT:  doing that was a XSS / open-proxy vulnerability that
>> squidguard had. Its not a good idea to just dump out query-string data
>> delivered by the client as body content. It needs to be sanitized
>> properly first.
> 
> ufdbGuard sends a sanitised URL so in this case dumping out the value of
> the
> url= parameter is safe.
> 

I'm speaking about the URL that comes back from the client after the
redirect 3xx has happened. The script should not assume that it is the
same as the sanitized URL the helper produced.

Amos