phplib's solution has been to re-register s globals ll the $_SESSION
vars.
The register_globals=Off has been placed, I suppose, to prevent GET/POST
(and any user_originated) var to overwrite uninitialized program
variables.
As session vars are not user_originated, and only the programmer can set
i
There is a flagrant bug there that allows anyone to chose a session ID
of his choice, instead of relying on the random device.
I think this breaks some POSIX-MIT-RFC somewhere and can be the cause
of easy exploits.
I would then say hat for a bugfix release it should be reasonabe to
fix it,.
I am
Dan Hardiker wrote:
>
> >> Well, more worrisome would be if a bad guy tricks you into clicking on
> >> a link or simply sends you an image in an email that makes a request
> >> to my server with a valid-looking session id. Then if you go to this
> >> site (that
> >
> > I've debunked that sce
Rasmus Lerdorf wrote:
>
> > On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
> >
> > > But could you at least answer the question? What is the advantage of
> > > allowing user-supplied new session ids? I see no reason not to add a
> > > check for this.
> >
> > For example, I have a set of C progr
On 02:45, sabato 17 agosto 2002, Rasmus Lerdorf wrote:
> > Edin Kadribasic wrote:
> > > > I absolutely agree with Stefan here. It is *not* PHP's job to
> > >
> > > secure
> > >
> > > > a connection. SSL does this.
> > >
> > > Like that's going to stop users from pasting url with SID in it
> > > to
Edin Kadribasic wrote:
>
> > I absolutely agree with Stefan here. It is *not* PHP's job to
> secure
> > a connection. SSL does this.
>
> Like that's going to stop users from pasting url with SID in it to
> an email, which is what this thread is about.
>
> Edin
The issue is also that anyone can
Many hosted sites would like to keep their session.save_path separate, within their
home dir, but are somehow prevented by the fact that gc wouldn't take place if the
path depth is > 2.
Because they obviously see a problem in implementing their own garbage collection, as
most hosting sites do
[EMAIL PROTECTED] (Sascha Schumann) wrote:
---
>Let's analyze the meaning of session.use_cookies, shall we?
>
>http://php.net/manual/en/ref.session.php says:
>
>"session.use_cookies specifies whether the module will use
>cookies to store the session id on the client side. Defaults
Giancarlo Pinerolo wrote:
>
> Jani Taskinen wrote:
> >
> > I was wondering (I'm propably wrong, it's almost 6am here :)
> > that wouldn't the real fix for this without having to add
> > yet-another-ini-option have been to fix this so th
ed
> by the cookie? btw. Cookies can be forged too..
>
> --Jani
>
>
> On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote:
>
> >Hi.
> >Last here, same period, I found that nasty thing in
> >?_PHPLIB[libdir]=http://
> >It was the nefarious start
ring' attacks, with no hope for
the poor cookie-enabled victim to avoid it.
Isn't his similar to the register_globals=on problem, where untrusted
user provided values can make their way inside the script? Isn't this
variable even more important, to let it in?
Giancarlo Pinerolo
--
Sascha Schumann wrote:
>
> > I noticed this risk long time before and I think it's a kind of
> > security fix as Sascha's comment, isn't it?
>
> That depends on your viewpoint.
>
> From my perspective, this is not urgent. It is not like an
> attacker can gain access to the server,
12 matches
Mail list logo
