Flash[:notice] Security

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” :slight_smile: 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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs