|
|
Posted by Matthew Weier O'Phinney on 06/21/05 06:18
* "bruce" <bedouglas@earthlink.net>:
> you miss what i'm saying, and what my point is. i as a server communicate
> with clients. under normal situations, the client is used to communicate
> back to the server. but what if someone created a 'client' that looked like
> IE, except this client was really sending the information entered by the
> user to who knows where...
I can see what you're saying here. But I can already see some other
issues that make this hard, if not impossible, to deal with:
* Proxy server between client and server. If there's a proxy server
between the client and server, it's possible the proxy server is
munging the browser agent strings. If that's the case, we simply will
not know for sure what the browser is -- or even necessarily what IP
from which a request originates.
* Many browsers allow the user to set the browser agent string. Look
through your server logs some time -- you'll see some incredibly
creative browser strings in there. This ability also allows one
browser to spoof as another. For instance, I know in the past that
Opera would allow you to select on the fly whether you wanted the
browser agent to be reported as IE (to get IE-specific CSS files).
* Who's going to keep the database of 'trusted' client browsers? You
mention MS IE as one such... but I sure as hell wouldn't place it on
*my* list. And, knowing how easy it is to spoof browser agent strings,
I wouldn't place Firefox of Opera on there either... oops! there goes
over 98% of my browser share! Limiting based on browser directly
contradicts the purpose of the web. More on that below.
<snip>
> this issue has nothing to do with HTTP protocols.
Maybe I'm seeing this entirely differently than you, but I think it's
*all* about HTTP protocols.
Web applications are written on top of HTTP, and HTTP has a very fluid
specification, because from the very beginning HTTP was designed to
deliver HTML documents in an agnostic way -- so that they may be read
from text-based browsers, graphical browsers, browsers on TVs, etc. The
fundamental building block, then is HTTP, which is a series of stateless
transactions. The servers and clients speak across this protocol, and
in between transactions have no inkling of the others' existence.
Furthermore, an HTTP server should not care what makes the request, so
long as it is well formed; if it is well formed, it returns a string (a
document). That's all it's supposed to do.
You mention above "except this client was really sending the information
entered by the user to who knows where". If they're not getting to my
site, or the request is getting redirected elsewhere, I can't do
anything about the situation; my server knows nothing about it. If they
are, there are a number of ways to maintain some awareness of particular
users between requests; sessions and cookies come to mind. It's very
easy to create server-side tags in sessions to prevent session hijacking
very much like you describe (using things like dates, browser agent
strings (looking for consistency between requests), etc.).
> hope this provides more clarification as to what i'm dealing with, and why
> it should be important to people who write secure apps/sites/systems. if you
> only focus on the server, you can't really say your service is really
> secure...
On the whole, I'm less worried about hijacked client browsers than I am
about zombie networks making repeated requests to my systems (DDOS on
port 80). I can use the tools of HTTP and PHP to track users across
requests. I personally think these are plenty powerful -- and help me
provide a service that can be agnostic of the device using it.
I understand your concerns, but they come more from a world where
environments can be strictly controlled, and the web ain't one of them.
> -----Original Message-----
> From: Matthew Weier O'Phinney [mailto:matthew@garden.org]
> Sent: Monday, June 20, 2005 1:23 PM
> To: php-general@lists.php.net
> Subject: [PHP] Re: security question...??
>
>
> * "bruce" <bedouglas@earthlink.net>:
>> a number of you write apache/web/server apps that deal with secure
>> information.. in doing some research it occured to me that a potential
> weak
>> link is on the client side, regarding the browser? how many of you
> actually
>> attempt to verify that the browser being used by the client is indeed a
>> legitimate (non-hacked) browser??
> >
>> or is there even a way to do this?
> >
>> or should i just go back to sleep..??
>
> What's the point?
>
> The reason I ask is that (1) it shouldn't matter HOW the HTTP request is
> initiated. What *should* matter is that the page handles the request
> gracefully and returns something (HTTP headers only, or headers + page)
> as a result. The request is simply a TCP transmission, nothing more,
> nothing less.
>
> (2) What is done with the page once received by the client shouldn't be
> an issue, either. Browsers may render the page however they choose; HTML
> is meant to give hints as to how to perform layout, but in the end, it's
> just a huge string.
>
> Is there some specific issue you're thinking about?
--
Matthew Weier O'Phinney | WEBSITES:
Webmaster and IT Specialist | http://www.garden.org
National Gardening Association | http://www.kidsgardening.com
802-863-5251 x156 | http://nationalgardenmonth.org
mailto:matthew@garden.org | http://vermontbotanical.org
Navigation:
[Reply to this message]
|