Re: Securing Tomcat Context Descriptor
I thing you can use the Java Security Manager and OS level file permisssion for this or wrote your own DataSource JNDI Factory. Peter Brett Parsons schrieb: Hi All, There is a requirement on the server that we have Tomcat 5.0.28 deployed that no username/password information can be stored in plaintext (in the open). Like many people, we are using JNDI datasources in our web application. The datasource connection information (including the database username/password) is stored in the Tomcat Context Descriptor under TOMCATDIR/conf/Catalina/localhost/myApp.xml. Does Tomcat provide a more secure way of storing the connection information stored in these context deployment descriptors? Has anyone else run into the same problem and been able to solve it somehow? Thanks, Brett - 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: Securing Tomcat Context Descriptor
A couple of observations: - If someone can read the context descriptor they pretty much own Tomcat and probably the server as well. If this person is unauthorised, you have big problems regardless of whether or not they have read-only access to the database. - If the password is encrypted, where do you store the decryption key? Tomcat still needs to be able to decrypt the password in order to use it to access the database. At best, this is security by obscurity which is not very good security at all. You could write some custom code that required the password to be entered on the command line when Tomcat starts but this still has the following issues: - If Tomcat goes down, you need someone who knows the password to restart it. If the group of people that know the password is small, you have an availability issue. - Chances are that everyone who administers Tomcat will know this password. Given that these people should be the only ones with access at the OS level to the Tomcat configuration files there seems little point in going to all this trouble. In my experience securing the configuration files (Tomcat JVM) using OS file permissions is usually the appropriate course of action to take unless your security environment is very unusual. Mark Brett Parsons wrote: Hi All, There is a requirement on the server that we have Tomcat 5.0.28 deployed that no username/password information can be stored in plaintext (in the open). Like many people, we are using JNDI datasources in our web application. The datasource connection information (including the database username/password) is stored in the Tomcat Context Descriptor under TOMCATDIR/conf/Catalina/localhost/myApp.xml. Does Tomcat provide a more secure way of storing the connection information stored in these context deployment descriptors? Has anyone else run into the same problem and been able to solve it somehow? Thanks, Brett - 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: Securing tomcat
On Mon, Oct 18, 2004 at 11:47:19AM +, kax wrote: : Are there any good documentation on how to secure Tomcat 5 for production use? I'd bet there's a lot of good advice in the archives, as this topic appears every so often. ;) Google's also a good starting point. High-level concepts to consider: 1/ Tomcat is just the container that runs your webapp; so ask yourself, how secure is my webapp against attacks and (intentionally) improper use? Several texts and websites cover this topic at length. 2/ Securing Tomcat is of limited value if there are holes elsewhere. Imagine a request, moving from the end-user's browser, through Tomcat (and perhaps a database) and then back to the user. What potential vulnerabilities exist? -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Securing tomcat
Hi, Ok, I'll try to find the stuff I want to do on google. But I have some other questions that is somehow related to the security issue. 1. From what I have read it is not possible to lookup the objects bound in the jndi in Tomcat from another JVM. Is this correct? 2. Can I use the same name for a datasource in two different web applications deployed on the same instance of Tomcat? I'm using a separate context file for each application. Thanks in advance /Kax From: QM [EMAIL PROTECTED] Date: 2004/10/18 må PM 12:55:46 GMT To: Tomcat Users List [EMAIL PROTECTED] Ämne: Re: Securing tomcat On Mon, Oct 18, 2004 at 11:47:19AM +, kax wrote: : Are there any good documentation on how to secure Tomcat 5 for production use? I'd bet there's a lot of good advice in the archives, as this topic appears every so often. ;) Google's also a good starting point. High-level concepts to consider: 1/ Tomcat is just the container that runs your webapp; so ask yourself, how secure is my webapp against attacks and (intentionally) improper use? Several texts and websites cover this topic at length. 2/ Securing Tomcat is of limited value if there are holes elsewhere. Imagine a request, moving from the end-user's browser, through Tomcat (and perhaps a database) and then back to the user. What potential vulnerabilities exist? -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - 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: Re: Securing tomcat
Hi, 1. From what I have read it is not possible to lookup the objects bound in the jndi in Tomcat from another JVM. Is this correct? Yeah. 2. Can I use the same name for a datasource in two different web applications deployed on the same instance of Tomcat? I'm using a separate context file for each application. Yeah. Obviously if you were declaring these datasources in a GlobalNamingResources block the answer would be No. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: securing tomcat...
Just put this in your web.xml for root webapp or others...
error-page
error-code404/error-code
location/404error.html/location
/error-page
and create 404error.html to say whatever you like.
Ken
Jason Pyeron wrote:
has any one put together a faq/howto on securing tomcat?
our first goal is to prevent determination of the server version by a web
client.
an example of this is for url http://127.1:8080/xxdfsdf this is returned, note the Server:
Apache Coyote/1.0 and Apache Tomcat/4.1.12
HTTP/1.1 404 /xxdfsdf
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Transfer-Encoding: chunked
Date: Tue, 31 Dec 2002 20:46:09 GMT
Server: Apache Coyote/1.0
htmlheadtitleApache Tomcat/4.1.12 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color
: white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color :
#0086b2;} HR{color : #0086b2;} --/STYLE /headbodyh1HTTP Status
404 - /xxdfsdf/h1HR size=1 noshadepbty
pe/b Status report/ppbmessage/b
u/xxdfsdf/u/ppbdescription/b uThe requested resource
(/xxdfsdf)
is not available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.12/h3/body/html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: securing tomcat...
-Original Message- From: Ken Anderson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 31, 2002 5:07 PM To: Tomcat Users List Subject: Re: securing tomcat... Just put this in your web.xml for root webapp or others... error-page error-code404/error-code location/404error.html/location /error-page and create 404error.html to say whatever you like. It would still be visible in the HTTP headers, which is only ten seconds additional work to determine for the casual hacker, and visible from any page. It's possible to change/remove the server string by editing the sources, of course. You could also front-end Tomcat with HTTPD, which I believe has a config element for changing the server string. The server string is a non-essential part of client-server operation for well-behaved servers so removing it won't make a difference, although it doesn't do great things for the statistics that are generated for Apache :-/ -b -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: securing tomcat...
Jason,
If by securing you mean hardening, well then no. But we have posted a
white paper on Tomcat security according to the servlet specification:
http://www.cafesoft.com/products/cams/tomcat-security.html
Gary
Jason Pyeron wrote:
has any one put together a faq/howto on securing tomcat?
our first goal is to prevent determination of the server version by a web
client.
an example of this is for url http://127.1:8080/xxdfsdf this is returned, note the Server:
Apache Coyote/1.0 and Apache Tomcat/4.1.12
HTTP/1.1 404 /xxdfsdf
Content-Type: text/html;charset=ISO-8859-1
Content-Language: en-US
Transfer-Encoding: chunked
Date: Tue, 31 Dec 2002 20:46:09 GMT
Server: Apache Coyote/1.0
htmlheadtitleApache Tomcat/4.1.12 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color
: white;background-color : #0086b2;} H3{font-family :
sans-serif,Arial,Tahoma;color : white;background-color : #0086b2;}
BODY{font-family : sans-serif,Arial,Tahoma;color : black;background-color
: white;} B{color : white;background-color :
#0086b2;} HR{color : #0086b2;} --/STYLE /headbodyh1HTTP Status
404 - /xxdfsdf/h1HR size=1 noshadepbty
pe/b Status report/ppbmessage/b
u/xxdfsdf/u/ppbdescription/b uThe requested resource
(/xxdfsdf)
is not available./u/pHR size=1 noshadeh3Apache
Tomcat/4.1.12/h3/body/html
--
Gary Gwin
http://www.cafesoft.com
*
* *
* The Cafesoft Access Management System, Cams, is security*
* software that provides single sign-on authentication and*
* centralized access control for Apache, Tomcat, and custom *
* resources. *
* *
*
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: securing tomcat... [RBS2003010100000068]
Ahoy there! This is an automated response, to let you know that we have received your query and will answer your email as soon as possible. We know you'd like to get back to playing our state-of-the-art online games. We'd therefore like to assure you that we are determined to keep our service at the level that you've come to expect from The River Belle Online Casino. Thank you for your patience and enjoy your day! Best wishes, Sebastian First Mate RIVER BELLE ONLINE CASINO RIVER BELLE CASINOS ONLINE RIVER BELLE ACES HIGH Enjoy Southern HospitalityFast Paced Casino Action www.riverbelle.com/a3099 www.aceshigh.com/a3181 24/7 toll-free support24/7 toll-free support USA:1 888 615 2383USA:1 877 566 0482 CANADA: 1 888 552 4196CANADA: 1 877 776 0549 UK: 0 800 783 4381UK: 0 800 169 8796 E-mail support: E-mail support [EMAIL PROTECTED][EMAIL PROTECTED] E.O.E. The River Belle Online Casino respects your online time and privacy. If you wish to be removed from our mailing list and not receive any promotional e-mails from us, please send an e-mail to [EMAIL PROTECTED] and type UNSUBSCRIBE in the subject bar. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
