On Fri, 5 Apr 2002, Chris Boget wrote: >> You can never assume that submitted data is benign or untampered. > > Ok, then how do you go about checking to make sure that submitted > data is, in fact, benign and acceptable for your use?
I use two general principles: 1) Rather than trying to rule out bad stuff, instead rule in good stuff. For instance, people often sanitize data with regular expressions that filter out some selected boogeyman characters (quotes, backslashes, semicolons, whatever, depending on context). I prefer to always approach it the other way, thinking of the minimum range of characters that are actually useful in the context, and allow ONLY those. $str = ereg_replace ('[^a-zA-Z]', '', $str); That way it's much less likely that some unanticipated attack will catch me by surprise. Another way of saying this would be to never assume anything about your inputs, and to explicitly mold each input to your program's needs. 2) If you already have a piece of data, try not to get it from the browser. Instead, just get the browser to send you a relative pointer to the appropriate item within your set. If someone is selecting an item from a list you already have in your database, make sure that the 'select' form element sends in the numerical ID of that item rather than its name - you already know the names. The ID can immediately be validated or discarded as bogus, and being a number, it's much safer to work with. In an example that came up today, someone needed to select a file stored on the server, and specify a path. There's no need to specify a full path in a case like that; it should always be relative to the top of the area in which web visitors are able to view files. In this case, you already know the first part of the path and there's no need to have the browser tell you. All you need to know is which subpath the user's selected. Probably all common sense but you never know... miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php