method=POST problem (maybe?)

[Sagefire135]

Ive been messing around with my pseudo-game and from a players standpoint i like to make things that normally would take a little work....easily done with the push of a button.  While from a coding standpoint, i dont want to allow an "easy button" to get things done, especially since this means a program could be made that would do it automatically. So im thinking about forms and POST vs GET; if i set my form to POST, a player wont be able to see what goes on behind the page. while if i use GET, everything is shown. my thinking led me to realize that it really isnt hard to find out whats going on behind the page via looking at source code.

So if i have a page blahblah.com/action.php that looks something like...

Code: [Select]

<form action="action.php" method="post">
Value 1<input type="text" name="value1">
Value 2<input type="text" name="value2">
<input type="submit" value="Submit">
</form>a player could easily just paste blahblah.com/action.php?value1=__&value2=__ with the desired info and bookmark it right?

Being curious, i tried this out on a game i play and it just wouldnt work. am i missing something and seeing a problem where one doesnt exist? or is there a way to prevent doing it altogether?

EDIT: Ok i see what i was doing wrong, the submit value needed to be set as well. so i made a simple page with a duplicate of the code that was on the page im looking at, then i directed my page to that one. it worked exactly how i was expecting. So the question now is can it be prevented?

[Bryan]

You probably want to look into setting up some form security tokens.  Here's a handy little simplified synopsis of some essentials on PHP and HTML Form Security.

You question seems to be related to -

CSRF stands for "Cross-Site Request Forgery", and CSRF attacks are similar in scope and methodology to XSS attacks. CSRF attacks usually either exploit the fact that many websites perform actions on HTTP GET requests—deleting blog posts, buying items etc.—or spoof a client request to a resource so that the website believes the request is genuine. Either way, the victim performs an action on a website that trusts him—usually his own—that he did not intend to happen.

Which is generally solved by these two methods-

The first is rather simple: never, ever use GET for any critical task. Instead, use a POST form. Such requests are harder to forge and have the added bonus that they are impossible to load into HTML image/script tags, eliminating an attacker's ability to exploit your site remotely.

The second is to make sure all requests originate from your own forms, eliminating the possibility that the request could have been loaded from a fake form on a different webpage. To do this, we can create a value— known by some as a "nonce", but here referred to as a "token"—that is created especially for the form, submitted along with it, and checked— along with the usual permission checks—before the action is performed.

Here's an example that creates and checks a token before deleting a forum post:

Code: [Select]

<?php

session_start();

if( !empty($_POST['post_id'] ) {
    if( !user->is_a_moderator )
        die;
    if( empty($_POST['token']) || $_POST['token'] != $_SESSION['token'] )
        die;

    // All fine: delete the post.
    delete_post( intval($_POST['post_id']) );

    // Unset the token, so that it cannot be used again.
    unset($_SESSION['token']);
}

$token = md5(uniqid(rand(), true));
$_SESSION['token'] = $token;

?>

<form method="post">

<p>Post ID to delete:</p>
<p><input type="text" name="post_id" /></p>

<input type="hidden" name="token" value="<?php echo $token; ?>" />

</form>
As we can see, using a POST form with a generated token is simple, straightforward and eliminates the possibility of CSRF attacks.

Lot's more on preventing various common forms of attacks at the link I provided and all over the internet with a few well phrased searches. Happy Coding

[tellmore]

Heh, yes it would be annoying if a form would be bookmarked, GET method does allow that.
Post is better.

There is something else You can try, its easy to make.
Set some hidden fields, and submit them with javascript.
Will not solve all issues, but looks good, and prevents less educated ones to findle with your forms.

[Bryan]

Relying on client-side authentication? 

[Sagefire135]

ahh nice! cant submit the form unless you know the secret token. which of course would only be known to the code nanoseconds before submiting. very clever.

[Nox]

as for CSRF - using POST instead of GET doesn't improve security at all... CSRF means that the source form is not from the system itself, so having POST for the attacker only means to change method="get" to method="post" and that's all
Of course generally it's much better to use POST in important cases but I belive this is not really the reason

Tokens are the way.
And yes, never rely on client-side authentication

[JGadrow]

The awesome benefit of form tokens is that you can create better hidden values. Basically, the form token serves as a unique identifier for a particular form instance. So, you can create a database table like:

form_token, var_name, value

So that you can insert truly hidden data that the client never has access to. For further security, you could tie the form_token to the user session. Meaning that you cannot access the form data from another user's session (as is the intent).

[jannesiera]

I don't really get why you should ever use GET... Why do I see people using get all the time, why wouldn't you just always use post?

[Harkins]

Because GET URLs should be idempotent and cacheable. POST is for making changes.

[jannesiera]

Because GET URLs should be idempotent and cacheable. POST is for making changes.

Ah, I see. Now gotta remember it .