Stop cookie spoof

[jaymc]

How can I stop cookie spoofing?

 

As in... using PHP's setcookie I set cookies to remember a users login..

 

However, for instance putting this into the address bar javascript:alert(document.cookie) reveals the cookie for the website they are on

 

If someone uses http://tinyurl.com and sets up some code as demonstrated above, its not hard for them to get their cookie details and in turn login as them as they have their cookie info!

 

How can I protect my self from this?

[limitphp]

I might be confused as to what your talking about, but doesn't the user take some responsibility also?

If they are on a public computer.....shouldn't they click "logout" or something to make sure the cookie gets deleted?

 

 

[revraz]

Maybe choose what you store in the cookie?  Like not their PW and UserId? 

[Maq]

Maybe choose what you store in the cookie?  Like not their PW and UserId? 

 

Then how are you supposed to remember a users login?  You should encrypt the information in your cookie.

[jaymc]

Ok, I found out how there where doing it..

 

Its odd they where getting cookie details as document.cookie etc will only return there cookie for the website they are on

 

Hence.. they must have been injecting code on my website for it to execute

 

www.website.com/page.php?username=john&age=<script url=www.external.com/java.js></script>

 

Then on my page if I had

 

echo $_GET['username'].$_GET['age']

 

There code was injected and executed!

 

Ive got around this using strip_tags to kill all HTML and Java code etc..

 

Is this strong enough?

[thebadbad]

But only the user can see the content of the cookie. And you can't hide a javascript call in a TinyURL. What you are thinking about, I guess, is a XSS (cross-site scripting) attack, where a vulnerable site can send cookie information to another site, if a user e.g. access

 

http://example.com/?search=[javascript here, sending cookie information to the hacker's site]

 

and example.com prints $_GET['search'] directly on the page, without sanitizing it. But that will only work for the 'hacker' if your site is vulnerable to that kind of an attack, e.g. if it outputs unsanitized user input.

 

Edit: I see you discovered that yourself.

[revraz]

Why do you feel you must store this info in a cookie is a better question.

 

Why can't you use a Authorization code and compare it to another key that isn't their UserID/PW? 

 

You can make a cookie authentication scheme different than a normal user login screen, they don't have to be the same.  That way if cookie info is gathered, it can't be used to log in manually.

 

Maybe choose what you store in the cookie?  Like not their PW and UserId? 

 

Then how are you supposed to remember a users login?  You should encrypt the information in your cookie.

[thebadbad]

You can use htmlentities() to display data instead of rendering it (if it's code).

[jaymc]

You can use htmlentities() to display data instead of rendering it (if it's code).

Yeh I was thinking that, however I have an issue with that too!

 

If someone wanted to put this as there name

 

I <3 cheese

 

And the char limit in the database is 11 chars... after the < is converted to entity it will display as <

 

Hence, I <3 cheese will not fit in the database

 

Thats the only issue I have with entities, any more ideas?

[thebadbad]

Simple. Save the data as is in the database (but remember mysql_real_escape_string()), and when displaying the data, run it through htmlentities().

[limitphp]

Why do you feel you must store this info in a cookie is a better question.

 

I think the problem here is that alot of people (including myself) don't know how we should logically build a login authentication system.  And so, we are asking questions about specifics in our code, but how we designed it in the first place might be really flawed, and so people get frustrated and ask why we did it like that in the first place, and we're not really sure because we are still trying to figure it all out.

 

My answer to this, is to first understand that there probably is a right way, pretty much a standard, as to how a login authentication should be built.  This page or system really should be posted somewhere and used as a standard.  There's really no reason to deviate from a standard method of doing something like building a login authentication system.  Deviating usually leads to all the confusion on both sides.

 

From talking to everyone on this forum, this is pretty much what I came up with as to how to handle login authenticiation systems:

http://www.phpfreaks.com/forums/index.php/topic,225392.msg1038791.html#msg1038791

 

Although, I am not using sessions because I wanted to have a "remember me" checkbox.  And from what I am told building your own custom session handler is the way to go about this.  Doing that was too complicated for me. But my solution seems to be secure and doesn't seem to contain any flaws that I know about.....of course, I am pretty wet behind the ears compared to most people here, though.

 

my 2 cents

[jaymc]

Simple. Save the data as is in the database (but remember mysql_real_escape_string()), and when displaying the data, run it through htmlentities().

Hmm, is there another option to do this altogether as htmlentities() will need to be added numerous times on over 500 pages....

[KevinM1]

Ok, I found out how there where doing it..

 

Its odd they where getting cookie details as document.cookie etc will only return there cookie for the website they are on

 

Hence.. they must have been injecting code on my website for it to execute

 

www.website.com/page.php?username=john&age=<script url=www.external.com/java.js></script>

 

Then on my page if I had

 

echo $_GET['username'].$_GET['age']

 

There code was injected and executed!

 

Ive got around this using strip_tags to kill all HTML and Java code etc..

 

Is this strong enough?

 

Strip_tags is good, but why aren't you validating incoming data?  I mean, an age shouldn't have the possible value of "My cat's breath smells like cat food."  It should simply be an integer.

[jaymc]

That was just an example, its not used for age

[jaymc]

I can apply validation easily by using array_map on $_POST and $_GET

[premiso]

That was just an example, its not used for age

 

If you ask me, you should know just about all the data coming into your site, with the exception of a site that uses templates/massive text.

 

But by knowing what is allowed and what is not you should be able to validate everything easily. Age should be an int, a username should only contain certain characters and have a min length, a password should be whatever as long as it is a certain length cause it should be md5 hashed. A text box, if it is not used for html purposes should not contain any html tags, etc.

 

I would also only grab data I expect. I never just loop through the get and post because someone can easily tack on what they want and it could potentially hurt the site. If these steps are taken you should not have any issues with XSS exploits.

 

If you do run a blog site with templates where a user can modify the code, I usually check for document.cookie and other misc. javascript XSS exploits and if it is there (even if included from another website I read in that file and keep following and checking) I tell the user that is not allowed.

 

I actually created a script that will read an off-site js file and if it has the document.cookie spread out between variables, it gathers all those variables and applys them like the script does and if that equals the document.cookie or non-allowed code than I disallow it.

 

If I can find that script I will post it here, but yea. =)

[jaymc]

Cool

 

Thanks.

[revraz]

Logic and security are two different things.  Things can be logically coded, but is it secure?

 

I gave my opinions and people commented on my statements, I then replied to their statements, not yours.  That is the purpose of a Quote in a post, to see what the Reply was in reply to.

 

There is no "right way", "common way", "standard way" of how people build their sites.  Everyone takes what they learn and applies it how they see fit.

 

And you can have Sessions along with a "Remember Me" cookie.

 

Why do you feel you must store this info in a cookie is a better question.

 

I think the problem here is that alot of people (including myself) don't know how we should logically build a login authentication system.  And so, we are asking questions about specifics in our code, but how we designed it in the first place might be really flawed, and so people get frustrated and ask why we did it like that in the first place, and we're not really sure because we are still trying to figure it all out.

 

My answer to this, is to first understand that there probably is a right way, pretty much a standard, as to how a login authentication should be built.  This page or system really should be posted somewhere and used as a standard.  There's really no reason to deviate from a standard method of doing something like building a login authentication system.  Deviating usually leads to all the confusion on both sides.

 

From talking to everyone on this forum, this is pretty much what I came up with as to how to handle login authenticiation systems:

http://www.phpfreaks.com/forums/index.php/topic,225392.msg1038791.html#msg1038791

 

Although, I am not using sessions because I wanted to have a "remember me" checkbox.  And from what I am told building your own custom session handler is the way to go about this.  Doing that was too complicated for me. But my solution seems to be secure and doesn't seem to contain any flaws that I know about.....of course, I am pretty wet behind the ears compared to most people here, though.

 

my 2 cents

[premiso]

Below is the code I used. The main downside is if a user is using a free stats counter/tracker that uses javascript/image this may flag it up as being bad. Other than that this will check all content, the javascript page and any page it includes/redirects to for bad stuff.  I know it is not the prettiest code in the world, nor the most efficient but it works.

 

You may have errors as this was in a class of mine, so I tried my best to weed out the class variables but hopefully it just works. Questions let me know.

 

<?php
/**
 * Checks the given content for any type of bad javascript.
 * returns an error message if it is bad content or
 * returns false if the content is fine.
 */
function jsSpamCheck($content) {
	$content = strtolower(stripslashes($content));
	if (ereg("script", $content)) {
        $javaScriptArr = split('<script', $content);

        foreach ($javaScriptArr as $key => $val) {
			list($val) = split('</script>', $val);

			if (ereg("src=", $val)) {
					list($url) = split(">", $val);
				if (!ereg("src=", $url)) {
					continue;
				}

				list(,$url) = split("src=", $val);


				if (ereg("language=", $url)) {

				}elseif (ereg("type=", $url)) {

				}

				$url = str_replace('"', "", $url);
				$url = str_replace("'", "", $url);
				$url = str_replace(">", "", $url);
				$url = trim($url);

				if (checkURL($url)) {
                    return "You have tried to use disallowed javascript code. We do not allow cookie access or any type of redirects on this site.";
				}
			}elseif (ereg("eval", $val)) {
				list($javaScript, $evalList) = split("eval", $val);

                $jsTags = split('";', $javaScript);
                foreach ($jsTags as $jsKey => $jsVal) {
					list($jsName, $jsValue) = split('="', $jsVal);
                    $jsName = ereg_replace('var ', '', $jsName);
                    $jsName = ereg_replace(" \n", '', $jsName);
                    if (trim($jsName) != "") {
						$jsEval[trim($jsName)] = $jsValue;
                    }
                }

				$evalList = ereg_replace("\(", "", $evalList);
                $evalList = ereg_replace(");", "", $evalList);
                $evalKeys = split("\+", $evalList);
                
				foreach ($evalKeys as $key => $val) {
					$jsOutput .= $jsEval[$val];
                }

                if (ereg("dow.locat", $jsOutput)) {
                    return "You have tried to use disallowed javascript code. We do not allow cookie access or any type of redirects on this site.";
                }
			}
		}

		return false;
	}
}

/**
 * Checks the given url for any type of redirection spam.
 * returns true if it does redirect and false if it does not.
 * this is a recursive function.
 */
function checkURL($url) {
	$file = @file_get_contents($url);
	$file = strtolower($file);
	if (ereg("location.href=", $file) || ereg("location.replace\(", $file)) {
		return true;
	}elseif (ereg("src=", $file)) {
		list(,$newURL) = split('http://', $file);
		if (ereg("'", $newURL)) {
			$splitAt = '\'';			
		}else {
			$splitAt = "\"";
		}

		list($newURL) = split($splitAt, $newURL);

		return checkURL("http://" . $newURL);
	}

	return false;
}
?>

[limitphp]

Logic and security are two different things.  Things can be logically coded, but is it secure?

 

I gave my opinions and people commented on my statements, I then replied to their statements, not yours.  That is the purpose of a Quote in a post, to see what the Reply was in reply to.

 

There is no "right way", "common way", "standard way" of how people build their sites.  Everyone takes what they learn and applies it how they see fit.

 

And you can have Sessions along with a "Remember Me" cookie.

 

 

I apologize if I came across as criticizing your post.  That wasn't my intention.

I was trying to point out the fact that there seems to be alot of confusion about how to do a login authentication system with newer users like myself. 

I wish there was a standard way to do a login authentication system.  To be logically built, to me, also means it would be secure.

Then, newbies, like myself could just use that standard way of doing it.

 

Its like saying....there's no standard way of adding 4 + 4.....people take what they learn about math and apply different approaches to the problem.....

you could add 1 four times and multiply it by two, you could add 2 + 2 and multiply that by two, etc.....

 

or you could just add 4+4......the standard de facto way of doing it.

 

 

 

[revraz]

You'll quickly find out, there will be a ton of ways to do even the most simple things.  This is pretty much the same with every language I've used.