Re: CsrfPreventionFilter for REST
2012/9/22 Violeta Georgieva violet...@apache.org: Hello, ** ** *Background information:* We are trying to protect our RESTful APIshttp://en.wikipedia.org/wiki/Representational_state_transfer from CSRF attack. The current Tomcat’s CSRF protection filter provides proper protection for web resources that are supposed to be accessed via some sort of navigation i.e. there’s an entry point which points to them (for example include links/post forms to them) . With REST APIs you do not have such entry points as the requests are done independently from each other. We are interested do you consider supporting CSRF protection for RESTful APIs? ** ** *Example attack:* Here is an example how to reproduce CSRF attack of RESTful APIs using the attached apps: 1. Check customers initial state: http://localhost:8080/restDemo/services/customers/ + login with tomcat/tomcat 2. **In the same browser open attacker’s app: http://localhost:8080/XSRFAttackerApp/ ** Behind the scenes request 2. takes advantage of your credentials stored in the browser and makes attacking POST request to a state changing operation http://localhost:8080/restDemo/services/customers/removeFirst on your behalf. After that the customer list is empty. ** ** The problem is that if we use the CSRF filter to protect this API /services/customers/removeFirst, this URL is then always served with *403 Forbidden* (due to the missing csrf token). In fact the REST API becomes unusable. ** ** *Research:* We’ve made some research on the topic and it seems that there is no absolutely secure and at the same time clear stateless solution. Since it is possible for an attacker to insert custom headers in the attacking requests, the validation over header presence is not secure enough. The ability to insert headers (or tokens in the request string as Tomcat's CSRF filter requires) is irrelevant, because the attacker has to know the exact token value and the value is random. If you are constantly receiving 403 on your POST requests it means that you are requesting wrong URL (one that does not contain the CSRF token) or your requests are not a part of the session. The only stable solution is again based on Synchronizer Token Patternhttps://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet but instead of encoded in URLs, the csrf token value can be transferred from and to the client through a custom csrf token header. The rest csrf token value needs to be stored in some sort of state on client and server side. In addition REST clients need to adopt this csrf token transfer mechanism.** ** *Proposal:* You can find on the link https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the CsrfPreventionFilter extended so that it is able to successfully protect state changing REST requests. They are validated based on the “X-CSRF-Token” header (the header name is configurable). (...) The main task of Tomcat's CSRFProtectionFilter is to protect the Manager application. The application does not use XMLHttpRequest so it cannot set the headers. So I see no point in implementing support for passing the token value in a header, as there is no use for it. Is there enough API available to extend the filter in a subclass to cover your specific use case? Note that CSRF protection has some specific task. It would not protect you if an attacker is able to request the welcome page and parse it to extract the token. It would not protect you if you are using non-secured HTTP and an attacker is able to sniff network traffic. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AuthenticatorBase setChangeSessionIdOnAuthentication without cookies
On 24/09/12 17:52, Mark Thomas wrote: On 24/09/2012 11:41, Brian Burch wrote: I draw the following conclusions: 1. A client that can accept a Set-Cookie for JSESSIONID will be able to maintain a persistent session (is that incorrectly overloading a reserved word?), no matter whether the session ID is changed once, many times, or not at all. Correct. 2. A client that cannot accept cookies will only be able to maintain a persistent session IF the server sends the correct (current) jsessionid as a path parameter appended to ALL urls within its response. That is achievable with servlets, jsps, jstl (all of which which can ask for an encoded url to be inserted into the dynamic web page). It cannot work with static html. Correct - Unless one starts parsing the static HTML e.g. via a filter and adding the path parameter. Messy but doable. There might even be a filter out there that does this. For example, httpd has a module that does this 3. Therefore, any webapp that MIGHT need to authenticate a client that does not accept cookies MUST generate EVERY protected resource url dynamically (to include the session ID). Correct - part from the option above. 4. Any webapp that cannot satify case 3 MUST turn off changeSessionIdOnAuthentication for its Context and degrade the session fixation protection for ALL of its clients. No sure I agree with this. If the URLs aren't being encoded then the session is going to break regardless of whether or not the session ID changes. Thanks Mark, I interpret your comment to be applicable to proper browser behaviour, which is the appropriate context for a discussion on the users list. Unlike a proper browser, the tomcat junit test class does a quite lot of screen-scraping and cheating of headers and urls (not very elegant, but it makes no claims to generality). My additional code was able to easily identify the initial jsessionid, but detecting and handling a changed value turned out to be more convoluted. I think this thread can be wrapped up now without (hopefully) causing confusion to future readers. Regards, Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 and Runtime.getRuntime()
On Sep 25, 2012, at 8:46 PM, Ray Collins wrote: I am using Tomcat7.0. The web application I created executes a script from the command line using Runtime.getRuntime(). This script sends an http: request to another server that is on the local network. For Some reason the script executes as if it has sent the http request but it really has not. Its like Tomcat is operating in a sandbox when it comes to accessing this URL on my local network. The JVM, if using a security manager, could prevent you from calling Runtime.getRuntime(), but if that happened you'd see a SecurityException. Once you start the script, it is executing outside of the JVM. I am using Ubuntu Server 12.04. If i run the script manually from the command line the script can access the URL with no problem. Why cant the script that tomcat has executed access this resource. The first thing that comes to mind would be permissions. If the script runs from the command line, it would run as your user. If it is run through the JVM and Tomcat, it'll run as the user that is running Tomcat. Have you tried logging in as the user that is running Tomcat and executing the script? Dan Any help is greatly appreciated. Ray - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 and Runtime.getRuntime()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ray, On 9/25/12 8:46 PM, Ray Collins wrote: I am using Tomcat7.0. The web application I created executes a script from the command line using Runtime.getRuntime(). This script sends an http: request to another server that is on the local network. For Some reason the script executes as if it has sent the http request but it really has not. Its like Tomcat is operating in a sandbox when it comes to accessing this URL on my local network. I am using Ubuntu Server 12.04 . If i run the script manually from the command line the script can access the URL with no problem. Why cant the script that tomcat has executed access this resource. Any help is greatly appreciated. Using Runtime.exec is fraught with difficulty, and most people don't do it right. Remember that you basically need 3 threads in order to run Runtime.exec: one to pump-in data for the sub-process's stdin (or you can close stdin for the sub-process and save yourself a thread), one to drain stdout and one to drain stderr. Sadly, there are no non-blocking options for draining stdout and stderr that I know of -- though I suppose you could go into a busy-wait checking stdout.available() and stderr.available() and draining them several bytes at a time. If you don't drain stdout and stderr, your process will block and if you are waiting on that Process from a request-dispatch thread, your thread will stall forever. Make sure you are properly using Runtime.exec or use a library that wraps it for you and handles all this complexity for you. Note that if you expose this capability publicly, you will essentially allow any remote user to execute an arbitrary number of processes on your server: you might want to consider using a queue with a fixed-width exec pipeline so that you don't launch 5000 processes on your app server. Also be very careful with command-line-building. If you are calling a shell to parse some stuff and then execute, be very aware of CLI injection attacks, too. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBjJHMACgkQ9CaO5/Lv0PA9KACgopecKKlBuTK/kVqZjfvoP7BF 5r4AoIgvdJjXjQbUOuIV06BVDaAO1dSl =2YIW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Installing CA cert on SSL enabled webserver
Hi all- I have a question about Tomcat 7.0.27. I have a webserver that I enabled S= SL access for. I have purchased a 3rd party cert. However; I am having trouble installing the cert on the server. Whenever, I go to https://myserver.mycompany.com, I receive the This site is untrusted message. My question is: How do you install a 3rd party SSL cert on Tomcat 7? Thanks in advance. Mike
Thomas MC-GOWAN est absent(e).
Je serai absent(e) du 26/09/2012 au 01/10/2012. Je répondrai à votre message dès mon retour. En cas de problème urgent, merci de vous adresser à dsp-cspit-cellul...@edf.fr avec le mot clé [GED] dans l'objet. Vous pouvez adresser vos demandes de support GED à la boite DSP-CSPIT-CELLULEDI avec dans l'objet de votre message [GED]
RE: Installing CA cert on SSL enabled webserver
Mike, Sounds like you installed it perfectly, otherwise no https connection to your web server would be possible. The problem with trust is on the client/browser side. You need to install the 3rd party Root CA cert on your client so your browser will trust your server's certificate. Regards, Steve -Original Message- From: users-return-236875-STEVEN.J.ADAMUS=saic@tomcat.apache.org [mailto:users-return-236875-STEVEN.J.ADAMUS=saic@tomcat.apache.org] On Behalf Of Michael Namaiandeh Sent: Wednesday, September 26, 2012 11:37 AM To: users@tomcat.apache.org Subject: Installing CA cert on SSL enabled webserver Hi all- I have a question about Tomcat 7.0.27. I have a webserver that I enabled S= SL access for. I have purchased a 3rd party cert. However; I am having trouble installing the cert on the server. Whenever, I go to https://myserver.mycompany.com, I receive the This site is untrusted message. My question is: How do you install a 3rd party SSL cert on Tomcat 7? Thanks in advance. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Installing CA cert on SSL enabled webserver
The browser says the cert is issued by the server itself and it should be issued by the 3rd party CA (in this case, GoDaddy), right? -Original Message- From: Adamus, Steven J. [mailto:steven.j.ada...@saic.com] Sent: Wednesday, September 26, 2012 3:34 PM To: Tomcat Users List Subject: RE: Installing CA cert on SSL enabled webserver Mike, Sounds like you installed it perfectly, otherwise no https connection to your web server would be possible. The problem with trust is on the client/browser side. You need to install the 3rd party Root CA cert on your client so your browser will trust your server's certificate. Regards, Steve -Original Message- From: users-return-236875-STEVEN.J.ADAMUS=saic@tomcat.apache.org [mailto:users-return-236875-STEVEN.J.ADAMUS=saic@tomcat.apache.org] On Behalf Of Michael Namaiandeh Sent: Wednesday, September 26, 2012 11:37 AM To: users@tomcat.apache.org Subject: Installing CA cert on SSL enabled webserver Hi all- I have a question about Tomcat 7.0.27. I have a webserver that I enabled S= SL access for. I have purchased a 3rd party cert. However; I am having trouble installing the cert on the server. Whenever, I go to https://myserver.mycompany.com, I receive the This site is untrusted message. My question is: How do you install a 3rd party SSL cert on Tomcat 7? Thanks in advance. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Installing CA cert on SSL enabled webserver
So, your web server is using a self-signed cert, and not the one you purchased. Installation of your 3rd part cert depends on which HTTPS connector you're using, APR (OpenSSL-based) or the JSSE-based connector. Good documentation on both are out there, but make sure you follow the correct one or you'll get really confused. -Original Message- From: users-return-236878-STEVEN.J.ADAMUS=saic@tomcat.apache.org [mailto:users-return-236878-STEVEN.J.ADAMUS=saic@tomcat.apache.org] On Behalf Of Michael Namaiandeh Sent: Wednesday, September 26, 2012 12:38 PM To: Tomcat Users List Subject: RE: Installing CA cert on SSL enabled webserver The browser says the cert is issued by the server itself and it should be issued by the 3rd party CA (in this case, GoDaddy), right? -Original Message- From: Adamus, Steven J. [mailto:steven.j.ada...@saic.com] Sent: Wednesday, September 26, 2012 3:34 PM To: Tomcat Users List Subject: RE: Installing CA cert on SSL enabled webserver Mike, Sounds like you installed it perfectly, otherwise no https connection to your web server would be possible. The problem with trust is on the client/browser side. You need to install the 3rd party Root CA cert on your client so your browser will trust your server's certificate. Regards, Steve -Original Message- From: users-return-236875-STEVEN.J.ADAMUS=saic@tomcat.apache.org [mailto:users-return-236875-STEVEN.J.ADAMUS=saic@tomcat.apache.org] On Behalf Of Michael Namaiandeh Sent: Wednesday, September 26, 2012 11:37 AM To: users@tomcat.apache.org Subject: Installing CA cert on SSL enabled webserver Hi all- I have a question about Tomcat 7.0.27. I have a webserver that I enabled S= SL access for. I have purchased a 3rd party cert. However; I am having trouble installing the cert on the server. Whenever, I go to https://myserver.mycompany.com, I receive the This site is untrusted message. My question is: How do you install a 3rd party SSL cert on Tomcat 7? Thanks in advance. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Connector for Sun ONE Web Server 7.0 and Tomcat 6.0.x
Yup Going the Apache Web Server route now. Also evaluating RedHat's JBoss EWS On Wed, Sep 19, 2012 at 2:05 PM, Pid * p...@pidster.com wrote: On 19 Sep 2012, at 16:59, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Wed, Sep 19, 2012 at 8:02 AM, Jay Rao jay...@gmail.com wrote: Is there a Tomcat Connector for Sun ONE Web Server 7.0 and Tomcat 6.0.x running on RedHat Linux 5.7 64-bit ? If not, any idea on when will it would be available please ? My guess: When dead, dreaming Cthulhu wakes in his house at R'lyeh and schedules a Tupperware party. LMAO I could be wrong, though. Or you could pay someone to create one. Or try the 6.x one that is the top result when you google sun one tomcat connector Or ditch Sun ONE and use something current. p -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
