tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread mamalacation

Dear all,

I had to setup a Windows 2008r2 box running tomcat 6.0.26 in a virtual
machine, in order to see if a project/site from a windows 2003 SP2 and
tomcat 5.0 could run on it. During the upgrade process everything worked
well (after a few tricks), except from one thing (at this point I have to
declare that I am no tomcat/Windows expert!):

The site has a place where people can download files from. When it displays
the files to be downloaded, it contains a hyperlink containing backslashes
in their names. Once a user clicks on those hyperlinks (using firefox), a
new tab is created and a blank page is displayed. The address bar shows the
link containing the backslashes. If I change them to frontslashes by hand,
the file is downloaded. If I use firefox and click on the same links on the
same site hosted on the older machine (tomcat 5, etc.), it works just fine.
IE on the other hand works fine on both servers.

I used a packet sniffer to intercept the packets and my results are as
follows (server1 is the old server and server2 is the new):

server1:

GET /site/archive%5C150%5CdownloadFile%5C3535%5CLec-1.ppt HTTP/1.1
Host: server1:8083
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9)
Gecko/20100526 Firefox/3.5.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
http://server1:8083/site/cms.downloadFile.data.do?method=jsplistPRMID=1020
Cookie: JSESSIONID=71B2F50E3D20E9CD2812BE4635315C4E;
__utma=55546303.157551831.1272378139.1274780984.1274887786.4;
__utmz=55546303.1272378139.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)
If-Modified-Since: Tue, 17 Mar 2009 09:08:43 GMT
If-None-Match: W/2693120-1237280923177


HTTP/1.1 304 Not Modified
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: No-cache
Date: Thu, 10 Jun 2010 13:20:39 GMT
Server: Apache-Coyote/1.1



server2:

GET /site/archive%5C150%5CdownloadFile%5C3535%5CLec-1.ppt HTTP/1.1
Host: server2:8083
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9)
Gecko/20100526 Firefox/3.5.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer:
http://server2:8083/site/cms.downloadFile.data.do?method=jsplistPRMID=1020
Cookie: JSESSIONID=DD8FE273A842A3F922C1ABE9C2803DA8;
__utma=55546303.157551831.1272378139.1274780984.1274887786.4;
__utmz=55546303.1272378139.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)


HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Thu, 10 Jun 2010 13:20:38 GMT
Connection: close


The above transactions are intercepted firefox sessions from the same client
to the two servers. One may notice that there are no practical differences
other than the two headers regarding caching (If-Modified-Since and
If-None-Match). Do be honest, I am not sure why the old server receives
caching headers whereas the new one doesn't (the configuration of the old
server was performed by other admins). Maybe the answer is hidden in this
point...but I don't think so.

Does anyone have a clue to what may be happening? I would very much like to
set some configuration directive in tomcat that instructs it to treat
backslashes in URIs as if they were frontslashes in order to stop this
issue, but I cannot find such one.

I Hope that somebody may help me in this.

Thank you all for your time in advance!
-- 
View this message in context: 
http://old.nabble.com/tomcat-6.0-404-error-only-on-firefox-due-to-backslashes--tp28844040p28844040.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread mamalacation

I have seen the configuration variables: 

org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH
and
org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH

that if they could be set to true, they could solve my problem, but I have
no idea where to place them (configuration file?!), and/or their syntax.
-- 
View this message in context: 
http://old.nabble.com/tomcat-6.0-404-error-only-on-firefox-due-to-backslashes--tp28844040p28844410.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread Pid
On 10/06/2010 15:41, mamalacation wrote:
 
 Dear all,
 
 I had to setup a Windows 2008r2 box running tomcat 6.0.26 in a virtual
 machine, in order to see if a project/site from a windows 2003 SP2 and
 tomcat 5.0 could run on it. During the upgrade process everything worked
 well (after a few tricks), except from one thing (at this point I have to
 declare that I am no tomcat/Windows expert!):
 
 The site has a place where people can download files from. When it displays
 the files to be downloaded, it contains a hyperlink containing backslashes
 in their names. Once a user clicks on those hyperlinks (using firefox), a
 new tab is created and a blank page is displayed. The address bar shows the
 link containing the backslashes. If I change them to frontslashes by hand,
 the file is downloaded. If I use firefox and click on the same links on the
 same site hosted on the older machine (tomcat 5, etc.), it works just fine.
 IE on the other hand works fine on both servers.
 
 I used a packet sniffer to intercept the packets and my results are as
 follows (server1 is the old server and server2 is the new):
 
 server1:
 
 GET /site/archive%5C150%5CdownloadFile%5C3535%5CLec-1.ppt HTTP/1.1
 Host: server1:8083
 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9)
 Gecko/20100526 Firefox/3.5.9
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-us,en;q=0.5
 Accept-Encoding: gzip,deflate
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive: 300
 Connection: keep-alive
 Referer:
 http://server1:8083/site/cms.downloadFile.data.do?method=jsplistPRMID=1020
 Cookie: JSESSIONID=71B2F50E3D20E9CD2812BE4635315C4E;
 __utma=55546303.157551831.1272378139.1274780984.1274887786.4;
 __utmz=55546303.1272378139.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)
 If-Modified-Since: Tue, 17 Mar 2009 09:08:43 GMT
 If-None-Match: W/2693120-1237280923177
 
 
 HTTP/1.1 304 Not Modified
 Cache-Control: no-cache
 Expires: Thu, 01 Jan 1970 00:00:00 GMT
 Pragma: No-cache
 Date: Thu, 10 Jun 2010 13:20:39 GMT
 Server: Apache-Coyote/1.1
 
 
 
 server2:
 
 GET /site/archive%5C150%5CdownloadFile%5C3535%5CLec-1.ppt HTTP/1.1
 Host: server2:8083
 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9)
 Gecko/20100526 Firefox/3.5.9
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-us,en;q=0.5
 Accept-Encoding: gzip,deflate
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive: 300
 Connection: keep-alive
 Referer:
 http://server2:8083/site/cms.downloadFile.data.do?method=jsplistPRMID=1020
 Cookie: JSESSIONID=DD8FE273A842A3F922C1ABE9C2803DA8;
 __utma=55546303.157551831.1272378139.1274780984.1274887786.4;
 __utmz=55546303.1272378139.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)
 
 
 HTTP/1.1 400 Bad Request
 Server: Apache-Coyote/1.1
 Content-Length: 0
 Date: Thu, 10 Jun 2010 13:20:38 GMT
 Connection: close
 
 
 The above transactions are intercepted firefox sessions from the same client
 to the two servers. One may notice that there are no practical differences
 other than the two headers regarding caching (If-Modified-Since and
 If-None-Match). Do be honest, I am not sure why the old server receives
 caching headers whereas the new one doesn't (the configuration of the old
 server was performed by other admins). Maybe the answer is hidden in this
 point...but I don't think so.
 
 Does anyone have a clue to what may be happening? I would very much like to
 set some configuration directive in tomcat that instructs it to treat
 backslashes in URIs as if they were frontslashes in order to stop this
 issue, but I cannot find such one.

Why not just fix the URLs?


p

 I Hope that somebody may help me in this.
 
 Thank you all for your time in advance!




signature.asc
Description: OpenPGP digital signature


Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread mamalacation



Pid * wrote:
 
 
 Why not just fix the URLs?
 
 p
 
  
 

I am not sure what you mean by saying fix the URLs, but in the meantime I
found out how to set the option org.apache.catalina.connector.
CoyoteAdapter.ALLOW_BACKSLASH=true in conf/catalina.properties, so now it
almost works! It starts downloading the file, but the filename to be saved
is path\to\file.ext  instead of file.ext.

Does anybody know how this can be fixed?
-- 
View this message in context: 
http://old.nabble.com/tomcat-6.0-404-error-only-on-firefox-due-to-backslashes--tp28844040p28845001.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread André Warnier

mamalacation wrote:



Pid * wrote:


Why not just fix the URLs?

p

 



I am not sure what you mean by saying fix the URLs, but in the meantime I
found out how to set the option org.apache.catalina.connector.
CoyoteAdapter.ALLOW_BACKSLASH=true in conf/catalina.properties, so now it
almost works! It starts downloading the file, but the filename to be saved
is path\to\file.ext  instead of file.ext.

Does anybody know how this can be fixed?


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.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread Ziggy
For security purposes, Mozilla applications block links to local files (and
directories) from remote files. This includes linking to files on your hard
drive, on mapped network drives, and accessible via Uniform Naming
Conventionhttp://en.wikipedia.org/wiki/Path_%28computing%29#Uniform_Naming_Convention(UNC)
paths. This
*prevents* a number of unpleasant possibilities, including:

   - Allowing sites to detect your operating system by checking default
   installation paths
   - Allowing sites to exploit system vulnerabilities (e.g., C:\con\con in
   Windows 95/98)
   - Allowing sites to detect browser preferences or read sensitive data

See here for more info
http://kb.mozillazine.org/Links_to_local_pages_don%27t_work

--
Dini


On Thu, Jun 10, 2010 at 5:18 PM, André Warnier a...@ice-sa.com wrote:

 mamalacation wrote:



 Pid * wrote:


 Why not just fix the URLs?

 p




 I am not sure what you mean by saying fix the URLs, but in the meantime
 I
 found out how to set the option org.apache.catalina.connector.
 CoyoteAdapter.ALLOW_BACKSLASH=true in conf/catalina.properties, so now it
 almost works! It starts downloading the file, but the filename to be saved
 is path\to\file.ext  instead of file.ext.

 Does anybody know how this can be fixed?


 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.




 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread mamalacation



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. 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.

Thank you for your answer and time.
-- 
View this message in context: 
http://old.nabble.com/tomcat-6.0-404-error-only-on-firefox-due-to-backslashes--tp28844040p28845545.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat 6.0 404 error only on firefox due to backslashes?

2010-06-10 Thread André Warnier

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