[SOLVED] Form Injection problems

[schilly]

Hi Everyone,

 

Hoping you can help. I've been using session authentication for a while on a few small sites without any problems up until now. 

 

I have recently been getting some html injections into a form that only members can view thought session authentication. I set up a log on the login page and compromised form to see if they were gaining access through the login form then injecting into the other form but the entries didn't match up so I assume they are bypassing my authentication script for that form.

 

Here is my authentication script which is called at the start of every member only page:

 

function memberAuth(){

session_start();

if($_SESSION['MEMBER'] !== "YES"){

session_destroy();

header("Location: memberLogin.php");

}

}

 

Is there any easy way to bypass this? I've used this for a while and never ran into any problems before.

 

If you need any additional info, please let me know.

 

Thx.

[haku]

change this:

 

if($_SESSION['MEMBER'] !== "YES")

 

to this:

 

if($_SESSION['MEMBER'] != "YES")

 

And see if that helps.

[Aureole]

In case you don't understand the difference between != and !==

 

<?php
// In PHP, both of these mean true...
$a = true;
$b = 1;

// Both $a and $b are true, but !== also checks to see if they are of the same type, $a is a boolean and $b is an integer.
if( $a !== $b ) echo( 'false' );
// Will return false.
?>

 

[gizmola]

Did you consider session fixation?  What's important is what you're doing in memberLogin.php.  This topic is discussed in many places, including an article that they've linked to on the php.net page for sessions, and there's also this article that's php specific by Chris Shifflet.  http://shiflett.org/articles/session-fixation

 

 

[schilly]

Thanks for the feedback. I recently changed to '!=='. Before I was using strcmp. Reading up on session fixation now.

[schilly]

Interesting article. I will start using session_regenerate_id();  when I set my session variables and see if that makes a difference.

[PFMaBiSmAd]

What does your code do after it calls that function? The header() redirect is performed by the browser. If your code just continues execution and the browser (or a script that could care less about headers your code sends out) does not redirect, then they will access the protected content on the page. You must execute an exit; statement at some point after the header() statement to stop the code on the rest of the page from executing.

[schilly]

There is no code after the redirect, it just loads up the form page.

 

So if they aren't using a browser or have some modded browser that doesn't recognize the header cmd then it will just send them my form and they can post to it?

 

Will exit; stop the html afterwards from loading?

 

Thx.

[schilly]

Sry bump. Anyone know about this?

[rhodesa]

Put an exit after your header call

 

<?php
function memberAuth(){
   session_start();
   if($_SESSION['MEMBER'] !== "YES"){
      session_destroy();
      header("Location: memberLogin.php");
      exit;
   }
}
?>

[schilly]

Ok so essentially custom requests to web servers can essentially bypass the header cmd and view any code after that?

[rhodesa]

i *think* so

[schilly]

Awesome thanks. I didn't really think about being able to bypass the header cmd. I'm guessing this is the problem. I will update tonight and see how it goes.

 

 

[rhodesa]

My rule of thumb: Always have an exit after a header('Location: file.php'); command

[schilly]

Looks like it fixed the problem. No spam in over a day now. Thanks everyone.