|
|
Posted by Flaming Corncob on 09/15/06 21:28
In article <1158337277.991741.205160@k70g2000cwa.googlegroups.com>,
"d43m0n AT shaw DOT ca" <barryd.it@gmail.com> wrote:
> Flaming Corncob wrote:
> > In article <1158073892.551973.254600@i3g2000cwc.googlegroups.com>,
> > "ZeldorBlat" <zeldorblat@gmail.com> wrote:
> >
> > > Flaming Corncob wrote:
> > > > Correct me if I'm wrong, but I thought that if you made a change to a
> > > > session, for example (forgive the lame example):
> > > >
> > > > If $_SESSION['tv'] equals "on" and you change it to "off"...
> > > >
> > > > You have to use header() else any changes were lost.
> > > >
> > > > By stupid accident I didn't direct a page through header() after I had
> > > > changed some things in the session and found that even if you closed the
> > > > browser window (not quit the browser - that kills any session) the
> > > > changes I made were ok. This leads me to believe it's possible to make
> > > > any changes to a session without having to redirect with header()? It
> > > > was my understanding that in order for any change to take effect
> > > > header() had to be used.
> > >
> > > Session data is stored on the server. A cookie is set on the client
> > > with the "session id" which is used to identify which session on the
> > > server to use. So, any changes you make to the $_SESSION array are
> > > written to the session data on the server. In other words, it doesn't
> > > matter what you do after that. The next request will again present the
> > > session id from the cookie and get the latest and greatest data from
> > > the session.
> >
> > Well, knowing this helps me a LOT. One of the things I've been trying to
> > do is use an alert box to send messages to a user if for example the
> > user enters a wrong password. I've had a work-around without an alert
> > box that just printed a message through the page they are viewing. I've
> > only started playing around with alert boxes to see how I might do it
> > easier and that's how I discovered this about cookies.. by mistake. This
> > makes things a WHOLE lot easier.
>
> Careful when programming with php sessions, as there are bugs that I
> had pointed roughly a year ago, and I have noticed an increase in
> interest of the bug, which probable means it hasnt been fixed.
>
> The flaw if I recall is due to the locking of the file, and during
> execution of the script is unable to unlock and destroy the file,
> esspecially if you want to write a secured session id, which I had
> called for an idea that the session id gets changed apon everytime the
> page is requested.
>
> Do not trust the internet, it is not encrypted and anyone can play as
> the 'middle man' by reading sent/received packets, or page requests in
> plainer sence. If you used secured session id, you can ensure, that
> there is only so much time during the page execution that someone can
> hop onto anothers session, thus read what the server had already sent.
>
> There are 2 ways I can see to fix this, and that is cache what the
> client is too see, and destroy it, and call it as hack attempt if its
> re-called. How ever, this still leaves holes, you could instead learn
> Javascript, and program the browser and check valid varibles, heck,
> even random variables and encrypt the js so no one else can detirman
> the method or content for which your viewing, of course, if your still
> playing the middle man, no matter what, the request and content will
> still be buffered on anothers computer.
Eh I don't use sessions to send any real personal data or anything.
About the most anybody would get from my site would be an email
address... which can be stolen by countless other ways.
Navigation:
[Reply to this message]
|