RE: Should not be this hard(why is this a security risk)
That is what I needed ... Thanks all To follow this up, why is this a security risk? Do they want specific mapping for each servlet? Thanks -Original Message- From: PELOQUIN,JEFFREY (HP-Boise,ex1) [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 9:54 AM To: 'Tomcat Users List' Subject: RE: Should not be this hard From the release notes Enabling invoker servlet: Starting with Tomcat 4.1.12, the invoker servlet is no longer available by default in all webapp. Enabling it for all webapps is possible by editing $CATALINA_HOME/conf/web.xml to uncomment the /servlet/* servlet-mapping definition. Using the invoker servlet in a production environment is not recommended and is unsupported. -Original Message- From: Randy Paries [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 8:51 AM To: 'Tomcat Users List' Subject: Should not be this hard Hello, me again This should have been so easy (famous last words) I am upgrading from tomcat jakarta-tomcat-4.0.4 to jakarta-tomcat-4.1.17 4.0.4 was working fine. For some reason I can not find my servlets ARG! In my web.xml I have a load-on-startup/ and in the log file , the servlet Starts ok But if I goto http://bart.mydomain.com:8080/servlet/uServlet I get a 404... Here is some details. I have to be missing something very simple. My static html and jsps work ok when I goto http://bart.mydomain.com:8080/index.html http://bart.mydomain.com:8080/jsp/dirgloblogin.jsp But if I goto http://bart.mydomain.com:8080/servlet/uServlet I get a 404 from the log file I get : 2002-12-19 09:42:13 StandardContext[]: Mapping contextPath='' with requestURI='/servlet/uServlet' and relativeURI='/servlet/uServlet 2002-12-19 09:42:13 StandardContext[]: Trying exact match 2002-12-19 09:42:13 StandardContext[]: Trying prefix match 2002-12-19 09:42:13 StandardContext[]: Trying extension match 2002-12-19 09:42:13 StandardContext[]: Trying default match 2002-12-19 09:42:13 StandardContext[]: Mapped to servlet 'default' with servlet path '/servlet/uServlet' and path info 'null' and update=true 2002-12-19 09:42:13 default: DefaultServlet.serveResource: Serving resource '/servlet/uServlet' headers and data In my server.xml I have Engine name=Standalone defaultHost=localhost debug=9 Host name=localhost debug=0 appBase=/home/unit unpackWARs=true autoDeploy=true Context path= docBase=/home/unit crossContext=true debug=9 reloadable=false /Context #ls -ls /home/unit/WEB-INF/classes total 104 32 -rwxrwxrwx1 apache apache 32734 Dec 18 21:31 bbsServlet.class 4 drwxrwxrwx3 apache apache 4096 Aug 24 22:19 com 36 -rw-rw-r--1 apache apache 33984 Nov 6 15:43 EditjsServlet.class 32 -rwxrwxrwx1 apache apache 31030 Dec 18 21:31 uServlet.class Thanks for any Help!!! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Should not be this hard(why is this a security risk)
See these messages: http://www.mail-archive.com/announcements@jakarta.apache.org/msg00122.ht ml http://www.mail-archive.com/announcements@jakarta.apache.org/msg00128.ht ml -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Randy Paries [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 11:20 AM To: 'Tomcat Users List' Subject: RE: Should not be this hard(why is this a security risk) That is what I needed ... Thanks all To follow this up, why is this a security risk? Do they want specific mapping for each servlet? Thanks -Original Message- From: PELOQUIN,JEFFREY (HP-Boise,ex1) [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 9:54 AM To: 'Tomcat Users List' Subject: RE: Should not be this hard From the release notes Enabling invoker servlet: Starting with Tomcat 4.1.12, the invoker servlet is no longer available by default in all webapp. Enabling it for all webapps is possible by editing $CATALINA_HOME/conf/web.xml to uncomment the /servlet/* servlet-mapping definition. Using the invoker servlet in a production environment is not recommended and is unsupported. -Original Message- From: Randy Paries [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 8:51 AM To: 'Tomcat Users List' Subject: Should not be this hard Hello, me again This should have been so easy (famous last words) I am upgrading from tomcat jakarta-tomcat-4.0.4 to jakarta-tomcat-4.1.17 4.0.4 was working fine. For some reason I can not find my servlets ARG! In my web.xml I have a load-on-startup/ and in the log file , the servlet Starts ok But if I goto http://bart.mydomain.com:8080/servlet/uServlet I get a 404... Here is some details. I have to be missing something very simple. My static html and jsps work ok when I goto http://bart.mydomain.com:8080/index.html http://bart.mydomain.com:8080/jsp/dirgloblogin.jsp But if I goto http://bart.mydomain.com:8080/servlet/uServlet I get a 404 from the log file I get : 2002-12-19 09:42:13 StandardContext[]: Mapping contextPath='' with requestURI='/servlet/uServlet' and relativeURI='/servlet/uServlet 2002-12-19 09:42:13 StandardContext[]: Trying exact match 2002-12-19 09:42:13 StandardContext[]: Trying prefix match 2002-12-19 09:42:13 StandardContext[]: Trying extension match 2002-12-19 09:42:13 StandardContext[]: Trying default match 2002-12-19 09:42:13 StandardContext[]: Mapped to servlet 'default' with servlet path '/servlet/uServlet' and path info 'null' and update=true 2002-12-19 09:42:13 default: DefaultServlet.serveResource: Serving resource '/servlet/uServlet' headers and data In my server.xml I have Engine name=Standalone defaultHost=localhost debug=9 Host name=localhost debug=0 appBase=/home/unit unpackWARs=true autoDeploy=true Context path= docBase=/home/unit crossContext=true debug=9 reloadable=false /Context #ls -ls /home/unit/WEB-INF/classes total 104 32 -rwxrwxrwx1 apache apache 32734 Dec 18 21:31 bbsServlet.class 4 drwxrwxrwx3 apache apache 4096 Aug 24 22:19 com 36 -rw-rw-r--1 apache apache 33984 Nov 6 15:43 EditjsServlet.class 32 -rwxrwxrwx1 apache apache 31030 Dec 18 21:31 uServlet.class Thanks for any Help!!! -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-user- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Should not be this hard(why is this a security risk)
These messages indicate that a fix is in the works: A new Tomcat 4.1.x release incorporating the fix to the invoker servlet will be made available shortly. Am I reading this correctly as saying the quick fix is to disable the invoker, but the long term fix is to change the invoker to make the problem go away? Larry [EMAIL PROTECTED] 12/19/02 09:38 AM See these messages: http://www.mail-archive.com/announcements@jakarta.apache.org/msg00122.html http://www.mail-archive.com/announcements@jakarta.apache.org/msg00128.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Should not be this hard(why is this a security risk)
-Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 12:09 PM To: [EMAIL PROTECTED] Subject: RE: Should not be this hard(why is this a security risk) These messages indicate that a fix is in the works: A new Tomcat 4.1.x release incorporating the fix to the invoker servlet will be made available shortly. Am I reading this correctly as saying the quick fix is to disable the invoker, but the long term fix is to change the invoker to make the problem go away? Actually, it's more the other way around. The quick fix was to patch the invoker servlet so that it doesn't allow you to invoke built-in servlets (such as the DefaultServlet). That eliminates the specific JSP source vulnerability that was reported in those messages. However, other servlets could have analogous problems. If for some reason you write a custom servlet that serves file content, for example, it could be vulnerable. Worse, any third-party servlets in your classpath can be executed, regardless of whether you actually use them or not in your application. All things said, the invoker servlet is a liability, and it's certainly not necessary in any case. It's best to use explicit mappings. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 Larry [EMAIL PROTECTED] 12/19/02 09:38 AM See these messages: http://www.mail-archive.com/announcements@jakarta.apache.org/msg00122.ht ml http://www.mail-archive.com/announcements@jakarta.apache.org/msg00128.ht ml -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Should not be this hard(why is this a security risk)
On Thu, 19 Dec 2002, Tim Moore wrote: Date: Thu, 19 Dec 2002 12:48:37 -0500 From: Tim Moore [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: Should not be this hard(why is this a security risk) -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 12:09 PM To: [EMAIL PROTECTED] Subject: RE: Should not be this hard(why is this a security risk) These messages indicate that a fix is in the works: A new Tomcat 4.1.x release incorporating the fix to the invoker servlet will be made available shortly. Am I reading this correctly as saying the quick fix is to disable the invoker, but the long term fix is to change the invoker to make the problem go away? Actually, it's more the other way around. The quick fix was to patch the invoker servlet so that it doesn't allow you to invoke built-in servlets (such as the DefaultServlet). That eliminates the specific JSP source vulnerability that was reported in those messages. However, other servlets could have analogous problems. If for some reason you write a custom servlet that serves file content, for example, it could be vulnerable. Worse, any third-party servlets in your classpath can be executed, regardless of whether you actually use them or not in your application. All things said, the invoker servlet is a liability, and it's certainly not necessary in any case. It's best to use explicit mappings. I agree with the above. For those who have existing applications based on /servlet/foo type URLs, you can emulate what the invoker servlet does by defining your servlet mappings cleverly. Assume you've got servlet classes com.mypackage.Foo and com.mypackage.Bar that you access with URLs like /servlet/com.mypackage.Foo and /servlet.mypackage.Bar. Adding the following to your web.xml will make those URLs work just as before without adding the vulnerability: servlet servlet-namefoo/servlet-name servlet-classcom.mypackage.Foo/servlet-class /servlet servlet servlet-namebar/servlet-name servlet-classcom.mypackage.Bar/servlet-class /servlet servlet-mapping servlet-namefoo/servlet-name url-pattern/servlet/com.mypackage.Foo/*/url-pattern /servlet-mapping servlet-mapping servlet-namebar/servlet-name url-pattern/servlet/com.mypackage.Bar/*/url-pattern /servlet-mapping Of course, you can also map your servlets to any other context-relative URL that you like, so you can make the URLs your users see prettier. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Should not be this hard(why is this a security risk)
Just a guess... Because someone could theoretically drop a servlet into your file system programmed to issue commands passed in as a parameter and execute them as root? - Original Message - From: Randy Paries [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Thursday, December 19, 2002 10:19 AM Subject: RE: Should not be this hard(why is this a security risk) That is what I needed ... Thanks all To follow this up, why is this a security risk? Do they want specific mapping for each servlet? Thanks -Original Message- From: PELOQUIN,JEFFREY (HP-Boise,ex1) [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 9:54 AM To: 'Tomcat Users List' Subject: RE: Should not be this hard From the release notes Enabling invoker servlet: Starting with Tomcat 4.1.12, the invoker servlet is no longer available by default in all webapp. Enabling it for all webapps is possible by editing $CATALINA_HOME/conf/web.xml to uncomment the /servlet/* servlet-mapping definition. Using the invoker servlet in a production environment is not recommended and is unsupported. -Original Message- From: Randy Paries [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 8:51 AM To: 'Tomcat Users List' Subject: Should not be this hard Hello, me again This should have been so easy (famous last words) I am upgrading from tomcat jakarta-tomcat-4.0.4 to jakarta-tomcat-4.1.17 4.0.4 was working fine. For some reason I can not find my servlets ARG! In my web.xml I have a load-on-startup/ and in the log file , the servlet Starts ok But if I goto http://bart.mydomain.com:8080/servlet/uServlet I get a 404... Here is some details. I have to be missing something very simple. My static html and jsps work ok when I goto http://bart.mydomain.com:8080/index.html http://bart.mydomain.com:8080/jsp/dirgloblogin.jsp But if I goto http://bart.mydomain.com:8080/servlet/uServlet I get a 404 from the log file I get : 2002-12-19 09:42:13 StandardContext[]: Mapping contextPath='' with requestURI='/servlet/uServlet' and relativeURI='/servlet/uServlet 2002-12-19 09:42:13 StandardContext[]: Trying exact match 2002-12-19 09:42:13 StandardContext[]: Trying prefix match 2002-12-19 09:42:13 StandardContext[]: Trying extension match 2002-12-19 09:42:13 StandardContext[]: Trying default match 2002-12-19 09:42:13 StandardContext[]: Mapped to servlet 'default' with servlet path '/servlet/uServlet' and path info 'null' and update=true 2002-12-19 09:42:13 default: DefaultServlet.serveResource: Serving resource '/servlet/uServlet' headers and data In my server.xml I have Engine name=Standalone defaultHost=localhost debug=9 Host name=localhost debug=0 appBase=/home/unit unpackWARs=true autoDeploy=true Context path= docBase=/home/unit crossContext=true debug=9 reloadable=false /Context #ls -ls /home/unit/WEB-INF/classes total 104 32 -rwxrwxrwx1 apache apache 32734 Dec 18 21:31 bbsServlet.class 4 drwxrwxrwx3 apache apache 4096 Aug 24 22:19 com 36 -rw-rw-r--1 apache apache 33984 Nov 6 15:43 EditjsServlet.class 32 -rwxrwxrwx1 apache apache 31030 Dec 18 21:31 uServlet.class Thanks for any Help!!! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Security RISK !
I think the idea of letting Apache directly access to the files into the webapp is interesting. This way there is no need to replicate the static content for Apache, and Apache will be faster serving all static content than Tomcat . But, at least in my experience, static files tend to be localized. Probably, a better approach would be to configure Apache to access some subdirectories into the webapp, such as /images and /js directories if they exist. If you mantain dynamic files separated from static ones, this task will be even easier. This way, you can let Apache serve your static content without compromising security, and without replicating files. - Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, October 24, 2002 12:08 PM Subject: Re: Security RISK ! 401/404 - Forbidden vs not found doesn't matter as long as the intruder is forbidden. Relying on confusing the user is a nice technique to preventing intruders since it may waste more of their time and make them more likely to give up. But that may make others more determined to try to break in. Depending on how apache is configured, the intruder will be able to view the HTTP response header and seeing you may be running mod_jk/mod_webapp or whatever. The intruder can also see if you are running jhtml,jsp, or /servlet/ - it will be easy to deduce you are using some servlet engine. Some servlet engines also set a session cookie per webapp. It would be easy to deduce that jsessionid cookie for /myfooapp indicates that /myfooapp is a webapp and it has a WEB-INF. So I will first ask for: http://bar/myfooapp/WEB-INF/web.xml. And hope I have a novice config and next ask for: http://bar/myfooapp/WEB-INF/ to see if I can get a directory listing. Then the fun really begins. Personally - I like my way better since I run multiple webapps on our servers. That way I don't have to explicitly protect each WEB-INF. (Which could get forgotten while installing a new webapp) Veniamin Fichin wrote: Tim Funk wrote: You'll want to protect your WEB-INF directory as well as any properties files. You can do that by using by the following in your httpd.conf: (This should be the syntax) Files ~ \.properties$ Order allow,deny Deny from all Satisfy All /Files Directory ~ /WEB-INF/ Order allow,deny Deny from all Satisfy All /Directory Recently I did something else. Say, I have a webapp named mine in Tomcat, and have this line in httpd.conf: Alias /mine /var/www/tomcat/webapps/mine/web I've made the web direcroty following recommendations described in section Source Organization of Tomcat docs (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/source.html). So, instead of denying any access to WEB-INF directory, I wrote: Alias /mine/WEB-INF /something_that_does_not_exists And, when I access http://localhost/mine/WEB-INF , I get 404 Not found error instead of 403 Forbidden . I think you will be more confusive for the intruder if he'll be told that WEB-INF don't even exists there. Or is this less secure to do that? -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
Rodrigo Ruiz wrote: I think the idea of letting Apache directly access to the files into the webapp is interesting. This way there is no need to replicate the static content for Apache, and Apache will be faster serving all static content than Tomcat. True, but bothersome to maintain. But, at least in my experience, static files tend to be localized. Probably, a better approach would be to configure Apache to access some subdirectories into the webapp, such as /images and /js directories if they exist. If you mantain dynamic files separated from static ones, this task will be even easier. This way, you can let Apache serve your static content without compromising security, and without replicating files. That way a web-app is encapsulated and Apache still gets to do it's job. The best thing would be if the connector would be able to do this auto-magically - that is, to create aliases in Apache for this kind of access, instead of having the Apache admin create these mappings every time a new web-app is installed. Nix. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
Tim Funk wrote: You'll want to protect your WEB-INF directory as well as any properties files. You can do that by using by the following in your httpd.conf: (This should be the syntax) Files ~ \.properties$ Order allow,deny Deny from all Satisfy All /Files Directory ~ /WEB-INF/ Order allow,deny Deny from all Satisfy All /Directory Recently I did something else. Say, I have a webapp named mine in Tomcat, and have this line in httpd.conf: Alias /mine /var/www/tomcat/webapps/mine/web I've made the web direcroty following recommendations described in section Source Organization of Tomcat docs (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/source.html). So, instead of denying any access to WEB-INF directory, I wrote: Alias /mine/WEB-INF /something_that_does_not_exists And, when I access http://localhost/mine/WEB-INF , I get 404 Not found error instead of 403 Forbidden . I think you will be more confusive for the intruder if he'll be told that WEB-INF don't even exists there. Or is this less secure to do that? -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
401/404 - Forbidden vs not found doesn't matter as long as the intruder is forbidden. Relying on confusing the user is a nice technique to preventing intruders since it may waste more of their time and make them more likely to give up. But that may make others more determined to try to break in. Depending on how apache is configured, the intruder will be able to view the HTTP response header and seeing you may be running mod_jk/mod_webapp or whatever. The intruder can also see if you are running jhtml,jsp, or /servlet/ - it will be easy to deduce you are using some servlet engine. Some servlet engines also set a session cookie per webapp. It would be easy to deduce that jsessionid cookie for /myfooapp indicates that /myfooapp is a webapp and it has a WEB-INF. So I will first ask for: http://bar/myfooapp/WEB-INF/web.xml. And hope I have a novice config and next ask for: http://bar/myfooapp/WEB-INF/ to see if I can get a directory listing. Then the fun really begins. Personally - I like my way better since I run multiple webapps on our servers. That way I don't have to explicitly protect each WEB-INF. (Which could get forgotten while installing a new webapp) Veniamin Fichin wrote: Tim Funk wrote: You'll want to protect your WEB-INF directory as well as any properties files. You can do that by using by the following in your httpd.conf: (This should be the syntax) Files ~ \.properties$ Order allow,deny Deny from all Satisfy All /Files Directory ~ /WEB-INF/ Order allow,deny Deny from all Satisfy All /Directory Recently I did something else. Say, I have a webapp named mine in Tomcat, and have this line in httpd.conf: Alias /mine /var/www/tomcat/webapps/mine/web I've made the web direcroty following recommendations described in section Source Organization of Tomcat docs (http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/source.html). So, instead of denying any access to WEB-INF directory, I wrote: Alias /mine/WEB-INF /something_that_does_not_exists And, when I access http://localhost/mine/WEB-INF , I get 404 Not found error instead of 403 Forbidden . I think you will be more confusive for the intruder if he'll be told that WEB-INF don't even exists there. Or is this less secure to do that? -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
This doesn't really pose a problem with a correctly configured connector that is setup to handle all *.jsp and servlet requests. rls Nikola Milutinovic [EMAIL PROTECTED] 10/22/2002 11:00 PM Please respond to Tomcat Users List To: Tomcat Users List [EMAIL PROTECTED] cc: Subject:Re: Security RISK ! Sigurður Bjarnason wrote: Hi all The question is.. is there any security risk if I Have the Apache DocumentRoot pointing straight to the webapps folder ?! First of all, Apache cannot handle JSPs and has no knowledge of Servlets. Second, if both Apache and Tomcat-via-connector access the same dir, won't there be a confusion? Third, yes, it is a security risk, since not only protection in Tomcat is bypassed, but Apache might display your JSP source. Nix. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
Robert L Sowders wrote: This doesn't really pose a problem with a correctly configured connector that is setup to handle all *.jsp and servlet requests. Perhaps, but that idea somehow defeats my idea of a web application as a path deployed from some other server. Maybe I'm wrong... Nix. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
You are not wrong at all. Best practices for web servers dictate that no programs that operate as root should have access to the document root of the web server. It is indeed a bad practice from a strict security stand point. I was just pointing out that it could be done without apparent danger of exposing jsp source. I didn't mean to condone that it should be done. Imagine the nightmare if all cgi's operated as root. :-() rls Nikola Milutinovic [EMAIL PROTECTED] 10/23/2002 02:29 AM Please respond to Tomcat Users List To: Tomcat Users List [EMAIL PROTECTED] cc: Subject:Re: Security RISK ! Robert L Sowders wrote: This doesn't really pose a problem with a correctly configured connector that is setup to handle all *.jsp and servlet requests. Perhaps, but that idea somehow defeats my idea of a web application as a path deployed from some other server. Maybe I'm wrong... Nix. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
Make sure you configure apache to forbid access to any /WEB-INF/ and /META-INF/ directories. You also may want to forbid access to *.war files in your DocumentRoot. If you use the lastest version of mod_jk 1.2 it will do this for you automatically if you use the JkAutoAlias config directive. Regards, Glenn Sigurður Bjarnason wrote: Hi all I am using apache 1.3 and tomcat 4.0.4 together I use apache to serve all the static content, witch I have a special directory for and Tomcat serve all the jsp and servlet stuff.. The question is.. is there any security risk if I Have the Apache DocumentRoot pointing straight to the webapps folder ?! ¨ Best Regards Siggi -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Security RISK !
Hi all I am using apache 1.3 and tomcat 4.0.4 together I use apache to serve all the static content, witch I have a special directory for and Tomcat serve all the jsp and servlet stuff.. The question is.. is there any security risk if I Have the Apache DocumentRoot pointing straight to the webapps folder ?! ¨ Best Regards Siggi -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
You'll want to protect your WEB-INF directory as well as any properties files. You can do that by using by the following in your httpd.conf: (This should be the syntax) Files ~ \.properties$ Order allow,deny Deny from all Satisfy All /Files Directory ~ /WEB-INF/ Order allow,deny Deny from all Satisfy All /Directory Sigurður Bjarnason wrote: Hi all I am using apache 1.3 and tomcat 4.0.4 together I use apache to serve all the static content, witch I have a special directory for and Tomcat serve all the jsp and servlet stuff.. The question is.. is there any security risk if I Have the Apache DocumentRoot pointing straight to the webapps folder ?! ¨ Best Regards Siggi -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
Sigurður Bjarnason wrote: Hi all The question is.. is there any security risk if I Have the Apache DocumentRoot pointing straight to the webapps folder ?! First of all, Apache cannot handle JSPs and has no knowledge of Servlets. Second, if both Apache and Tomcat-via-connector access the same dir, won't there be a confusion? Third, yes, it is a security risk, since not only protection in Tomcat is bypassed, but Apache might display your JSP source. Nix. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Security RISK !
One issue I am aware of, but may not apply, is that apache I think has a setting that can autofill in file extensions for you. If you put the files in the same folder you may want to check for that. If you map *.jsp to go to tomcat, index.jsp goes to tomcat. But if you type in /index apache, under that circumstance, would show the source of the jsp. There is also an issue with tomcat 4.0.4 and before if you type in the default servlet with the jsp name as an extension, it'll show the source. That is with or without apache though. -Dennis On Tue, 2002-10-22 at 10:23, Sigurður Bjarnason wrote: Hi all I am using apache 1.3 and tomcat 4.0.4 together I use apache to serve all the static content, witch I have a special directory for and Tomcat serve all the jsp and servlet stuff.. The question is.. is there any security risk if I Have the Apache DocumentRoot pointing straight to the webapps folder ?! ¨ Best Regards Siggi -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Wouldn't this be a security risk??
Hello everyone, I have been running tomcat for a while and just started to notice a few things. First, let me say I have it configure on a linux server with mod_webapp, with Tomcat version 4.0.3. Let's say I have a war file application called hello.war that I call like so: http://mydomain.com/webapps/hello/ But if I call it this way: http://mydomain.com/webapps/hello.war it forces a download. I realize this is not the proper way to call it but if someone did call it this way.. I believe I can stop this through Apache but I am not quite too sure. Does anyone else notice this or have a fix for it??? THanks, Chad -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Wouldn't this be a security risk??
Have apache deny the request. Very simple change to httpd.conf. For example: # No one in my WEB-INF directory Location /WEB-INF/ AllowOverride none deny from all /Location # No one look at my properties files Files ~ *.properties Order allow,deny Deny from all Satisfy All /Files # No one look at my website app config # OK - This is redundant since its in WEB-INF Files ~ web.xml Order allow,deny Deny from all Satisfy All /Files -Tim Chad Kellerman wrote: Hello everyone, I have been running tomcat for a while and just started to notice a few things. First, let me say I have it configure on a linux server with mod_webapp, with Tomcat version 4.0.3. Let's say I have a war file application called hello.war that I call like so: http://mydomain.com/webapps/hello/ But if I call it this way: http://mydomain.com/webapps/hello.war it forces a download. I realize this is not the proper way to call it but if someone did call it this way.. I believe I can stop this through Apache but I am not quite too sure. Does anyone else notice this or have a fix for it??? THanks, Chad -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
