Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
For any nonsense or banter that doesn't fit anywhere else. LoL! omg! ROFL! 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
check my CSRF security for flaws, please?
Posted by: Kyo
Date: May 10, 2008 07:46AM

first, before headers are sent:
-------------------------
if($verificatingsessions == 1) {
if(!$_COOKIE['session']) {
$ver = md5(rand(1000000,9999999));
setcookie("session",$ver);
}
else $ver = $_COOKIE['session'];
}

---------------------------
in the form:
--------------------------------

if($verificatingsessions == 1) {
echo "<input type=\"hidden\" name=\"ver\" value=\"".htmlspecialchars($ver)."\">";
}
----------------------------------
actually checking the verification, once the form has been sent
---------------------------------------
if(!$_COOKIE['session'] || $_COOKIE['session'] != $_POST['ver']) die("Verification Error.");
else setcookie("session","");
-----------------------------

Can you find any flaws? It's kind of half-assed so if you have any improvement suggestions, I welcome them

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: DoctorDan
Date: May 10, 2008 12:50PM

Do you perhaps want to tie $ver to a specific person by hashing in with it some information unique to the user? Useragent, IP, etc.

-Dan

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: Kyo
Date: May 10, 2008 03:25PM

I've thought about it, but I really want it to be random. If an attacker knew the IP or useragent of the user (any CSRF page that is PHP could figure it out, and embed it in the forgery) they could harm him. With a random number there isn't really anything they can do unless they have XSS and can set cookies. But if they have XSS they can just embed the page in a frame, and control it from the XSS'd parent.

Talking about which, do any of you guys know a way to prevent that? I mean, if you find XSS you're pretty much able to do any CSRF as well, simply because you can load any page in an iframe, and control the forms on it with javascript.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: DoctorDan
Date: May 10, 2008 07:23PM

Checking referrers, using subdomains, and using HTTPOnly cookies can all help in different ways. Your best bet, though, is to just do your best to prevent XSS.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: kuza55
Date: May 10, 2008 09:34PM

If you can set a cookie for the user, then it's trivially bypassed by setting a cookie you know, and sometimes it is quite possible to set a cookie for a user without having a usable XSS flaw.

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: Kyo
Date: May 11, 2008 02:24AM

Oh, I check referrers, that's just not displayed in the code.
My XSS protection is also ok, as far as I'm concerned.


Say, kuza55, can you give me a little more info on that?
I know that any cookie will do, but I figured it was good enough, as long as you can't set cookies.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Date: May 11, 2008 09:51AM

doesn't $ver = md5(rand(1000000,9999999));

output a possible of only 8999999 unique md5 session ids? This can potentially cause two visitors to have the same session on a high traffic site. Not to mention makes it more likely the session id can be guessed. Just a thought O.O

How about this to generate your session id?


$sid = '';
$chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
for ($i = 0; $i < 32; $i++)
{
    $sid .= $chars[mt_rand(0, 61)];
}


Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: Kyo
Date: May 11, 2008 03:48PM

1) it doesn't matter if two users have the same session, because it's just a cookie that verifies that it's a human submitting the form.
2) guessing it would require you to be ridiculously lucky, and this gets changed for every form, so that's pretty much pointless as well.

None the less I have switched to a much more elegant solution!

When logging in, a salt is created, which is used to salt the cookie containing the password. This has been in my system for a long time, so I, after getting help from the IRC channel with considering all potential dangers, put the md5 of that salt and the users IP combined as md5(); on every form, and the server checks if it's correct.
Because only the server knows the salt, and because it changes with every login, this is good enough.
It will also stop people who, for some reason, can create cookies on your server from being able to work around this security.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: DoctorDan
Date: May 11, 2008 04:24PM

I like that solution much better :)

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: digi7al64
Date: May 11, 2008 10:59PM

I posted this a while ago at Critical Security. Essentially is a encapsulated csrf object which covers pretty much what people here are already saying.

Anyways, it simple to use and it accepts a "initVal" which acts as salt. It can be used on forms, urls whatever. Ohh, also the id of the form field changes based on the initVal which also makes it another step harder to parse the html looking for the key. Of course this is still a simplified version to my "personal" version but it should be good enough for almost everything.

interface iCSRF {
    function createFormHTML($initVal);
    function createTokenQuerystring($initVal);
    function validateToken($initVal);
}

class CSRFVersion_1_0 implements iCSRF {

    private $m_key;
    private $m_token;
        
    private function generateToken($initVal){
        return md5($this->m_key.$_SERVER['HTTP_USER_AGENT'].$initVal);
    }
        
    private function setKey($initVal){
        $this->m_key = md5($_SERVER['REMOTE_ADDR'].$initVal);
    }
    
    private function setToken($initVal){
        $this->m_token = $this->generateToken($initVal);
    }
    
    //Initialize Token
    private function initializeToken($initVal){    
        $this->setKey($initVal);
        $this->setToken($initVal);        
    }
    
    //Return html code for forms
    public function createFormHTML($initVal){
        $this->initializeToken($initVal);
        return ('<input type="hidden" id="'.$this->m_key.'" name="'.$this->m_key.'" value="'.$this->m_token.'"/>');
    }
    
    //Return querystring value for urls
    public function createTokenQuerystring($initVal){
        $this->initializeToken($initVal);
        return ($this->m_key.'='.$this->m_token);
    }
    
    //Validate token request
    public function validateToken($initVal){
        if (!empty($initVal)){
            $this->setKey($initVal);
            if (!empty($_POST[$this->m_key])) {
                if ($_POST[$this->m_key] === $this->generateToken($initVal)){
                    return true;
                }
            } else {
                if (!empty($_REQUEST[$this->m_key])) {
                    if ($_REQUEST[$this->m_key] === $this->generateToken($initVal)){
                        return true;
                    }
                }    
            }
        }
        return false;
    }                
}

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'



Edited 1 time(s). Last edit at 05/11/2008 11:02PM by digi7al64.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Date: May 12, 2008 03:43PM

Kyo Wrote:
-------------------------------------------------------
> 1) it doesn't matter if two users have the same
> session, because it's just a cookie that verifies
> that it's a human submitting the form.

Ah, I assumed it was used to keep someone logged in as well, my mistake =o)

> When logging in, a salt is created, which is used
> to salt the cookie containing the password. This
> has been in my system for a long time, so I, after
> getting help from the IRC channel with considering
> all potential dangers, put the md5 of that salt
> and the users IP combined as md5(); on every form,
> and the server checks if it's correct.

I agree, much better implementation, but what about people whose ISPs use proxy caches? Their IP may change frequently, have you considered other environment variables?

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: digi7al64
Date: May 12, 2008 07:05PM

CrYpTiC_MauleR Wrote:
-------------------------------------------------------
> but what about people whose ISPs use proxy caches? Their IP
> may change frequently, have you considered other
> environment variables?

With the exception of the user agent chances are there are really no other viable alternatives to use. Also allowing changing IP addresses is why session replay/hijacking techniques are so successful. If you allow this then you really are allowing people using tor and products of the like to access your system. As a lead dev for internet banking this is an extremely bad idea as it opens the site to lots of different attacks.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Date: May 12, 2008 09:03PM

Bank of America uses a flash application upon login to gather info about the client's system, if it doesn't match the info they have previously gathered on their end, it considers the system new and asks a security question. Can this method be used in place of IP checking? I don't know anything about flash and what info it can gather so not sure how reliable it can be, but should be much safer than using and IP or common environment variables.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: fragge
Date: May 12, 2008 10:34PM

i wouldn't use flash on anything. ever.

Options: ReplyQuote
Re: check my CSRF security for flaws, please?
Posted by: Kyo
Date: May 14, 2008 07:47AM

While you can choose whether or not you want the cookies to be IP secure in the admin control panel (well you can choose if you let your users choose to log in ip-insecure), by default, the cookies are always ip-secure anyway, so it doesn't matter for me.

As how it was previously mentioned, I don't want any sessions to be hijacked

Options: ReplyQuote


Sorry, only registered users may post in this forum.