Re: Session Security
Simple solution: use SSL for all pages that have a session. AFAIK there's no way to keep a session secure without it all being over SSL. So the login process must be over SSL, and then everything until log-out should be over SSL also (I'm making the assumption that you're only using sessions for a restricted area of the site). See www.owasp.org for excellent information on securing web apps. http://www.owasp.org/documentation/topten/a3.html covers session management. Martin Jagadeesha T wrote: Hi All, Cookie information goes to the server in a clear text I think. I don't know it can be configured to send as a cypher text. When it goes in the network to browser, If not ssl enabled, Cookie;Jsessionid;value can be seen through Ethereal and also copied, If anybody tries with that cookie with the url. It will take the person to directly to that page.How can disable it. Please could anybody tell me how to avoid it. Thanks, Jagadeesha T __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session security questions?
Chris, I just had a discussion with Harry Mantheakis concerning the same point. Of course it is always good (and often necessary) to secure the sessionid (with SSL). In the time of "mega-proxies" with more than one IP address comparing IP addresses won't be of much use. Andreas Mohrig -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 2:16 PM To: Tomcat Users List Subject: Re: session security questions? Andreas, >> 1. Where is the session variable stored? server side or client >> cookie? > However, > the sessionid is passed back and forth between the server and the > client, of course. But that should not be a problem, because of the > (pseudo) random and quite complex nature of sessionids it would be > hard to guess someone else's sessionid. Yes, it's hard to guess the id of a session. However, if you were to snoop HTTP traffic and intercepted someone's HTTP header, then you could easily use that session id to hijack someone else's session by submitting the same cookie header to the server. You can try other techniques of preventing this from happening, including comparing IP addresses from requests (see the archives for a discussion of this; including how it doesn't always work!). -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session security questions?
Andreas, 1. Where is the session variable stored? server side or client cookie? However, the sessionid is passed back and forth between the server and the client, of course. But that should not be a problem, because of the (pseudo) random and quite complex nature of sessionids it would be hard to guess someone else's sessionid. Yes, it's hard to guess the id of a session. However, if you were to snoop HTTP traffic and intercepted someone's HTTP header, then you could easily use that session id to hijack someone else's session by submitting the same cookie header to the server. You can try other techniques of preventing this from happening, including comparing IP addresses from requests (see the archives for a discussion of this; including how it doesn't always work!). -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session security questions?
Vincent, 1. If you put some object into session-scope, it will be stored on the server (in the memory occupied by the java-process executing your webapp). Some persistence mechanisms may save it to disk or into a database. But you would know if that is the case for you. However, the sessionid is passed back and forth between the server and the client, of course. But that should not be a problem, because of the (pseudo) random and quite complex nature of sessionids it would be hard to guess someone else's sessionid. 2. I do not know of such a possibilitie, and it would certainly be a serious bug. However, anyone having root/administrator-access to your machine could probably tamper with the memory and thereby manipulating you session-state. But that would be the least of your problems, then. 3. If that would be the case, you would have to trust what the client sends you. This is generally a very bad idea for security reasons (anyone can fake what he sends to you if he knows what he's doing). But luckily this is not the case. Greetings Andreas Mohrig -Original Message- From: Vincent Chen [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 11:37 AM To: [EMAIL PROTECTED] Subject: session security questions? Hi, all I am running tomcat as application server and using session to store objects which will determine what dynamic content will be displayed. It's typical, but I have the following question: 1. Where is the session variable stored? server side or client cookie? 2. If variables stored in server side, is it possible to fake it and is there a proof of concept exists? 3. If variable stored in client cookie, I have the same question for point 2. Thanks, Vincent - 每天都 Yahoo!奇摩 海的顏色、風的氣息、愛你的溫度,盡在信紙底圖 http://tw.promo.yahoo.com/mail_premium/stationery.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Security
In a previous life, I used a similar technique and was defeated when the network guys put a cache engine in front of our servers. Then, all requests came from the same IP address. This sort of thing can happen based on other priorities in the organization and break your best solutions. The main thing with security is to determine who the threat is and how difficult you want to make bypassing your security. In many cases, the added expense (in time and money) is not worth the slim chance that you are trying to eliminate. I don't know if that is the case for you, but it's worth some review before trying to build a security system. For the most bang for the buck, only allow access to the admin portions through SSL. This encrypts the cookie along with the rest of the request. The only thing you'd have left to worry about is physical security of the system. G. Wade Sjoerd van Leent wrote: > > Here is a question to do the same without cookies, so storing something > in a cookie just won't work at al. I know that an IP address is not the > best solution at all, but when you're using an internal network, it will > work. I agree that using an IP address is by far not the best solution, > but the odds are low... > > Sjoerd > > -Original Message- > From: Mike Cherichetti (Renegade Internet) > [mailto:[EMAIL PROTECTED] > Sent: zondag 17 augustus 2003 22:29 > To: Tomcat Users List > Subject: RE: Session Security > > Todd, > > Putting the IP address of the user in the session won't work too well. > An > AOL user for example may have a different IP address every time they > send in > a request. And, it's obviously possible for someone to spoof an IP > address. > > The best solution I've found to prevent sessions from being stolen is to > use > a one time access token. The token, which I usually create by doing > MD5(ip > + timestamp + random #), gets stored in a cookie and in the session > itself. > So, say a user logs in, they get a token and when they come back with > their > next request they send in that token. Your authentication logic checks > the > token in the cookie against the token in the session and handles > accepting > or denying the request. When the response is processed, you give them a > new > token and continue this cycle for all requests to follow. > > Now, lets say someone manages to steal the session. That person is > going to > get a different token than the legitimate user that's logged in > currently > has. So, when the legitimate user sends in their next request with a > wrong > token, you should catch that the session has been compromised and > invalidate > it immediately. This will result in the malicious user being kicked > out. > > Still, this isn't a perfect solution because most users forget to > logout. > Using a low timeout value for the session is the only way I know of to > deal > with this scenario. You could run your application under HTTPS instead > of > HTTP too if that's an option :) > > Hope that helps, > Mike > > -Original Message- > From: Todd O'Bryan [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 17, 2003 2:45 PM > To: [EMAIL PROTECTED] > Subject: Session Security > > Is there any block against someone stealing someone else's session id > and using it for nefarious purposes? In other words, if I write a grade > book program, could a sharp student write down the session id from a > web address (if cookies are off) or look in the teacher's cookie file, > and then go to a computer in the library and use the same session id to > connect to the grade book page before the teacher logs out? > > Does the session id check itself against the issuing computer's IP > address or anything to prevent such a thing from happening? I realize > it's a stretch that someone might leave their computer unattended long > enough for such a thing to happen, but I just want to be sure. Also, > could someone listening in to the net traffic grab the session id and > then use it? > > Thanks, > Todd > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Security
I would avoid basing security on IP address, in addition to the spoofing attack already mentioned, some proxy servers and cache engines replace the source IP address when they pass the request to your server. Under these circumstances, everyone seems to come from the same IP address. As recommended, a good book (or expert) on security is a requirement for looking at these kinds of problems. There is almost always more to it than you think. G. Wade Sjoerd van Leent wrote: > > An easy workaround is to save the client IP-address in the session, and > look each page if this IP-address is the address the client has. It's > not waterproof, but it makes it far more difficult (ensure that a good > router is available) > > Sjoerd van Leent > > -Original Message- > From: Richard Dunn [mailto:[EMAIL PROTECTED] > Sent: zondag 17 augustus 2003 21:02 > To: Tomcat Users List > Subject: Re: Session Security > > On Sunday 17 August 2003 12:44, Todd O'Bryan wrote: > > Is there any block against someone stealing someone else's session id > > and using it for nefarious purposes? In other words, if I write a > grade > > book program, could a sharp student write down the session id from a > > web address (if cookies are off) or look in the teacher's cookie file, > > and then go to a computer in the library and use the same session id > to > > connect to the grade book page before the teacher logs out? > > > > Does the session id check itself against the issuing computer's IP > > address or anything to prevent such a thing from happening? I realize > > it's a stretch that someone might leave their computer unattended long > > enough for such a thing to happen, but I just want to be sure. Also, > > could someone listening in to the net traffic grab the session id and > > then use it? > > > > Thanks, > > Todd > > I am not a security expert, but if someone with my limited knowledge on > security can use a tool like tcpdump and do some of what your saying > (and I > have), a nefarious type whose primary interest is doing this type of > thing > certainly can. > > The number of possible exploits are endless, but for a start I would > suggest > using SSL to encrypt the login info and data going over the wire. There > are > things you can do programatically to check for the computer's IP, but > this > can also be spoofed by someone with even a little knowledge. > > I would recommend getting a good book on security. There are things you > can do > at the system admin level to decrease the chance of a security breach, > but > you also have to put the right stuff in your programs. Holes on either > one > can negate the other. > > - > 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: Session Security
> Also, could someone listening in to the net traffic grab the session > id and then use it? > > Thanks, > Todd > Better yet, if you're not using SSL, they can grab the plaintext HTML that goes back and forth between teacher and server. They see everything the teacher sees. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session Security
Here is a question to do the same without cookies, so storing something in a cookie just won't work at al. I know that an IP address is not the best solution at all, but when you're using an internal network, it will work. I agree that using an IP address is by far not the best solution, but the odds are low... Sjoerd -Original Message- From: Mike Cherichetti (Renegade Internet) [mailto:[EMAIL PROTECTED] Sent: zondag 17 augustus 2003 22:29 To: Tomcat Users List Subject: RE: Session Security Todd, Putting the IP address of the user in the session won't work too well. An AOL user for example may have a different IP address every time they send in a request. And, it's obviously possible for someone to spoof an IP address. The best solution I've found to prevent sessions from being stolen is to use a one time access token. The token, which I usually create by doing MD5(ip + timestamp + random #), gets stored in a cookie and in the session itself. So, say a user logs in, they get a token and when they come back with their next request they send in that token. Your authentication logic checks the token in the cookie against the token in the session and handles accepting or denying the request. When the response is processed, you give them a new token and continue this cycle for all requests to follow. Now, lets say someone manages to steal the session. That person is going to get a different token than the legitimate user that's logged in currently has. So, when the legitimate user sends in their next request with a wrong token, you should catch that the session has been compromised and invalidate it immediately. This will result in the malicious user being kicked out. Still, this isn't a perfect solution because most users forget to logout. Using a low timeout value for the session is the only way I know of to deal with this scenario. You could run your application under HTTPS instead of HTTP too if that's an option :) Hope that helps, Mike -Original Message- From: Todd O'Bryan [mailto:[EMAIL PROTECTED] Sent: Sunday, August 17, 2003 2:45 PM To: [EMAIL PROTECTED] Subject: Session Security Is there any block against someone stealing someone else's session id and using it for nefarious purposes? In other words, if I write a grade book program, could a sharp student write down the session id from a web address (if cookies are off) or look in the teacher's cookie file, and then go to a computer in the library and use the same session id to connect to the grade book page before the teacher logs out? Does the session id check itself against the issuing computer's IP address or anything to prevent such a thing from happening? I realize it's a stretch that someone might leave their computer unattended long enough for such a thing to happen, but I just want to be sure. Also, could someone listening in to the net traffic grab the session id and then use it? Thanks, Todd - 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: Session Security
Todd, Putting the IP address of the user in the session won't work too well. An AOL user for example may have a different IP address every time they send in a request. And, it's obviously possible for someone to spoof an IP address. The best solution I've found to prevent sessions from being stolen is to use a one time access token. The token, which I usually create by doing MD5(ip + timestamp + random #), gets stored in a cookie and in the session itself. So, say a user logs in, they get a token and when they come back with their next request they send in that token. Your authentication logic checks the token in the cookie against the token in the session and handles accepting or denying the request. When the response is processed, you give them a new token and continue this cycle for all requests to follow. Now, lets say someone manages to steal the session. That person is going to get a different token than the legitimate user that's logged in currently has. So, when the legitimate user sends in their next request with a wrong token, you should catch that the session has been compromised and invalidate it immediately. This will result in the malicious user being kicked out. Still, this isn't a perfect solution because most users forget to logout. Using a low timeout value for the session is the only way I know of to deal with this scenario. You could run your application under HTTPS instead of HTTP too if that's an option :) Hope that helps, Mike -Original Message- From: Todd O'Bryan [mailto:[EMAIL PROTECTED] Sent: Sunday, August 17, 2003 2:45 PM To: [EMAIL PROTECTED] Subject: Session Security Is there any block against someone stealing someone else's session id and using it for nefarious purposes? In other words, if I write a grade book program, could a sharp student write down the session id from a web address (if cookies are off) or look in the teacher's cookie file, and then go to a computer in the library and use the same session id to connect to the grade book page before the teacher logs out? Does the session id check itself against the issuing computer's IP address or anything to prevent such a thing from happening? I realize it's a stretch that someone might leave their computer unattended long enough for such a thing to happen, but I just want to be sure. Also, could someone listening in to the net traffic grab the session id and then use it? Thanks, Todd - 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: Session Security
An easy workaround is to save the client IP-address in the session, and look each page if this IP-address is the address the client has. It's not waterproof, but it makes it far more difficult (ensure that a good router is available) Sjoerd van Leent -Original Message- From: Richard Dunn [mailto:[EMAIL PROTECTED] Sent: zondag 17 augustus 2003 21:02 To: Tomcat Users List Subject: Re: Session Security On Sunday 17 August 2003 12:44, Todd O'Bryan wrote: > Is there any block against someone stealing someone else's session id > and using it for nefarious purposes? In other words, if I write a grade > book program, could a sharp student write down the session id from a > web address (if cookies are off) or look in the teacher's cookie file, > and then go to a computer in the library and use the same session id to > connect to the grade book page before the teacher logs out? > > Does the session id check itself against the issuing computer's IP > address or anything to prevent such a thing from happening? I realize > it's a stretch that someone might leave their computer unattended long > enough for such a thing to happen, but I just want to be sure. Also, > could someone listening in to the net traffic grab the session id and > then use it? > > Thanks, > Todd I am not a security expert, but if someone with my limited knowledge on security can use a tool like tcpdump and do some of what your saying (and I have), a nefarious type whose primary interest is doing this type of thing certainly can. The number of possible exploits are endless, but for a start I would suggest using SSL to encrypt the login info and data going over the wire. There are things you can do programatically to check for the computer's IP, but this can also be spoofed by someone with even a little knowledge. I would recommend getting a good book on security. There are things you can do at the system admin level to decrease the chance of a security breach, but you also have to put the right stuff in your programs. Holes on either one can negate the other. - 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: Session Security
On Sunday 17 August 2003 12:44, Todd O'Bryan wrote: > Is there any block against someone stealing someone else's session id > and using it for nefarious purposes? In other words, if I write a grade > book program, could a sharp student write down the session id from a > web address (if cookies are off) or look in the teacher's cookie file, > and then go to a computer in the library and use the same session id to > connect to the grade book page before the teacher logs out? > > Does the session id check itself against the issuing computer's IP > address or anything to prevent such a thing from happening? I realize > it's a stretch that someone might leave their computer unattended long > enough for such a thing to happen, but I just want to be sure. Also, > could someone listening in to the net traffic grab the session id and > then use it? > > Thanks, > Todd I am not a security expert, but if someone with my limited knowledge on security can use a tool like tcpdump and do some of what your saying (and I have), a nefarious type whose primary interest is doing this type of thing certainly can. The number of possible exploits are endless, but for a start I would suggest using SSL to encrypt the login info and data going over the wire. There are things you can do programatically to check for the computer's IP, but this can also be spoofed by someone with even a little knowledge. I would recommend getting a good book on security. There are things you can do at the system admin level to decrease the chance of a security breach, but you also have to put the right stuff in your programs. Holes on either one can negate the other. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session\Security Checking
Nope, Filters are new to Servlets 2.3 http://java.sun.com/products/servlet/Filters.html Also, download the Servlet spec, it's full of great info, and not just about Filters. http://jcp.org/aboutJava/communityprocess/first/jsr053/index.html > -Original Message- > From: Robert Priest [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 12:13 PM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > Ok. thanks. > > Do you have any links to the proper documentation for doing this? > > When you say filter, you are not speaking of a "Realm" are you? > > Could you clarify for me? > > -Original Message- > From: Mike Curwen [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 12:55 PM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > If you've already implemented your own access control, then > certainly it might be more feasible to extend that to this > set of pages. A filter might be the best, if you can use a > 2.3 compliant container. > > The filter would simply check for the presence of a session. > If there isn't one, sendRedirect() to a login page. Else, > the filter will just 'pass through' the request. The filter > can be mapped to any requests for /downloaddir/* > > > -----Original Message- > > From: Robert Priest [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 28, 2003 11:46 AM > > To: 'Tomcat Users List' > > Subject: RE: Session\Security Checking > > > > > > But I still need to change how my user are authenticated, > > correct. I now need to handle that authentication through the > > realm instead of a Form on our page now, right? > > > > -Original Message- > > From: Mike Curwen [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 28, 2003 12:33 PM > > To: 'Tomcat Users List' > > Subject: RE: Session\Security Checking > > > > > > I think using a realm and simply setting up /downloaddir/* as > > a 'protected resource' is the way to go. The functionality > > you're looking for has already been implemented by > > Container-Managed Auth. > > > > Also.. if you use a container AUTH scheme, then you don't > > need the Session ID in the URL. The mere presence of a > > session will prove that your user is "logged in and authenticated". > > > > > > > -Original Message- > > > From: Robert Priest [mailto:[EMAIL PROTECTED] > > > Sent: Monday, July 28, 2003 11:25 AM > > > To: 'Tomcat Users List' > > > Subject: RE: Session\Security Checking > > > > > > > > > thanks, rick. I appreciate the info. But I am not sure > that we want > > > to use realm for our solution. But I certainly think it > is feasible. > > > > > > I think we are more in the market for some sort of simple session > > > guard. Please allow me to explain a little further. Then I would > > > like to hear your opinion about the suggested approach > versus adding > > > a REALM: > > > > > > the URL for the download will contain a session id for > the user. So > > > if you will allow me to modify my example: > > > > > > Say user A logs in and has a session id of "1" and wants > to download > > > abc.jar. He will be redirected to the url: > > > http://localhost/myservlet/downloaddir/1/abc.jar > > > > > > now I would like to put in place a guard servlet. So in > myservlet's > > > web.xml I will add > > > > > > > > > com.myproj.web.GUARD > > > /downloaddir/* > > > > > > > > > The intention is for the "Guard" servlet to: > > > > > > 1. Inspect the url for sessionid ("1" in this case"). > > > 2. Get it and compare it to the current session id > > > (session.getID()). 3. if the two match, then start an > http download. > > > 4. If not then, throw up an "Access Denied" error page. > > > > > > That is pretty much all we need to do. I also don't want to add > > > basic\Form authentication at this point for those directories. We > > > simply want to match whether the session id in the url is > the same > > > as the one the current user is using. > > > > > > That way, if another user, who will have a different > session number > > > (3 or what have you) tries to
RE: Session\Security Checking
Ok. thanks. Do you have any links to the proper documentation for doing this? When you say filter, you are not speaking of a "Realm" are you? Could you clarify for me? -Original Message- From: Mike Curwen [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 12:55 PM To: 'Tomcat Users List' Subject: RE: Session\Security Checking If you've already implemented your own access control, then certainly it might be more feasible to extend that to this set of pages. A filter might be the best, if you can use a 2.3 compliant container. The filter would simply check for the presence of a session. If there isn't one, sendRedirect() to a login page. Else, the filter will just 'pass through' the request. The filter can be mapped to any requests for /downloaddir/* > -Original Message- > From: Robert Priest [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 11:46 AM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > But I still need to change how my user are authenticated, > correct. I now need to handle that authentication through the > realm instead of a Form on our page now, right? > > -Original Message- > From: Mike Curwen [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 12:33 PM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > I think using a realm and simply setting up /downloaddir/* as > a 'protected resource' is the way to go. The functionality > you're looking for has already been implemented by > Container-Managed Auth. > > Also.. if you use a container AUTH scheme, then you don't > need the Session ID in the URL. The mere presence of a > session will prove that your user is "logged in and authenticated". > > > > -Original Message- > > From: Robert Priest [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 28, 2003 11:25 AM > > To: 'Tomcat Users List' > > Subject: RE: Session\Security Checking > > > > > > thanks, rick. I appreciate the info. But I am not sure that > > we want to use realm for our solution. But I certainly think > > it is feasible. > > > > I think we are more in the market for some sort of simple > > session guard. Please allow me to explain a little further. > > Then I would like to hear your opinion about the suggested > > approach versus adding a REALM: > > > > the URL for the download will contain a session id for the > > user. So if you will allow me to modify my example: > > > > Say user A logs in and has a session id of "1" and wants to > > download abc.jar. He will be redirected to the url: > > http://localhost/myservlet/downloaddir/1/abc.jar > > > > now I would like to put in place a guard servlet. So in > > myservlet's web.xml I will add > > > > > > com.myproj.web.GUARD > > /downloaddir/* > > > > > > The intention is for the "Guard" servlet to: > > > > 1. Inspect the url for sessionid ("1" in this case"). > > 2. Get it and compare it to the current session id > > (session.getID()). 3. if the two match, then start an http > > download. 4. If not then, throw up an "Access Denied" error page. > > > > That is pretty much all we need to do. I also don't want to > > add basic\Form authentication at this point for those > > directories. We simply want to match whether the session id > > in the url is the same as the one the current user is using. > > > > That way, if another user, who will have a different session > > number (3 or what have you) tries to paste in: > > > > http://localhost/myservlet/downloaddir/1/abc.jar > > > > he\she will get an access denied. > > > > Is that more understandable? > > > > We are trying to prevent cutting and pasting of urls. > > > > We are mainly concerned with just providing\denying access to > > this directory and not security to an entire web application > > where I think the REALM would be more applicable (i am not > > sure whether that is right or wrong...). > > > > > > -Original Message- > > From: Rick Roberts [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 28, 2003 12:09 PM > > To: Tomcat Users List > > Subject: Re: Session\Security Checking > > > > > > Found a link for ya: > > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html > > > > Rick > > > > Robert Priest wrote: > > > How can I
RE: Session\Security Checking
If you've already implemented your own access control, then certainly it might be more feasible to extend that to this set of pages. A filter might be the best, if you can use a 2.3 compliant container. The filter would simply check for the presence of a session. If there isn't one, sendRedirect() to a login page. Else, the filter will just 'pass through' the request. The filter can be mapped to any requests for /downloaddir/* > -Original Message- > From: Robert Priest [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 11:46 AM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > But I still need to change how my user are authenticated, > correct. I now need to handle that authentication through the > realm instead of a Form on our page now, right? > > -Original Message- > From: Mike Curwen [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 12:33 PM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > I think using a realm and simply setting up /downloaddir/* as > a 'protected resource' is the way to go. The functionality > you're looking for has already been implemented by > Container-Managed Auth. > > Also.. if you use a container AUTH scheme, then you don't > need the Session ID in the URL. The mere presence of a > session will prove that your user is "logged in and authenticated". > > > > -----Original Message- > > From: Robert Priest [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 28, 2003 11:25 AM > > To: 'Tomcat Users List' > > Subject: RE: Session\Security Checking > > > > > > thanks, rick. I appreciate the info. But I am not sure that > > we want to use realm for our solution. But I certainly think > > it is feasible. > > > > I think we are more in the market for some sort of simple > > session guard. Please allow me to explain a little further. > > Then I would like to hear your opinion about the suggested > > approach versus adding a REALM: > > > > the URL for the download will contain a session id for the > > user. So if you will allow me to modify my example: > > > > Say user A logs in and has a session id of "1" and wants to > > download abc.jar. He will be redirected to the url: > > http://localhost/myservlet/downloaddir/1/abc.jar > > > > now I would like to put in place a guard servlet. So in > > myservlet's web.xml I will add > > > > > > com.myproj.web.GUARD > > /downloaddir/* > > > > > > The intention is for the "Guard" servlet to: > > > > 1. Inspect the url for sessionid ("1" in this case"). > > 2. Get it and compare it to the current session id > > (session.getID()). 3. if the two match, then start an http > > download. 4. If not then, throw up an "Access Denied" error page. > > > > That is pretty much all we need to do. I also don't want to > > add basic\Form authentication at this point for those > > directories. We simply want to match whether the session id > > in the url is the same as the one the current user is using. > > > > That way, if another user, who will have a different session > > number (3 or what have you) tries to paste in: > > > > http://localhost/myservlet/downloaddir/1/abc.jar > > > > he\she will get an access denied. > > > > Is that more understandable? > > > > We are trying to prevent cutting and pasting of urls. > > > > We are mainly concerned with just providing\denying access to > > this directory and not security to an entire web application > > where I think the REALM would be more applicable (i am not > > sure whether that is right or wrong...). > > > > > > -Original Message- > > From: Rick Roberts [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 28, 2003 12:09 PM > > To: Tomcat Users List > > Subject: Re: Session\Security Checking > > > > > > Found a link for ya: > > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html > > > > Rick > > > > Robert Priest wrote: > > > How can I check for a Valid session id before allowing access to a > > > file? > > > > > > For example: > > > > > > - I have a directory containing files for download: > > > http://localhost/myservlet/downloaddir/ > > > - but before you download a file, say abc.jar (by using > > > "http://localh
Re: Session\Security Checking
Robert Priest wrote: the URL for the download will contain a session id for the user. So if you will allow me to modify my example: Say user A logs in and has a session id of "1" and wants to download abc.jar. He will be redirected to the url: http://localhost/myservlet/downloaddir/1/abc.jar now I would like to put in place a guard servlet. So in myservlet's web.xml I will add com.myproj.web.GUARD /downloaddir/* The intention is for the "Guard" servlet to: 1. Inspect the url for sessionid ("1" in this case"). 2. Get it and compare it to the current session id (session.getID()). 3. if the two match, then start an http download. 4. If not then, throw up an "Access Denied" error page. I don't think there is anyway to implement this concept. Because, you can't know the value of session.getID() in advance. Therefore you can't set up the downloaddir as described. I suppose you could figure out a way to do what you want without using container managed authentication, but I can't think of a good reason to not use it. -- *** * Rick Roberts* * Advanced Information Technologies, Inc. * *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session\Security Checking
But I still need to change how my user are authenticated, correct. I now need to handle that authentication through the realm instead of a Form on our page now, right? -Original Message- From: Mike Curwen [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 12:33 PM To: 'Tomcat Users List' Subject: RE: Session\Security Checking I think using a realm and simply setting up /downloaddir/* as a 'protected resource' is the way to go. The functionality you're looking for has already been implemented by Container-Managed Auth. Also.. if you use a container AUTH scheme, then you don't need the Session ID in the URL. The mere presence of a session will prove that your user is "logged in and authenticated". > -Original Message- > From: Robert Priest [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 11:25 AM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > thanks, rick. I appreciate the info. But I am not sure that > we want to use realm for our solution. But I certainly think > it is feasible. > > I think we are more in the market for some sort of simple > session guard. Please allow me to explain a little further. > Then I would like to hear your opinion about the suggested > approach versus adding a REALM: > > the URL for the download will contain a session id for the > user. So if you will allow me to modify my example: > > Say user A logs in and has a session id of "1" and wants to > download abc.jar. He will be redirected to the url: > http://localhost/myservlet/downloaddir/1/abc.jar > > now I would like to put in place a guard servlet. So in > myservlet's web.xml I will add > > > com.myproj.web.GUARD > /downloaddir/* > > > The intention is for the "Guard" servlet to: > > 1. Inspect the url for sessionid ("1" in this case"). > 2. Get it and compare it to the current session id > (session.getID()). 3. if the two match, then start an http > download. 4. If not then, throw up an "Access Denied" error page. > > That is pretty much all we need to do. I also don't want to > add basic\Form authentication at this point for those > directories. We simply want to match whether the session id > in the url is the same as the one the current user is using. > > That way, if another user, who will have a different session > number (3 or what have you) tries to paste in: > > http://localhost/myservlet/downloaddir/1/abc.jar > > he\she will get an access denied. > > Is that more understandable? > > We are trying to prevent cutting and pasting of urls. > > We are mainly concerned with just providing\denying access to > this directory and not security to an entire web application > where I think the REALM would be more applicable (i am not > sure whether that is right or wrong...). > > > -Original Message- > From: Rick Roberts [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 12:09 PM > To: Tomcat Users List > Subject: Re: Session\Security Checking > > > Found a link for ya: > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html > > Rick > > Robert Priest wrote: > > How can I check for a Valid session id before allowing access to a > > file? > > > > For example: > > > > - I have a directory containing files for download: > > http://localhost/myservlet/downloaddir/ > > - but before you download a file, say abc.jar (by using > > "http://localhost/myservlet/downloaddir/abc.jar";), I want > to make sure > that > > you have a valid session id. If your > > session id is invalid, you get an access denied page. if > not, a http > > download is started. > > > > so I guess what I want is to intercept any request to that > > "downloaddir" and perform session\security checking (by another > > servlet or jsp page) before allowing access... > > > > > > Now, is adding additional servlet\jsp the best way to go > about this, > > or is there a better way through Tomcat configuration? > > > > > > Thanks. > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > *** > * Rick Roberts* > * Advanced Information Technologies, Inc. * > *** > > >
RE: Session\Security Checking
I think using a realm and simply setting up /downloaddir/* as a 'protected resource' is the way to go. The functionality you're looking for has already been implemented by Container-Managed Auth. Also.. if you use a container AUTH scheme, then you don't need the Session ID in the URL. The mere presence of a session will prove that your user is "logged in and authenticated". > -Original Message- > From: Robert Priest [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 11:25 AM > To: 'Tomcat Users List' > Subject: RE: Session\Security Checking > > > thanks, rick. I appreciate the info. But I am not sure that > we want to use realm for our solution. But I certainly think > it is feasible. > > I think we are more in the market for some sort of simple > session guard. Please allow me to explain a little further. > Then I would like to hear your opinion about the suggested > approach versus adding a REALM: > > the URL for the download will contain a session id for the > user. So if you will allow me to modify my example: > > Say user A logs in and has a session id of "1" and wants to > download abc.jar. He will be redirected to the url: > http://localhost/myservlet/downloaddir/1/abc.jar > > now I would like to put in place a guard servlet. So in > myservlet's web.xml I will add > > > com.myproj.web.GUARD > /downloaddir/* > > > The intention is for the "Guard" servlet to: > > 1. Inspect the url for sessionid ("1" in this case"). > 2. Get it and compare it to the current session id > (session.getID()). 3. if the two match, then start an http > download. 4. If not then, throw up an "Access Denied" error page. > > That is pretty much all we need to do. I also don't want to > add basic\Form authentication at this point for those > directories. We simply want to match whether the session id > in the url is the same as the one the current user is using. > > That way, if another user, who will have a different session > number (3 or what have you) tries to paste in: > > http://localhost/myservlet/downloaddir/1/abc.jar > > he\she will get an access denied. > > Is that more understandable? > > We are trying to prevent cutting and pasting of urls. > > We are mainly concerned with just providing\denying access to > this directory and not security to an entire web application > where I think the REALM would be more applicable (i am not > sure whether that is right or wrong...). > > > -Original Message- > From: Rick Roberts [mailto:[EMAIL PROTECTED] > Sent: Monday, July 28, 2003 12:09 PM > To: Tomcat Users List > Subject: Re: Session\Security Checking > > > Found a link for ya: > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html > > Rick > > Robert Priest wrote: > > How can I check for a Valid session id before allowing access to a > > file? > > > > For example: > > > > - I have a directory containing files for download: > > http://localhost/myservlet/downloaddir/ > > - but before you download a file, say abc.jar (by using > > "http://localhost/myservlet/downloaddir/abc.jar";), I want > to make sure > that > > you have a valid session id. If your > > session id is invalid, you get an access denied page. if > not, a http > > download is started. > > > > so I guess what I want is to intercept any request to that > > "downloaddir" and perform session\security checking (by another > > servlet or jsp page) before allowing access... > > > > > > Now, is adding additional servlet\jsp the best way to go > about this, > > or is there a better way through Tomcat configuration? > > > > > > Thanks. > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > *** > * Rick Roberts* > * Advanced Information Technologies, Inc. * > *** > > > - > 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: Session\Security Checking
thanks, rick. I appreciate the info. But I am not sure that we want to use realm for our solution. But I certainly think it is feasible. I think we are more in the market for some sort of simple session guard. Please allow me to explain a little further. Then I would like to hear your opinion about the suggested approach versus adding a REALM: the URL for the download will contain a session id for the user. So if you will allow me to modify my example: Say user A logs in and has a session id of "1" and wants to download abc.jar. He will be redirected to the url: http://localhost/myservlet/downloaddir/1/abc.jar now I would like to put in place a guard servlet. So in myservlet's web.xml I will add com.myproj.web.GUARD /downloaddir/* The intention is for the "Guard" servlet to: 1. Inspect the url for sessionid ("1" in this case"). 2. Get it and compare it to the current session id (session.getID()). 3. if the two match, then start an http download. 4. If not then, throw up an "Access Denied" error page. That is pretty much all we need to do. I also don't want to add basic\Form authentication at this point for those directories. We simply want to match whether the session id in the url is the same as the one the current user is using. That way, if another user, who will have a different session number (3 or what have you) tries to paste in: http://localhost/myservlet/downloaddir/1/abc.jar he\she will get an access denied. Is that more understandable? We are trying to prevent cutting and pasting of urls. We are mainly concerned with just providing\denying access to this directory and not security to an entire web application where I think the REALM would be more applicable (i am not sure whether that is right or wrong...). -Original Message- From: Rick Roberts [mailto:[EMAIL PROTECTED] Sent: Monday, July 28, 2003 12:09 PM To: Tomcat Users List Subject: Re: Session\Security Checking Found a link for ya: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html Rick Robert Priest wrote: > How can I check for a Valid session id before allowing access to a file? > > For example: > > - I have a directory containing files for download: > http://localhost/myservlet/downloaddir/ > - but before you download a file, say abc.jar (by using > "http://localhost/myservlet/downloaddir/abc.jar";), I want to make sure that > you have a valid session id. If your > session id is invalid, you get an access denied page. if not, a http > download is started. > > so I guess what I want is to intercept any request to that "downloaddir" > and perform session\security checking (by another servlet or jsp page) > before allowing access... > > > Now, is adding additional servlet\jsp the best way to go about this, or is > there a better way through Tomcat configuration? > > > Thanks. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- *** * Rick Roberts* * Advanced Information Technologies, Inc. * *** - 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: Session\Security Checking
Found a link for ya: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html Rick Robert Priest wrote: How can I check for a Valid session id before allowing access to a file? For example: - I have a directory containing files for download: http://localhost/myservlet/downloaddir/ - but before you download a file, say abc.jar (by using "http://localhost/myservlet/downloaddir/abc.jar";), I want to make sure that you have a valid session id. If your session id is invalid, you get an access denied page. if not, a http download is started. so I guess what I want is to intercept any request to that "downloaddir" and perform session\security checking (by another servlet or jsp page) before allowing access... Now, is adding additional servlet\jsp the best way to go about this, or is there a better way through Tomcat configuration? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- *** * Rick Roberts* * Advanced Information Technologies, Inc. * *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session\Security Checking
Any of the "container authentication" methods do this for you. Look into "BASIC AUTH", "FORM AUTH" and JDBC Realm and you should find all you need to know about how that works. Once you decide which AUTH method is best for your situation, we can help you get it working. Robert Priest wrote: How can I check for a Valid session id before allowing access to a file? For example: - I have a directory containing files for download: http://localhost/myservlet/downloaddir/ - but before you download a file, say abc.jar (by using "http://localhost/myservlet/downloaddir/abc.jar";), I want to make sure that you have a valid session id. If your session id is invalid, you get an access denied page. if not, a http download is started. so I guess what I want is to intercept any request to that "downloaddir" and perform session\security checking (by another servlet or jsp page) before allowing access... Now, is adding additional servlet\jsp the best way to go about this, or is there a better way through Tomcat configuration? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- *** * Rick Roberts* * Advanced Information Technologies, Inc. * *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]