On Mon, Sep 30, 2013 at 4:51 PM, Tjerk Meesters wrote:
> On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki wrote:
>
>> Hi Leigh,
>>
>> On Fri, Sep 27, 2013 at 7:12 PM, Leigh wrote:
>>
>>> So on a successful session hijack (correct SID, new IP) the attacker
>>> gets a new SID and keeps the valid sess
On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki wrote:
> Hi Leigh,
>
> On Fri, Sep 27, 2013 at 7:12 PM, Leigh wrote:
>
>> So on a successful session hijack (correct SID, new IP) the attacker
>> gets a new SID and keeps the valid session while the legitimate user
>> gets kicked out.
>>
>> Not seein
On Sat, Sep 28, 2013 at 2:07 PM, Sanford Whiteman
wrote:
>> ... ESPECIALLY since userland implementation is so trivial.
I do not see any new argument in this discussion since a couple of
days. If desired, I would suggest to create a RFC (should have been
done already :) and move to the next steps
> ... ESPECIALLY since userland implementation is so trivial.
"Trivial" for most users means "copy-paste an unmaintained class
library you found somewhere" so you haven't solved the problem. Unless
something comes from one of the few trusted security extensions or
from a top framework, it's doubtf
On 28 September 2013 12:25, Leigh wrote:
>
> On Sep 28, 2013 10:39 AM, "Peter Lind" wrote:
> >
> > So you're stuck with two choices: accept that PHP security is lax and
> that as a result a lot of code will have many attack vectors, or try to
> change the language itself for the better. The thir
On Sep 28, 2013 10:39 AM, "Peter Lind" wrote:
>
> So you're stuck with two choices: accept that PHP security is lax and
that as a result a lot of code will have many attack vectors, or try to
change the language itself for the better. The third option of "educate" is
a mirage.
>
PHP provides you
On 28 September 2013 11:27, Madara Uchiha wrote:
> You guys are missing the point. This isn't a language level issue. I
> can imagine some sort of package or a library being made, some sort of
> wrapper around the current session commands, perhaps integrated into
> some sort of extension.
>
> But
You guys are missing the point. This isn't a language level issue. I
can imagine some sort of package or a library being made, some sort of
wrapper around the current session commands, perhaps integrated into
some sort of extension.
But it is NOT a language level issue. This isn't a problem the
la
Hi Leigh,
On Fri, Sep 27, 2013 at 7:12 PM, Leigh wrote:
> So on a successful session hijack (correct SID, new IP) the attacker
> gets a new SID and keeps the valid session while the legitimate user
> gets kicked out.
>
> Not seeing how that improves things at all.
>
There are 2 improvements
1.
Hi,
On Fri, Sep 27, 2013 at 6:54 PM, Leigh wrote:
> On 27 September 2013 11:39, Peter Lind wrote:
> > On 27 September 2013 12:12, Leigh wrote:
> >>
> >> So on a successful session hijack (correct SID, new IP) the attacker
> >> gets a new SID and keeps the valid session while the legitimate us
On 27 September 2013 12:54, Leigh wrote:
> On 27 September 2013 11:39, Peter Lind wrote:
> > On 27 September 2013 12:12, Leigh wrote:
> >>
> >> So on a successful session hijack (correct SID, new IP) the attacker
> >> gets a new SID and keeps the valid session while the legitimate user
> >> get
On 27 September 2013 11:39, Peter Lind wrote:
> On 27 September 2013 12:12, Leigh wrote:
>>
>> So on a successful session hijack (correct SID, new IP) the attacker
>> gets a new SID and keeps the valid session while the legitimate user
>> gets kicked out.
>>
>> Not seeing how that improves things
On 27 September 2013 12:12, Leigh wrote:
> On 26 September 2013 11:32, Tjerk Meesters
> wrote:
> >
> > On Thu, Sep 26, 2013 at 6:19 PM, Leigh wrote:
> >>
> >> There's several scenarios where a users IP changes and you don't want to
> >> drop their session. (That doesn't mean it should simply ha
Am 27.09.13 12:12, schrieb Leigh:
> On 26 September 2013 11:32, Tjerk Meesters wrote:
>>
>> On Thu, Sep 26, 2013 at 6:19 PM, Leigh wrote:
>>>
>>> There's several scenarios where a users IP changes and you don't want to
>>> drop their session. (That doesn't mean it should simply have an option to
On 26 September 2013 11:32, Tjerk Meesters wrote:
>
> On Thu, Sep 26, 2013 at 6:19 PM, Leigh wrote:
>>
>> There's several scenarios where a users IP changes and you don't want to
>> drop their session. (That doesn't mean it should simply have an option to
>> disable it either)
>
>
> Let's be clea
> Under normal circumstances, entering elevator or tunnel would not loose
> session ID most likely since lost connection would not loose session ID.
> When end-users simply lost their connection, IP address wouldn't change.
There's good reason to believe that the "event" of being assigned a
new
Hi Standord,
On Fri, Sep 27, 2013 at 9:45 AM, Sanford Whiteman <
swhitemanlistens-softw...@cypressintegrated.com> wrote:
> > When URL based session is used, this feature should be
> > disabled as pages are cached by browsers.
>
> OK, I suppose, but that seems to be an edgier case than what we're
> When URL based session is used, this feature should be
> disabled as pages are cached by browsers.
OK, I suppose, but that seems to be an edgier case than what we're
already discussing.
> BTW, if connection is unstable and an app force user to logout,
> is it going to be a problem? It would dep
Hi Sanford,
On Fri, Sep 27, 2013 at 7:57 AM, Sanford Whiteman <
swhitemanlistens-softw...@cypressintegrated.com> wrote:
> > Users who are concerned for this situation should disable it. Users
> > who are concerned security should accept this case.
>
> I assume "users" are as we understand them he
> Users who are concerned for this situation should disable it. Users
> who are concerned security should accept this case.
I assume "users" are as we understand them here, i.e. me.
But as a developer-user I would likely want to empower my end-users to
turn off this feature themselves. With high-
> Let's be clear here: this won't happen (in most cases), because the client
> will simply get a new cookie and the session will keep working; it's like
> what you would implement if your user level goes from anonymous to logged
> in and vice versa.
I'm glad you addressed this because I'd been thi
Hi Tjerk,
On Thu, Sep 26, 2013 at 7:32 PM, Tjerk Meesters wrote:
>
>> Many people still have dynamic IP addresses for their home connections,
>> but
>> the group who would suffer the most would be mobile users. It's pretty
>> frustrating to use most sites with a phone as it is, without being kick
Hi,
On Thu, Sep 26, 2013 at 6:19 PM, Leigh wrote:
> On Sep 24, 2013 3:43 AM, "Laruence" wrote:
> >
> > I don't think this is language concerning issue.
> >
> > it could be done in user script..
> >
> > thanks
>
> I agree entirely with Laurence (and others). This shouldn't be a core
> feature.
On Sep 24, 2013 3:43 AM, "Laruence" wrote:
>
> I don't think this is language concerning issue.
>
> it could be done in user script..
>
> thanks
I agree entirely with Laurence (and others). This shouldn't be a core
feature. It's not one size fits all.
There's several scenarios where a users IP c
On Tue, Sep 24, 2013 at 4:29 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. Ther
Hi Madara,
On Thu, Sep 26, 2013 at 7:49 AM, Madara Uchiha wrote:
> Why couldn't this be implemented on userland again? I don't feel this
> is a language level issue.
>
PHP is not only language, but also meta framework.
It is better to think as how framework support session. IMHO.
I suppose ther
Why couldn't this be implemented on userland again? I don't feel this
is a language level issue.
On Wed, Sep 25, 2013 at 8:55 AM, Yasuo Ohgaki wrote:
> Hi Mike,
>
> On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks wrote:
>
>> Each and every type of prevention measure has consequences and not only
Hi Mike,
On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks wrote:
> Each and every type of prevention measure has consequences and not only
> that but MAJOR consequences. If you are detecting IP changes you rule out
> most if not all major proxy networks that exist. While not first of mind;
> wh
On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki wrote:
> Hi,
> On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara wrote:
>
>> When you have a group of front-end termination points in a pool, proxying
>> requests off to hundreds of machines for thousands of applications, tying a
>> session to any IP i
On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attackers. There
Hi Laruence,
On Tue, Sep 24, 2013 at 11:42 AM, Laruence wrote:
> I don't think this is language concerning issue.
>
> it could be done in user script..
>
Session should be managed as secure as possible.
We can promote better session management in document.
It's an option.
Regards,
--
Yasuo Oh
Hi,
On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara wrote:
> When you have a group of front-end termination points in a pool, proxying
> requests off to hundreds of machines for thousands of applications, tying a
> session to any IP is a headache. IMO, sessions are supposed to be tied to
> users
When you have a group of front-end termination points in a pool, proxying
requests off to hundreds of machines for thousands of applications, tying a
session to any IP is a headache. IMO, sessions are supposed to be tied to
users, not any given inbound IP that can, and may, jump between different
r
Hey:
On Tue, Sep 24, 2013 at 10:29 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> There isn't any good counter measure session hijack.
> However, we can regenerate session ID if IP address has changed.
> Hijacked users might notice that they have been logged out if session
> ID is regenerated by attacker
34 matches
Mail list logo
