My setup is as follows
A main application servlet accessible under /myApp/mainServlet/
A little "hand made" soap proxy that adds security headers (usernames, passwords) to soap calls coming from a client
A Flex client that talks to the main servlet (through a BlazeDS interface), and sends some soap calls to a third party through this soap proxy
The flex client has a session id which is set when it first talks to the main servlet and it returns a HTTP header such as "Set-Cookie: "JSESSION: something; Path=/myApp". This cookie is then sent the the server to inform of which session the client is associated to.
The problem is that the little soap proxy also returns a cookie with a session id (for each call made through it) - and the Flex client then uses these cookies when talking to the main servlet. These other session ids are unknown to it, and then of course nothing works ...
I do not want a session cookie to be returned from the soap proxy, and I have verified that the problem would be solved by doing so by telling an Apache front-end to strip all "Set-Cookie" headers coming from the soap proxy. Unfortunately (due to some setup restrictions), this is not a way I can go in production, and so I will need to fix it programmatically.
How can I make the servlet not try to set any session ids? I believe I have seen ways of telling Jetty (the app server) not to send sessions ids, but that would also affect the main servlet's ability to do so as well, and is also not portable.
The proxy servlet is a very basic Spring Controller (just implementing the interface), so basically just a bare bone servlet.
Removing the cookie can be done with res.setHeader("Set-Cookie", null);
Edit: It is good to know, that this removes all cookies, since they are all set in the same header.
I recommend that you don't do it in your servlet, a Filter is better, because it's less intrusive, something like:
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws IOException, ServletException
{
HttpServletResponse res = (HttpServletResponse) response;
try
{
chain.doFilter(request, res);
}
finally
{
res.setHeader("Set-Cookie", null);
}
}
This solution is inspired by this article at randomcoder.
Related
We have a embedded Jetty 10.0.12 server, configure everything programmably (no web.xml) and already have a few servlets registered. We want to add a new servlet for an internal API. I have already done this. We now want to secure it. Security would be pretty simple: if the request did not come from within the server, reject it. This is good enough because we employ other security standards in the other servlets. I know where to start: create and register a filter:
public class InternalFilter implements Filter {
#Override
public void doFilter(final ServletRequest request, final ServletResponse response, final FilterChain chain) throws IOException, ServletException {
// TODO: Check if request is internal.
// I.e., came from another registered servlet in the same JVM.
// If it is internal, then `chain.doFilter`.
}
}
I do not know how to proceed from here.
I'll start by assuming that "internal" means you are using either RequestDispatcher.include() or RequestDispatcher.forward().
If so, then you can check the HttpServletRequest.getDispatcherType() value.
Value
Meaning
DispatcherType.FORWARD
Request arrived from a call to RequestDispatcher.forward().
DispatcherType.INCLUDE
Request arrived from a call to RequestDispatcher.include().
DispatcherType.REQUEST
Request arrived from the beginning of the server handling tree.
DispatcherType.ASYNC
Request arrived from call to HttpServletRequest.startAsync()
DispatcherType.ERROR
Request arrived from error handling (either an unhandled exception, or from a call to HttpServletResponse.sendError()
In short - I would like to add such service endpoints to my servlet that can only be called from localhost. The restriction should be coded in the servlet itself, i.e it should not depend on Tomcat/Apache to be configured in a certain way. At the same time, there are many other, existing endpoints that should be reachable externally.
Longer description - I am creating an HTTP API that 3rd parties can implement to integrate with my application. I am also supplying a default implementation, bundled together with my app, that customers with simple requirements can use, without having to implement anything.
The endpoints of my default implementation should be reachable only for my app, which happens to be the same servlet as the one supplying the implementation, i.e it runs on the same host. So for security reasons (the API is security related), I want my implementation to be usable only for my app, which in the first round means restricting access to localhost for a set of HTTP endpoints.
At the same time, I don't want to rely on customers setting up their container/proxy properly, but do the restriction in my servlet, so that there are no changes required for existing installations.
So far the only idea I had was to check the requestor's IP addess in a servlet filter - so I am wondering if there is a better, more sophisticated way.
I think you should add Web Filter to your application and check your url in doFilter method. Check request.getRemoteAddr() and endpoint link you can put in urlPattern.
Like this:
#WebFilter(urlPatterns = "/*")
public class RequestDefaultFilter implements Filter {
#Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (isForbidden(request, response))
return;
else
chain.doFilter(request, response);
}
}
isForbidden implementation is up to you. In response you just send 403 error code for example.
You can check make same check in servlet and send in response 403 error.
We have created a Rest API using Spring.
There is no security implemented.
Now we are going to use Apigee for API management, it will provide various services, for monitoring, security, etc.
All our clients should now call our API using Apigee rather than directly calling our service on our server.
How can we enforce that the bypassing of Apigee is impossible?
I guess, in our code, we can have a filter and use the "Access-Control-Allow-Origin" property, something like:
public class OurFilter implements Filter
{
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException,
ServletException {
HttpServletResponse response = (HttpServletResponse) res;
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, PUT, DELETE");
chain.doFilter(req, res);
}
}
Where the "*" would be replaced by the Apigee Ip, domain name or something.
My question is how safe is that. Can people just add a header to their http request and call our server directly successfully? Or does it check the origin IP on the low level individual "IP packets".
And if it is spoofable just by editing the http header, what is the right way to make the bypassing of Apigee impossible?
Many Thanks
The headers you consider using are for enabling CORS, which is important for the browser (client) side, but it doesn't provide any security for the server side.
If you want to secure your backend API against direct usage, you will have to establish some kind of authentication between Apigee and the backend API, so the backend API denies any requests coming from other clients.
There are different options, how to do this. It depends on the required level of security and the capabilities of the backend API.
For example:
Restrict by IP address - allow requests from Apigee's IP address only
Use a shared secret - When communicating with the backend API Apigee will add a header containing a secret key, which is recognized by the backend. This is probably the easiest solution and provides a reasonable level of security. Of course, assuming that the communication is over HTTPS only :).
Use two-way SSL - This is more secure, but also more complicated. Apigee side will have to authenticate to the backend API using a client certificate.
In case if user works with web application via web browser, the user's session is managed by application server. It takes care of sessions creation, validation, timeouts, disposings, etc.
And as far as I know there is no such mechanisms in the other case, if user works with app via remote client and uses SOAP web services.
So the question is, how can we manage users' sessions in case of web services and implement the same mechanisms of session management such as invalidation, prolongation, disposing?
Assuming you use JAX-WS and SOAP/HTTP it is possible to work with container managed security (and e.g. session cookies) as well. You just have to inject WebServiceContext in your service. It allows access to all HTTP environment variables:
#Resource
WebServiceContext wsContext;
A detailed example is available here. Of course, your clients must support this as well (if they are JAX-WS based it works). Nevertheless, a rule of thumb is that web services should not maintain any state at all, they should behave stateless. See this on SO.
Edit: You can access the ServletRequest by:
#WebMethod
public void foo() {
final MessageContext mc = this.wsContext.getMessageContext();
final ServletRequest sr = mc.get(MessageContext.SERVLET_REQUEST);
/* works if this is a HTTP(s) request */
if (sr != null && sr instanceof HttpServletRequest) {
final HttpServletRequest hsr = (HttpServletRequest) sr;
hsr.getSession(true);
/* ... */
} else {
/* do some exceptional stuff */
}
}
The session created above should behave in exactly the same way as a 'standard' web session. You must make sure that your clients understand that as well. They have to submit the session identifier (cookie) on each subsequent call.
I think you are talking about how to maintain web-services session(state-full web-services).
In this case following link can help you:
https://blogs.oracle.com/sujit/entry/ws_addressing_and_stateful_webservice
Web Service does not support session state for achieving high scalability, web service is designed stateless.
Session state handling is not a part of SOAP specification. The cookie stores a token which acts as session identifier. There are a number of ways to pass the session identifier: as an HTTP cookie, as a SOAP header, or as an element in the SOAP message body.
A SOAP header is transport independent, but it requires the SOAP client and service to agree on the format of the SOAP header, and it required that both the SOAP client and SOAP server implementations support SOAP headers. If you use the SOAP body to pass the session id, then it's up to the service (i.e., your application code) to re-establish the state on each call. Stateful processing can make cross-SOAP interoperability a bit more challenging, but it does work. Check into the capabilities of your SOAP implementation. source
I need to implemented something like a filter or listener, that intercepts HTTP requests and retrieves the HTTP headers for various purposes.
I use Java, Jboss application server and web services. I want this filtering system to be performed prior to the Web Services call - was thinking about aspects but they do not hold the HTTP related stuff. After the filter, the service call should be carried out.
Jax-WS handlers don't work for me either as they only hold the SOAP payload.
Any ideas?
Thanks in advance.
can you not create a servlet filter which intercepts all the requests coming to your webservice engine? If you are using Axis or anyother SOAP engine, I hope you should be able to create a filter that intercepts all the requests coming to the main servlet that the SOAP engine provides.
public void doFilter(ServletRequest request,ServletResponse response,FilterChain chain) throws IOException,ServletException
{
HttpServletRequest httpRequest=(HttpServletRequest)request;
HttpServletResponse httpResponse=(HttpServletResponse)response;
Enumeration headerNames = httpRequest.getHeaderNames();
while(headerNames.hasMoreElements()) {
String headerName = (String)headerNames.nextElement();
out.println(headerName);
out.println(request.getHeader(headerName));
}
chain.doFilter(request,response);
}
Use libpcap and the Java interface jNetPcap.