| Re: sessions causing refreshing not to work [message #178341 is a reply to message #178332] |
Wed, 06 June 2012 19:50   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
Peter H. Coffin wrote:
> On Tue, 05 Jun 2012 20:52:23 +0200, Thomas 'PointedEars' Lahn wrote:
>> Peter H. Coffin wrote:
>>> On Tue, 05 Jun 2012 06:46:28 +0200, Thomas 'PointedEars' Lahn wrote:
>>>> > Set session.use_trans_sid, unset session.use_cookie, don't forget to
>>>> > grab the session ID out of the $_GET array for every page load. Yes,
>>>> > your URLs will be ugly, and it'll be not impossible for someone to end
>>>> > up screwing things somehow with URL bookmarking or sharing.
>>>>
>>>> More importantly, it will be a security hole to be exploited:
>>>>
>>>> < https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Manage_Sessi on_ID_as_Any_Other_User_Input>
>>>
>>> Sorry, I refuse to think of what *should be* expected behavior
>>
>> It is by no means expected behavior.
>
> Sure it is.
I am afraid that either I am misunderstanding your position or you do not
know what you are arguing for or against.
> "DO NOT TRUST THE CLIENT".
That is beside the point.
>>> as a "security hole". People can manipulate cookie values almost as
>>> easily
>>
>> Because of that, HTTP-only cookies have been invented.
>
> DO NOT TRUST THE CLIENT. That only *helps* mitigate third-party attacks.
DO NOT SHOUT AROUND HERE. If you read my posting more carefully, you will
realize that by no means I am saying that we should trust the client.
However, different approaches result in different risk assessments. The
risk of transmitting a session ID accidentally is greater when it is part of
the URI. Therefore, it is *safer* (not: safe) to use HTTP-only cookies for
that than a URI component.
On a side note, storing the session ID in cookies instead of URIs also is
more search-engine friendly. The resulting document becomes considerably
smaller (the more links, the smaller), and no additional measures have to be
applied that the search engine would not index those URIs.
>>> and they're no more trustworthy than a $_GET result.
>>
>> Correct, but by contrast they are not stored unencrypted in the user's
>> history, cannot be accidentally transmitted, and so on.
>
> If the site's properly policing client input, all of those things are
> dealt with, from the site's perspective.
Intrinsically, they cannot be dealt with completely.
>>> This doesn't even bear discussing separately, and doing so only ends up
>>> further complicating an issue that enough people have trouble learning
>>> into their bones in the first place.
>>
>> You are wrong.
>
> Heh. Succinct, but about as useful as "You are a doody-head".
That paragraph of yours constituted a fallacy. There was nothing else to
reply while staying polite and saving free-time for more important problems.
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom(at)94(dot)75(dot)214(dot)39>
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]