| sessions causing refreshing not to work [message #178315] |
Sun, 03 June 2012 03:17  |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
I have page data being sent through a php script that uses sessions to
pass along variables. These vars are used to load data.
If a user opens a page, everything works fine.
If they open another in a new window it works fine.
If they tab back over to the original browser window and hit refresh it
switches to the last page they opened in the other window.
This is because sessions is keeping that last var data in memory so the
old page when refreshed reads the new var data and opens new data
instead of refreshing the old.
How would I go about fixing this so a page doesn't lose it's var data on
refresh?
Mike
|
|
|
|
| Re: sessions causing refreshing not to work [message #178316 is a reply to message #178315] |
Sun, 03 June 2012 03:57  |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
> I have page data being sent through a php script that uses sessions to
> pass along variables. These vars are used to load data.
>
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.
> If they tab back over to the original browser window and hit refresh it
> switches to the last page they opened in the other window.
>
> This is because sessions is keeping that last var data in memory so the
> old page when refreshed reads the new var data and opens new data
> instead of refreshing the old.
>
> How would I go about fixing this so a page doesn't lose it's var data on
> refresh?
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.
--
76. If the hero runs up to my roof, I will not run up after him and
struggle with him in an attempt to push him over the edge. I will
also not engage him at the edge of a cliff. (In the middle of a
rope-bridge over a river of lava is not even worth considering.)
|
|
|
|
|
|
|
|
| Re: sessions causing refreshing not to work [message #178319 is a reply to message #178318] |
Sun, 03 June 2012 13:59 |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
Fred wrote:
> Le 03/06/2012 05:17, Michael Joel a écrit :
>
>> I have page data being sent through a php script that uses sessions to
>> pass along variables. These vars are used to load data.
>>
>> If a user opens a page, everything works fine.
>> If they open another in a new window it works fine.
>
>
> same browser? ==>> same session
>
>
>> If they tab back over to the original browser window and hit refresh it
>> switches to the last page they opened in the other window.
>>
>> This is because sessions is keeping that last var data in memory so the
>> old page when refreshed reads the new var data and opens new data
>> instead of refreshing the old.
>
>
>
> I think the problem is every loaded pages change the state of
> the server so the 2 opened windows are linked together.
>
>
>>
>> How would I go about fixing this so a page doesn't lose it's var data on
>> refresh?
>>
>> Mike
>
>
>
> since pages sharing same datas. It is not possible like this.
>
> But is it really a problem?
>
>
> Fred
It is if the user wants to open to documents at once and tries to
refresh on.
I guess the easiest is to go with passing data by the url, not clean
looking but the information is the important thing.
Mike
|
|
|
|
|
|
| Re: sessions causing refreshing not to work [message #178321 is a reply to message #178320] |
Sun, 03 June 2012 19:13 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 03 Jun 2012 16:43:07 +0200, Fred wrote:
> Le 03/06/2012 15:59, Michael Joel a écrit :
>> It is if the user wants to open to documents at once and tries to
>> refresh on.
>> I guess the easiest is to go with passing data by the url, not clean
>> looking but the information is the important thing.
> I see what you mean.
> It's not so bad. Many sites proceed like this with a permalink or a kind
> of request. And URL could be bookmarked to access to specific
> information.
Perhaps the issue here is using one web page to present too many
different sets of content? And it might be better to either separate the
required content by url.
If that's not possible, pass a "sub-session" (for want of a better term)
id in the get, and track in the session which sub-session was displaying
which set of content data. Sub-session ids would only be valid for the
current session, and could be fairly short, as you have a 62 element
alphabet to work with, 0-9A-Za-z, so eg 4 characters gives you 62^4 (over
14 million) identifiers.
You'd need to add a new sub-session id whenever you generated a link to
content that wasn't already in the session's table.
Rgds
Denis McMahon
|
|
|
|
| Re: sessions causing refreshing not to work [message #178322 is a reply to message #178317] |
Mon, 04 June 2012 03:20 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 03 Jun 2012 13:07:20 +0200, Fred wrote:
> Le 03/06/2012 05:57, Peter H. Coffin a ?crit :
>
>>
>> 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.
>>
>
> session.use_trans_sid and session.use_cookie are 2 ways to manage
> session but the result will be the same.
Allowing the use of something is not the same as forcing the use of
something. Either option can be allowed or disallowed independantly.
It's kind of important because the "default", the type that all the doco
talk about, is session via cookie. Session via $_GET is a bit more manual
(you have to fetch the SID explicitly), and the way that the
configuration stuff is set up allows for other means of store/fetching
session IDs, which may someday come along.
--
22. No matter how tempted I am with the prospect of unlimited power, I
will not consume any energy field bigger than my head.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: sessions causing refreshing not to work [message #178323 is a reply to message #178316] |
Mon, 04 June 2012 05:56 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin, 03.06.2012 05:57:
> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>> I have page data being sent through a php script that uses sessions to
>> pass along variables. These vars are used to load data.
>>
>> If a user opens a page, everything works fine.
>> If they open another in a new window it works fine.
>> If they tab back over to the original browser window and hit refresh it
>> switches to the last page they opened in the other window.
>>
>> This is because sessions is keeping that last var data in memory so the
>> old page when refreshed reads the new var data and opens new data
>> instead of refreshing the old.
>>
>> How would I go about fixing this so a page doesn't lose it's var data on
>> refresh?
>
> 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.
Don't do this.
1) It won't change anything. The session itself will remain the same -
therefore it makes no sense to transmit the ID via the URL.
2) Adding session IDs to forms may destroy validity of the documents
(also see
< http://www.mtdev.com/2002/06/why-you-should-disable-phps-session-use_trans_ sid>).
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: sessions causing refreshing not to work [message #178324 is a reply to message #178315] |
Mon, 04 June 2012 05:59 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Michael Joel, 03.06.2012 05:17:
> I have page data being sent through a php script that uses sessions to
> pass along variables. These vars are used to load data.
>
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.
> If they tab back over to the original browser window and hit refresh it
> switches to the last page they opened in the other window.
>
> This is because sessions is keeping that last var data in memory so the
> old page when refreshed reads the new var data and opens new data
> instead of refreshing the old.
Well - thats what sessions are made for - manage a state for a *client*,
not a single *window* or tab.
> How would I go about fixing this so a page doesn't lose it's var data on
> refresh?
Think about your concept. Either you use a state within the session or
you use the URL (or URL parameters) to determine, what to display. But
the session will always be the same, even if the user opens multiple
windows/tabs within the same browser.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: sessions causing refreshing not to work [message #178325 is a reply to message #178315] |
Mon, 04 June 2012 07:12 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 03/06/2012 5:17, Michael Joel escribió/wrote:
> I have page data being sent through a php script that uses sessions to
> pass along variables. These vars are used to load data.
>
> If a user opens a page, everything works fine.
> If they open another in a new window it works fine.
> If they tab back over to the original browser window and hit refresh it
> switches to the last page they opened in the other window.
>
> This is because sessions is keeping that last var data in memory so the
> old page when refreshed reads the new var data and opens new data
> instead of refreshing the old.
>
> How would I go about fixing this so a page doesn't lose it's var data on
> refresh?
Your description suggests that you are using a (single) global session
variable to save a setting that can take many values. It's hard to
suggest a fix without further details but I have the impression that you
should be using an array to store the server side information and a GET
parameter to store the array key. E.g.: instead of:
/example.php
$_SESSION['search'] = 'foo'
$_SESSION['page'] = 33
$_SESSION['results'] = 'blah';
.... you should do something like:
/example.php?search=foo&page=33
$_SESSION['foo'][33]['results'] = 'blah';
/example.php?search=bar&page=1
$_SESSION['bar'][1]['results'] = 'hello';
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: sessions causing refreshing not to work [message #178326 is a reply to message #178323] |
Mon, 04 June 2012 16:20 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 04 Jun 2012 07:56:49 +0200, Arno Welzel wrote:
> Peter H. Coffin, 03.06.2012 05:57:
>
>> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>>> I have page data being sent through a php script that uses sessions to
>>> pass along variables. These vars are used to load data.
>>>
>>> If a user opens a page, everything works fine.
>>> If they open another in a new window it works fine.
>>> If they tab back over to the original browser window and hit refresh it
>>> switches to the last page they opened in the other window.
>>>
>>> This is because sessions is keeping that last var data in memory so the
>>> old page when refreshed reads the new var data and opens new data
>>> instead of refreshing the old.
>>>
>>> How would I go about fixing this so a page doesn't lose it's var data on
>>> refresh?
>>
>> 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.
>
> Don't do this.
>
> 1) It won't change anything. The session itself will remain the same -
> therefore it makes no sense to transmit the ID via the URL.
It WILL, though, mean that users can have separate sessions in different
tabs in the browser, which is the effect of the original problem that
was requested help with.
> 2) Adding session IDs to forms may destroy validity of the documents
> (also see
> < http://www.mtdev.com/2002/06/why-you-should-disable-phps-session-use_trans_ sid>).
Yup, there's tradeoffs for everything.
--
53. If the beautiful princess that I capture says "I'll never marry
you! Never, do you hear me, NEVER!!!", I will say "Oh well" and
kill her.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: sessions causing refreshing not to work [message #178327 is a reply to message #178326] |
Tue, 05 June 2012 01:27 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin, 04.06.2012 18:20:
> On Mon, 04 Jun 2012 07:56:49 +0200, Arno Welzel wrote:
>> Peter H. Coffin, 03.06.2012 05:57:
>>
>>> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>>>> I have page data being sent through a php script that uses sessions to
>>>> pass along variables. These vars are used to load data.
>>>>
>>>> If a user opens a page, everything works fine.
>>>> If they open another in a new window it works fine.
>>>> If they tab back over to the original browser window and hit refresh it
>>>> switches to the last page they opened in the other window.
>>>>
>>>> This is because sessions is keeping that last var data in memory so the
>>>> old page when refreshed reads the new var data and opens new data
>>>> instead of refreshing the old.
>>>>
>>>> How would I go about fixing this so a page doesn't lose it's var data on
>>>> refresh?
>>>
>>> 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.
>>
>> Don't do this.
>>
>> 1) It won't change anything. The session itself will remain the same -
>> therefore it makes no sense to transmit the ID via the URL.
>
> It WILL, though, mean that users can have separate sessions in different
> tabs in the browser, which is the effect of the original problem that
> was requested help with.
Only, if the user manually removes the session ID in the URL *and*
Cookies are not used at all.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: sessions causing refreshing not to work [message #178328 is a reply to message #178316] |
Tue, 05 June 2012 04:46 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin wrote:
> On Sat, 02 Jun 2012 23:17:03 -0400, Michael Joel wrote:
>> I have page data being sent through a php script that uses sessions to
>> pass along variables. These vars are used to load data.
>>
>> If a user opens a page, everything works fine.
>> If they open another in a new window it works fine.
>> If they tab back over to the original browser window and hit refresh it
>> switches to the last page they opened in the other window.
>>
>> This is because sessions is keeping that last var data in memory so the
>> old page when refreshed reads the new var data and opens new data
>> instead of refreshing the old.
>>
>> How would I go about fixing this so a page doesn't lose it's var data on
>> refresh?
>
> 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>
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>
|
|
|
|
| Re: sessions causing refreshing not to work [message #178330 is a reply to message #178328] |
Tue, 05 June 2012 12:14 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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 as a
"security hole". People can manipulate cookie values almost as easily
and they're no more trustworthy than a $_GET result. 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.
--
Judging by this particular thread, many people in this group spent their
school years taking illogical, pointless orders from morons and having
their will to live systematically crushed. And people say school doesn't
prepare kids for the real world. -- Rayner, in the Monastery
|
|
|
|
| Re: sessions causing refreshing not to work [message #178331 is a reply to message #178330] |
Tue, 05 June 2012 18:52 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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.
> as a "security hole". People can manipulate cookie values almost as easily
Because of that, HTTP-only cookies have been invented.
> 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.
> 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.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
|
| Re: sessions causing refreshing not to work [message #178332 is a reply to message #178331] |
Tue, 05 June 2012 20:05 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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. "DO NOT TRUST THE CLIENT". Clean incoming stuff, provide for
backing out everything that the client does, etc. The same stuff we
always end up talking about as "security holes" are not discrete little
things but part of an overriding principle. Learning only the little
things and not the principle is WHY stuff becomes exploitable.
>> 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.
It something between bupkis and squat against someone that's trying to
hijack a session and has access to anything more than a javascript jail.
>> 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. From the user's perspective,
the same hazards exist with cookies, http-only or otherwise, or are
"secured" by only by preventing exactly the kind of behavior that the
OP is hoping to enable: separating the session from the one-to-one
relationship with the browser/OS-user combination to something else.
>> 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".
--
29. I will dress in bright and cheery colors, and so throw my enemies
into confusion.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: sessions causing refreshing not to work [message #178333 is a reply to message #178315] |
Tue, 05 June 2012 20:51 |
Michael Joel
Messages: 42
Registered: October 2011
Karma: 0
|
Member |
|
|
Thanks for all the information.
I decoded to just pass all variables through the URL.
There is no security threat since there is nothing needing security to
it. They are all just documents available for public viewing. Right now
no information (except document selection) is taken from the user.
If I get into needing user input then I will need to start worrying
about security.
Again Thanks,
Mike
|
|
|
|
| Re: sessions causing refreshing not to work [message #178335 is a reply to message #178333] |
Tue, 05 June 2012 22:09 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Joel wrote:
> Thanks for all the information.
>
> I decoded to just pass all variables through the URL.
> There is no security threat since there is nothing needing security to
> it. They are all just documents available for public viewing. Right now
> no information (except document selection) is taken from the user.
>
> If I get into needing user input then I will need to start worrying
> about security.
>
> Again Thanks,
> Mike
Nice example of not applying nuclear security measures to freecycled
old clothes, as it were. Horses for courses!
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: sessions causing refreshing not to work [message #178340 is a reply to message #178330] |
Wed, 06 June 2012 12:34 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 6/5/12 8:14 AM, 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 as a
> "security hole". People can manipulate cookie values almost as easily
> and they're no more trustworthy than a $_GET result. 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.
>
The security hole is treating the SessionI D as totally safe to using in
any manner, doing things like building SQL queries by just appending the
value (without going through escaping, since real session id's don't
need to be escaped).
|
|
|
|
| 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: 0
|
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
]