tags:

views:

113

answers:

3

Just had a thought

post.php

if (isset($_SESSION['id'])) {

if (isset($_POST['comment'])) {
insert()
}

<form method="post" action="post.php">

<textarea name="comment"></textarea>

<input type="submit" class="btn" value="Submit">

</form>

}

$_SESSION['id'] needs to be set to access post.php. Is that safe enough?

Just thinking maybe someone can just create a session on their site and make their own post.php and redirect it to my site? can you do that?

<form method="post" action="http://mysite.com/post.php"&gt;

<textarea name="comment"></textarea>


<input type="submit" class="btn" value="Submit">

</form>

Exucse my limited english

A: 

The real issue is that people can intercept the packet midflight and rewrite the values of the form to be whatever they want. What security goals are you trying to accomplish? People will always be in complete control over the values sent from the client, make sure your application doesn't assume anything of the data coming back.

Look at Tamper Data for Firefox: https://addons.mozilla.org/en-US/firefox/addon/966

Stefan Mai
i don't think it's that critical if people can tamper with the comment they posted themselves (as tamper data would enable them). the issue here is that only logged in people may be able to post. for this, session id hijacking must take place - and that's a different problem.
Schnalle
@stefan mai: ok, other people rewriting your content by hijacking network traffic may be a problem, but is solved by https.
Schnalle
+3  A: 

Just as general advise, I always prefer "bail-out-soon" over "if-if-if". Meaning, the top should look more like :

if (!isset($_SESSION['id'])) {
    // display_error();
    // redirect()
    // whatever else needs to be done
    exit;
}

// continue as planned
deceze
A: 

i can't see any imminent problem. if it's critical, make sure data is sent over https, so people hijacking network traffic can't tamper with it (as Stefan Mai suggested). otherwise, it seems ok - as long as nobody is stealing your users session cookies.

decezes method is just another coding style. it doesn't increase security per se, but may prevent sloppy programmers from making mistakes in the form of:

if (checkIfLoggedIn()) {
  doPrivateThing();
}

doAnotherPrivateThing();  // bug: the programmer should have 
                          // put that into the if-conditional

otherwise, make sure the session id is stored in a cookie, and never passed transparently over the URL! i'm not sure about the default settings in the php.ini nowadays, but it used to do url rewrites automatically if cookies are disabled. better check that.

as far as i remember, the ini-option is session.use_only_cookies (should be enabled)

php/session security

update:

"Just thinking maybe someone can just create a session on their site"

no, that won't work. sessions are created upon session_start(); (or sometimes automatically). $_SESSION['id'] has nothing to do with the session_id();, it's just some variable. though it's not very well named, because other could indeed confuse it (maintainability!). better name it $_SESSION['isUserLoggedIn']; or something like that.

Schnalle
Yeah true, security-wise my suggestion doesn't make any difference, if there's no mistake in the code. The point is, a programmer is his own worst enemy, so you always want to reduce the chances of introducing stupid little mistakes that may turn into a security nightmare.
deceze
yes, i wrote exactly that: "may prevent sloppy programmers from making mistakes" :)
Schnalle