how to securely store a record index when editing a mysql record

[dino d.]

hi everyone- my subject pretty much says it all- is there a secure way
to do this? the non-secure ways are, as i understand it, to populate
a listbox with indices as names, or maybe use a hidden control. is the
only secure way with sessions? i was also thinking about perhaps
creating a meta table that says who is editing which record right
now. any advice?

thanks,
dino

[Jerry Stuckle]

dino d. wrote:

hi everyone- my subject pretty much says it all- is there a secure way
to do this? the non-secure ways are, as i understand it, to populate
a listbox with indices as names, or maybe use a hidden control. is the
only secure way with sessions? i was also thinking about perhaps
creating a meta table that says who is editing which record right
now. any advice?

thanks,
dino

Define "Editing a MySQL record".

What happens if the user brings up an edit form then shuts off the
computer, for instance?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[dino d.]

i'm really mostly concerned about how to pass the record id of the
edited record on post without exposing the record ID to the html
source. thanks for any help.

dino
On Mar 9, 10:46 pm, Jerry Stuckle <[e-mail]:

dino d. wrote:

hi everyone- my subject pretty much says it all- is there a secure way
to do this? the non-secure ways are, as i understand it, to populate
a listbox with indices as names, or maybe use a hidden control. is the
only secure way with sessions? i was also thinking about perhaps
creating a meta table that says who is editing which record right
now. any advice?

thanks,
dino

Define "Editing a MySQL record".

What happens if the user brings up an edit form then shuts off the
computer, for instance?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

dino d. wrote:

i'm really mostly concerned about how to pass the record id of the
edited record on post without exposing the record ID to the html
source.

You don't. You store that ID in a session variable.

This may become a problem if you are editing several records at the same
time. though. Think about using ID hashes, or random tickets.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

[Jerry Stuckle]

dino d. wrote:

On Mar 9, 10:46 pm, Jerry Stuckle <[e-mail]:

>dino d. wrote:

>>hi everyone- my subject pretty much says it all- is there a secure way
to do this? the non-secure ways are, as i understand it, to populate
a listbox with indices as names, or maybe use a hidden control. is the
only secure way with sessions? i was also thinking about perhaps
creating a meta table that says who is editing which record right
now. any advice?
thanks,
dino

Define "Editing a MySQL record".

What happens if the user brings up an edit form then shuts off the
computer, for instance?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

i'm really mostly concerned about how to pass the record id of the
edited record on post without exposing the record ID to the html
source. thanks for any help.

dino

(Top posting fixed)

Lots of ways. As Iván suggested, use a session variable. A hash doesn't
work (not reversible), but you could also append a hidden string (known
only to you) and encrypt it.

But the question begs - why worry about exposing the id? It's only an
identifier to a row, and should not have any meaning of its own. If
you're trying to obscure it for security reasons, it won't work.
Obscurity is no security. Rather you need to have other means of
verifying if this person is authorized to edit the row.

P.S. Please don't top post. Thanks.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

Jerry Stuckle wrote:

Lots of ways. As Iván suggested, use a session variable. A hash doesn't
work (not reversible),

It works, if you store a rainbow table as a session variable (to reverse the
hash when the client posts the data), and expose the hash to the client.

The ticket idea is similar, but uses random strings instead of hashes.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

[Jerry Stuckle]

Iván Sánchez Ortega wrote:

Jerry Stuckle wrote:

>Lots of ways. As Iván suggested, use a session variable. A hash doesn't
work (not reversible),

It works, if you store a rainbow table as a session variable (to reverse the
hash when the client posts the data), and expose the hash to the client.

The ticket idea is similar, but uses random strings instead of hashes.

true - but wouldn't a reversible encryption be a lot easier?

But either way - it's still security by obscurity - which is no security
at all.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[dino d.]

>

But the question begs - why worry about exposing the id? It's only an
identifier to a row, and should not have any meaning of its own. If
you're trying to obscure it for security reasons, it won't work.
Obscurity is no security. Rather you need to have other means of
verifying if this person is authorized to edit the row.

ok, sorry for the top posting, by "top posting" you mean writing your
reply at the top, right? back to the question - i don't want to give
the user an opportunity to monkey around with the html somehow, and
send back a bogus response via a POST variable. I want to ensure 2
things- first, that the person is authorized to edit this row, and
second, that this is the row that he or she is authorized to edit. It
sounds like sessions are the way to go with some kind of encyrption.
Is that the generally accepted way of doing this?

Thanks again,
Dino

[Gordon Burditt]

>ok, sorry for the top posting, by "top posting" you mean writing your

>reply at the top, right? back to the question - i don't want to give
the user an opportunity to monkey around with the html somehow, and

Using CURL is much easier than monkeying around with HTML, and you
can't stop it.

>send back a bogus response via a POST variable.
I want to ensure 2
things- first, that the person is authorized to edit this row, and

Then when the user submits his edit of the row, you CHECK that he
is authorized to edit that row *WHEN HE SUBMITS IT*. This is not
the same thing as checking what the user is authorized to edit when
he pulls up a screen of records he might edit, or checking when he
starts the edit (although those are a good idea ALSO). Why? Between
those times, the user might have had his account cancelled, or he
might not own the record any more, or he's changed jobs so he doesn't
have the authority to edit records any more, or whatever.

>second, that this is the row that he or she is authorized to edit. It
sounds like sessions are the way to go with some kind of encyrption.
Is that the generally accepted way of doing this?

Data in sessions is not sent to the browser nor accepted back from
it, so the user cannot directly tinker with it. It's good for
keeping track, for example, of who if anyone is logged in for this
session. But editing inherently involves getting input from the
user. Check that he has the authority AT THE TIME YOU'RE MAKING
THE CHANGES, as well as earlier. The editing process will probably
involve several checks that the user has the authority to edit: don't
skimp on these.

[=?ISO-8859-15?Q?Iv=E1n_S=E1nchez_Ortega?=]

dino d. wrote:

ok, sorry for the top posting, by "top posting" you mean writing your
reply at the top, right? back to the question - i don't want to give
the user an opportunity to monkey around with the html somehow, and
send back a bogus response via a POST variable.

Then don't allow your users to get anywhere near a web browser.

I want to ensure 2 things- first, that the person is authorized to edit
this row,

Use a decent auth, and implement some kind of ACLs.

and second, that this is the row that he or she is authorized to
edit.

Easy - echo the row primary key. No need to obfuscate it. In your "security"
paranoia, you are forgetting about more important things - like data
integrity and concurrency.

It sounds like sessions are the way to go with some kind of
encyrption. Is that the generally accepted way of doing this?

The accepted way to do this is to learn about the possible meanings
of "security" in computer science (integrity, confidentiality, reliability,
non-repudiation, etc etc). Then, think about what you *really* need in your
app.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

http://acm.asoc.fi.upm.es/~mr/
Proudly running Debian Linux with 2.6.18-4-amd64 kernel, KDE3.5.3, and PHP
5.2.0-10 generating this signature.
Uptime: 23:13:59 up 1 day, 9:35, 3 users, load average: 0.92, 0.87, 0.66

[Jerry Stuckle]

dino d. wrote:

>But the question begs - why worry about exposing the id? It's only an
identifier to a row, and should not have any meaning of its own. If
you're trying to obscure it for security reasons, it won't work.
Obscurity is no security. Rather you need to have other means of
verifying if this person is authorized to edit the row.

ok, sorry for the top posting, by "top posting" you mean writing your
reply at the top, right? back to the question - i don't want to give
the user an opportunity to monkey around with the html somehow, and
send back a bogus response via a POST variable. I want to ensure 2
things- first, that the person is authorized to edit this row, and
second, that this is the row that he or she is authorized to edit. It
sounds like sessions are the way to go with some kind of encyrption.
Is that the generally accepted way of doing this?

Thanks again,
Dino

Yep, that's right. This one is much better.

And there is no way you can prevent the user from monkeying around with
the html.

For instance - I can display the html source, copy it to notepad and
edit it to my hearts content. Save it on my own machine and load it in
to the browser. When I submit it it will still go to your site. The
whole think may take less than two minutes.

Yes, you can save the data in the session. But Gordon has some very
valid comments on why you need to determine if they can edit the row at
the time the user submits the edit request.

Any dangerous operation (i.e. altering a database entry) needs to be
authorized at the time of the submission.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[dino d.]

Any dangerous operation (i.e. altering a database entry) needs to be
authorized at the time of the submission.

ok - so just to clarify, what is the technique to do this- with a meta
table on the database server, i.e.:
Table Permissions:

UserID: int TableID: int RecordID: int Permission: int

how about with sessions? if anything else, can you give some
specific techniques as to how to do this? what i'm really trying to
get to is, what is the generally accepted, easiest (built into php?)
way to ensure that the user is authorized to edit a row upon
submission? thanks for all the posts.

thanks again,
dino

[Gordon Burditt]

>Any dangerous operation (i.e. altering a database entry) needs to be

>authorized at the time of the submission.

ok - so just to clarify, what is the technique to do this- with a meta
table on the database server, i.e.:
Table Permissions:

UserID: int TableID: int RecordID: int Permission: int

>how about with sessions?

A quite reasonable rule is that only a particular session can alter
data (say, a shopping cart contents) associated with that session.

>if anything else, can you give some
specific techniques as to how to do this? what i'm really trying to
get to is, what is the generally accepted, easiest (built into php?)
way to ensure that the user is authorized to edit a row upon
submission? thanks for all the posts.

There are all sorts of different rules possible, and it depends
largely on the site and what it's for. Usually, these are related
to "business rules", for example, customers can't alter prices or
give discounts to other customers. Only supervisors can approve
refunds or orders over $1,000. You can't cancel an order after it
has been shipped (at least not directly; talk to customer service).
1. No one is allowed to edit anything through the web.
("read only" informational site, porn site)
2. Only site admins are allowed to edit anything.
("read only" informational site, porn site)
3. Users may sign up and create their own accounts. Subsequently,
they may edit their own contact information and password. Users may
create and edit their own orders in process of creation, but not
after submission. Customer service reps may edit any order.
(e-commerce site, perhaps)
4. Users may sign up and create their own (class 0, initially) accounts.
Subsequently, they may edit their own contact information and password.
Class 2 accounts and higher may read posts. Class 5 accounts and
higher may reply to posts. Class 6 accounts and higher may start a
new thread. Class 14 accounts and higher may delete any post.
Class 15 accounts may alter the class of any account.
No one may edit (other than by deleting) existing posts.
(forum site with multiple access levels)
5. Anyone may edit anything (I've heard Wikipedia described this way).
6. Anyone may post anything. No one may cancel anything.
(USENET).

The concept of a "user" needs to tie in with the existing setup of your
site. If a user can edit "his own" records, there needs to be some way
to determine who owns a record. Perhaps "a user's orders" are defined
as orders created by that user while logged in under that account. An
e-commerce site that lets users create orders on another user's bill in an
unrestricted manner won't last long.