Welcome Guest, Not a member yet? Register   Sign In
Database Update Question
#11

[eluser]Derek Allard[/eluser]
Actually, I must confess to having done it both ways Wink

Later today I'm releasing another version of Bamboo. I spent part of my morning converting a form from action="controller/edit_method/invoice_id" into the hidden form field method just so that the end code would look more similar. At the end of the day, just as much information is moved, and neither approach offers anything in the way of speed or security. The hidden form field has the added advantage (or disadvantage depending on your point of view) of not being cached in the browser history.
#12

[eluser]Michael Wales[/eluser]
I've always followed the additional segment route - I never thought about the browser caching it.

May be good to note for future reference.

What ideas can we come up with to further secure that hidden field - to ensure people aren't manually editing the form and submitting it?

My first thought:
Establish a salt, SHA1($salt . $id) into flashdata as well as the salt itself, place the plain-text ID into a hidden field.

On form processor, ensure the flashdata SHA1 == flashdata ($salt . $this->input->post($id))

Yay for psuedo-code.
#13

[eluser]Negligence[/eluser]
To make it secure, you have to do either one or two things.

1) Ensure that the database record is valid before you do anything with it. I've seen too many applications that don't check to see if an ID exists before operating with it.

2) If necessary, check that the database record belongs to, or is editable, by the current user. If not, stop what you're doing.

These two steps are simple and they go a long way towards making your application less susceptible to security problems.

In response to your solution Michael, a better approach is to store the record ID in the session, do not use it in the URL/form, and retrieve it after the form has been submitted. This way the ID itself cannot be tampered with it all, making the process foolproof.
#14

[eluser]Michael Wales[/eluser]
Quote:In response to your solution Michael, a better approach is to store the record ID in the session, do not use it in the URL/form, and retrieve it after the form has been submitted. This way the ID itself cannot be tampered with it all, making the process foolproof.

heh - or do that Smile
Why did I over complicate that so much!?
#15

[eluser]ehalber[/eluser]
@Negligence et al

Currently I'm using a session to limit access to the admin area. Do I need to create another table in my database to hold information concerning which record is being worked on? For example, currently I have a couple of tables, one for events and one for user access which stores the session info. Would I need to create a third table and use it to store the id associated with the record I want to update?

Actually, this may be another discussion entirely, but is there a best practices approach for handling data in this way. For example, should I abandon using the post to send data, preferably moving all data back and forth through session variables? Do you know of any online examples to illustrate your ideas?
#16

[eluser]Nick Husher[/eluser]
The only issue I can see with storing the ID in a session variable, especially if authentication is through a persistent session, is that you potentially expose yourself to an cross-site request forgery attack. It's pretty unlikely, but it's something you should be aware of.
#17

[eluser]Derek Allard[/eluser]
A little birdie told me automated CSRF protection is being worked on in CodeIgniter. I'm hopeful it'll make it into the next release.
#18

[eluser]Nick Husher[/eluser]
Now that would be an impressive feat. Any chance you can give me/us a rundown on how it works? There are a bunch of cool ways that I've thought of, but they always come down to either being unworkable or inconvenient to the user.
#19

[eluser]Derek Allard[/eluser]
Not right now Nick, but it will just be a measure of protection. There's no such thing as perfect security, everyone here knows that, but I'm hopeful it will help mitigate the possibilities. Anyhow, stay tuned!




Theme © iAndrew 2016 - Forum software by © MyBB