At 00:07 25/04/01 -0400, Paul D. Robertson wrote:
>On Tue, 24 Apr 2001, mouss wrote:
>
> > The correct way to do it is something like this:
> > assume you want to match a URL "u" with a balacklisted URL "b".
> > then first decompose each of them to the base components:
> > scheme (http, ftp, ...)
>
>I believe the spec. has a user identification thing in here.
yes, you can specify username:passwd before the server:
http://username:passwd@site:port/path
sure a filter should check that.
> It's
>important because it's extremely poorly seperated and can contain
>anything- it makes things like http://www.microsoft.com@realURL possible
>for some sets of browsers- the ultimate in URLized social engineering :(
you're right. filters should check this and not let it go.
>(I'm not sure the seperator is an at symbol, but I'm just not in a good
>enough mood to trapse through the HTTP spec. again.)
I confirm: it is an at symbol.
>I believe you've missed the %dd conversion step, which can be
>per-character. That's what makes HTTP so much fun and pattern matching on
>URIs so much pain...
I talked about that, but only in the path "section". you're right that it
applies to the whole URI.
>No doubt in part caused by protocol design specifications that don't take
>into account downstream usage issues. HTTP *sucks* as a protocol- no
>length restrictions, no code normalizaitons, no structure worth
>mentioning, poor tokenization....
I agree that http is a deceiving protocol, but I don't think the real
reason is that.
I think the human nature makes that people think they know instead of
searching.
people think they're good, unless evidence shows the converse. also, companies
still take the same way: sell yesterday, code today, design tomorrow...
>You know, I bet that everyone on the list passes HTTP and probably no more
>than three people have even done a cursorary protocol evaluation on it. I
>wonder who the third person is?
Today, http should be though of as a TCP replacement. everything goes in:)
>When you look at specs like HTTP and FTP, then the list of protocols
>"supported" by most firewalls it's not comforting.
A paradox is that
- firewall vendors know what security is and what should be done for security
- most customers don't know what security is, but know what services and
features they want.
but since FW vendors need customers, they simply do what the latter want. So
we're finally living in a world where mediocrity is ok if it goes with the
money:)
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
