I have a struts 1.2 application with multiple different applications housed in it, each with their own config file. The issue I have comes down to an XSS attack. Each app is setup as follows...
http://www.myapp.com/app/app1/welcome.action
http://www.myapp.com/app/app2/welcome.action
http://www.myapp.com/app/app3/welcome.action
Where the app1, app2, and app3 are folders. The issue I have is that a user could do the following...
http://www.myapp.com/app/app1<img src=a onerror=alert("alert")>/welcome.action
Causing an XSS attack on the site. The issue is since the "app1" is a folder I can't use a servlet filter to prevent malicious code there. Any advice from anyone?
Create a Servlet filter and map it to URL pattern /* as first filter in the chain. Then all requests will be routed through this filter. In the filter.doFilter() handle special characters like "<". Better look at OWASP ESAPI (java) project to handle these things: http://code.google.com/p/owasp-esapi-java/
Related
I have a class that extends JAX-RS' Application. Its ApplicationPath is currently "/", however this overrides all requests from the root, which sucks because I have a lot of other servlets listed in web.xml that I don't want to handle with REST. I'd like to gradually move these existing endpoints over to JAX-RS, but all examples I've seen would imply that I can't selectively handle endpoints like this without URL rewrite rules on the server.
I would like to move these endpoints as such without having to rename them, i.e. without having to change /stuff/list to /rest/stuff/list.
Is there any other way? I'm using RESTeasy as my provider. It has a resteasy.resources web.xml parameter option with which I can specify my resources manually, but an Application with an ApplicationPath is still needed.
I am using JBoss 4.0.5.GA to run a set of java applications. One of them is a web frontend, using Spring 1.4. URL mappings are configured in a way that 'fake' pages from request URLs are mapped to controllers. That means that when someone requests /index.htm, there's no actual 'index.htm' on disk, and that request maps to a specific conroller which then renders a jsp view.
So the problem is as follows: I need to tell JBoss to somehow forward all requests for directory indices to corresponding 'index.htm' URLs like so: / → /index.htm; /news/ → /news/index.htm; /foo/bar/baz/ → /foo/bar/baz/index.htm and so on.
I can't use Tomcat's welcome-file-list feature because it looks for those files on disk, while all 'index.htm's are fake and don't actually exist on disk.
Why can't you add a controller that handles requests for / URLs, that forwards on to the index.htm controllers?
If that's not an option, consider using The URLRewriteFilter library to perform forwarding or redirecting. This should be able to sit outside of your own code.
I've got a Spring Web MVC application (and also a BlazeDS application, though not as relevant) where files are dynamically generated based on certain client actions.
I'd like to just map a certain directory on the file system to Spring MVC (or the app server) url and let it serve the files in that directory (with streaming and standard last-modified header support). Ideally, the mapped directory would be configured via the spring config, since I already have support per-machine for setting that up.
So, how can I do this? The best I can find so far is to write a controller that reads the file manually and streams it byte-by-byte. However, that seems far less than ideal. Is support for something like this already baked into Spring MVC or the standard application server spec?
Thanks!
If your processing model supports it, why not cut the middleman of the filesystem out of the picture completely and just stream the files back through the response stream as they are generated? Take a look at the AbstractExcelView and AbstractPDFView classes of Spring MVC to see some examples of how this is done.
or the standard application server spec?
Yes, there is. As you didn't mention which one you're using, I'll give a Tomcat-targeted answer. All you basically need to do is to add a Context element for /path/to/your/resources in /conf/server.xml:
<Context docBase="/path/to/your/resources" path="/resources" />
This way they'll be accessible through http://example.com/resources/...
Ideal for this is using an lightweight proxying server in front of your appserver, like a nginx or lighthttpd. You can configure it for serving static content, without calling your app.
If directory and files so dynamic, you can prepare real path to file at your controller and give this filepath to the frontend server, using headers. For example for nginx it's a X-Accel-Redirect header. Read more about this (and follow links for other http servers) there
I am new to J2EE and related stuff in general. I am trying to move a particular web application from a Sun One server deployment on to JBoss. The application is filled with a lot of servlets where each one re-directs to another.
There are way too many servlets for me to enter a mapping between each of these servlet class to a URL-mapping individually in web.xml. The application code has many redirects where they name the servlet class names itself in the redirect-URL. As of now when I run it on JBoss the redirections to URL with servlet classnames in URL don't seem to work on JBoss (it gives a 404: Not Found, probably since there is no mapping in the web.xml). So is there any config setting that I can set to allow this to happen or should manually enter each and every URLpattern-to-Servlet mapping in the web.xml?
Thank you.
There are two solutions.
As we know JBoss uses Tomcat under the hood as a servlet container. You can enable invoker servlet, that would save you from mapping the whole lot in web.xml. But beware, it will be naive to do that, and not at all encouraged.
Secondly, you can write another servlet/filter and map just that in your web.xml for every url pattern, may be. Then that new servlet of your can forward the requests to whatever servlet it should.
I hope you get my point.
Not sure what you mean by this
the application code has many redirects where they name the servlet class names itself in the redirect-URL
Do you have hardcoded urls in the servlet classes? How many servlets? If you have hardcoded urls they may all have broken because the context is slightly different, or the appname, etc.etc. Can you post an example?
Well, there are some hard-coded URLs in the code, but even if i typed in the right URLs in browser directly I still get a 404. There are about 30 servlets (a conservative approximation). Ex: http://FQDN_SERVER.com/?arg1=ABCD&arg2=XYZ
Here the servlet-classname is literally the classname of the servlet without ".class" extension, which may not be a good practice. But the code is full of such redirections and if I have to change this then I have to add a new url-pattern to each of these servlets in the web.xml and construct a new red-rect URL for each of these servlets. So is there anyway I can avoid this or will I have to go through the pain of doing the above mentioned?
Thanks,
Manoj
Sorry the URL-pattern looks this http://FQDN_SERVER.com/servlet-classname?arg1=ABCD&arg2=XYZ
I have a very basic question about MVC web applications in Java.
Since the olden days of raw JSP up until current technologies like Seam, a very basic pattern has always been the internal dispatch from the controller that initially accepted the request to the view layer that creates the output to be sent to the client.
This internal dispatch is generally done (although the mechanism may be hidden through an extra layer of configuration) by asking the servlet container for a new resource using a URL. The mapping of these URL are done by the same web.xml that also defines the "real" URL to the outside.
Unless special measures are taken, it is often possible to directly access the view layer directly. Witness the Seam "registration" demo, where you can bypass "register.seam" and directly go to "registered.xhtml". This is a potential security problem. At the very least, it leaks view template source code.
I am aware that this is only a basic sample application, but it is also strange that any extra measures should need to be taken to declare these internal resources invisible to the outside.
What is the easiest way to restrict URL entry points?
Is there maybe something like the "WEB-INF" directory, a magic URL path component that can only be accessed by internal requests?
You can prevent access to internal resources by using a security-constraint in your web.xml deployment descriptor.
For example, I use the following configuration to prevent direct access to JSPs:
<!-- Prevent direct access to JSPs. -->
<security-constraint>
<web-resource-collection>
<web-resource-name>JSP templates</web-resource-name>
<url-pattern>*.jsp</url-pattern>
</web-resource-collection>
<auth-constraint/> <!-- i.e. nobody -->
</security-constraint>
I would not recommend allowing Internet requests to directly access your appserver. I'd throw a webserver in front, then in it, allow the request of certain kinds of URLs. Don't want people to go to foo.com/jsps? Restrict it once and for all there.
There's a bit of a conversation on the topic here: hiding pages behind WEB-INF?
One way to handle this would be to construct a Servlet Filter which examines the request path of every request and handles each request accordingly. Here is a link that could help get you started, JavaServer Pages (JSP) and JSTL - Access control with JSP
I have now seen a couple of applications that put their internal JSP into WEB-INF/jsp. That seems to do the trick, at least for JSP, and also for Velocity. It does not seem to work for JSF, though.