I'm trying to implement Tomcats CSRF protection filter for my web app where the users are stored in a MySQL DB, and due to my controller being written to forward all requests I've edited the filter mapping to
<filter-mapping>
<filter-name>
CSRFPreventionFilter
</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
However as per the OWASP recommendations I'm also invalidating the users session when they log in and then create a new one.
This causes the filter to kick in and I get a 403.
I've looked around but cannot find a way to get the filter to work with this strategy.
So should I abandon the filter or invalidating the session?
Workaround is to define an additional page for a successful login
Related
The basic architecture of my application is React front-end consuming a RESTful API sitting on top of a polyglot storage layer.
Front-end:
React consuming APIs
Back-end:
Python
Flask
Authentication
Auth0+OKTA
Everything is working great. However, I need to have different roles for the users. In other words, I need to control the actions that a user can perform on a resource based on the role.
Example:
-User A wants to add a new user
-He has a token in his request, so I know User A is Authenticated
-Now I need to make sure he can in fact add users base on his role.
I don't want to hard-code the user roles as suggested in other solutions, and I would like to allow for custom roles to be added.
Also, I want to be respectful of people's time, so if there is a resource that addresses my concern, please feel free to point me to it.
These are my questions:
1. Are there any best practices for implementing what I am trying to accomplish?
2. Could you point me to examples or tutorials discussing authorization(not authentication)?
3. Do I check at each service call if the authenticated user can also perform the action or do I provide the roles in some form after authorization, so a service request contains both the authentication and authorization token?(this seems pretty easy to hack so I am guessing no...)
If I sound confused on the topic of authorization, it is because I am. Please feel free to point me to any resource that have been helpful to you.
Thank you in advance for taking the time to help! I really appreciate it.
You can use a framework like Yosai that is based on Apache Shiro.
These are some features:
Enables Role-Based Access Control policies through permission-level and role-level access control
Two-Factor Authentication, featuring Time-based One-Time Passwords
Native Support for Caching and Serialization
Event-driven Processing
Ready for Web Integration
I'm rather confused right now on how to get CORS to work correctly on my Tomcat server. I have an application that offers a REST API. This API works just fine via testing with a Chrome app called Advanced Rest Client. Here is where I'm getting confused...
Do I need to edit the web.xml file for the entire Tomcat server or just the one in the specific web app I'm working with?
Why does my call work via Advanced Rest Client (which is a web app in a browser) and not via my web page?
I can offer any information you would like to help better describe this issue. This is one of my first posts here so please excuse the lack of any expected information. If you want to see the call or the filter I'm placing or the javascript I'm using to make the call please just ask. I'm just not sure what is needed to help debunk something like this. Thank you very much!
Do I need to edit the web.xml file for the entire Tomcat server or just the one in the specific web app I'm working with?
Depends what you are up to. If you edit the global web.xml, you are of course enabling CORS for every URL pattern matching the filter definition. Say if you insert the following:
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CorsFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Then all AJAX calls going to http://myhost.mydomain/myapp/* will be CORS-enabled. You can also use this filter to restrict CORS to only one WAR file - advantage of course: you don't have to edit the global web.xml file
Why does my call work via Advanced Rest Client (which is a web app in a browser) and not via my web page?
Impossible to say without logs of the request/response communication, but most likely this Advanced Rest Client is trusted and therefore does not need to do CORS calls (after all, it is not loaded from site A and tries to access site B via AJAX, but explicitly installed by you, the user). You could find out in the Chrome Dev tools: look if there are Origin: http://foo.example headers for every GET/POST-request. If yes, then it's CORS, if no then not.
This paragraph from the Chrome extensions developer page indicates this:
Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions.
I have setup FORM-authentication within web.xml (java-webcontainer) successfully.
I did not find a way to sent the username/password within the get-request of the restful-uri from my client when using FORM-Authentication. So I have to use BASIC-Authentication only for the restful-uri.
So I have this question:
How can I set up both form-based authentication and basic authentication?
Basic authentication should only be enabled for the restful-uri.
I was also facing a similar problem and I realized that if you are using Wildfly then its possible to configure multiple mechanism using web.xml:-
<auth-method>BASIC?silent=true,FORM</auth-method>
Using this silent basic authentication will be tried first, which is basic authentication that only takes effect if an Authorization header is present. If no such header is present then form authentication will be used instead.
Maybe its too late for a reply but I just updated this in case someone finds this useful :P
There were no responses here for a while, so I did a quick servlet refresher myself. Servlet specs indeed allow only one <login-config> element per web application, so there is no way to have an entry point with BASIC authetication for the REST API and another with FORM-based authentication for the UI. The only option is to build them as two independently deployable applications. To avoid code duplication, it might be a good idea just to let the UI application talk to the REST API the same way the third-party clients are supposed to.
Let me preface this by admitting that this is my first webapp and first experience with JSF, so I've probably made some poor design decisions.
Here's what I'm trying to do:
I have a webapp using JSF 2.0, which is accessible through a Facebook canvas. This webapp allows a user to view/manipulate data from a database of sensor readings. On the very first time the Facebook user accesses my app, I ask the user to enter login credentials for the database, then send the user to the home page. Thereafter, the user should always go straight to the home page, since I associate the user's FB id with the database user profile.
Current implementation:
I have the Facebook canvas URL going to a servlet. This servlet checks the signed_request parameter passed by Facebook to get the user ID, and then looks in the database to see if the user has already completed the provisioning process. If the user has done so, he is redirected to the application home page.
The problem:
Most of my logic to do these checks currently exists within a managed bean (session-scoped). To use the bean within the servlet, I'm manually instantiating the bean and adding it to the session, since the JSF framework hasn't had a chance to create it yet. As my system is getting more complicated, this is causing problems due to dependencies between the various beans. Also, it seems like a generally bad approach to the problem.
Solutions? From my web searching, it sounds like there might be several ways to do this. One way would be to set the canvas to a JSF landing page, where a managed bean would grab the signed_request parameter and validate that the user has completed the provisioning step. From there, the bean would forward to the proper page. Another possibility might be to have an eager bean that does the same thing, but this seems "wrong".
What's the best way to resolve this and adhere to "proper" JSF paradigms?
Thanks in advance!
There are a number of different ways that this can be handled. The JSF landing page is one idea and the eager bean are some ways that this can be handled.
If you ignore the fact that you are integrating with Facebook then ultimately you are trying to solve an authentication and authorization problem. Facebook is handling your authentication, and telling your web application what the identity of a user is, and it is your web app's job to remember that person's identity throughout the session, and authorize this person to visit the requested page.
I have implemented it before where I had all of my managed beans extend a BaseBean class that on creation and initialization checked for the existence of a specific SessionScoped bean that contained the user identitification information. If this bean did not exist or was not authorized to access this bean then I would redirect. The problem with this approach was that it authorized only the use of managed beans, and not pages.
Another approach I had was to utilize a servlet filter that would essentially check every page request and look for the session scoped bean that contained the currently authenticated user. If this wasn't found then I would look for the specific request parameters and authenticate and create the session bean, and if that didn't exist would redirect to an Unauthorized page.
This approach worked well until I realized that Authentication and Authorization of Java web applications is a well understood and near universal problem. After a little bit of looking and research I discovered that security frameworks like Spring Security 3 can indeed be integrated into JSF and handle nearly all of the complexity of complex authentication and authorization. You could very easily integrate a custom Facebook authentication handler for Spring Security and control access by user role to the individual page level, all from XML configuration. It is highly worth looking into if you have the time to learn something new.
I'm retrofitting my application with GWT History support, and I've stumbled on a case where I'm not quite sure what to do. The answer to this question doesn't necessarily have to be GWT-related.
GWT's History support functions by passing around hash tags (i.e. index.html#token). Security restrictions require users be logged in prior to actually being able to access index.html, so they get sent over to a login page, retaining the token (login.html#token). So far, so good. Now the user becomes authenticated and Spring sends them over to index.html (the default target) and eliminates the #token part of the URL.
How can I force Spring Security to maintain the token and send my newly authenticated user to the page they requested (index.html#token)? Since I've already got Spring Security authentication working, I'd prefer to not restructure the way my app handles logins.
After a great deal of digging, I found my answer on Spring's Jira. As Colin Alworth stated, that token isn't actually part of the request, so Spring Security never sees it server-side, and thus can't use it to determine the final URL. So the approach I used was to append the hash (client-side) to j_spring_security_check, making it j_spring_security_check#token. Now the token gets passed along just fine, allowing me to have a well-secured app with working tokens.
Thanks for your help Colin, your answer got me thinking in the right direction.
The server doesn't get to see this token as part of the GET/POST request as you've noted, it is only seen by the browser. Best fix that I've seen for this in the past is for the login page to take note of the current window.location.hash, and pass that along, either along with the login form (assuming a redirect will take place that keeps the hash around), or to the server as a login param so it can redirect properly.
Here's what happens, it might help you solve the problem:
sending unauthenticated users from index.html to login.html is most
likely implemented as an HTTP 3xx redirect, and that's why the
browser keeps the hash fragment (#token).
Once they login, spring sends them from login.html to index.html not
via 3xx redirect so the browser doesn't keep the token.
One solution would be to inject the token into index.html, and pick it up with GWT. Another one is to make login.html -> index.html a 3xx redirect (if spring allows that).