| session cookie: client side [message #175870] |
Thu, 03 November 2011 09:10  |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
On a given PC, since the user can read a session cookie, the session is
secured only because no others can read it.
Is my statement correct (of course disregard virus) ?
Thanks.
|
|
|
|
| Re: session cookie: client side [message #175871 is a reply to message #175870] |
Thu, 03 November 2011 12:23  |
Balazs Nadasdi
Messages: 7
Registered: November 2011
Karma: 0
|
Junior Member |
|
|
I don't know I understood your question totally but...
If the user can read the session cookie then any others can read the session cookie. The browser can't recognize who sits in front of the monitor.
Another way: If user can read session cookie + it's not an SSL channel -> any others can sniff it (local machine or another machine on the route/wifi)
Mechanism: on server side the system generates a Session ID (SID). The SID identifies the session datas ($_SESSION in PHP). The Server store session data in a file or database. on client side the client knows only the SID but the client doesn't know session data, only ID. Client sends its SID, the server find data.
So... for example: If you test IP of the client and SID your can secure the session from outside of the box but you can't do it with inside of the box..
Use SSL + check IP + never-never-ever store important information in cookies.
|
|
|
|
| Re: session cookie: client side [message #175892 is a reply to message #175871] |
Fri, 04 November 2011 06:14 |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
> I don't know I understood your question totally but...
>
> If the user can read the session cookie then any others can read the
> session cookie. The browser can't recognize who sits in front of the
> monitor.
>
> Another way: If user can read session cookie + it's not an SSL
> channel -> any others can sniff it (local machine or another machine
> on the route/wifi)
>
> Mechanism: on server side the system generates a Session ID (SID).
> The SID identifies the session datas ($_SESSION in PHP). The Server
> store session data in a file or database. on client side the client
> knows only the SID but the client doesn't know session data, only ID.
> Client sends its SID, the server find data.
>
> So... for example: If you test IP of the client and SID your can
> secure the session from outside of the box but you can't do it with
> inside of the box.
>
> Use SSL + check IP + never-never-ever store important information in
> cookies.
I am a bit confused now.
For example, using the Opera browser, a user can check a cookie value. I
understand that this value is used to identify a user, ie I can read it. But
other people, on LAN or internet, cannot read it because when I send data,
the data is enrcypted via https.
I suppose the cookie value is the Session ID.
|
|
|
|
| Re: session cookie: client side [message #175897 is a reply to message #175892] |
Fri, 04 November 2011 11:55 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/4/2011 2:14 AM, sl@exabyte wrote:
>> I don't know I understood your question totally but...
>>
>> If the user can read the session cookie then any others can read the
>> session cookie. The browser can't recognize who sits in front of the
>> monitor.
>>
>> Another way: If user can read session cookie + it's not an SSL
>> channel -> any others can sniff it (local machine or another machine
>> on the route/wifi)
>>
>> Mechanism: on server side the system generates a Session ID (SID).
>> The SID identifies the session datas ($_SESSION in PHP). The Server
>> store session data in a file or database. on client side the client
>> knows only the SID but the client doesn't know session data, only ID.
>> Client sends its SID, the server find data.
>>
>> So... for example: If you test IP of the client and SID your can
>> secure the session from outside of the box but you can't do it with
>> inside of the box.
>>
>> Use SSL + check IP + never-never-ever store important information in
>> cookies.
>
> I am a bit confused now.
>
> For example, using the Opera browser, a user can check a cookie value. I
> understand that this value is used to identify a user, ie I can read it. But
> other people, on LAN or internet, cannot read it because when I send data,
> the data is enrcypted via https.
>
> I suppose the cookie value is the Session ID.
>
The cookie does not identify the user - it is just the session id. What
the server does with it is something else.
In general, the session id does identify the computer from which the
cookie is being sent because the session id is a rather long
pseudo-random alphanumeric value. Yes it's possible for someone else to
intercept and read the session id, but in general it's unlikely.
The real question is - what is the problem you are trying to resolve?
If the data are that sensitive, you should be using a secure protocol
for everything. If the data aren't sensitive enough to require a secure
protocol, why do you think the cookie is?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: session cookie: client side [message #175898 is a reply to message #175897] |
Fri, 04 November 2011 14:21 |
sl@exabyte
Messages: 16
Registered: March 2011
Karma: 0
|
Junior Member |
|
|
> The cookie does not identify the user - it is just the session id. What
> the server does with it is something else.
>
> In general, the session id does identify the computer from which the
> cookie is being sent because the session id is a rather long
> pseudo-random alphanumeric value. Yes it's possible for someone else
> to intercept and read the session id, but in general it's unlikely.
>
> The real question is - what is the problem you are trying to resolve?
> If the data are that sensitive, you should be using a secure protocol
> for everything. If the data aren't sensitive enough to require a
> secure protocol, why do you think the cookie is?
I think I am missing something. By the term 'secure protocol', ie SSL,
implies that HTTPS be used, rather than HTTP, isn't it ?
Sorry if it is a stupid question. Anyway I shall google for SSL and HTTPS.
|
|
|
|
| Re: session cookie: client side [message #175899 is a reply to message #175892] |
Fri, 04 November 2011 15:52 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Fri, 04 Nov 2011 14:14:52 +0800, sl@exabyte wrote:
> I am a bit confused now.
Clearly.
> For example, using the Opera browser, a user can check a cookie value. I
> understand that this value is used to identify a user, ie I can read it.
> But other people, on LAN or internet, cannot read it because when I send
> data, the data is enrcypted via https.
>
> I suppose the cookie value is the Session ID.
A cookie value is whatever it is set to.
A single page can have multiple cookies with different names, values and
expiration times.
If you're trying to keep track of a session between web pages, there are
several approaches, of which using a session cookie is one.
However, any user when requesting a web page can generate any cookie name
with any data value that they like.
The "session cookie" in php is by default called "PHPSESSID" (it can be
defined locally to be called something else).
The session cookie is sent from the server to the browser when the php
function "session_start()" is called in php. This should be called in
every page that uses the session before any html code is sent to the
client.
When "session_start()" is called, it first looks to see if a cookie
matching the session cookie name was received in the http request.
If it was, and the session id in the cookie is current, the relevant
session data is placed in the $_SESSION[] superglobal. If the session id
was not valid, or no session cookie was received, a blank $_SESSION[]
superglobal is created and a session id is allocated.
Finally, the session cookie is sent back to the client as part of the
response.
The session cookie is only protected by encryption in an https session.
Sessions don't only happen with https, they can happen with http as well.
HTTP(S) are protocols for requests from a client to a server and
responses by a client.
Cookies are a type of data transferred in http(s) requests and responses.
The name, content and use of the any specific cookie has no bearing on or
relationship to the protocol used to carry it between the client and
server.
Rgds
Denis McMahon
|
|
|
|
| Re: session cookie: client side [message #175900 is a reply to message #175897] |
Fri, 04 November 2011 15:53 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Fri, 04 Nov 2011 07:55:55 -0400, Jerry Stuckle wrote:
> The real question is - what is the problem you are trying to resolve?
Sounds like his real problem might be "homework" ;)
Rgds
Denis McMahon
|
|
|
|
| Re: session cookie: client side [message #175903 is a reply to message #175898] |
Fri, 04 November 2011 18:40 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/4/2011 10:21 AM, sl@exabyte wrote:
>> The cookie does not identify the user - it is just the session id. What
>> the server does with it is something else.
>>
>> In general, the session id does identify the computer from which the
>> cookie is being sent because the session id is a rather long
>> pseudo-random alphanumeric value. Yes it's possible for someone else
>> to intercept and read the session id, but in general it's unlikely.
>>
>> The real question is - what is the problem you are trying to resolve?
>> If the data are that sensitive, you should be using a secure protocol
>> for everything. If the data aren't sensitive enough to require a
>> secure protocol, why do you think the cookie is?
>
> I think I am missing something. By the term 'secure protocol', ie SSL,
> implies that HTTPS be used, rather than HTTP, isn't it ?
>
> Sorry if it is a stupid question. Anyway I shall google for SSL and HTTPS.
>
>
A secure protocol is one in which the content is encrypted between the
two systems. For web pages, it would typically be https. Command line
prompts would generally be ssl. There are others also, i.e. for ftp and
other protocols.
But you still haven't answered the question - what are you trying to
accomplish? What is sensitive enough that it requires a secure protocol?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: session cookie: client side [message #175904 is a reply to message #175900] |
Fri, 04 November 2011 18:41 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/4/2011 11:53 AM, Denis McMahon wrote:
> On Fri, 04 Nov 2011 07:55:55 -0400, Jerry Stuckle wrote:
>
>> The real question is - what is the problem you are trying to resolve?
>
> Sounds like his real problem might be "homework" ;)
>
> Rgds
>
> Denis McMahon
Could be, Denis, could be ;)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]