We are facing problems with XSS attacks to our application. We are preventing this by using normal filters for GET requests.
We are using RESTEasy REST webservice calls to our application. Our filter not filtering the data inside form GET/POST/DELETE/PUT requests.
The basic requirment is we need to check the XSS attacks on all the fields,headers and cookies as well.
How do we get the posted values before invoking the method. Just like filters what we did for normal requests.
I am using resteasy2.0 version for our app.
Is there anyway to update the request wrapper before going to invoke rest method.
Please give us some suggestions on this. Thanks in advance.
Thanks,
Govind.
Resteasy 2.0 allows you to use Interceptors on JAX-RS invocations and route them through listener-like objects.
You can declare an interceptor to check your request body and/or header before a JAX-RS resource method is invoked.
You can give a look to the docs here : Resteasy Interceptors Documentation
An example on how use it : Resteasy Interceptors Example
If I have understood it properly you want a filter like in Servlet so that you can handle each request before it hit the REST function. It will also keep your implementation common for all REST alls. Correct me if I am wrong.
One simple solution coming in my mind though I never worked with resteasy2.0.
You can write a common function and call that function from your REST methods first line. Check for scripting elements in that function and if found throw error or do something else.
Related
I apologize if some of my terminology is off, I'm still trying to learn:
I'm using the Dropwizard framework and I have a resource class with all my various POST/GET/etc methods. They all work fine when hit from Postman, browsers, etc. If I try something that has no matching path in the resource class I get an exception with HTTP status 405 - method not allowed.
Is there a way to default to some other method where I can display troubleshooting help -- like a list of what the available APIs are or a link to some documentation? Sort of like a try catch type of logic. Not sure what the options are or if there is a best way to do this.
Any help is appreciated. Thanks!
I don't think you might want to do that. REST over HTTP is driven "mostly" by the HTTP method and the end-point the same will act upon it.
In any stack, try to avoid that since you have specific actions for specific resources...anything else should be treated as something the server didn't understand, in the same way the HTTP protocol would behave.
Being said that, just apply a wildcard, usually * to one of the methods as a fallback action. That should work on Jersey and Spring Boot (MVC) as well.
I really like functional programming, I like its immutability concepts and also it's no side-effects concepts for functions.
I'm trying to take some of these concepts into java.
Now I have some kind of a servlet which receives a request and if browser did not send a cookie to server then i would like to create a cookie with a certain path to the user.
now inside the servlet i don't want to hold that logic because its common to multiple servlets.
so i extract it into some kind of a cookie manager which will do that:
CookieManager.java.handleCookies(request, response)
Check if browser sent cookie.
If not set cookie with new session cookie value with certain path.
however i don't like it because now the servlet will call the CookieManager.java.handleCookie will have a side effect I would rather it to return some kind of a response and further use it in my servlet wihtout having it effect its parameters that i'm passing into it.
anyone can suggest a solution which would both be elegant, no side effects, and excellent in performance?
thanks
You can make use of servlet filter. It would be well suited for your case. You can map your filter to URL pattern and write your code inside dofilter method. Filters are recommended if you want to have pre and post prcoess of request/response. Since you are doing preprocess for you request it would fit in your case. If is also loosely coupled, because you can remove it, modify it, or add another rule anytime without modifying the core servlet code.
One good solution is to use create a servlet which will act as a parent class for all other servlets.
Now in this servlet put this logic of cookie handling in a common function say handlecookie.
In your get and post APIs of this servlet first call this handleCookie and then service API of servlet (keep this empty)
In al child servlet classes you can only override the service class inherited from the parent class and things should work fine for you
Servlet filters are other solution that you can make use of.
This must have been answered previously, but my Google powers are off today and I have been struggling with this for a bit. We are migrating from an old PHP base to a Jersey-based JVM stack, which will ultimately provide a JSON-based RESTful API that can be consumed from many applications. Things have been really good so far and we love the easy POJO-to-JSON conversion. However, we are dealing with difficulties in Cross-Domain JSON requests. We essentially have all of our responses returning JSON (using #Produces("application/json") and the com.sun.jersey.api.json.POJOMappingFeature set to true) but for JSONP support we need to change our methods to return an instance of JSONWithPadding. This of course also requires us to add a #QueryParam("callback") parameter to each method, which will essentially duplicate our efforts, causing two methods to be needed to respond with the same data depending on whether or not there is a callback parameter in the request. Obviously, this is not what we want.
So we essentially have tried a couple different options. Being relatively new to Jersey, I am sure this problem has been solved. I read from a few places that I could write a request filter or I could extend the JSON Provider. My ideal solution is to have no impact on our data or logic layers and instead have some code that says "if there is a call back parameter, surround the JSON with the callback, otherwise just return the JSON". A solution was found here:
http://jersey.576304.n2.nabble.com/JsonP-without-using-JSONWithPadding-td7015082.html
However, that solution extends the Jackson JSON object, not the default JSON provider.
What are the best practices? If I am on the right track, what is class for the default JSON filter that I can extend? Is there any additional configuration needed? Am I completely off track?
If all your resource methods return JSONWithPadding object, then Jersey automatically figures out if it should return JSON (i.e. just the object wrapped by it) or the callback as well based on the requested media type - i.e. if the media type requested by the client is any of application/javascript, application/x-javascript, text/ecmascript, application/ecmascript or text/jscript, then Jersey returns the object wrapped by the callback. If the requested media type is application/json, Jersey returns the JSON object (i.e. does not wrap it with the callback). So, one way to make this work is to make your resource method produce all the above media types (including application/json), always return JSONWithPadding and let Jersey figure out what to do.
If this does not work for you, let us know why it does not cover your use case (at users at jersey.java.net). Anyway, in that case you can use ContainerRequest/ResponseFilters. In the request filter you can modify the request headers any way you want (e.g. adjust the accept header) to ensure it matches the right resource method. Then in the response filter you can wrap the response entity using the JSONWithPadding depending on whether the callback query param is available and adjust the content type header.
So what I ultimately ended up doing (before Martin's great response came in) was creating a Filter and a ResponseWrapper that intercepted the output. The basis for the code is at http://docs.oracle.com/cd/B31017_01/web.1013/b28959/filters.htm
Essentially, the filter checks to see if the callback parameter exists. If it does, it prepends the callback to the outputted JSON and appends the ) at the end. This works great for us in our testing, although it has not been hardened yet. While I would have loved for Jersey to be able to handle it automatically, I could not get it to work with jQuery correctly (probably something on my side, not a problem with Jersey). We have pre-existing jQuery calls and we are changing the URLs to look at the new Jersey Server and we really didn't want to go into each $.ajax call to change any headers or content types in the calls if we didn't have to.
Aside from the small issue, Jersey has been great to work with!
Can you pass some data from a javax.servlet.Filter to a Jersey endpoint without using ThreadLocal or HttpSession?
And because the first question will be "why do you want to do this?": mostly curious. In practice I think I could use this to pass some data generated during authentication to the endpoint. Not using ThreadLocal eliminates the temptation to use that down the chain (hope there's no need to explain why that's evil) and not using HttpSession is more of a quirk :)
Try injecting with #Context. I'm not sure what object you will receive though (somewhere I saw WebServiceContext, which is jax-ws), but it should contain the HttpServletRequest. so you will be a able to set request attributes in the filter and read them in the rest service
Today's browsers (or HTML < 5) only support HTTP GET and POST, but to communicate RESTful one need PUT and DELETE too. If the workaround should not be to use Ajax, something like a hidden form field is required to overwrite the actual HTTP method.
Rails uses the following trick:
<input name="_method" type="hidden" value="put" />
Is there a possibility to do something similar with JAX-RS?
Not strictly a JAX-RS solution but spring 3.0 comes with a HiddenHttpMethodFilter that implements exactly the trick that rails does, defaults to the same _method parameter.
Note that you don't need to be using all of spring to use this filter, you can just configure it in your web.xml and ignore the rest of spring.
Jersey also has something similar, filtering a header field though. Documentation can be found here
To quote Roy Fielding:
In any case, there are plenty of
RESTful services that do nothing but
GET and POST. The key is how those
methods are used, not what methods are
used. To give a specific example, what
makes a wiki more or less RESTful is
almost always determined by how it
(ab)uses GET and sessions -- whether
it uses PUT or POST for editing pages
is sugar topping in comparison.
Emphasis is mine, taken from this post
http://tech.groups.yahoo.com/group/rest-discuss/message/10746