Aditi Sinha wrote:
Thanks Guys.
As per my reading of the suggested material and looking at the logs that
Andre has shared, I think there are two ways in which the directory
traversal attack could be made.
1. By having ..\ equivalents in the URL itself
2. By having ..\ equivalents in the request parameters.
In my case, I am not worried about the request parameters since my
application doesn't handle any such path related queries and all request
parameters are signed by our client app.
So, It would really help me narrow down on a course of action ff you guys
can tell me -
*Whether someone can get access to any file/directory outside the tomcat
webapps folder using "Style 1 (using ..\ equivalent in the URL itself)
Directory traversal attack (scoped to Tomcat) on Windows".*
In principle, they can not, unless you specifically take steps to make life
easy for them.
For example, if inside of your webapps directory, you had symbolic links leading elsewhere
(but I don't think that under Windows this works).
In your normal setup, is there any front-end system in front of Tomcat, or do
clients
always access Tomcat directly ?
(Because if there is a front-end, it is relatively easy to make configuration mistakes at
the front-end level which allow the front-end to bypass Tomcat security and access
resources that the client should not be able to access. That was one of the points of
CVE-2007-0450).
Note also that the fact that you do not have explicit filename or filepath
parameters
passed as arguments or query strings in your application, does not mean that you do not
have security isues of this general nature. *Everything* that a user types in a form of
your application and that is later used by your application to do anything at the OS or
filesystem level, even after mangling or combination with other information in your
application, is suspect by definition. For example, such inputs could easily contain
characters such as ">", "|", "&" etc.. which may trigger a special effect in some entirely
different area of your application.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
