How secure is flash[:notice] ? I’m working on a website that captures
fairly sensitive information. Someone fills out a form with this info
(over SSL), then it submits to a confirmation screen. From the
confirmation screen it submits to a “save” action and outputs the
results. But the problem is, if someone hits refresh a few times it
saves multiple times.
I modified the save function to set flash[:notice] = @sensitivedata and
do a redirect_to to an action that reads back the @sensitivedata from
flash[:notice] to display on the final save page. That way if they hit
refresh it won’t resave anything.
Would it be possible for another website user to accidentally be served
the flash[:notice] of another person? I may just redirect_to the final
screen and reread the data back from the database, but thinking about
all this made me wonder how secure flash[:notice] really is.
Would it be possible for another website user to accidentally be served
the flash[:notice] of another person? I may just redirect_to the final
screen and reread the data back from the database, but thinking about
all this made me wonder how secure flash[:notice] really is.
The flash is just a convenience gateway to the session. So if you trust
the session, you’ll trust the flash. And the session is simply just a
unique md5 string in a cookie on the client that gets shot across on
every request, which the server uses to find the session row/file with.
It’s not a highly complicated system, so if you wanted to dig in to do
your own verification, it shouldn’t be that onerous.
DHH wrote:
Would it be possible for another website user to accidentally be served
the flash[:notice] of another person? I may just redirect_to the final
screen and reread the data back from the database, but thinking about
all this made me wonder how secure flash[:notice] really is.
The flash is just a convenience gateway to the session. So if you trust
the session, you’ll trust the flash. And the session is simply just a
unique md5 string in a cookie on the client that gets shot across on
every request, which the server uses to find the session row/file with.
It’s not a highly complicated system, so if you wanted to dig in to do
your own verification, it shouldn’t be that onerous.
Well I’m storing a user object in the session and testing for that
object to make sure the user is logged in (i.e. if @session[:user] !=
nil, of which I’m sure may not be safe and secure either). So I suppose
I trust the session enough to use the flash. But I think I’ve just
decided to go with a generic “Thank you for submitting…” type page and
just not show the saved data on the final screen.
On 2006-09-20, at 16:30 , The B. wrote:
Would it be possible for another website user to accidentally be
served
the flash[:notice] of another person? I may just redirect_to the
final
screen and reread the data back from the database, but thinking about
all this made me wonder how secure flash[:notice] really is.
as david said, the flash is stored in the session.
there’s another quirkiness of the flash that you should be aware,
though:
the action that receives the flash is the request immediately
following the one that populated the flash. that means that in quasi-
parallel requests (e.g. user opens many tabs) or in multiple
refreshes, the flash may go to an undesired page.
On 2006-09-20, at 17:30 , The B. wrote:
Well I’m storing a user object in the session and testing for that
object to make sure the user is logged in (i.e. if @session[:user] !=
nil, of which I’m sure may not be safe and secure either). So I
suppose
I trust the session enough to use the flash. But I think I’ve just
decided to go with a generic “Thank you for submitting…” type
page and
just not show the saved data on the final screen.
It’s not a specially good idea to store AR objects in the session, as
they may become outdated and so on. Preferrably, store the id, and
define a controller method that finds the actual object.
If the saved data you want to show is an AR object, you may simply
pass the id in the url and re-retrieve the record in the final
screen, much simpler than relying on the flash.
“The B.” wrote:
But the problem is, if someone hits refresh a few times it
saves multiple times.
So the root cause seems to be multiple saves. I wonder if this is a
normal
behavior.
To me this sounds like a bug in your code.
Long
Long wrote:
“The B.” wrote:
But the problem is, if someone hits refresh a few times it
saves multiple times.
So the root cause seems to be multiple saves. I wonder if this is a
normal
behavior.
To me this sounds like a bug in your code.
Long
It’s not really a “bug,” it’s more of a “feature” 
It’s basically
happening because the “save” method has a “save” view to display the
final details. But if someone hits refresh, the browser will resubmit
the data to the save method again, thus saving a new entry. To be more
secure, I think I’ll follow Caio’s advice, store only the id in the
session, and redirect to a URL that specifies the id and just pull the
model from the database.
Long wrote:
Long
Agreed. You’re ‘save’ action should re-direct to a ‘show’ action after
saving, so that if the user refreshes, all they refresh is the ‘show’,
not the ‘save’. See the ‘add_to_cart’ method in AWDR (Page 84 in the
1st addition) for an example.