* "bruce" <bedouglas@xxxxxxxxxxxxx>: > 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@xxxxxxxxxx] > Sent: Monday, June 20, 2005 1:23 PM > To: php-general@xxxxxxxxxxxxx > Subject: Re: security question...?? > > > * "bruce" <bedouglas@xxxxxxxxxxxxx>: >> 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@xxxxxxxxxx | http://vermontbotanical.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
