[TriLUG] I want to build an HTTP Proxy for Home
Aaron S. Joyner
aaron at joyner.ws
Mon Aug 2 15:31:10 EDT 2004
Mike Johnson wrote:
> <>Yes. The null byte has to occur in the path on the server, not in the
> name itself. The specific instance I was looking into was bypassing
> wildcard blocks. For instance, a filter denying access to a URL with
> the word 'nude' in the path:
> http://www.example.com/nude.jpg
> That was blocked by the wildcard in place. However:
> http://www.example.com/%00nude.jpg
> would allow me access to the naughty jpg.
>
>Do y'all use wildcard filters, such as the example I gave above? If so,
>is the example I gave above blocked?
>
>
First off: We don't use many 'expression' based filters (regex filters),
as squidGuard likes to call them - because we've found they can cause a
lot of false positives if not very carefully written. And if tightly
controlled, they don't match very much that the domain and url based
filters do not.
So I had to craft a bit of a synthetic example, but yes squidGuard is
still vulnerable to this type of attack. Observe that
http://example.com/ourregexfilter is blocked, but
http://example.com/%00ourregexfilter is not blocked and returns a 404
(because obviously no such file exists at example.com).
>Please understand that I was not trying to say 'squidguard is useless
>because it can't protect against X'. I was truely asking if there was a
>solution for the problem. I am not implementing this for myself, but
>helping someone else. And yes, I'm being deliberatly vague about the
>environment I'm dealing with.
>
>Mike
>
>
Since squidGuard uses the ASCII null internally to determine the end of
it's strings (it's written in C), a work around would be tricky, at
best. I'm looking it over and pondering it w/ a friend who does more C
than I do, and I'll post something to the list if I come up w/ a silver
bullet.
Aaron S. Joyner
More information about the TriLUG
mailing list