mamalacation wrote:
awarnier wrote:
No. But before you find a "solution" and create a big security issue, I
suggest that from now on you check this with different browsers, and
particularly different IE versions.
I think that the "fix" you found is really a kludge, in that it kind of
works by making some pieces of software believe that this is an
acceptable file name, while other pieces may see this as a file path.
But it seems *really* dangerous to me.
As pid indicated, you should fix the problem, not the symptom.
Or you will end up sorry, I am quite certain.
Fixing the URLs in this case means to replace the %5C's (escaped \) by
escaped "/" characters, before you send the links to the browser.
OK, now I understand what you mean by "fixing the URLs". The problem with
this alternative, is that I have no access to the source code (which is
huge, by the way), and I wish to solve this issue through the
configuration-way (because I believe that the problem can be solved that
way) and not the code-way . That is because on tomcat 5 there is no issue
with the filenames, and hence I assumed that this should be the case with
tomcat 6 too.
On the other hand, you are right as far as security is concerned, and I
wouldn't want to impose any security holes by using this "fix".
The potential issue here is that if the filename comes from the server
as "\windows\system32\some.dll", and the user just clicks on OK, and
some buggy version of a browser just does it, you may get some very
unhappy users.
I just
assume that there should be a rational solution to my problem, without
having to touch the sources and/or opening holes in my system.
That is not so sure.
I have not checked this (and it would require some work) but it is at
least possible that this difference in behaviour between Tomcat 5.x and
6.x is the result of a change made explicitly to avoid such a security
issue. In such a case, I would not expect that there would be any
configuration possibility at the server level in Tomcat 6.x that would
allow you to do something that is fundamentally incorrect.
It is also possible that this was a bug in Tomcat 5.x, and that this bug
has been fixed in a later version of Tomcat 5.x, but not in the version
you are running on the old server.
The basic problem here seems to be at the application level, which
creates invalid URL links to documents on the server. (At least I think
they are invalid, and that even if the server is a Windows server, URLs
pointing to server files should still have "/" as the path separator).
So you should first complain to the application developers, and ask them
to fix their application.
I know that this is not necessarily easy, but asking the Tomcat
developers to provide an option which /might/ create a security issue is
not going to be any easier.
Otherwise, you /may/ still have a couple of options.
One of them would be this :
http://tuckey.org/urlrewrite/
which may allow you to catch these URLs early, and flip their slashes
before letting Tomcat try to serve the document.
But I do not know if it would see the original URL soon enough to avoid
the Tomcat error.
If not, then you could try an Apache httpd with mod_rewrite, in front of
your Tomcat. But maybe Apache httpd also rejects these URLs early.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
