Re: [Full-Disclosure] defense against session hijacking
Somewhat related, SCTP is a multi homed transport protocol. If it find a home in webapps, using IPs as IDs becomes harder. :-) Sam On Mon, 2003-11-17 at 16:16, Thomas M. Duffey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Sorry if this is common knowledge or regularly discussed; I'm fairly new to the list. I see quite a few messages on this and other security lists about session hijacking in Web applications. Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? Do many programmers really overlook this simple method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? Best Regards, - -- :: t h o m a s d u f f e y :: h o m e b o y z i n t e r a c t i v e -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/uTrH8fKWAp8CzDARAhyOAJ9kXkkiUERgEVRWhH5GtGACTKA1hwCfak+7 KsyUSQG+iAcPVxX3BIdTTRc= =9f2R -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
On Tuesday 18 November 2003 14:18, Jason Ziemba wrote: I'm not going to claim that my method is fool-proof, but.. If you are using sessions on your site then you should have the ability to track the movement of a user through-out your system. If you record the last page the user was on (with a specific session-id) and then check the referrer server variable on their next hit. Compare the referrer to their last known page. Most of the time (depending on the complexity of your site) the referrer and last known page should match. If their session is 'hijacked', odds are the 'hijacker' will not be following in a valid user's footsteps, more likely they will just be coming at the server with rogue data. The referrer check won't match and thus the validity of the session request is also void. Hello, if you open a link in a new tab or a new window and then open a link in the original tab/window, this check will fail and thus lock out legitimate users. Furthermore, it won't really help to improve security as the referer header can easily be spoofed. Regards Jakob ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
On Mon, 17 Nov 2003, Gary E. Miller wrote: Yo Thomas! Some ISPs like AOL use ganged proxies/caches. You may get the same session from different proxies as they round robin. Overly agressive web caches are a big problem for web apps. not to mention that IP's can be spoofed. Thanks, Ron DuFresne ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
I'm not going to claim that my method is fool-proof, but.. If you are using sessions on your site then you should have the ability to track the movement of a user through-out your system. If you record the last page the user was on (with a specific session-id) and then check the referrer server variable on their next hit. Compare the referrer to their last known page. Most of the time (depending on the complexity of your site) the referrer and last known page should match. If their session is 'hijacked', odds are the 'hijacker' will not be following in a valid user's footsteps, more likely they will just be coming at the server with rogue data. The referrer check won't match and thus the validity of the session request is also void. The catch is, how much programming are you willing to do to ensure the integrity of your system. If you are looking for the easy-route (using PHP's embedded session module) then there is no direct way to secure the sessions. If you are willing to build you own session module for your given CGI language then the sky is the limit (as long as you are willing to get your hands dirty at the start). Jason Ziemba -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Sorry if this is common knowledge or regularly discussed; I'm fairly new to the list. I see quite a few messages on this and other security lists about session hijacking in Web applications. Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? Do many programmers really overlook this simple method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? Best Regards, - -- :: t h o m a s d u f f e y :: h o m e b o y z i n t e r a c t i v e -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/uTrH8fKWAp8CzDARAhyOAJ9kXkkiUERgEVRWhH5GtGACTKA1hwCfak+7 KsyUSQG+iAcPVxX3BIdTTRc= =9f2R -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
Hi, Am Mon, 2003-11-17 um 22.16 schrieb Thomas M. Duffey: method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? why you don't force session handling with cookies and set session lifetime to 20mins (or so)? Bart ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
If you record the last page the user was on (with a specific session-id) and then check the referrer server variable on their next hit. Compare the referrer to their last known page. Most of the time (depending on the complexity of your site) the referrer and last known page should match. If their session is 'hijacked', odds are the 'hijacker' will not be following in a valid user's footsteps, more likely they will just be coming at the server with rogue data. The referrer check won't match and thus the validity of the session request is also void. 1. The referrer header is an optional header in HTTP. Most current browsers send it, but some allow you to turn it off entirely for privacy reasons. 2. The referrer header is trivial to spoof, since it comes from the client, and HTTP is more or less a stateless protocol between requests. Conclusion: Your suggestion is in no way more secure, and it requires users to turn on the referrer header, which they may not feel comfortable doing, generally. As for a constructive suggestion: Fix your cross site scripting holes. Doing so is the best way to avoid session hijacking. Design your apps from the ground up to be secure. Quote anything remotely resembling HTML that comes from an untrusted source and is displayed on your dynamic pages. cheers, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] defense against session hijacking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Sorry if this is common knowledge or regularly discussed; I'm fairly new to the list. I see quite a few messages on this and other security lists about session hijacking in Web applications. Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? Do many programmers really overlook this simple method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? Best Regards, - -- :: t h o m a s d u f f e y :: h o m e b o y z i n t e r a c t i v e -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/uTrH8fKWAp8CzDARAhyOAJ9kXkkiUERgEVRWhH5GtGACTKA1hwCfak+7 KsyUSQG+iAcPVxX3BIdTTRc= =9f2R -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
On Mon, Nov 17, 2003 at 03:16:55PM -0600, Thomas M. Duffey wrote: Sorry if this is common knowledge or regularly discussed; I'm fairly new to the list. I see quite a few messages on this and other security lists about session hijacking in Web applications. Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? Do many programmers really overlook this simple method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? This would break things like NATed machines and such. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
Yo Thomas! Some ISPs like AOL use ganged proxies/caches. You may get the same session from different proxies as they round robin. Overly agressive web caches are a big problem for web apps. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Mon, 17 Nov 2003, Thomas M. Duffey wrote: Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
Hey Thomas this has been discussed many times in the past and basically it boils down to these problems: 1. Many corporations use proxies so everyone appears to come from one IP address. A session based only on IP will have some pretty bad results like session jumping without people trying. 2. Large ISPs (AOL, Sympatico.ca, etc...) use super proxies that cause their clients to not only come from 1 IP but also these clients can hop across entire class A networks. This means your users get pretty mad when they keep getting kicked off. 3. Given 1 and 2 will cause you all sorts of problems it is easier (not more secure) to go with psuedo-random session-ids. If you have an application that is in a tightly controlled environment (like LAN access only) then IPs can be considered. Although with remote access/VPN and B2B access this can also be problematic. On Nov 17, 2003, at 1:16 PM, Thomas M. Duffey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Sorry if this is common knowledge or regularly discussed; I'm fairly new to the list. I see quite a few messages on this and other security lists about session hijacking in Web applications. Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? Do many programmers really overlook this simple method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? Best Regards, - -- :: t h o m a s d u f f e y :: h o m e b o y z i n t e r a c t i v e -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/uTrH8fKWAp8CzDARAhyOAJ9kXkkiUERgEVRWhH5GtGACTKA1hwCfak+7 KsyUSQG+iAcPVxX3BIdTTRc= =9f2R -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html --- Bill Pennington, CISSP, CCNA Chief Technology Officer WhiteHat Security Inc. http://www.whitehatsec.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
On Mon, 2003-11-17 at 14:16, Thomas M. Duffey wrote: Hi All, Sorry if this is common knowledge or regularly discussed; I'm fairly new to the list. I see quite a few messages on this and other security lists about session hijacking in Web applications. Isn't it good defense for a programmer to store the IP address of the client when the session is initiated, and then compare that address against the client for each subsequent request, destroying the session if the address changes? Do many programmers really overlook this simple method to protect against such an attack? It's not perfect but should significantly increase the difficulty of such an attack with little or no annoying side effects for the legitimate user. Would it be useful to extend the session modules of the common Web scripting languages (e.g. PHP) to enable an IP address check by default? Best Regards, - -- :: t h o m a s d u f f e y :: h o m e b o y z i n t e r a c t i v e Defense is not always an objective of programmers. Often they have a goal to make it work then apply security as an afterthought. Security is often an added burden in the debugging process too, because when you are troubleshooting data on the wire, its much easier to spot a problem if it is sent unencrypted. There are major packages out there that will restrict a session to an IP (bugzilla.mozilla.org). SourceForge offers an option to stay in SSL after authentication which by not letting any other session variables be seen, should also go far towards preserving integrity. At the server side, although initially obvious that basing session information on an IP address makes sense - there are proxies and other methods of load balancing that throw a wrench in that plan. Often just plain keeping a hash string either in the url or in a cookie on the client is the only way to accurately track sessions from a user. Often the tradeoff that is made is to keep session continuity as a priority (thus allowing hijacking by capturing URLs), possibly mitigated by changing that string each time so that a captured URL would no longer be valid after the real user clicks on another page... But then passing the appropriate information (shopping cart for example) to another server or an encrypted session on the same server - but requiring fresh authentication moments before purchasing using stored information. This way a hijacked shopping session does no good without successfully authenticating to the purchasing server. -- Scott Taylor - [EMAIL PROTECTED] BOFH Excuse #149: Dew on the telephone lines. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
On Mon, 2003-11-17 at 16:44, Damian Gerow wrote: Thus spake David Maynor ([EMAIL PROTECTED]) [17/11/03 17:30]: This would break things like NATed machines and such. Could you explain how, please? I think David was hinting at pooled NAT address. Image an internal network that gets NATed to addresses a.b.c.d.5 until a.b.c.d.12. Kinda like Gary's ganged proxies. The debates over using IP addresses, ports, TTLs and other connection based elements do come up from time to time. However, you are trying to authenticate/verify the user on the other end, not networking equipment in between. Logically you should check user elements (such as browser ID perhaps). Or wrap it in SSL, use hard to guess/brute session ID's and hope for the best like the rest if us :) Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] defense against session hijacking
David Maynor wrote: This would break things like NATed machines and such. Could you please elaborate? -- [EMAIL PROTECTED] AIM: l4m3n00b MSN: [EMAIL PROTECTED] http://www.instable.net GnuPG Public Key: http://www.instable.net/pubkey.asc Please forgive my English, I'm an American. The only sovereign you can allow to rule you is reason. - Wizard's Sixth Rule, Faith of the Fallen by Terry Goodkind pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] defense against session hijacking
Thus spake David Maynor ([EMAIL PROTECTED]) [17/11/03 17:30]: This would break things like NATed machines and such. Could you explain how, please? If machine A gets NATed to firewall B, and webserver C gets the session... It's going to record the address of firewall B, not machine A. I fail to see how using the connection source's IP address would break NAT.* And I don't know what you mean by 'and such'. Not that I think basing your entire session security on the IP address is a good idea -- proxies and such. Using it as *part* of your session security (onions, people, onions) might work, depending on how a networks round-robin'ed proxies are set up, if the session really *is* needed to be carried cross-machine (I've done it before), or any other reason I haven't thought of yet. FWIW, (and I know how hated they are), SecurityFocus has a mailing list specifically for web application security -- [EMAIL PROTECTED], I believe. - Damian * = The only thing I could think of is session hijacking, if the source IP is your only method of session security, by other machines behind the same NATing gateway. This is possible. Again, onions. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
On Mon, Nov 17, 2003 at 05:44:24PM -0500, Damian Gerow wrote: Thus spake David Maynor ([EMAIL PROTECTED]) [17/11/03 17:30]: This would break things like NATed machines and such. Could you explain how, please? If machine A gets NATed to firewall B, and webserver C gets the session... It's going to record the address of firewall B, not machine A. I fail to see how using the connection source's IP address would break NAT.* And I don't know what you mean by 'and such'. You assume a straight 1 to 1 natting, that is not always the case. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] defense against session hijacking
Thus spake Frank Knobbe ([EMAIL PROTECTED]) [17/11/03 18:01]: I think David was hinting at pooled NAT address. Image an internal network that gets NATed to addresses a.b.c.d.5 until a.b.c.d.12. Kinda like Gary's ganged proxies. Ah, okay. That makes a little more sense. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
