tomcat 6.0 404 error only on firefox due to backslashes?
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?
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?
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?
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?
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?
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?
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?
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