Chris Shiflett <mailto:[EMAIL PROTECTED]> on Monday, November 10, 2003 8:21 PM said:
> It would probably need to be either very short or very long. Yes, I would prefer very long so as to be as complete as possible. >> 2. The session id should not be stored on the client. > > I'm not sure I agree with this. Can you elaborate? Though it can be > argued that sending the session identifier is a security risk, it is > the one that is necessary for state (and therefore session) > management. Elaborate? Well I was just thinking that this could somehow be used to impersonate someone. How or why I'm not really sure. That's why I wrote the email instead of hauling off to write an article (most of which would be misinformed without having a better understanding). >> 3. A unique identifier should be created for the user when the user >> logs in. This unique identifier should not be based on the user's >> name, password, id, or session id. > > What is the difference between the session and unique identifiers? Well I guess there isn't one now that you've asked that question. 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. >> 6. The login page should be done over HTTPS. (Sounds like a good idea >> but is this necessary? Is this killing a mouse with a jackhammer?) > > It depends on the amount of risk that is acceptable. Requests for > non-SSL URLs are sent in the clear and are vulnerable to things such > as sniffing, man in the middle attacks, and other similar attacks. > > Yahoo offers the user a choice between SSL and non-SSL logins, and > they default to non-SSL. Some sites describe the choice as secure > versus fast. 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? >> 7. All input received via $_POST and/or $_GET should be thoroughly >> filtered > > 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). >> 10. Use htmlentities() on data that will be put through a SQL query >> to prevent XSS attacks. http://php.net/htmlentities > > This is a nice suggestion. While htmlentities() cannot be guaranteed > to defend against all XSS vulnerabilities, I would bet that most XSS > vulnerabilities are due to a complete lack of filtering logic. 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? 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.) > Hope that helps. Sure does, thanks. Chris. -- Don't like reformatting your Outlook replies? Now there's relief! http://home.in.tum.de/~jain/software/outlook-quotefix/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
