I work on a web application that is vulnerable to CSRF(Cross Site Request Forgery) attack. Tomcat 7 has a CSRF prevention filter. I went through the description to configure this filter.
This filter expects that we call HttpServletResponse#encodeRedirectURL(String) or HttpServletResponse#encodeURL(String).
However, I see that in my application we are not using the above mentioned methods. We forward the response using mapping.findForward(target); without touching the request or response object. Can you please let me know how or where can I integrate encodeURL() or encodeRedirectURL() methods in my code?
Any help in this regard is appreciated.
Thanks,
You can Write a Servlet and map all urls (/*) to this servlet in your web.xml file. now you can use encodeUrl method through HttpServletResponse.
Related
How do we handle incoming request to a wrong contextpath in spring mvc?
I have deployed a spring mvc application having contextpath as
http://exampledomain.com/mycontext
But when I try accessing url http://exampledomain.com/wrongcontext I get error as HTTP Status 404 - /wrongcontext/
I have implemented error handling which works fine for all wrong url when correct context path is used but it does not work for wrong context path.
I am trying to understand how do we redirect all incoming request to specific page in production environment..
thanks in advance
Your application can only see requests to its context /mycontext There is nothing your application can do about requests to other contexts.
You can however deploy an application at the root context / and implement an error handler there.
Check out this answer: How to customize JBoss AS7 404 page
That answer relates to JBoss, but the same idea will apply on other servers.
It is not possible to handle wrong context path requests in Spring since it only will handle the requests which goes to your context root. You have to take a look at server configuration parameters to redirect those kind of requests. If you are working on Tomcat, check path parameter of context.xml:
https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context
We can use #ExceptionHandler inside a #Controller or #ControllerAdvice to handle such kind of exceptions and decide on the view page to be rendered.
#ExceptionHandler({ HttpRequestMethodNotSupportedException.class,
HttpMediaTypeNotSupportedException.class, HttpMediaTypeNotAcceptableException.class,
MissingPathVariableException.class, MissingServletRequestParameterException.class,
ServletRequestBindingException.class,MethodArgumentNotValidException.class, MissingServletRequestPartException.class,
NoHandlerFoundException.class})
public ModelAndView handleException(){
return new ModelAndView("errorpage");
}
I'm setting the security system on my project (Grails - Angularjs) with Spring Security Rest Plugin v1.5.4 (using spring security core 2.0.0) for Grails 2.4.4. Doc about this plugin can be found here.
I'm testing the login and logout with postman chrome rest client and I'm able to do a login OK, but I'm getting a 404 when I do logout.
In the documentation clearly says:
The logout filter exposes an endpoint for deleting tokens. It will
read the token from an HTTP header. If found, will delete it from the
storage, sending a 200 response. Otherwise, it will send a 404
response
You can configure it in Config.groovy using this properties:
Config key...................................................................................Default
value
grails.plugin.springsecurity.rest.logout.endpointUrl....................../api/logout
grails.plugin.springsecurity.rest.token.validation.headerName....X-Auth-Token
So, after doing a login successfully, I tried to do a logout to that url (my_host_url/api/logout) with a GET method and sending a header X-Auth-Token with the token I got previously from login.
But I keep getting a 404. See image below
Edit: I'm setting the chain map like this (in order to get a stateless behavior):
grails.plugin.springsecurity.filterChain.chainMap = [
'/api/**': 'JOINED_FILTERS,-exceptionTranslationFilter,-authenticationProcessingFilter,-securityContextPersistenceFilter,-rememberMeAuthenticationFilter', // Stateless chain
'/**': 'JOINED_FILTERS,-restTokenValidationFilter,-restExceptionTranslationFilter' // Traditional chain
]
So. What am I doing wrong here, or what am I missing?
Thanks in advance!
You missed another excerpt from the docs. It's a warning message literally before the chunk you quoted, and says:
Logout is not possible when using JWT tokens (the default strategy), as no state is kept in the server.
If you still want to have logout, you can provide your own implementation by creating a subclass of JwtTokenStorageService and overriding the methods storeToken and removeToken. Then, register your implementation in resources.groovy as tokenStorageService.
I have a 3rd party .jsp that I am trying to use in my SpringMVC 3.2 application.
the URL call looks like this:
http://localhost:8080/dms/pcc.jsp/Page/q/0/AttributescumentID=eJQAyAEYASgBJAFMAMgAlADIARgBsAG8AZwBvAC4AdABpAGYA0
I am getting a 404 error. How do I map this in my web.xml?
when I call
http://localhost:8080/dms/pcc.jsp
it works (well, no 404 errors) but I need to send it the parameters.
Changing the 3rd party jsp might be problematic, so how does one map this call straight to the jsp?
Thanks in advance.
Really a broad question. I would start with checking mapping in #Controller, then move into application-config.xml and then web.xml.
It would be nice if you would look at sample Spring Application.
If call to http://localhost:8080/dms/pcc.jsp works, you should try following thing.
http://localhost:8080/dms/pcc.jsp?AttributescumentID=eJQAyAEYASgBJAFMAMgAlADIARgBsAG8AZwBvAC4AdABpAGYA0&otherParams=something
The Page/q/0/ part in URL seems to be messing things up for you. If these also are parameters to be sent, send it the way explained above.
So we're using spring-security-redirect as a parameter in the form that is sent to j_spring_security_check, in order to send the user to the correct page after a successful login. Migrating from Spring security 3.0 to 3.1, this stopped working. We use a subclass of SavedRequestAwareAuthenticationSuccessHandler, overriding onAuthenticationSuccess(), and debugging that method I see that getTargetUrlParameter() returns null. isAlwaysUseDefaultTargetUrl() returns false.
Browsing around I can't find anyone having similar problems... I find some references to AbstractAuthenticationTargetUrlRequestHandler.DEFAULT_TARGET_PARAMETER, which seems to have disappeared in 3.1.
Any ideas?
As per Spring security 3.1 xsd,
Attribute : authentication-success-handler-ref
Reference to an AuthenticationSuccessHandler bean which should be used to handle a successful authentication
request. Should not be used in combination with default-target-url (or always-use-default-target-url) as the
implementation should always deal with navigation to the subsequent destination.
So, in your subclass, you have to perform the redirection.
I'm looking to disable jsessionid from being used in the https headers.
Is there a way to turn this off or disable this being set as a cookie in tomcat 7?
I either want the jsessionid to arrive embedded into a GET method url name value pairs or to be part of a POST request name value pairs.
I know all the advantages and disadvantages of using cookie based sessioning and url rewriting but I have specific needs for specific impl of restful web services.
I need tomcat 7 to accept jsessionid without using the http header: jsessionid.
Thanks.
UPDATE:
so I looked around some more and found this which is implemented using the web.xml conf.
However the following doesn't seem to work with Tomcat 7.
<session-config>
<tracking-mode>URL</tracking-mode>
</session-config>
is it a case of TC7 not fully implementing the servlet 3.0 spec?
The web.xml setting works for me with Tomcat 7.0.20.
Log and check the effective (and maybe the default) session tracking modes:
logger.info("default STM: {}" , servletContext.getDefaultSessionTrackingModes());
logger.info("effective STM: {}" , servletContext.getEffectiveSessionTrackingModes());
Maybe your app override somewhere in the code the session tracking modes. An example:
final Set<SessionTrackingMode> trackingModes =
Collections.singleton(SessionTrackingMode.COOKIE);
servletContext.setSessionTrackingModes(trackingModes);
Check ServletContext.setSessionTrackingModes() calls in your code.
It's also possible to set default session tracking modes in the Tomcat's context settings but I found that web.xml settings override them.