Developing a secure PHP login and authentication strategy

前端 未结 8 1578
借酒劲吻你
借酒劲吻你 2020-12-13 03:05

I\'m developing a login and authentication system for a new PHP site and have been reading up on the various attacks and vulnerabilities. However, it\'s a bit confusing, so

8条回答
  •  醉酒成梦
    2020-12-13 03:50

    The scheme seems needlessly complex in a few ways, in that the added complexity doesn't gain you anything in functionality or security.

    1. Any data that's sent by the browser (e.g. cookies, User-agent) is spoofable. Checking User-agent will only help when the attacker is behind the same NAT as the spoofed user and the attacker is using a different browser but doesn't think to change the User-agent.
    2. Sessions store the session id client-side using either cookies or a URL query parameter. If you want to extend the life of a session, use session_set_cookie_params to keep the session cookie around longer.

    The User-agent isn't secret data, so hashing it is unecessary.

    The attacks that session cookie+checking remote IP won't catch are:

    1. the attacker is behind the same NAT as the user
    2. Blind injection attacks, where the attacker spoofs the user's IP. Despite being write-only, these can still do some damage.
    3. attacks that make use of the user's own browser, such as cross-site request forgery (CSRF).

    2) could be prevented if you can work out a way of sending a challenge to the user's browser, which must be responded to before completing the request, but this is tricky when you didn't write the client. With AJAX it can be done. 3) (as noted by MindStalker) can be prevented by checking the Referer header, which works because CSRF attacks don't have the ability to affect arbitrary headers, and XMLHttpRequest shouldn't allow the Referer header to be set (as per the W3C standard, though implementations might not be compliant). With iframes, it might be possible to get around a Referer check. Also, the Referer header might be blocked client-side.

提交回复
热议问题