The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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)

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.

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'.

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.

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.

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.

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)

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona

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.

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.

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.

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?

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).

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".