Similar to this question I have some Jersey web services I would like to restrict for internal office use. Is it secure enough to check IP addresses using the HttpServletRequest? Specifically, are there cases where the value returned by request.getRemoteAddress() cannot be trusted? My code is something like this:
#POST
#Path("update")
public Response updateCityInfo(#Context HttpServletRequest request) {
String remoteAddress = request.getRemoteAddr();
if (!remoteAddress.startsWith("10.10")) {
return Response.status(Status.FORBIDDEN).build();
}
...
I'm not concerned with security so much, I just want anyone from within a certain network to be able to access this endpoint.
That might work. However there are some caveats. For starters, if you are behind a loadbalancer/proxy, then the remoteAddress will likely be that of the proxy and not of the client who originated the request. Since loadbalancers are generally inside of your firewall, they will probably have a 10.* address.
This seems like something that should be handled at the firewall level and not at the application level.
Filtering in-coming request from external address at the network level can easily prevent your application from being spoofed. But this does not mean that your application is not doing any thing in terms of security. your application should have a proper authentication and authorization mechanism.
Related
I am very much new to web services. I have exposed some REST services using Jersey 2 in integration with Spring. Now I need to secure those rest services using authentication with username/password. I am told not to use Spring Security.
I have no idea of how to do this. I did search on the net but various links show various implementation and I am unable to decide how to proceed with it.
A common way for authenticating with username and password is to use Basic Authentication. Basically the client needs to send a request header Authorization, with the the header value as Basic Base64Encoded(username:password). So is my username is peeskillet and my password is pass, I, as a client, should set the header as
Authorization: Basic cGVlc2tpbGxldDpwYXNz
In a servlet environment, the container should have support for Basic authentication. You would configure this support on the web.xml. You can see an example in 48.2 Securing Web Applications of the Java EE tutorial. You will also notice in an example
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
That is for SSL support. This is recommended for Basic Authentication.
If you don't want to deal with the hassle of working with security domains and login modules, realm, and such, that would be required to customize the servlet support, or if you're just not in a servlet environment, implementing Basic Auth in a ContainerRequestFilter is really not too difficult.
You can see a complete example of how this could be done at jersey/examples/https-clientserver-grizzly. You should focus on the SecurityFilter
The basic flow in the filter goes something like this
Get the Authorization header. If it doesn't exist, throw an AuthenticationException. In which case the AuthenticationExceptionMapper will send out the header "WWW-Authenticate", "Basic realm=\"" + e.getRealm() + "\", which is part of the Basic Auth protocol
Once we have the header, we parse it just to get the Base64 encoded username:password. Then we decode it, then split it, then separate the user name and password. If any of this process fails, again throw the WebApplicationException that maps to a 400 Bad Request.
Check the username and password. The example source code just checks if the username is user and the password is password, but you will want to use some service in the filter to verify this information. If either of these fail, throw an AuthenticationException
If all goes well, a User is created from the authenticate method, and is injected into an Authorizer (which is a SecurityContext). In JAX-RS, the SecurityContext is normally used for authorization`.
For the authorization, if you want to secure certain areas for certain resources, you can use the #RolesAllowed annotation for your classes or methods. Jersey has support for this annotation, by registering the RolesAllowedDynamicFeature.
What happens under the hood is that the SecurityContext will be obtained from the request. With the example I linked to, you can see the Authorizer, it has an overridden method isUserInRole. This method will be called to check against the value(s) in #RolesAllowed({"ADMIN"}). So when you create the SecurityContext, you should make sure to include on the overridden method, the roles of the user.
For testing, you can simply use a browser. If everything is set up correctly, when you try and access the resource, you should see (in Firefox) a dialog as seen in this post. If you use cURL, you could do
C:/>curl -v -u username:password http://localhost:8080/blah/resource
This will send out a Basic Authenticated request. Because of the -v switch, you should see all the headers involved. If you just want to test with the client API, you can see here how to set it up. In any of the three cases mentioned, the Base64 encoding will be done for you, so you don't have to worry about it.
As for the SSL, you should look into the documentation of your container for information about how to set it up.
So this is really a matter what you would like to achieve. My case was to get this thing running with mobile and a One-Page-App JavaScript.
Basically all you need to do is generate some kind of header that value that will be needed in every consecutive request you client will make.
So you do a endpoint in which you wait for a post with user/password:
#Path("/login")
public class AuthenticationResource {
#POST
#Consumes("application/json")
public Response authenticate(Credentials credential) {
boolean canBeLoggedIn = (...check in your DB or anywher you need to)
if (canBeLoggedIn) {
UUID uuid = UUID.randomUUID();
Token token = new Token();
token.setToken(uuid.toString());
//save your token with associated with user
(...)
return Response.ok(token).type(MediaType.APPLICATION_JSON_TYPE).build();
} else {
return Response.status(Response.Status.UNAUTHORIZED).build();
}
}
}
Now you need to secure resource with need for that token:
#Path("/payment")
#AuthorizedWithToken
public class Payments {
#GET
#Produces("application/json")
public Response sync() {
(...)
}
}
Notice the #AuthorizedWithToken annotation. This annotaation you can create on your own using special meta annotation #NameBinding
#NameBinding
#Target({ElementType.METHOD, ElementType.TYPE})
#Retention(RetentionPolicy.RUNTIME)
public #interface AuthorizedWithToken {}
And now for the filter that implements checking of the header:
#AuthorizedWithToken
#Provider
public class XAuthTokenFilter implements ContainerRequestFilter {
private static String X_Auth_Token = "X-Auth-Token";
#Override
public void filter(ContainerRequestContext crc) throws IOException {
String headerValue = crc.getHeaderString(X_Auth_Token);
if (headerValue == null) {
crc.abortWith(Response.status(Response.Status.FORBIDDEN).entity("Missing " + X_Auth_Token + " value").build());
return;
}
if(! TOKEN_FOUND_IN_DB) {
crc.abortWith(Response.status(Response.Status.UNAUTHORIZED).entity("Wrong " + X_Auth_Token + " value").build());
return;
}
}
}
You can create any number of your own annotations checking for various things in the http request and mix them. However you need to pay attention to Priorities but that actually easy thing to find. This method needs using https but that is obvious.
Security comes in two main flavours :
Container Based
application based
the standard way to secure spring applications is to use Spring Security (formerly Acegi).
It would be interesting to know why you're not being allowed to use that.
You could use container based security, but I'm guessing that your use of spring precludes that option too.
Since the choice of Spring is usually to obviate the need for the use of a full J2EE container (Edit : though as pointed out below by others, most ordinary servlet containers do allow you to implement various container based security methods)
This really only leaves you with one option which is to roll your own security.
Your use of Jersey suggests that this might be a REST application.
In which case you really ought to stick with standard HTTP Authentication methods that
comes in the following flavours in reverse order of strength :
BASIC
Digest
Form
Certificate
REST applications are usually supposed to be 'stateless', which essentially rules out form based authentication (because you'd require the use of Session)
leaving you with BASIC, Digest and Certificate.
Your next question is, who am I authenticating. If you can expect to know the username AND the password of the user based on what URL they requested (say if it's one set of credentials for all users) then Digest is the best bet since the password is never sent, only a hash.
If you cannot know the Password (because you ask a third party system to validate it etc.) then you are stuck with BASIC.
But you can enhance the security of BASIC by using SSL, or better yet, combining BASIC with client certificate authentication.
In fact BASIC authentication over HTTPS is the standard technique for securing most REST applications.
You can easily implement a Servlet Filter that looks for the Authentication Header and validates the credentials yourself.
There are many examples of such filters, it's a single self contained class file.
If no credentials are found the filter returns 401 passing a prompt for basic auth in the response headers.
If the credentials are invalid you return 403.
App security is almost an entire career in itself, but I hope this helps.
As the former posts say, you could go with different options, with a varying overhead for implementation. From a practical view, if you're going to start with this and are looking for a comfortable way for a simple implementation, I'd recommend container-based option using BASIC authentication.
If you use tomcat, you can setup a realm, which is relatively simple to implement. You could use JDBCRealm, which gets you a user and password from specified columns in your database, and configure it via server.xml and web.xml.
This will prompt you for credentials automatically, everytime you are trying to access your application. You don't have any application-side implementation to do for that.
What I can tell you now is that you already did most of the 'dirty' job integrating Jersey with Spring. I recommend to you to go an Application-based solution, is it does not tie you to a particular container. Spring Security can be intimidating at first, but then when you tame the beast, you see it was actually a friendly puppy.
The fact is that Spring Security is hugely customizable, just by implementing their interfaces. And there is a lot of documentation and support. Plus, you already have a Spring based application.
As all you seek is guidance, I can provide you with some tutorials. You can take advantage from this blog.
http://www.baeldung.com/rest-with-spring-series/
http://www.baeldung.com/2011/10/31/securing-a-restful-web-service-with-spring-security-3-1-part-3/
Hi I am looking for a way to authenticate users when they make WebSocket connection and simply if they are not authenticated close the connection. I am using Dropwizard framework and Atmosphere for the WebSocket connections. Here is the example that I use.
It would be great if I could use '#Auth' annotation provided by Dropwizard for authentication when the connection is establishing.
How are you exposing this? Is it through a javascript frontend?
You are using the servlet based approach as described in your link and here: https://cvwjensen.wordpress.com/2014/08/02/websockets-in-dropwizard/, and not the jersey atmosphere extension?
If you are using the servlet based approach would recommend using a token-based approach putting the token in the http header an then access this header in the #Ready handler method, like this:
#Ready
public String onReady(final AtmosphereResource resource) {
String AuthHeader = resource.getRequest().getHeader("Authorization");
...DO AUTH HERE
logger.info("Resource {} connected ", resource.uuid());
return "Connect " + resource.uuid();
}
Then, you could also easily close the connection if auth fails. However, depending on your client side implementation, you might want to think about this. If the client auto-reconnects on close, you have a scenario of constant closing and opening of sockets that may cause a resource drain. You could, if auth is not successful, store a private variable that states whether or not this instance is authenticated and just drop sending any messages to or process any messages from it. That would also be a "obscure" way of letting an attacker know that auth failed, it simply is in a limbo state; connected, but not failed or closed. Just not receiving any data. But again, this is specific to your implementation.
Jwt auth is an option, check this out: https://github.com/ToastShaman/dropwizard-auth-jwt. I have, although not made it public, ported this implementation to dropwizard 0.8rc3-SNAPSHOT. If you need this, please let me know and I can post it to github.
I am working on an internal tool that simulates SOAP responses for different web services that our product uses. This is intended for use in local development.
The idea is to store the SOAP responses in the database as a blob data. During the mapping of a URL keys to a response, the URL keys and expected SOAP response will be stored to the database. The simulated SOAP response will be as a string body in POST request.
The SOAP response will be stored as a blob in the database along with URL keys. If the URL is /configureresponse/{responsetype}/{responsecode}/, then the values of response type and response code will be saved to the database along with the SOAP response as string.
I am building a Spring MVC application for the same. The code snippet is given below
#Controller
#RequestMapping(value = "/configureresponse/{responsetype}/{responsecode}",
method = RequestMethod.POST)
public ModelAndView configureResponse(
#PathVariable String responseType, #PathVariable String responseCode,
#RequestBody String soapResponse) {
}
How do I return a Servlet Response such as 200 OK or 403 Forbidden based on certain conditions?
Is there a way to secure the incoming XML response and the outgoing XML response? This is an internal tool, but I am not sure how to handle XML injection or any other security issues.
UPDATE: How do I secure the application against a billion laughs attack or make it more secure?
Should I be checking for XSRF vulnerability? If yes, how do I do that?
How do I handle simultaneous concurrent inputs for the same response and request?
UPDATE: How do I check if say one thread is updating the response for a given response type and response code, while the other thread is viewing the response for a given response type and response code?
How do I return a Servlet Response such as 200 OK or 403 Forbidden based on certain conditions?
There are several ways to do this. For instance, you could change your return type to a ResponseEntity<String>, which has a constructor that accepts an HttpStatus. Or, you could simply pass in an HttpServletResponse and set the response code there. Knowing Spring, there are probably 20 more valid ways to do this. I would suggest reading through the excellent Reference Guide available on their site.
Is there a way to secure the incoming XML response and the outgoing XML response? This is an internal tool, but I am not sure how to handle XML injection or any other security issues.
Not sure what you mean by "secure". If you mean transmission, then use SSL. If you mean authorization/authentication use Spring Security. If you mean something else, then I am not sure what to offer except to say I need a better explanation of what you want/need.
Should I be checking for XSRF vulnerability? If yes, how do I do that? Any link or tutorial would be welcome.
Security should be a concern, whether it's an internal app or external. Most hacks now-a-days are done by social engineering their way into the intra-net of a company. Take the recent Target breach. I believe they used the AC repair service to gain access to the building. I went to a Schmoocon talk once where a guy hired to test a companies' security actually got a job as a janitor and would plug in a Linux device he built, go mop some floors, then pick up the device which had scanned all their internal networks. So, yes, if you believe you should guard against an attack, then I would say do so.
How do I handle simultaneous concurrent inputs for the same response and request?
Not sure what you mean by this. Spring MVC typically uses session to isolate requests. If two different users request the same thing, they are two different requests for the same thing. I would suggest using some caching so that you are not hitting your DB every time, but other than that I see no problem.
We have 2 different web applications that are running on the same tomcat.
webapp#1, webapp#2.
Webapp#1 is connecting to webapp#2 via this service method:
this.restTemplate.postForObject(url,
request,
responseType);
webapp#2 is receiving this request in the following controller:
#RequestMapping(value = "/bla", method = RequestMethod.POST)
#ResponseStatus(value = HttpStatus.OK)
#ResponseBody
public ResponseDTO requestSomething(#RequestBody RequestDTO requestDTO, HttpServletRequest request) {
return new ResponseDTO("Hello");
}
Now, we have a security requirement that this controller we are revealing in webapp#2 will only recieve requests from webapp#1.
What are our alternatives in achieving that? Do we have to create a new session in webapp#2 from webapp#1? if so where do the credentials comes from ? should we agree on something predefined?
Does spring security have any way to solve this?
Thanks!
I'm happy if someone can tell me if there is a special (and good) way for webapps in the same container, but AFAIK these are the options:
Option 1: Disregard that they are in the same Tomcat
In other words, do it like the two webapps were on two different locations. For example, you can use HTTP Basic authentication; it is rather easy do a ClientHttpRequestFactory implementation that adds the Authorization header for RestTemplate on the client side (webapp#1) and Spring Security has built-in support for handling it on the server side (webapp#2). With Basic authentication, communication can be stateless and no session is required. Only disadvantage is that both web apps need to know the credentials.
Option 2: Check for localhost
The idea is that in webapp#2 check where the request comes from. Compare ServletRequest.getRemoteAddr() with 127.0.0.1 (or any other loopback address). If you want to apply Spring Security, you need create a custom filter in the security chain. Advantage: webapp#1 does not need any credentials. Disadvantage: Depending on your server setup, this can be unsafe! If a user can open connections on the machine, it can pretend to be webapp#1. Be extra careful if there is a proxy of some kind on the machine.
I have found numerous academic answers to this question, but I would like one from practitioners in the field.
Background
I would like to create a Java-based RESTful API, using the Grails framework for a variety of mobile clients (iOS and Android) to access protected resources through my service. I require authentication on certain requests, and I already have SSL setup over the wire (so all requests occur over https). My web API will eventually be exposed as a service to other web applications.
Problem
What authentication method do people recommend for a web service that is to be consumed by mobile devices, and eventually other web applications?
These are what I see as my choices. Can you tell me when would be appropriate use cases for each one?
I can do HTTP Basic authentication
I can do HTTP Digest authentication
I can implement OAuth authentication (1.0 or 2.0)?
I can pass the credentials as parameters in my request
I can use an authentication method above, and then pass a delegate/token around for authentication
I can implement my own custom HTTP authentication headers
I can use cookies and pass those to the server on each request
Other...?
Need
If you have one leaning one way or another, I'd like to know why you would choose that method. Better yet, if you're doing this in Grails, I'm very interested.
I already know...
I've already read through the excellent answers here and Richardson and Ruby's book, Restful Web Services.
REST is stateless protocol, thus using "work sessions" - I mean login/work/(auto)logout concept is somewhat questionable. Sending credentials as a parameter with each request seems to be the most often used method due to its simplicity. Just keep in mind that
1) The api url must be SSL only - it makes sense to use a dedicated domain AND ip address, e.g. api.example.com and configure your web server to handle SSL only for this address and domain. Just to avoid accidental disclosure of credentials.
2) Avoid using login/password with the request if possible, use "API key" (a shared secret) instead. You always may use "API key" instead of login/password if authentication is all you need, that is you do not need authorization (all users share the same permissions) and no need for logging (who did what).
3) Rather than sending the API key with each request, it is better to "sign" the request using shared secret and supply the signature. With the key long enough you may use this technique over plain unencrypted http.
=== responding to a comment ===
If you need authorization, just use basic authentication:
HTTPBuilder builder = new HTTPBuilder("https://api.example.com/v1/foo/bar")
builder.auth.basic(login, password)
builder.headers.put('Accept', 'application/json')
def result = builder.request(POST, JSON) { req ->
body = [
....
]
response.'201' = { resp, json ->
....
}
response.success = { resp, json ->
....
}
response.failure = { resp ->
log.error "failure, ${resp.statusLine}"
}
}