This was a question about testing file upload functionality using a local java server on Windows 7 platform. Since the question evolved with Marko's input, I have edited it, so that those who run into the same challenge do not waste time on evolution details and reach conclusions sooner.
The challenge was to direct uploaded file to a folder outside of the WAR structure and successfully read it from there. For example: upload an image into c:/tmp/ and then redirect to a confirmation page that displays the image <img src="c:/tmp/test.jpg" />. The upload worked but image would not be displayed. And based on Marko's input, this makes sense because browser sitting at localhost will refuse to load anything from local disk structure using c:. Maybe these are security considerations similar to those with file input control where we cannot set a default path...
The following tag will work in a locally created .html file but when pasted into a jsp, it won't work. And the difference is that browser uses localhost to get to the jsp.
<img src="c:/tmp/test.jpg" />
Solutions
I think that Marko's answer pretty much defines what needs to be done. While I didn't go with that approach, it clearly is the better way to do it and I will accept that as the answer. Thanks, Marko!
For those who don't want to bother installing a Web server and are willing to live with a bit of a hack, here's what I have done. Again, I didn't want to upload files into my WAR structure because I would then need to remember about clearing that folder before deploying to the server. But that upload folder still needs to be accessible, so I simply created another dummy project and put that upload folder under its WebContent. This works for the purposes of my local testing. The only nuisance is that after uploading a file, I need to refresh the dummy project's WebContent in Eclipse.
config.properties
#for uploading files
fileUploadDirectory=C:/javawork/modelsite/tmp/WebContent
#for building html links
publicFileServicePrefix=http://localhost:8080/tmp
<img src="http://localhost:8080/tmp/test.jpg" /> // this works - tmp is the name of my dummy project.
If you are citing literally the HTML that goes to the browser (the one that you access via "vieew source") then this has nothing to do with Java. The browser is the one who interprets these links. If they fail to load, the problem is in the browser/file system.
UPDATE
According to the results of your additional diagnostics, I conclude that the browser (sensibly!) refuses to load anything from your local disk if it is referenced from an HTML file coming from an internet URL, even when that URL is localhost.
UPDATE 2
(Deleted, irrelevant)
UPDATE 3
However you handle the files uploaded to the server, it's definitely not going to look like your solution -- the file is on the server's local filesystem, not client's. This sort of thing can be handled at the Apache HTTP server level -- reserve an URL section for static content and configure Apache with a base directory from which to serve the static content. Even if you run the server locally, on the same machine where you test it, you still need to go through the network interface.
Related
I am working on some security alerts on one of our servers whereby a 'file download' JSP file is able to let a user download contents of WEB-INF for the web application (Which is located in the root folder of the site). It is a very crudely simple file, written in 2007, that uses java.io.FileInputStream on unsanitised input to return a file to the user.
The alert actually claimed that this was a directory traversal problem, which it is in one way as the following URI would download the web.xml for the user:
http://domain.com/filedownload.jsp?filename=../../WEB-INF/web.xml&filepath=some/directory/
Now obviously the 'directory traversal' part should be corrected by doing user input sanitising (Which this script does not yet do). However, the following URI also delivers the web.xml to the user, but input sanitisation for directory traversal would not help here, unless the sanitisation checks for 'WEB-INF' and other 'illegal' directories...
http://domain.com/filedownload.jsp?filename=web.xml&filepath=WEB-INF/
Is there a standardised way to prevent this in common servlet containers or does this need to be entirely managed by the developer of the code? I noticed that the Java 'normalize()' function would not strip out this directory from the user input.
I tried searching for an answer for this, but all I could find was information about preventing the 'serving' of WEB-INF directly, but nothing about preventing it from being accessed from a JSP file itself.
Thanks,
Tom...
You say the JSP page is using java.io.FileInputStream to read the file. That is a standard Java class that is not aware of the fact that it is running inside a servlet container.
So java.io.FileInputStream will be able to access any file that can be accessed by the user process the servlet container (JVM) is running under. There's nothing you could configure in the servlet container to prevent that.
You might like to make sure that files in other areas of the filesystem completely unrelated to the servlet container can't be accessed, e.g. like "/etc/passwd".
Assuming you're running on Linux, what does this URL do:
http://domain.com/filedownload.jsp?filename=passwd&filepath=/etc/
If it does return the file, you've got a bigger problem! Perhaps the security software (not sure what you're using?) that created the alerts will prevent download. If not, operating system file permissions can help, as long as the web server isn't running under root or other privileged account, but that's a short-term emergency fix only.
So no, there there no standardised way to prevent this in common servlet containers, and yes, it does need to be entirely managed by the developer of the code.
When using java.io.FileInputStream, it's the responsibility of the writer / maintainer of the JSP page to ensure that only valid paths are accessed.
It is quite a common question but I can't find an answer to it
I have a simple HTML with an input text box (type=file) and a submit button. On clicking the submit button, I call a js function where I try to get the complete path of the file
var data = $('#fileName').val();
the issue is I am not getting complete file path of the file I am uploading. I know due to security reasons chrome gives me a C:\fakePath\filename and firefox gives me only the fileName. But in case I need a complete path what shall I do?
PS: Further I will make an ajax call and give that file path to the back-end which needs it to read that file using FileReader
You cannot get the complete path! there is no way to do that!! Even though you are on an intranet and you have enough permissions.
A workaround for this is to have a textarea and ask the user to enter the complete path of the file.
In short you can't have the full name of a file once is loaded on server side, you will just have the file name and its content in a raw byte array (among other attributes). This is not a Java thing nor other server side technologies issue, is related to browser implementation (but it looks that IE6 may contain a flaw about this).
Not directly related to your question but caught my attention
PS: Further I will make an ajax call and give that file path to the back-end which needs it to read that file using FileReader
Usually, you can't handle a file upload using ajax because it can lead to security holes. Still, there are some browsers (like Chrome and Firefox) that allows you to send a file using XMLHttpRequest but that isn't allowed on some browsers (like IE8-) so you have to use an iframe in order to make the file ajax uploading work.
In order to avoid handling all these problems, I would advice you to use a third-party js library that handles the ajax file upload. An example is blueimp jQuery file upload that also has Java server side examples (DISCLAIMER: I do not work in this project nor I'm associated with blueimp in any way). Note that using this plugin requires that you have a mid knowledge on HTML/JavaScript/jQuery/Java Server Side so if you're a starter it may take you some time to make it work, but once it does is pretty good.
I dont know which technology you are using.. but you can always get file name once it is uploaded on server (Using php or .net )
your steps to upload should be like below:
1) Upload file to the server (e.z. /uploadedFiles/...filename
2) Create a method which will fetch file name from the uploaded path
3) simply insert file name in to the database (this will give you flexibility to change folder name of uploaded docs in future if required)
Generally filenames are not stored as it is . to avoid name conflict in future. So it is a advisable to always rename your filename by adding minutes & seconds after itsname.
If any doubts do ask.
Hope it helps.
Browsers block the filepath access on javascript for securit reasons.
The behavior makes sense, because the server doesn't have to know where the user stores the file on his computer, it is irrelevant to the upload process.
I am creating a series of websites that will share a common java code base but will each have a different look and feel, as well as make slightly different calls to a database. Each site will have a unique URL (www.siteA.com, www.siteB.com).
The necessary database information is stored in properties files that appear to be loaded when the applications are deployed (to a JBoss 4.2.3 server). The CSS and images are in static folders.
What I want:
The user enters www.siteA.com
The "unbranded" site is initialized
Java (or whatever needs to) checks the URL to see which files to load
siteA.properties and siteA.css are loaded from the siteA resources folder
siteA's customized site is served to the client
If www.siteB.com is entered, all of its info would be loaded. When I want to add a new Site C, I will just create a siteC resources folder, put the SiteC versions of properties and CSS in it, and the underlying common code should take care of noticing that www.siteC.com was entered and grab from the new folder. All of this should happen without having to redeploy any of the elements common to all the sites.
I think I've mostly figured out how to get the CSS/images side of this working, but I can't get the properties files loaded this way.
Is this even possible? I haven't even been able to find a high-level discussion of the process.
Why don't you look up the HOST http header and output the relevant information for each server using a PHP script. You can output common content using file from an HTML file stored somewhere on the server.
Kind of hard to explain in one line but my problem is essentially like this:
I made a java applet that I want to run on a web page that I packaged into a .jar file. I'm able to get the applet working fine using the <applet> tag but the problem is, if the user views the page source, they will see:
<applet archive="directory/program.jar">
Assuming .jar files can be easily opened and all the class files decompiled, all the user would have to do is go to www.url.com/directory/program.jar to download my .jar and they would have all my source code :(
So I'm wondering if there is either a way to protect my code/jar from being decompiled (other than obfuscation) or to use some kind of server-side script to feed the contents of the .jar directly to the browser from a server-side location not publically visible.
Any help is appreciated.
This is fundamentally impossible.
Java applets run the client.
Anything that runs on the client can be disassembled and modified by a sufficiently advanced user.
You should move your sensitive logic to the server and invoke it using HTTP requests ( and remember that the user can use Fiddler).
While you're at it, you should probably replace your applet with HTML and Javascript.
Other than obfuscation or encryption, no--one way or the other, the browser will have access to the jar.
You might be able to create an applet that loads more functionality at runtime.
There is no effective way to block access to the source code of any page; for the page to be readable by browsers and search engines, the source code has to be accessible, and therefore can be viewed and/or copied. That's just how the web works. HTML is sent as a text document and interpreted client-side.
Disabling the right-click is little more than an annoyance, and it works sporadically in alternative browsers. Even if you succeed, the View Source option in the menu is always present. The viewer could also use a download tool such as Wget, or even get the page from the Google cache without visiting your site at all.
Edit: Oops! I misunderstood your question. You should follow #SLaks advice and "move your sensitive logic to the server and invoke ot using HTTP requests ( and remember that the user can use Fiddler)."
While quantum mechanics do rule the universe, they have less of a grip on your code than you might suspect. You cannot both deploy code to the client browser and not deploy code to the client browser. You have the option of doing one or the other.
You can prevent direct browsing to your .jar file by locating it beneath the WEB-INF directory in your WAR file. This will also prevent <applet archive="directory/program.jar"> from working.
Once the jar is beneath the WEB-INF directory you will need something to feed the resource to the client browser; the Spring resources servlet is good for this (If you are using Java and Spring). I feel confident that other such tools exist. With the Sprint resours servlet, your would deploy your applet with something like this: <applet archive="resource/program.jar".
If you write your own resource distributor, you can add security to make it harder to get the jar file; perhaps add a header to your requests like IRGud: <user_id here> and fail any request that does not have that header (or acceptable contents in the header).
For example purposes, let's say I have a series of Locations on a website and the urls are of the form /location/#/ where # is the id of the location I want to view. Since I'm using Django with Apache, all of my static content is in /media. Each Location page is trying to load a Java applet that allows for file uploads.
<applet
codebase="/media/java/"
code="com.elementit.JavaPowUpload.Manager"
archive="JavaPowUpload.jar, commons-logging-1.1.jar, commons-httpclient-3.1-rc1.jar, commons-codec-1.3.jar"
width="200"
height="100"
name="java-uploader"
id="id-java-uploader"
mayscript="true"
alt="JavaPowUpload by www.element-it.com"></applet>
All of the listed jar files are in /media/java/ and are found by the web server. The applet appears to load on the page without a problem but when looking at the network traffic during page load I see there are several errors. Basically the applet seems to be looking for files that are within the jar, say com.elementit.JavaPowUpload.Messages_en.class, but is asking the web server for them, which amounts to requesting /media/java/com/elementit/JavaPowUpload/Messages_en.class, which of course does not exist. Note that if I get rid of codebase and give the full path to each jar, I still have a similar problem where the request is then /location/#/com/elementit/JavaPowUpload/Messages_en.class. How do I set things up so that the jar file is searched rather than the filesystem?
See the codebase_lookup applet attribute.
Despite taking this code from another page on a different server, it appears there is a slight error in the applet's code attribute. Adding .class to the string fixed my problem, but I'm unsure why it works without it on the other host and page.
code="com.elementit.JavaPowUpload.Manager.class"