How would one solve this?
An application has a form with a password and other input fields. The user must enter their password in order to submit a transaction along with other transaction info. The password is required as a security check at point of transaction submission.
The form input values are bound to a command object.
This was the way our application was handling this:
void submitAction(FooCommand command){
if(command.hasErrors()){
render(view: ‘show’, model: [command:command])
}
//else do save and redirect
}
We became aware that by using render instead of redirect, the user’s password was visible in the browser cache after user logs out. The URL used in the render is the same as the POST URL. After the user logs out, someone else could use the browser back button and resubmit the form while using a tool like firebug to inspect the POST parameters and gain access to the user's password.
There is also a requirement to persist the user’s input from the form back to the page that displays the validation errors. So a simple redirect with error message in the flash would fail this requirement.
The proposed solution is to use the chain method to put the
command object into the flash scope so a redirect is possible to display errors and user input. This prevents someone from accessing the POST URL, and thus the password, in browser tools.
void submitAction(FooCommand command){
if(command.hasErrors()){
chain(action: ‘show’, model: [command:command])//redirect instead of render
}
//else do save and redirect
}
One potential downside is storing command objects in the flash scope (ultimately the session) that might have eagerly fetched relationships in the command. Could storing command objects in the session affect performance?
Is there a better solution?
To prevent showing a page after logout when someone hits the back button, use the following response header:
Cache-Control: no-store, must-revalidate
Chain sounds like the way to go. You don't need to use Hibernate/JPA entities for your models, you could make a class specific to the form and copy to your entities. This might take less memory, though you're not likely to store it for too long using a flash map.
Related
So I just read this article by Jeff Atwood and I wanted to make sure I understand it correctly as to how it applies to my use case. I am trying to validate a session for silent login. For security purposes this should be done with a POST right? Does it matter? I am just passing the sessionID and username from the cookie.
When it comes to CSRF (Cross-site request forgery), you can cause a user to take any action on any site which they are logged in to provided that the action requires only a GET. Forcing this to be done over a POST request defeats the approach of embedding an image, script tag, whatever in another page.
Even POST isn't completely secure in this scenario. There are other ways to mount a CSRF attack on a site using POST. Clickjacking/UI-Redressing enables another site to trick a user into submitting a form to a different website.
Basically the best way to validate is to add an automatically generated, hidden form element. You can store this inside your session data (Example: $_SESSION for PHP) so that you only need to generate a token at the start of a session. Of course, an attack could try do something like clickjacking (mentioned above) in combination with a iframe pointing directly to your site and possibly some JS to hide things a little.
For anything important you should re-prompt the user for their password, thereby greatly diminishing the value of any successful CSRF attacks.
In the sample Java code for Google+ server-side authentication there is this comment within the code for handling requests to the url /connect:
// Normally the state would be a one-time use token, however in our
// simple case, we want a user to be able to connect and disconnect
// without reloading the page. Thus, for demonstration, we don't
// implement this best practice.
//request.session().removeAttribute("state");
The state attribute is a random sequence generated on the page load of the default route (/) and must be presented by the ajax call to /connect for the connect request to succeed.
The comment implies that it is improper for the state to remain in the session, but has been commented out simply to allow the user to log in and out repeatedly in the example.
However, I do want the user to be able to log in and out at will, without reloading the page. If I keep the value for state in the session am I allowing an exploit? Should I be generating a new state and updating it somewhere in the DOM on /disconnect? Or should I do something different altogether?
In short, the state value set in the session is used to prevent cross-site-request-forgery (CSRF/XSRF). In the samples, we have a completely trusted path when performing the OAuth v2 flow so for that specific scenario token validation is redundant.
For more information about the state parameter you can look at:
Forming the URL (OAuth v2)
Confirm anti-forgery state token
Related question and answer here.
User's can log in from any page.
I'd like to have the form redirect to the current page the user is on and clear the POST data so they can refresh without problems.
I can't seem to figure out how to do it, or find how to do it, without using an external library or middleware.
Any help would be appreciated!
EDIT:
There is a login form that appears in the top of every page. The user may enter their credentials and the form's action leads to itself.
The server checks to see if a user is logging in, and if the correct POST variables are set, it sets the required various session variables.
I'm wondering how I can redirect the user to the page on which they used the login form.
Since you don't want to use a framework like Express, I think you're either going to have to implement some form of session management yourself (to keep track of where the user came from), or use the Referer HTTP header (which might not always be sent, though) to redirect them back once they are authenticated.
Of course, you're going to generate those redirects yourself:
res.writeHead(303, { Location : req.headers.referer });
res.end();
Or, if you're not using a separate URI that the credentials are posted to (like /login), but just want to 'reload' the current page, you can use this:
res.writeHead(303, { Location : req.url });
res.end();
We're using JSF in a very simple way. All we're doing is implementing tags that contain a little Java code.
I have implemented a "security" tag that sends a 302 redirect back to the login page whenever the user isn't logged in:
// make them log in
ctx.getExternalContext().redirect("login.xhtml");
ctx.responseComplete();
The trouble is that the redirect() method doesn't stop the rest of the page being rendered. Tags that are further down the page are getting executed. This is a problem because non-logged-in users could see things they shouldn't if they had their browser ignore redirects.
How do I get responseComplete() to do what I thought it was supposed to do?
Its always better to implement the login related logic in a servlet filter, like below:
Implement a filter for the URL patterns that you want to secure
In the filter, check if the user is logged in (may be by just checking if Username/UserId is present in user session)
If the user is not logged in, redirect the user to a HTML based login page.
If the user is logged in, let the user access the resources.
There are a lot of ways (may be better than this) to implement this, but this is the most basic one.
Maybe you could use a flag to verify if the user is logged in.
Then, you can use the render=#{managedBean.logged} property in the tags you don't want to render.
This is just a workaround... can't really help too much with that amount of information you gave.
Try it!
ctx.getExternalContext().dispatch("login.xhtml");
ctx.responseComplete();
So how do you maintain the form security about posting data to different page problem? For instance you have a member and he/she tries to change the personal settings and you redirected member to
www.domain.com/member/change/member_id
member changed the values and post the data to another page by changing the action with firebug or something else. For instance
www.domain.com/member/change/member_id_2
How do you handle this problem without using sessions?
This problem arises when there are no server side validations!
So, the solution is to have server side validations.
Why not use Session state? It's designed for that.
Alternatively use cookies or URL's with unique session style ID embedded in it, which allows you to tie it back to a specific user.
How do you handle members without session?
Before modifying anything, check if the current user has the right to do so. For example, if you're user #1 and your details are at /members/change/1, you post to the same url, and with firebug you change the form to point to /members/change/2. When processing the form, you have to check if the userid in the form is the current user's id, and if not, display an error.
You could crypt the identity information (member_id) and add it as parameter or url path. When the request is posted to the member_id form, you can verify that the crypted member_id (which is part of the request) matches the member_id.