사용자 세션 핸들러
One thing I do is encrypt everything server side that passes into my $_SESSION array. This might be overkill, but if anyone can see or gets access to my $_SESSION array it'll be encrypted gibberish and my system won't process anything coming from the $_SESSION array unless it matches my encryption key.
세션과 보안
외부 링크: » 세션 고정
세션 모듈은 세션에 저장한 정보가 세션을 생성한 사용자만 볼 수 있다는 보장을 하지 않습니다. 세션에 할당한 값을 기반으로 세션의 무결성을 보호할 추가적인 측정을 취해야 합니다.
세션으로 운반되는 데이터의 중요성을 평가하고 추가적인 보호를 적용해야 합니다 -- 이는 비용을 발생하며, 사용자 편의를 감소합니다. 예를 들어, 간단한 사회적 엔지니어링 전략에서 사용자를 보호하려면, session.use_only_cookies를 활성화합니다. 이 경우, 사용자 측에서 쿠키를 무조건 활성화해야 하며, 그렇지 않으면 세션이 작동하지 않습니다.
존재하는 세션 id가 다른 사람에게 유출되는 여러 방법이 있습니다. 유출된 세션 id는 다른 사람이 지정한 id에 할당된 자원에 접근할 수 있게 합니다. 먼저, 세션 id를 운반하는 URL입니다. 외부 사이트에 링크할 때, 세션 id를 포함하는 URL은 외부 사이트의 referrer 기록에 남을 수 있습니다. 두번째, 더 활동적인 공격자는 네트워크 트래픽을 감시할 수 있습니다. 암호화되지 않으면, 세션 id는 네트워크에 일반 텍스트로 떠다닙니다. 이에 대한 해결책은 SSL을 구현하여 사용자에게 강제하는 것입니다.
add a note
User Contributed Notes
세션과 보안
saamde at gmail dot com
11-Jun-2010 06:27
bmearns at ieee dot org
27-Jan-2009 11:41
In addition to ip-address binding not always being effective, it can also prevent users connecting through a proxy-pool from even being able to use your site. In such a scenario, a person's IP address may very well change with every access.
If you're handling anything remotely secure, the only safe option is HTTPS. If the data doesn't need to be that secure, than you should not allow a high-jacked session to do too much damage. Basically, don't assume that a person really is who they pretend to be just because the session says a person authenticated with a username and password: it may have been that person who logged in, but that doesn't mean it's still that person. So if you're going to do something like change passwords or something, require them to authenticate again on the same form.
Of course this needs to be done in some secure way, as well, so that the password is not just floating over the network. A good way to do this is sending a nonce (number-used-once) along with the form and some javascript to concatenate the nonce to the password, then perform a cryptographic hash of the combined string. The resulting valid-once "password" should then be sent instead of the plain text password. To be effective, you also need to prevent people from using the form if they don't have JavaScript enabled. You can do this by disabling the form fields in HTML, then re-enabling them in JavaScript.
justin at fatbird dot ca
18-Jan-2009 06:56
IP checking is a sometimes useful feature with two limitations that are important to be aware of:
1. Anyone surfing behind a proxy (e.g., someone at work) will provide the proxy's IP, not his own. Session ID replay attacks will not be prevented by IP checking for an attacker on the user's side of the proxy.
2. If the PHP application is behind a reverse proxy, the reverse proxy's IP address will be the only request IP seen by PHP, so IP checking is useless.
Anurag Jain
12-Dec-2008 09:28
Websites which have sensitive information need to be patched to ensure its not exploited because of session issues.
In earlier versions of apache cookie reliability was not assumed and hence the default method was always using url-rewrite which meant every url link, every form submission etc would have a PHPSESSID=<sessionid> passed along to inform the server about the active session. New versions have turned this off using
session.use_trans_sid = 0
in the /etc/php5/apache2/php.ini file.
Reasons?
Well one might safe the offline page as a bookmark or pass the link across to others not realizing that the session id information is also sent. So someone who quickly accesses these pages could possible get logged on, this was also true wrt search engines, and I guess in some cases it being seen as duplicate content as the same page will have a different session id every time the robots scan the website.
But having this set does not mean you are protected. Let me explain.
What prevents me from presetting the session id! Assume there is a banking site www.example.com which has a login screen at www.example.com/login.php
I can send you can email with a link to the bank site as http://www.example.com/login.php?PHPSESSID=12345
When you click on the link it presents the session id as 12345 rather then asking the server to generate a new one. This is called session fixation. Keep in mind even with session.use_trans_sid = 0 this will work as this sets it only not to use url-rewrite. To prevent this altogether set session.use_only_cookies = 1 which ensures that only cookies will be used, but this could cause problems when dealing with transaction which involve switch sites, i.e. siteA forwards to site B for payment which forwards to siteA for thank you, in which case a phpsessid inform might be used to revive the old session.
A good approach would always be to at the login screen and immediately post login to force a new session id generated using random numbers
session_start();
$newsessid = somerandomnumberfunction();
session_id($newsessid);
you can also use session_regenerate_id() function to generate a new id
session_start();
session_regenerate_id();
Also its always good to ensure every valid session is checked against an ip. One good method is to store the session id and remote ip information in a table, or better store the ip as a session variable itself, once the user logs in and ensure that this is continued for remaining pages for security. This ofcourse wont work when users use the same office or shared network as the ip to the outside world is the same.
https is always a good idea for sensitive sites, but keeping it persistent for all pages which use session is important if you really want a foolproof system else anyone can always sniff your packets.
So to quickly go through the bits
- set session.use_trans_sid = 0 in /etc/php5/apache2/php.ini file.
- Ensure you always use a new self generated session id on successful login attempt.
- Try setting session.use_only_cookies = 1 and check if all works fine.
- Use https throughout to ensure no one can sniff your session id.
- Store session id, remote IP information and compare for successive pages
JonathanFeller at NOSPAMgmx dot ch
27-Oct-2008 12:22
Perhaps, you would also like to timeout a session after some idle time. I noticed that session.gc_maxlifetime is not suitable for this. So I used this code to do the job:
<?php
if (!isset($_SESSION['timeout_idle'])) {
$_SESSION['timeout_idle'] = time() + MAX_IDLE_TIME;
} else {
if ($_SESSION['timeout_idle'] < time()) {
//destroy session
} else {
$_SESSION['timeout_idle'] = time() + MAX_IDLE_TIME;
}
}
?>
Olle Bergkvist
21-Oct-2008 03:47
It is also quite important to (somehow) make sure that the cookies you're setting (including the session cookie) is only visible to the site that created it (or to other trusted sites only).
If the cookie's path is set to '/' (the whole domain), then any website on the same domain (might be lots of websites) _will_ get the cookie through HTTP headers and could possibly hijack your session.
One slightly acceptable protection would be to lock a session to one IP adress.