matt... 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... how would i as a server app be able to know this. if i knew, i might refuse to deal with this client app, and tell the user that the client is a fraud! this is crucial if you're really going to have a secure system between server and client. as far as i can tell, most people take your approach and don't even think about it... if msoft had a way of identifying that the app is indeed a msoft IE/app/client, i might as a server choose to talk to it because i 'trust' it... this issue has nothing to do with HTTP protocols. 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... from my $0.02 worth, more thought needs to be focused on this issue as well... -bruce -----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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
