Re: [jug-discussion] HttpSession question...
Embedding encrypted info about things like the domain, ip address, and user credentials in the cookie as well as a timeout for the cookie can make it very difficult to spoof though. Ollie On Thu, 2004-02-19 at 23:46, Nicholas Lesiecki wrote: I second Andy. BTW, It is possible to spoof someone else's session id cookie, posing a security risk. An application with serious security concerns (banking, ecommerce) would need to pay attention to this vulnerability. Nick On Feb 19, 2004, at 10:41 PM, Andrew Barton wrote: Hi Robert, Your understanding is the same as mine. But, the security question you pose is interesting. I wonder if it would be possible to change your session ID and access someone else's session. Depending on the application, this could be a security risk. I'll have to look into that... Andy On 2/19/04 8:55 PM, Robert Zeigler [EMAIL PROTECTED] wrote: Recently, somebody proposed an interesting question to me which, though I'm pretty sure I know the answer, I've been unable to verify. So, I decided to turn here to see if someone with more wisdom than I had an answer. ;) My understanding of HttpSessions is that, unless you specifically write something to a cookie, the only thing stored on the client side is the sessionID (either via a cookie or via URL rewriting). However, if I do a session.setAttribute(someattr,someobject), that object is simply stored (typically in memory, though not necessarily) server side, available in the web application context. Correct so far? In other words, session attributes are not directly editable client side... right? I mean, this makes complete sense to me, as the client in a web app really doesn't give a hoot about foo or bar, it just wants html. However, someone made a claim to me recently that some information stored as a session attribute could be alterred directly by the user, client side, and therefore posed a security risk to a particular application. Any thoughts? Thanks for the help on this... I've looked over the javadocs, etc., and while they don't say anything to negate my viewpoint, they also don't say anything specifically to validate it. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Barton eBlox, Inc. 520.903.2541 x102 voice 520.903.2542 fax Discover storeBlox and webBlox at the new eBlox.com! http://www.eblox.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] HttpSession question...
Not to diverge too far from the topic, but... Even with encryption you have to careful, as the WEP (Wired Equivalent Privacy, part of the 802.11 spec) folks found out the hard way. I don't recall what the relevant data were, but some part of WEP involved sending some bytes and a crc-32 checksum of those bytes encrypted with some kind of stream cipher (RC-4?). The checksum was intended to allow the recipient to verify the integrity of the data. However, an attacker could modify the encrypted message so that the bytes were modified and the checksum was changed appropriately. This was only one of several attacks on WEP related to bad crypto usage. So depending on the kind of cipher you use, it is possible to make directed changes to the ciphertext without having any knowledge of the key. Therefore, it's sometimes crucial to use a cryptographically secure message authentication code, like SHA-1, before trusting your plaintext. In fact, it seems to be enough in the case we're talking about here to use only a MAC, without encryption. You just have to hash in something the client doesn't know, like a 128 bit random number, or else the client can just recompute the hash... Michael Oliver wrote: Embedding encrypted info about things like the domain, ip address, and user credentials in the cookie as well as a timeout for the cookie can make it very difficult to spoof though. Ollie On Thu, 2004-02-19 at 23:46, Nicholas Lesiecki wrote: I second Andy. BTW, It is possible to spoof someone else's session id cookie, posing a security risk. An application with serious security concerns (banking, ecommerce) would need to pay attention to this vulnerability. Nick On Feb 19, 2004, at 10:41 PM, Andrew Barton wrote: Hi Robert, Your understanding is the same as mine. But, the security question you pose is interesting. I wonder if it would be possible to change your session ID and access someone else's session. Depending on the application, this could be a security risk. I'll have to look into that... Andy On 2/19/04 8:55 PM, Robert Zeigler [EMAIL PROTECTED] wrote: Recently, somebody proposed an interesting question to me which, though I'm pretty sure I know the answer, I've been unable to verify. So, I decided to turn here to see if someone with more wisdom than I had an answer. ;) My understanding of HttpSessions is that, unless you specifically write something to a cookie, the only thing stored on the client side is the sessionID (either via a cookie or via URL rewriting). However, if I do a session.setAttribute(someattr,someobject), that object is simply stored (typically in memory, though not necessarily) server side, available in the web application context. Correct so far? In other words, session attributes are not directly editable client side... right? I mean, this makes complete sense to me, as the client in a web app really doesn't give a hoot about foo or bar, it just wants html. However, someone made a claim to me recently that some information stored as a session attribute could be alterred directly by the user, client side, and therefore posed a security risk to a particular application. Any thoughts? Thanks for the help on this... I've looked over the javadocs, etc., and while they don't say anything to negate my viewpoint, they also don't say anything specifically to validate it. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Barton eBlox, Inc. 520.903.2541 x102 voice 520.903.2542 fax Discover storeBlox and webBlox at the new eBlox.com! http://www.eblox.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I say to you that the VCR is to the American film producer and the American public as the Boston strangler is to the woman home alone. -Jack Valenti, President, Motion Picture Association of America, Inc., before The House Subcommittee on Courts, Civil Liberties, and The Administration of Justice, August, 1982, http://cryptome.org/hrcw-hear.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] HttpSession question...
I think you are right, otherwise the J2EE spec would be insecure by definition. A *request* attribute can be changed just by appending it as a URL parameter, but that is really just another name for a form field. Maybe that is what they are thinking of. Robert Zeigler wrote: However, someone made a claim to me recently that some information stored as a session attribute could be alterred directly by the user, client side, and therefore posed a security risk to a particular application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] HttpSession question...
That's what I was thinking... but I wanted to bounce it off someone to make sure I wasn't going crazy. ;) Thanks for the validation. =) Robert Chad Woolley wrote: I think you are right, otherwise the J2EE spec would be insecure by definition. A *request* attribute can be changed just by appending it as a URL parameter, but that is really just another name for a form field. Maybe that is what they are thinking of. Robert Zeigler wrote: However, someone made a claim to me recently that some information stored as a session attribute could be alterred directly by the user, client side, and therefore posed a security risk to a particular application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] HttpSession question...
Hi Robert, Your understanding is the same as mine. But, the security question you pose is interesting. I wonder if it would be possible to change your session ID and access someone else's session. Depending on the application, this could be a security risk. I'll have to look into that... Andy On 2/19/04 8:55 PM, Robert Zeigler [EMAIL PROTECTED] wrote: Recently, somebody proposed an interesting question to me which, though I'm pretty sure I know the answer, I've been unable to verify. So, I decided to turn here to see if someone with more wisdom than I had an answer. ;) My understanding of HttpSessions is that, unless you specifically write something to a cookie, the only thing stored on the client side is the sessionID (either via a cookie or via URL rewriting). However, if I do a session.setAttribute(someattr,someobject), that object is simply stored (typically in memory, though not necessarily) server side, available in the web application context. Correct so far? In other words, session attributes are not directly editable client side... right? I mean, this makes complete sense to me, as the client in a web app really doesn't give a hoot about foo or bar, it just wants html. However, someone made a claim to me recently that some information stored as a session attribute could be alterred directly by the user, client side, and therefore posed a security risk to a particular application. Any thoughts? Thanks for the help on this... I've looked over the javadocs, etc., and while they don't say anything to negate my viewpoint, they also don't say anything specifically to validate it. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Barton eBlox, Inc. 520.903.2541 x102 voice 520.903.2542 fax Discover storeBlox and webBlox at the new eBlox.com! http://www.eblox.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] HttpSession question...
I second Andy. BTW, It is possible to spoof someone else's session id cookie, posing a security risk. An application with serious security concerns (banking, ecommerce) would need to pay attention to this vulnerability. Nick On Feb 19, 2004, at 10:41 PM, Andrew Barton wrote: Hi Robert, Your understanding is the same as mine. But, the security question you pose is interesting. I wonder if it would be possible to change your session ID and access someone else's session. Depending on the application, this could be a security risk. I'll have to look into that... Andy On 2/19/04 8:55 PM, Robert Zeigler [EMAIL PROTECTED] wrote: Recently, somebody proposed an interesting question to me which, though I'm pretty sure I know the answer, I've been unable to verify. So, I decided to turn here to see if someone with more wisdom than I had an answer. ;) My understanding of HttpSessions is that, unless you specifically write something to a cookie, the only thing stored on the client side is the sessionID (either via a cookie or via URL rewriting). However, if I do a session.setAttribute(someattr,someobject), that object is simply stored (typically in memory, though not necessarily) server side, available in the web application context. Correct so far? In other words, session attributes are not directly editable client side... right? I mean, this makes complete sense to me, as the client in a web app really doesn't give a hoot about foo or bar, it just wants html. However, someone made a claim to me recently that some information stored as a session attribute could be alterred directly by the user, client side, and therefore posed a security risk to a particular application. Any thoughts? Thanks for the help on this... I've looked over the javadocs, etc., and while they don't say anything to negate my viewpoint, they also don't say anything specifically to validate it. Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Barton eBlox, Inc. 520.903.2541 x102 voice 520.903.2542 fax Discover storeBlox and webBlox at the new eBlox.com! http://www.eblox.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
