RE: [WEB SECURITY] Session hijacking protection

["Boaz Shunami" <BoazS@xxxxxxxxxxxxxxxx>]

------_=_NextPart_001_01C7C2B8.78E5332A
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi Frederic,
=20
You can also consider 2FA - Two Factor Authentication, hence linking the =
session to a token of some sort.
=20
Best Regards,
=20
Boaz Shunami
Division Manager, Technology Services
Comsec Consulting B.V.

=20

________________________________

=EE=E0=FA: Gabriel K?lin [mailto:Gabriel.Kaelin@visonys.com]
=F0=F9=EC=E7: =E1 09/07/2007 13:17
=E0=EC: frederic.lebeau@websurf.be; websecurity@webappsec.org
=F0=E5=F9=E0: AW: [WEB SECURITY] Session hijacking protection



Hi Frederic

I think the article is well written in that it provides an attempt of how=
 to link user information other than just the cookie value for session ac=
cess granting. But the measures are still very primitive and it's worthfu=
l to have a look at the caveats as pointed out in the article.

If you want a website to be accessible for everybody, you probably don't =
want to exclude a user group just because one simple criterium - such as =
a constant IP or network address - is not met. As long as there are "regu=
lar" situations that can result in a violation of your criteria, you may =
turn away clients from the website.

Of course it always depends on the user base of your application how rest=
rictive you want to be. In a company-network, you may have control over t=
he clients and the network they use, so you can be more restrictive and g=
rant access based on simple criteria.

In general, however, I think, the way to go is rather that you think of f=
lexible metrics that end in an indication how "sane" a session is, assumi=
ng the request will be processed. Changes in properties of a request can =
be reflected as a change in the sanity-level of a session. As properties =
of a request you can think of the source IP-address, HTTP headers, SSL se=
ssion ID or combinations thereof etc. Finally, based on the sanity-level,=
 you can decide what action to take, e.g. denying access or raising an al=
ert.

A major difference to the method in the article is, that a request is gra=
nted access based on request and session history and without the need of =
modifying a cookie with a hmac.

I'm not aware of any framework using such a mechanism and it's not obviou=
s what criteria are most powerful to prevent session hijacking. I'm wonde=
ring whether some people have more information about such metrics.

Gabriel

________________________________

Von: frederic.lebeau@websurf.be [mailto:frederic.lebeau@websurf.be]
Gesendet: Do 05.07.2007 14:00
An: websecurity@webappsec.org
Betreff: [WEB SECURITY] Session hijacking protection



Hello,

I'm investigating about session linkage with IP adress + other user relat=
ed
info.
An old article i'v found:
http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/

What do you think about this kind of protection?
Is there other user parameters that we can use to trust the user?

Thanks for the feedback wich is always very interesting...


-------------------------------------------------------------------------=
---
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]




-------------------------------------------------------------------------=
---
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]



*************************************************************************=
*************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager=
 or  the=20
sender immediately and do not disclose the contents to anyone or make cop=
ies.

** eSafe scanned this email for viruses, vandals and malicious content. *=
*
*************************************************************************=
*************************
------_=_NextPart_001_01C7C2B8.78E5332A
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dwindows=
-1255">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7233.6=
9">
<TITLE>AW: [WEB SECURITY] Session hijacking protection</TITLE>
</HEAD>
<BODY>
<DIV id=3DidOWAReplyText29422 dir=3Drtl>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#000000 size=3D2>H=
i=20
Frederic,</FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DI=
V>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>You can also cons=
ider 2FA - Two=20
Factor Authentication, hence linking the session to a token of some=20
sort.</FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DI=
V>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>Best Regards,</FO=
NT></DIV>
<DIV dir=3Drtl><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;<=
/DIV></DIV>
<DIV id=3DidSignature79155 dir=3Drtl><FONT face=3DArial color=3D#000000 s=
ize=3D2>
<DIV class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; DIRECTION: ltr; unicode-bidi: embed; TEXT-A=
LIGN: left; mso-layout-grid-align: none"=20
align=3Dleft><FONT face=3DVerdana><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Tahoma">Boaz=20
Shunami</SPAN><SPAN style=3D"COLOR: navy"><?xml:namespace prefix =3D o ns=
 =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></FONT></DI=
V>
<DIV class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; DIRECTION: ltr; unicode-bidi: embed; TEXT-A=
LIGN: left; mso-layout-grid-align: none"=20
align=3Dleft><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Ta=
homa"><FONT=20
face=3DVerdana>Division Manager, Technology Services<BR></FONT><I><FONT=20
face=3DVerdana><STRONG>Comsec Consulting B.V<SPAN=20
class=3DGramE>.</SPAN></STRONG><BR></FONT></I></SPAN></DIV>
<DIV class=3DMsoNormal dir=3Dltr=20
style=3D"MARGIN: 0cm 0cm 0pt; DIRECTION: ltr; unicode-bidi: embed; TEXT-A=
LIGN: left; mso-layout-grid-align: none"=20
align=3Dleft></FONT><FONT face=3DArial color=3D#000000 size=3D2><SPAN=20
style=3D"mso-bookmark: _MailAutoSig"><FONT size=3D3><B><I><SPAN=20
style=3D"COLOR: navy; FONT-FAMILY: 'Book Antiqua'; mso-no-proof: yes"></S=
PAN></I></B></FONT></SPAN>&nbsp;</DIV></FONT></DIV>
<DIV dir=3Dltr><BR></DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>=EE=E0=FA:</B> Gabriel K&#=
228;lin=20
[mailto:Gabriel.Kaelin@visonys.com]<BR><B>=F0=F9=EC=E7:</B> =E1 09/07/200=
7=20
13:17<BR><B>=E0=EC:</B> frederic.lebeau@websurf.be;=20
websecurity@webappsec.org<BR><B>=F0=E5=F9=E0:</B> AW: [WEB SECURITY] Sess=
ion hijacking=20
protection<BR></FONT><BR></DIV>
<P dir=3Dltr><FONT size=3D2>Hi Frederic<BR><BR>I think the article is wel=
l written=20
in that it provides an attempt of how to link user information other than=
 just=20
the cookie value for session access granting. But the measures are still =
very=20
primitive and it's worthful to have a look at the caveats as pointed out =
in the=20
article.<BR><BR>If you want a website to be accessible for everybody, you=
=20
probably don't want to exclude a user group just because one simple crite=
rium -=20
such as a constant IP or network address - is not met. As long as there a=
re=20
"regular" situations that can result in a violation of your criteria, you=
 may=20
turn away clients from the website.<BR><BR>Of course it always depends on=
 the=20
user base of your application how restrictive you want to be. In a=20
company-network, you may have control over the clients and the network th=
ey use,=20
so you can be more restrictive and grant access based on simple=20
criteria.<BR><BR>In general, however, I think, the way to go is rather th=
at you=20
think of flexible metrics that end in an indication how "sane" a session =
is,=20
assuming the request will be processed. Changes in properties of a reques=
t can=20
be reflected as a change in the sanity-level of a session. As properties =
of a=20
request you can think of the source IP-address, HTTP headers, SSL session=
 ID or=20
combinations thereof etc. Finally, based on the sanity-level, you can dec=
ide=20
what action to take, e.g. denying access or raising an alert.<BR><BR>A ma=
jor=20
difference to the method in the article is, that a request is granted acc=
ess=20
based on request and session history and without the need of modifying a =
cookie=20
with a hmac.<BR><BR>I'm not aware of any framework using such a mechanism=
 and=20
it's not obvious what criteria are most powerful to prevent session hijac=
king.=20
I'm wondering whether some people have more information about such=20
metrics.<BR><BR>Gabriel<BR><BR>________________________________<BR><BR>Vo=
n:=20
frederic.lebeau@websurf.be [<A=20
href=3D"mailto:frederic.lebeau@websurf.be";>mailto:frederic.lebeau@websurf=
=2Ebe</A>]<BR>Gesendet:=20
Do 05.07.2007 14:00<BR>An: websecurity@webappsec.org<BR>Betreff: [WEB SEC=
URITY]=20
Session hijacking protection<BR><BR><BR><BR>Hello,<BR><BR>I'm investigati=
ng=20
about session linkage with IP adress + other user related<BR>info.<BR>An =
old=20
article i'v found:<BR><A=20
href=3D"http://msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/";>http:=
//msdn.microsoft.com/msdnmag/issues/04/08/WickedCode/</A><BR><BR>What=20
do you think about this kind of protection?<BR>Is there other user parame=
ters=20
that we can use to trust the user?<BR><BR>Thanks for the feedback wich is=
 always=20
very=20
interesting...<BR><BR><BR>-----------------------------------------------=
-----------------------------<BR>Join=20
us on IRC: irc.freenode.net #webappsec<BR><BR>Have a question? Search The=
 Web=20
Security Mailing List Archives:<BR><A=20
href=3D"http://www.webappsec.org/lists/websecurity/";>http://www.webappsec=
=2Eorg/lists/websecurity/</A><BR><BR>Subscribe=20
via RSS:<BR><A=20
href=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.webappse=
c.org/rss/websecurity.rss</A>=20
[RSS=20
Feed]<BR><BR><BR><BR><BR>------------------------------------------------=
----------------------------<BR>Join=20
us on IRC: irc.freenode.net #webappsec<BR><BR>Have a question? Search The=
 Web=20
Security Mailing List Archives:<BR><A=20
href=3D"http://www.webappsec.org/lists/websecurity/";>http://www.webappsec=
=2Eorg/lists/websecurity/</A><BR><BR>Subscribe=20
via RSS:<BR><A=20
href=3D"http://www.webappsec.org/rss/websecurity.rss";>http://www.webappse=
c.org/rss/websecurity.rss</A>=20
[RSS Feed]<BR><BR></FONT></P>

*************************************************************************=
*************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager=
 or  the=20
sender immediately and do not disclose the contents to anyone or make cop=
ies.

** eSafe scanned this email for viruses, vandals and malicious content. *=
*
*************************************************************************=
*************************
</BODY>
</HTML>
------_=_NextPart_001_01C7C2B8.78E5332A--