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 programs for IRCG load
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 scenario already a
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 scenario already a few times. The net
Sascha:
If you want your site to be safe, enable
session.use_only_cookies and be done with it. No amount of
checking on the server side can otherwise prevent this class
of attacks.
By the way, does session.use_only_cookies work with
session.use_cookies=off?
I'm using an
So you wish to prevent your users from forging GET/POST values and are
willing to rely on client-side cookies ?
How is that any safer ?
On Tue, 2002-08-20 at 09:18, Marko Karppinen wrote:
Sascha:
If you want your site to be safe, enable
session.use_only_cookies and be done
Xavier:
So you wish to prevent your users from forging GET/POST values and are
willing to rely on client-side cookies ?
How is that any safer ?
On Tue, 2002-08-20 at 09:18, Marko Karppinen wrote:
By the way, does session.use_only_cookies work with
session.use_cookies=off?
Who said
It is also very conceivable that a person would send a link to a java
applet or any other kind of wrapper (PHP or other CGI actually would be
able to establish the connection on the server side always sending the
same user agent string and sending back the data from your site) to
establish the
It is also very conceivable that a person would send a link to a java
applet or any other kind of wrapper (PHP or other CGI actually would be
able to establish the connection on the server side always sending the
same user agent string and sending back the data from your site) to
establish
Dan Hardiker wrote:
It is also very conceivable that a person would send a link to a java
applet or any other kind of wrapper (PHP or other CGI actually would be
able to establish the connection on the server side always sending the
same user agent string and sending back the data from your
hi,
Like I said before, this discussion is not about the method by which an SID
is propogated nor generated.
It is about:
1) knowing when it is safe to display sensative information - user education
2) the possibility to verify credentials, besides the SID.
Given 2), the easiest solution is to
Hi Dan,
This was exactly what I meant to suggest by allowing to time out any
session even active.
Even though your workaround would also definitely make the task harder,
as George pointed out, we still don't have a solution against a
motivated cracker.
I think it would be very good but I am
IP match makes no sense. Someone's ip can change dramatically from one
click to the next due to dhcp leases timing out, roaming from one wireless
gateway to the next, coming through a round-robin dns batch of proxy
servers, etc.
i quote myself:
p.s. storing IP/USERAGENT/whatnot on the
At 05:31 PM 8/20/02 +0200, Tit \Black\ Petric wrote:
the ip match should be implemented too, but trough a php.ini switch, since i
see how that behaviour might not be desired from your comment above, i would
default it to off thou, let the user/admin/whatnot change it if they desire
to do that.
Rasmus Lerdorf wrote:
Ok, then that is a bug that needs to be fixed before 4.3.
This is one of the current session module behavior that I worry.
We need at least strlen. (and char range check)
I check them both in my save handler. (Not published session_pgsql,
but my private session save
No, I think the check we need here is one that checks to see if the
session specified in the user-supplied PHPSESSID exists. If it does not
exist, toss that session id and replace it with a PHP-generated one.
Perhaps Sascha has some thoughts on these two session-related things I'd
like to see
Rasmus Lerdorf wrote:
No, I think the check we need here is one that checks to see if the
session specified in the user-supplied PHPSESSID exists. If it does not
exist, toss that session id and replace it with a PHP-generated one.
Perhaps Sascha has some thoughts on these two
Rasmus Lerdorf wrote:
No, I think the check we need here is one that checks to see if the
session specified in the user-supplied PHPSESSID exists. If it does not
exist, toss that session id and replace it with a PHP-generated one.
Perhaps Sascha has some thoughts on these two
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 scenario already a few times. The net
result
Well, while it is true that it is impossible to completely prevent, our
current setup doesn't do anything at all to prevent it which makes the
attack much simpler. There is currently no need for the attacker to visit
the site to be attacked at all and thus he doesn't need any keepalive
stuff to
PROTECTED]
Cc: Yasuo Ohgaki [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, August 20, 2002 12:27 AM
Subject: Re: [PHP-DEV] trans-sid warning?
Well, while it is true that it is impossible to completely prevent, our
current setup doesn't do anything at all to prevent it which makes the
attack
matching ip limits the number of session hijackings to atleast the same
network you are on (behind a fw/router which does nat), and the users who
use the same http proxy as you (in case you use one)
so its either expire/generate (rotate,morph,mutate) SID on each pageload, or
the more
Rasmus Lerdorf wrote:
Well, while it is true that it is impossible to completely prevent, our
current setup doesn't do anything at all to prevent it which makes the
attack much simpler. There is currently no need for the attacker to visit
the site to be attacked at all and thus he doesn't
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
Well, while it is true that it is impossible to completely prevent, our
I've been through this argument a couple of times and I don't
plan to spend more time on it.
If you want your site to be safe, enable
session.use_only_cookies and
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.
On Tue, 20 Aug 2002, Sascha Schumann wrote:
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
Well, while it is true that it is impossible to
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 programs for IRCG load
testing. It uses a simple FSM
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 programs for IRCG load
testing. It uses a
On Monday, August 19, 2002, at 07:56 PM, Rasmus Lerdorf wrote:
To conclude: Don't trade useful features for pseudo security.
Removing this feature just increases the feeling of having a
'secure' site and decreases the desire to protect oneself by
activating
To play devil's advocate, pure cookie based authentication is not a
panacea. If you allow users to put things like javascript on your site,
or if you have users who exploit ie bugs like the about: cookie domain
bug from last year, cookies can be stolen and session hijacked. pure
cookie
]
Subject: Re: [PHP-DEV] trans-sid warning?
To play devil's advocate, pure cookie based authentication is not a
panacea. If you allow users to put things like javascript on your site,
or if you have users who exploit ie bugs like the about
.
-Original Message-
From: Sascha Schumann [mailto:[EMAIL PROTECTED]]
Sent: Mon 19/08/2002 8:50 PM
To: George Schlossnagle
Cc: Rasmus Lerdorf; Yasuo Ohgaki; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] trans-sid warning?
To play devil's advocate
Schlossnagle
Cc: Rasmus Lerdorf; Yasuo Ohgaki; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] trans-sid warning?
To play devil's advocate, pure cookie based authentication is not a
panacea. If you allow users to put things like javascript on
your site
To: Xavier Spriet
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] trans-sid warning?
This is not the issue we are discussing. PHP already times out inactive
sessions, and in this particular case the session has even been created
yet, so
Again, this is a good step, but is not at all effective against an
attacker motivated to compromise your site.
You are right. However, it could be an acceptable policy to improve overall
security.
The problem is, while this
But the real issue here is about session hijacking. Yes, of course
people can send whatever session id they want to PHP. Since the
session id comes from the user we need to accept what is sent.
This is what I consider unconceivable.
Why ever should tickets issued by the user be
Hrm.. Wait a second though, Giancarlo is saying that if the user passes
in a session id himself and that session does not exist, then that will be
the session id he will be given if a session is created on that request.
Is that correct, Giancarlo?
From looking at the code and testing that
Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
Hrm.. Wait a second though, Giancarlo is saying that if the user passes
in a session id himself and that session does not exist, then that will be
the session id he will be given if a session is created on that request.
Is that
Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
Hrm.. Wait a second though, Giancarlo is saying that if the user passes
in a session id himself and that session does not exist, then that will be
the session id he will be given if a session is created on that request.
Is
Il 00:13, lunedì 19 agosto 2002, hai scritto:
Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
Hrm.. Wait a second though, Giancarlo is saying that if the user
passes in a session id himself and that session does not exist, then
that will be the session id he will be
Ok, then that is a bug that needs to be fixed before 4.3.
On Mon, 19 Aug 2002, Giancarlo wrote:
Il 00:13, lunedì 19 agosto 2002, hai scritto:
Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
Hrm.. Wait a second though, Giancarlo is saying that if the user
passes in a
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 an email, which is what
Any propagation, doesn't matter.
The passed id must exist, otherwise discarded and regenerated.
I saw that php already creates the session at the start.
The possibility to count on a stable name, because recreable anytime
and though surviving gc, is a great weaknes for that tipe of snoop.
Rasmus Lerdorf wrote:
Any propagation, doesn't matter.
The passed id must exist, otherwise discarded and regenerated.
I saw that php already creates the session at the start.
The possibility to count on a stable name, because recreable anytime
and though surviving gc, is a great
But the real issue here is about session hijacking. Yes, of course people
can send whatever session id they want to PHP. Since the session id comes
from the user we need to accept what is sent. Perhaps a check should be
added to make sure it looks like a proper session id before using it, but
Il 02:48, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
But the real issue here is about session hijacking. Yes, of course people
can send whatever session id they want to PHP. Since the session id comes
from the user we need to accept what is sent.
This is what I consider
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 provide
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
Can we not document the real issues about this in the manual, and just
say something like
There are security issues in using any type of sessions with HTTP,
please read the manual at
http://www.php.net/en/manual/security.sessions.html
for a more detail discussion on this subject..
regards
At 15:46 14-8-2002, Alan Knowles wrote:
Can we not document the real issues about this in the manual, and just say
something like
There are security issues in using any type of sessions with HTTP, please
read the manual at
http://www.php.net/en/manual/security.sessions.html
for a more detail
Inlined for the list.
Index: reference.xml
===
RCS file: /repository/phpdoc/en/reference/session/reference.xml,v
retrieving revision 1.8
diff -u -r1.8 reference.xml
--- reference.xml 28 Jul 2002 14:04:32 - 1.8
+++
I do not understand the sense of this whole discussion.
HTTP is a plaintext protocol. So nothing transfered over HTTP can be secure.
No urls, no session no anything.
Stefan
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
+para
+ Therefore, when dealing with sensative information, there should +
always be additional methods to decide whether it is a valid +
session. Sessions are strongnot reliable/strong as a secure +
authentication mechanism.
+/para
So if Im to write an online web-based
Guys, documentation is about giving people information that will help them
solve problems, not about FUD. That was my original point about the
php.ini entry. You can't just state that something is very very bad
without giving workable solutins and alternatives.
Present ways of solving the
hi,
I absolutely agree with Stefan here. It is *not* PHP's job to secure
a connection. SSL does this.
-daniel
- Original Message -
From: Stefan Esser [EMAIL PROTECTED]
Sent: Wed, 14 Aug 2002 16:23:16 +0200
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] trans-sid warning?
I do
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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
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.
There are 2 issues at play here, firstly is educating PHP site builders
that
At 17:15 14-8-2002, Dan Hardiker wrote:
+para
+ Therefore, when dealing with sensative information, there should +
always be additional methods to decide whether it is a valid +
session. Sessions are strongnot reliable/strong as a secure +
authentication mechanism.
+
At 17:22 14-8-2002, Rasmus Lerdorf wrote:
Guys, documentation is about giving people information that will help them
solve problems, not about FUD. That was my original point about the
php.ini entry. You can't just state that something is very very bad
without giving workable solutins and
So if Im to write an online web-based banking system (either in
Java/JSP,
PHP, ASP - whatever)... what method would you suggest that IS secure?
As for the propagation of the session id, there is only one
pseudo-secure
method -- using HTTP basic authentication. On authenticated pages, the
So if Im to write an online web-based banking system (either in
Java/JSP,
PHP, ASP - whatever)... what method would you suggest that IS secure?
As for the propagation of the session id, there is only one
pseudo-secure
method -- using HTTP basic authentication. On authenticated pages, the
Dan Hardiker:
However, HTTP basic authentication is passed the same as session
cookies
(discussed earlier in this thread) - in the headers of the HTTP
communication. This can very easily be faked with something like cURL.
On the other hand, if you know the user's credentials, why bother to
Melvyn Sopacua wrote:
At 15:46 14-8-2002, Alan Knowles wrote:
Can we not document the real issues about this in the manual, and just
say something like
There are security issues in using any type of sessions with HTTP,
please read the manual at
As much as I think trans-sid sucks from a performance perspective, what's
with this comment in php.ini-dist?
; trans sid support is disabled by default.
; Use of trans sid may risk your users security. It may not be
; feasible to use this option for some sites. Use this option with caution.
62 matches
Mail list logo
