Re: Nonce-secured pages generate 403 errors

2016-09-02 Thread Joe Tseng
One thing I forgot to mention... In my servlet controller's auth method,
when a user's login is approved, the controller redirects the browser to
another page. I noticed looking in my browser's network tab the CSRF_NONCE
token in the request URL changes value between the auth method and the
eventual destination. Is this normal? I also recall reading Tomcat is
supposed to cache the last five tokens for a given current session - the
change in token values shouldn't affect usage, correct?

On Fri, Sep 2, 2016 at 10:14 AM Joe Tseng 
wrote:

> For my app I was *mostly* successful in securing it using Tomcat's
> CsrfPreventionFilter tool. I can land on my unsecured login.jsp page and
> get the app to still redirect based on login success.
>
> My problem is regardless of login success I'm getting a 403 error; I may
> be implementing the token check incorrectly though. When I originally read
> up on how to implement CSRF in a traditional MVC app I was under the
> impression I had to provide the token in a hidden field in a POST form. My
> initial effort was aimed at providing that value from the session's
> CSRF_NONCE attribute but that kept on coming up null or of type lrucache.
>
> Other posts said all I had to do was pass my unaltered POST form action
> URL through HttpServletResponse.encodeRedirectURL() and the resulting
> CSRF_NONCE GET value would be automagically be handled by the filter (e.g.
> https://help.hana.ondemand.com/help/e5be9994bb571014b575a785961062db.html).
> Now I can produce CSRF_NONCE values all day long and be redirected to
> action page, but that page is producing a 403. I put a print statement in
> my action page, but my browser isn't getting that far, leading me to think
> I need to do something additional in my filter configuration.
>
> As an aside, I currently use a custom class that extends
> org.apache.catalina.filters.CsrfPreventionFilter so I can override
> doFilter() and filter out any checks to CSS or JS files. That works for
> excluding unsecured content but is that the right approach? Is that causing
> my main issue?
>
> My web.xml is currently as follows:
>
>  
>   CSRF
>   filter.CustomCSRFFilter
>   
>entryPoints
>/,/login.jsp,/JS/MIST.js
>   
>  
>  
>   CSRF
>   /*
>  
>
> Appreciative of any useful assistance...
>
>  - Joe
>
>


Nonce-secured pages generate 403 errors

2016-09-02 Thread Joe Tseng
For my app I was *mostly* successful in securing it using Tomcat's
CsrfPreventionFilter tool. I can land on my unsecured login.jsp page and
get the app to still redirect based on login success.

My problem is regardless of login success I'm getting a 403 error; I may be
implementing the token check incorrectly though. When I originally read up
on how to implement CSRF in a traditional MVC app I was under the
impression I had to provide the token in a hidden field in a POST form. My
initial effort was aimed at providing that value from the session's
CSRF_NONCE attribute but that kept on coming up null or of type lrucache.

Other posts said all I had to do was pass my unaltered POST form action URL
through HttpServletResponse.encodeRedirectURL() and the resulting
CSRF_NONCE GET value would be automagically be handled by the filter (e.g.
https://help.hana.ondemand.com/help/e5be9994bb571014b575a785961062db.html).
Now I can produce CSRF_NONCE values all day long and be redirected to
action page, but that page is producing a 403. I put a print statement in
my action page, but my browser isn't getting that far, leading me to think
I need to do something additional in my filter configuration.

As an aside, I currently use a custom class that extends
org.apache.catalina.filters.CsrfPreventionFilter so I can override
doFilter() and filter out any checks to CSS or JS files. That works for
excluding unsecured content but is that the right approach? Is that causing
my main issue?

My web.xml is currently as follows:

 
  CSRF
  filter.CustomCSRFFilter
  
   entryPoints
   /,/login.jsp,/JS/MIST.js
  
 
 
  CSRF
  /*
 

Appreciative of any useful assistance...

 - Joe