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
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. Therefore, users have slight chance
to notice that they were under att
35 matches
Mail list logo
