sergio masci wrote:

>> Seriously, if sending URLs with forward slashes in the URL path to your web
>> server is a security risk, you definitely should look into your server
>> and/or web application.
> 
> When I use other peoples apps or libraries I don't really want to waste my 
> time testing or debugging them. In some cases I couldn't even if I wanted 
> to (e.g. no time, no source etc).

When you use code from someone else, you either trust it or you test it or
you have someone you trust test it. There are not really any other options.
But what does this have to do with the issue at hand? 

> And it's not just about sending '/' instead of '\', it's about servers AND 
> browsers AND CGIs AND libraries and browsers running scripts embedded in 
> the page AND...

No. It is specifically about a URL with embedded and encoded backslashes
that was sent back with the embedded and encoded backslash converted to a
forward slash. You called that a security risk. I asked you to provide one
scenario where this would be a security risk. So far you didn't provide
one. From my experience designing web applications, I'm quite positive that
this is not a security risk, but I'm also willing to let you convince me --
it just needs a reasonable scenario. 

Of course, browsers and all you mention are security risks in a general
sense, but to what degree browsers are more or less "forgiving" with
non-standard or even wrong HTML has little to do with this. Hackers don't
have to rely on browsers (and probably rarely do) to create their attack
requests. Any security of a web server or web site that relies on any
specific browser behavior is seriously broken right from the start. You can
open an http connection to any web server using a simple telnet terminal
and send to the server what you want -- literally. And people do that.
Don't rely on browser behavior for security; it's irrelevant. Also RFCs are
not that relevant for security; you need to be able to handle safely
everything you possibly may receive, not just standard-conform requests.

It may really be worth your while to go back and look at this specific
issue. Go to Roman's page in question, look at the image hrefs and find out
what you have to do to them to make them load. Then put that into the
context of your (correct) allegation that backslashes in the path of URLs
can present a security risk. (I still think that if they do, that's a
serious bug with the web server, but we all know that bugs are possible.)

> I originally suggested you have a look with google but you dismissed that 
> as if I were trying get you to do something that I could not be bothered 
> to. 

This is not true. I've done my homework. I just have already done that
since a long time ago, so that any search now wouldn't bring up that much
new, and not specifically about this issue. I don't think it would bring up
anything about a forward slash in a URL being a security risk, in a general
sense.

> The fact is I did start looking before I suggested it and came up with 
> too much stuff to look at quickly - hence you want proof you look for it. 
> I'm happy in my inital assessment.

Can you please post at least one link that suggests that this specific
scenario is a security risk for any of the common web servers? If there is
so much stuff, that should be easy. But it seems you just glanced over it,
saw that there are many ways to try to break a web application (but still
few to succeed in that with a good one) -- but this specific issue didn't
necessarily come up in any of them. (Most of the security risks are either
bugs in browsers or web applications "tricked" through arguments they don't
handle properly -- forgotten to properly quote etc. In both there is a
potential for backslashes to create trouble, BTW.)

I'm not saying there are no security risk, and of course when designing a
web application you have to look quite closely at many things -- and one of
them is that any possible URL that your web server may try to handle must
not be a security risk.

But your first comment was that sending backslashes to the server may be a
security risk. While this is true, you consistently seem to miss the point
that the standard-conform behavior in this case involves sending an encoded
backslash back to the server. So if this is a security risk, so be it --
Roman Black wrote that URL into his page, and the standard requires that it
be sent back to the server, right? There's not much a browser can do about
this; the server simply needs to be prepared to handle the request without
creating a security risk. But then, if the server can handle this
straight-forward standard-conform behavior, why should it have a problem
with the more "normal" guessed URL that IE, Opera and possibly others try?
This one does _not_ include a backslash, not encoded and not unencoded --
the encoded backslashes have been replaced by forward slashes.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist