--- "Chris W. Parker" <[EMAIL PROTECTED]> wrote: > My original thinking was that I wouldn't be using the session id as I > would the unique identifier because of point #2 (you shouldn't store the > session id on the client). But since you point out that storing the > session id is a necessary evil (if I understand you correctly) I see > that it would be ok to forget about generating another unique identifier > and just use the session id instead.
Yes, I consider it a necessary evil. The propogation of the session identifier is the greatest challenge we face when trying to provide a secure session management mechanism. > Well then let met ask this: Is an SSL login option something you > personally setup by default as part of your regular login routine or > would you only create one if the client requested/had a need for it? Not to avoid the question, but it really depends. :-) If someone is logging in to gain access to some technical documentation that I don't want to be public, and if their password was generated by my system (so there is no risk of it being important data to the user), then I would probably not bother with SSL. The risk (unauthorized access to a document) isn't too big of a deal. This is all based on my (or the client's) perception of the risk involved. Greater risk warrants more expensive safeguards. If the customer is logging in to their online banking system, there had better be some SSL. :-) > > I would say any data that originates from any external source should > > be treated as tainted data until it can be properly verified via data > > filtering. > > Ok so then that means I forgot about $_COOKIE (which you mention a > little later in your email). What about data you obtain via an XML feed? What about an email message you check with a Web-based mail client? It might be best to not try and definitely declare what counts as foreign data, because it's a sort of "everything else" type of thing. If it doesn't originate within the PHP script itself, it is foreign. > In your article from php|arch (http://www.phparch.com/sample.php?mid=16) > the first of your 5 points in protecting against XSS is to use > htmlentities(), strip_tags(), and utf8_decode() when filtering your > data. Would using all three of these protect against everything? I mention using functions like those to help with your filtering logic. The point is to try your best to use native PHP functions whenever possible. When you write your own, you have to factor in the possibility of an error creating a security vulnerability. This is certainly possible with the native functions, but it is much less likely. The more important point is to only allow data that you feel is safe rather than to try and prevent data you feel is unsafe. You mentioned this in an earlier email. > If not, can you give an example of what data can be passed, put through > those filtering functions, and still cause problems? (For understanding > sake.) Hmmm, not off the top of my head. However, I think the important perspective is to try and avoid battles of creativity. If you place yourself in such a battle with every potential attacker in the world, you will probably lose. Yes, example exploits are fantastic for demonstrating the need for certain preventive measures, but don't take the approach of trying to prevent specific exploits. Adopting secure programming practices is much safer and can prevent attacks you may have not even thought of. Hope that helps. Chris ===== My Blog http://shiflett.org/ HTTP Developer's Handbook http://httphandbook.org/ RAMP Training Courses http://www.nyphp.org/ramp -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
