| Issue 86: | THttpSession.CookieMode ignored / Session ID leak | |
| 1 person starred this issue and may be notified of changes. | Back to list |
What steps will reproduce the problem?
1. Create a Prado application
2. Add <module class="THttpSession" ... CookieMode="Only" ... /> to
application.xml
3. Create a session in the application, and observe the links generated
with THttpRequest::constructUrl() in the resulting page
What is the expected output? What do you see instead?
With THttpSession.CookieMode set to Only there should be no session IDs
applied to URLs under no circumstances. However, Prado does in fact append
the session IDs to the URL even in this case, provided, the original
php.ini settings don't prohibit that.
What version of the product are you using? On what operating system?
Prado 3.1.3
Please provide any additional information below.
The problem arises from the fact, that THttpRequest determines whether it
should apply SIDs to the resulting URLs _before_ the session module is
instantiated and the configuration variables from application.xml applied
to it. Therefore, it always reads the SID preference settings stored in
the php.ini file on the server, and never sees the potential updates to
those settings for the session (made by ini_set('session.xxx')), which is
also made by THttpSession:setCookieMode(). However, when the latter
happens, THttpRequest is already instantiated and has checked the
session.xxx SID preference ini variables, and stored the result in
THttpRequest::$_cookieOnly, thus making THttpRequest::constructUrl()
append session IDs even when it is prohibited by the application.xml
settings.
This is not only a bug, but also a security vulnerability, because it
enables the leaking of session IDs through HTTP Referer fields, browser
history and URL logs.
|
|
,
Dec 10, 2008
Also THttpSession allows conflicting settings to be set both in application.xml and also at run-time. Namely, if you have both UseTransparentSessionID="true" and CookieMode="Only" set in the application.xml, then both of them get applied (without changing the other property to some plausible one), even tho they contradict each other. Depending on the order of the processing either setting CookieMode=Only should clear UseTransparentSessionID to false, or setting UseTransparentSessionID=True should change CookieMode from Only to Allowed - even though I think CookieMode should always take precedence over UseTransparentSessionID (since that reflects only a sub- behaviour for a specific setting of CookieMode), and trying to set UseTransparentSessionID to true while CookieMode=Only should emit a warning or a fatal exception. This is also neccessary, because PHP will still do transparent session ID append to the URLs if session.use_only_cookies=1, but also session.use_trans_sid=1. Thanks to the latter one (and the bug specified above) if you have both UseTransparentSessionID="true" and CookieMode="Only" set in the application.xml then you will get URLs with duplicate(!) session IDs applied to them (one ID applied by the THttpSession::constructUrl() missing out on the fact that CookieMode has been set to "Only", and the second by PHP's own transparent URL-altering session manager, which was enabled by setting UseTransparentSessionID), unless URL altering for session IDs is disabled by default in php.ini (in which case only the PHP transparent processor will apply the URL, even though that will still lead to session ID leaks, which is unexpected and undesired if you have CookieMode="Only" set). |
|
,
Jan 11, 2009
Move to 3.1.5.
Labels: Milestone-3.1.5
|
|
,
May 29, 2009
(No comment was entered for this change.)
Labels: -Milestone-3.1.5 Milestone-3.1.6
|
|
,
Jul 22, 2009
Move to 3.1.7
Labels: Milestone-3.1.7
|
|
 Sign in to add a comment
|
