Post #40,295
5/29/02 9:42:36 AM
|
Should have been more explicit
Table structure is three colums: session_id, variable_name, variable_value, unique index on session_id, variable_name. Each session can set any arbitrary number or variables with any names. So I could have: | session_id | variable_name | variable_value | | 123456 | item | chair | | 123456 | color | red | | 123456 | price | 123.45 |
After the select query, the session object would have: $session->item = 'chair' $session->color = 'red' $session->price = '123.45' Makes carrying form values through a multi-page order process really simple. Just name all form values that need to be added to the session as array members ( <input type="text" name="data[item]">). When the session is built, it does: foreach($data as $key => $val){
if( !in_array($key,$reserved_names){
$query = "REPLACE INTO
session_values (session_id, variable_name, variable_value)
VALUES ('$sid', '$key', '$val')";
$db->Query($query);
}
}The array reserved_names contains any reserved words. Right now it's only username_display. ===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,312
5/29/02 11:39:36 AM
|
I would not be comfortable with that!
Do you know what a strange variable name could do to you? Read through what some strange variables in Perl do! (Change how you read input, match REs, lots of fun stuff.) Let alone if someone adds a new variable and doesn't realize that they should reserve it.
Basically you are now coding on the model of, "The user is allowed to do anything they want, and I will try to compensate." But what if you overlook something?
Also looking at that code, it looks like you are taking the customer's word on what the price of the item is. When a would-be cracker sees that the price is going back to the CGI script, one of the first things they will try is to upload their custom prices. Can they get a bargain? Oops!
You are reminding me of [link|http://www.perlmonks.org/index.pl?node_id=157252|this story], it is really bad and you didn't even realize it. You are putting their responses directly into the SQL without escaping them. That allows obvious and non-obvious attacks.
I just mentioned an obvious one. Here is a non-obvious one. Someone who knows what they are doing would try putting in various values that try to escape out of a string and then insert arbitrary SQL. A bit of playing around with the syntax and you have essentially handed over your database to anyone with the right knowledge and a little patience. This isn't an obvious attack, but it is bog standard, and unless you do something I don't see, you are vulnerable as all hell to it.
(And this isn't even getting at questions about how session IDs are created and validated. If you use a standard incremental ID system, watch out for users trying to guess and hijack neighbouring sesssions!)
Did I scare you yet?
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,314
5/29/02 11:53:39 AM
|
Yes, I am doing things I didn't show
Yes, I'm escaping inputs. I wasn't even looking at the actual code when I posted that, so it's quite a bit short of the real thing.
At some point, the input you get from a page has to go into the database, and you have to take all appropriate measures to prevent attacks. But, given that you are taking these precautions, is there any particular reason what I'm doing with variable-variables is a problem?
IOW assuming I do all the appropriate checks and nothging screwy goes into the database, is there any problem with how I get it back out and turn it into properties of the session object?
I realize there's the potential problem with using reserved words, but it's already bad practice IMO to use reserved words as variable names.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,452
5/29/02 10:25:54 PM
|
You're stopping short of a better solution.
I know PHP let's you create abitrary instance variables, but why are you doing it? Wouldn't an array be simpler? i.e. $session[$value].
Wade.
"Ah. One of the difficult questions."
|
Post #40,507
5/30/02 9:56:00 AM
|
6 of one, 1/2-dozen of the other
That just ends up as the difference between $session->name vs. $session[name]. At work I've got a similar class that provides both, because we've got some people who prefer each syntax. (No, no one is bothering to enforce a coding standard.)
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,659
5/30/02 11:50:47 PM
|
Slightly bigger difference
A hash is a private namespace. Now you don't have to worry about any possibility that your global variables conflict with the ones from the form. Much better.
I don't know what PHP offers in terms of iterating over a data structure, but it should also offer easy ways to iterate over your form variables should anyone want to do that. This is also a good thing.
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #40,699
5/31/02 9:14:47 AM
|
I must be missing something
A hash is a private namespace. Now you don't have to worry about any possibility that your global variables conflict with the ones from the form. Much better.
In my scheme, form variables end up visible as properties of the $session object. Namespace doesn't get much more private than that. Or am I misunderstanding you?
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #40,828
6/1/02 1:03:47 AM
|
I know what you're overlooking.
Dynamic instance variables are a feature of PHP that are really a side-effect of its dynamic variable rules. In short: they shouldn't work, but they do.
Hash tables are actually exactly what you should be using because that's what they were intended for.
Wade.
"Ah. One of the difficult questions."
|
Post #40,941
6/3/02 9:43:02 AM
6/4/02 9:26:11 AM
|
That could be nasty
Dynamic instance variables are a feature of PHP that are really a side-effect of its dynamic variable rules. In short: they shouldn't work, but they do.
Do they intend to "fix" this? That would break a few somewhat critical parts of my code. (Of course, I could always just rewrite the important lines to use eval() statements.)
[Edit was a typo]
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
Edited by drewk
June 4, 2002, 09:26:11 AM EDT
|
Post #41,062
6/4/02 6:16:32 AM
|
I don't know.
From a theroetical point of view, it would be nice to have it fixed. But the developers of PHP defend it and similar behaviour by saying that classes and objects in PHP are nice to haves. If it's on the ToDo list, it's down some way.
At least if you use a hash, you don't have to worry about whether the key is a legal variable name or not :-).
Wade.
"Ah. One of the difficult questions."
|
Post #41,071
6/4/02 9:07:57 AM
|
Out of curiousity
What could happen to him if a key was not a legal variable name?
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #41,244
6/5/02 7:01:46 AM
|
I don't know.
Knowing PHP, it would probably let you put almost anything in there. I say "almost" because I've seen hints in the comments in the online documentation that certain characters are used in the symbol table to flag "special" entries. Conflicting with those would be Interesting, to say the least.
Wade.
"Ah. One of the difficult questions."
|
Post #41,078
6/4/02 9:27:42 AM
|
So PHP supports hashes?
If so, then I should probably go read up on why they're so wonderful. Maybe if I understood exactly what they are I would see what Ben's been getting at a little easier.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #41,243
6/5/02 7:00:02 AM
|
Yes. It does.
They're called "arrays" in PHP and you probably already use them.
I can hear you going "huh?". PHP is the first language I've encountered that combines lists and hash-tables into the same data type. There are advantages, sure, but it's somewhat unorthodox. In most languages, they are separate data types. To use PHP's arrays as hashs, just use the $var['key'] format.
Wade.
"Ah. One of the difficult questions."
|
Post #41,255
6/5/02 9:33:11 AM
|
Blinding flash of the obvious
I use arrays like that all the time. In fact, the only difference in my code would be foreach( $result as $key => $val ){
$this->$key = $val;
} vs. foreach( $result as $key => $val ){
$this->variables[$key] = $val;
} ===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
Post #41,018
6/3/02 7:29:53 PM
|
Stupid question?
As you know, I don't know PHP. So I am giving somewhat generic advice.
But still if the namespace is so private, then why do you have to worry about listing values to avoid? Conversely if you used a hash, shouldn't there be no possibility of conflict between the form and a list of private variables?
Cheers,
Ben
"... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything."
--Richard Feynman
|
Post #41,077
6/4/02 9:24:45 AM
|
Why there's names to avoid
Originally it was because user_id and user_display_name were key fields used in JOIN statements. Now, though, I am using session_id as the only key field, and joining user_id from the session table to the user table. I then create a user object that is a property of the session object. So now to get the user_display_name I use $session->user->user_display_name. Which means the only reserved names are session_id and user.
Yes, these changes were partly in response to the concerns you raised.
But still if the namespace is so private, then why do you have to worry about listing values to avoid?
So that I don't overwrite the user object with a variable of the same name.
===
Microsoft offers them the one thing most business people will pay any price for - the ability to say "we had no choice - everyone's doing it that way." -- [link|http://z.iwethey.org/forums/render/content/show?contentid=38978|Andrew Grygus]
|
