Posting variables WITHOUT get

[Jake Arkinstall]

HI again peeps.

I was wondering if theres a way to send variables to a page without GET?

The reason is that theres a small page with a form on. There is a session set with a user-id. I want this user-id to go to this form page, however the page doesn't access the sessions.

my way around this was to put the session into a variable in the URL, but the user can always change this and enter data under some other id.

to get the page, there's a link in a <select> box, which when clicked will go to this page.

Is there a way to send a variable to this page without GET or SESSION?

[greg76]

Howdy,

if I understand correctly, there IS a session on form page, the one that catches user's ID.

So, instead of using GET - how about POST?

You can create hidden var with user's ID, and when an user hits 'submit' button, all data (from the form + hidden field with his/her ID) are transferred to a result page (if different from 'form' page -> I usually use same file, just separate blocks to be displayed using an IF condition).

When using POST, no vars are shown.
Cheers,
Gee dot Bee
(to be a bee or not to be a bee)

[devbanana]

True no variables are shown, but they can still change the value of the hidden field either using JavaScript injection or copying the form and changing the value, then submitting. So it provides no more security than GET.

Why can't you just use sessions?

[greg76]

True no variables are shown, but they can still change the value of the hidden field either using JavaScript injection or copying the form and changing the value, then submitting. So it provides no more security than GET.

Why can't you just use sessions?

of course, but now u r talking about peeps that want to deliberately mess up with your/his/her/mine site. in that case -> where is a will there is a way, and you won't be able to protect anything.

I am talking about foul protection from 'normal' users and 'weekend hackers'.

[greg76]

Why can't you just use sessions?

So, don't secure because "they'll be able to get in, anyway" sounds like an odd view to me.

No, not at all, secure as much as you can, as your knowledge allows you, anyways.

If there is a form, there IS this or that way of sending form's values. Either way someone who knows how to mess up things - and if s/he is willing to - can still f** up your site.

Tell me, how sessions would prevent a site from being hacked?
Sooner or later the session's value (which means NEXT page, where session gets its value) will become a variable and therefore can/may/would/could mess up anything.

I was saying, if someone wants to deliberately destroy your site and know the way of doing this - there is nothing that would stop him/her. All protections we apply, they are for sunday's hackers.

I protect my forms by double-checking scripts: javascript and php (which has mysql injection's anti-scripts implemented, too), but I am aware that there are peeps waaaaaay more advanced in either javascript and/or php than me, who can crack my finest protections in NO time at all.

Would not you agree with me?!

[clamcrusher]

Tell me, how sessions would prevent a site from being hacked?
Sooner or later the session's value (which means NEXT page, where session gets its value) will become a variable and therefore can/may/would/could mess up anything.

but the visitor cannot view or alter the value of the variable(unless you explicitly let them). that is one of the main reasons to use sessions, to be able to associate data with a user without letting them influence it.

obviously sessions are only as secure as you make them. but its not hard to prevent a user from modifying session data, in fact you must produce some code which will let them.

[greg76]

but its not hard to prevent a user from modifying session data, in fact you must produce some code which will let them.

scusi mi?

if I can save the site on my local drive (ctrl+s for PC, apple key +s for MAC), modify it, and send out data I want what would stop me from messing up your site? Try and go, try and go, try and go, sooner or later your sooo-secured-site would be hacked.

You just give me ideas, mate.

whatever your protections are (and I am talking about average web developer, like myself), they are for Sunday's hackers.

If someone skillfull in that area of hacking wants to mess up up site, what would stop him/her?

[devbanana]

which proves my point:
whatever your protections are (and I am talking about average web developer, like myself), they are for Sunday's hackers.

If someone skillfull in that area of hacking wants to mess up up site, what would stop him/her?

I don't understand what you're saying. Clamcrusher was saying that users cannot edit the data within sessions, so they are indeed secure, since they are stored on the server.

[greg76]

I protect my forms by double-checking scripts: javascript and php (which has mysql injection's anti-scripts implemented, too)

I stated before that I do validate the data, to ensure the output does not caontain unwanted things.

All I am saying is that there are peeps out there way more skilled in this stuff than me who hack sites just for fun and I don't think any script would stop them.

Cheerios,
GeeBee

[devbanana]

So, don't secure because "they'll be able to get in, anyway"? It's not that difficult to mess with a value like that, so I wouldn't think it'd be too uncommon for people to know how to do that. Anyone with even basic knowledge of HTMl can copy the form, change the value and submit.

Really, not securing because they'll be able to hack it anyway, sounds like an odd view to me.

[devbanana]

maybe in some cases. Really i tdepends on the type of site. Huge sites where it is crutial they stay up and are not hacked (enterprise businesses, etc), would have much more stringent measures in place to ensure their application is secure. Undoubtedly this would include SSL.

For the average web site, really it's up to the developer how far to go to protect the application. Really if there's a security hole that I know how to fix and doesn't cost, or at least not more than I'm willing to spend, then I'll fix it. There's no sense whatsoever in leaving a security hole that can be fixed easily, such as the case in this thread.

Depending on what the action is being performed for or to the user specified by the given user ID, this could potentially be a huge security hole that users won't be very happy about if exploited.

[Jake Arkinstall]

Anyway, back to my problem.

I have a file called top.php, which has a banner and a small login form. This file is "require"d in nearly all pages, as it includes the design and the database info. This design is for a full page. My main problem is that i want the form page to be relatively small, only 300 by 200 pixels. This stops me from requireing top.php. The form file connects to a database after it's submitted and inserts the data, but i have a column which contains the ids of the members who submitted it, so i can only allow them to view the forms THEY have submitted. I need a way to transport a variable to that page telling it what to put.

I can only access sessions from the pages which have top.php in them.

I would do greg's idea, however the client made it clear that she wanted the form to be accessed by a drop-down box

why do women have to be so picky???? (no offence)

[clamcrusher]

I can only access sessions from the pages which have top.php in them.

why cant you use session without including this top.php file? i really see no reason why you couldnt.

if you must, i suppose you could store the value of the variable in a database, and then generate a large unique id for it. pass that id into a hidden field, when the form is received use that id to query the db and retrieve the value of that variable.

but, that is now almost a session in concept, and it would seem to me to be much easier for you to just use the already existing session for this user.

[devbanana]

So, refactor. You shouldn't have presentation and business logic mixed together, anyway. Put the logic into functions, or classes if you're so inclined, and include that where needed.

By the way, when you say "IDs" in "column", that sets off a non-normalized data alarm for me. It sounds like your database design needs work. You should only ever have one atomic value in a column; never a list.

[Jaffizzle]

if you put a session_start() at the top of the form...then wouldnt you be able to access the session variables?

[clamcrusher]

you can edit the html all you want. you can send whatever data to the webserver you want. if i dont choose to let your data into my session, you're out of luck bud, you cant modify my session data.

maybe you dont understand fully what a php session is, or we are talking about different things.

If someone skillfull in that area of hacking wants to mess up up site, what would stop him/her?

solid code, validation, and proper logic stops them.

bad code, or bugs in your platform/other software on the server may allow them to do what they want. however, the only thing relevant to this discussion is the bad code aspect.

[greg76]

if i dont choose to let your data into my session, you're out of luck bud, you cant modify my session data.

dude,

session WILL get its value no matter what. And there are only two ways for a session to get its value: GET or POST

Like I said: try and go, and your sessions are gone, pal.
IF I wanted to mess up your site, that is.




If I don't know something, would u be so kind to englighten me?

[clamcrusher]

dude,

session WILL get its value no matter what. And there are only two ways for a session to get its value: GET or POST

Like I said: try and go, and your sessions are gone, pal.
IF I wanted to mess up your site, that is.




If I don't know something, would u be so kind to englighten me?

this isnt black magic. "uber hacking skill" does not allow you to skip serverside validation routines unless the validation routines are poorly written or non existant.

i dont think you understand the concept of serverside validation. you should validate data before you accept it or use it. this is because someone can send any value you want to a script(just like you said). i think you are under the assumption that everyone blindly accepts user input and trusts it as being safe. this is often the case with amateur code, which is not "good code".

[devbanana]

It's called data validation. You don't just let any data in; you validate it as appropriate, assuming nothing is clean. There really should be no way to hack into the application if all data is validated properly and stored securely (e.g., in a session).

[shiflett]

I was wondering if theres a way to send variables to a page without GET?

With a different request method? Sure.

The reason is that theres a small page with a form on. There is a session set with a user-id. I want this user-id to go to this form page, however the page doesn't access the sessions.

So, you've stored a "user-id" in the session, correct? Why don't you solve the "page doesn't access the session" problem instead of trying to figure out a way around that?

my way around this was to put the session into a variable in the URL, but the user can always change this and enter data under some other id.

Anything that comes from the user can be changed by the user. This is fundamental.

[Jake Arkinstall]

ok, i think i've got ANOTHER way around it.
how about if I put a MODIFIED session id, created by doing some maths. This is then reversed on the other page and run through like usual.

although the user could still change the id in the url, what are the chances of getting a correct one?

[devbanana]

You still haven't answered why you can't just use session_start() and use the session normally.

[devbanana]

You can believe that, but do you have proof? Tell me why a script couldn't stop them if it validates all user data?

[clamcrusher]

a summary of what youre saying:
"i dont understand the language/programming enough to prevent unwanted side effects"

that is very different than saying:
"it is impossible to prevent unwanted side effects"

just because you dont understand something, does not mean other people dont.

to say you have validated the data, yet someone still hacks you, is to say that you didnt validate it properly.