11 seriousness of the problem

The security breach I described is only a significant problem if you run a site that has a cookie-powered login for an administration panel – as is the case with most web based content management systems. Sites that do not use cookies in this way are not nearly as badly affected – a malicious third party could still “trick” someone by adding content to your site temporarily (through adding it to the query string and tricking someone in to visiting the site via that URL). Michel’s sanitiser is a good way of avoiding this – I tend to use PHP’s htmlentities() function for the same purpose.

posted at 07:20 pm on October 13, 2002 by Simon Willison

12 aside

Cheers, that’s a helpful article, but one little meta-gripe. It’d be nice if i could make the small text larger in ala articles by choosing View -> Text Size -> Larger [IE6/Win2002]. Jakob N would roll in his grave (if he were dead).

cheerio

posted at 07:51 pm on October 13, 2002 by Matthew Bartlett

13 This isn't working...

OK… No, I haven’t used PHP before… and this seemed like such a perfect idea since I have a client going live in two days thought wants accessibility and styleswitching. I was attempting to use this as a “no javascript” method of doing this.

I contacted my host who said that PHP was now enabled for the site… followed the directions in the tut… and ended up with a completely unstyled page. :( When trying it in Mozilla, I do see the option of “other stylesheets” and can even choose the one I have as an alternate… but not with the PHP switcher…

Has anyone been successful with this article? Is it missing anything? I even tried the code in Michel V’s post above and now I’m getting an error that says:

Warning: Cannot add header information – headers already sent by (output started at /home/sites/site171/web/testing/switcher.php:2) in /home/sites/site171/web/testing/switcher.php on line 5

Warning: Cannot add header information – headers already sent by (output started at /home/sites/site171/web/testing/switcher.php:2) in /home/sites/site171/web/testing/switcher.php on line 6

So is it hopeless? Or is there some little errata… or am I just “not getting it?” It has been a long day. :-P

posted at 08:04 pm on October 13, 2002 by Stephanie

14 More security issues

It should be mentioned that you should not:

setcookie (‘sitestyle’, $set, time()+31536000, ‘/’, ‘yourdomain.com’, ‘0’);

As was mentioned, the variable $set can be made to be anything (including bogus HTML) and that information would then be saved to the clients machine. In circumstances beyond what was discussed above, I’m not sure that this is a big deal, but you’re allowing external sites to set cookies for your site this way.

One thing that immediately popped to mind is that you should check the referer. There could be problems with proxy servers (as was mentioned), but if you check the referer to see if it is YOUR server, then you are better off. Also you may check the value of $site against some “acceptable” names like “red”, “blue”, “green” like this:

$acceptStyle = array(“red”, “blue”, “green”);
if(in_array(trim($site), $acceptStyle)){ // set the cookie here…
}

Also, in general, always use the “superglobal” variables ($_REQUEST, etc.) when getting data from users, not the variables that are automatically created through register_globals.

posted at 08:05 pm on October 13, 2002 by Rob

15 Thanks!

Thanks for the answers guys.

posted at 11:09 pm on October 13, 2002 by Marty M

16 Why not

I think it’s kind of neat to see code in the article almost identical to what I’ve done before with this. Great minds, right? In fact it gave me reason to dig out the script of the site it’s on and clean it up a bit, incorporating all the suggestions made thus far as well as more modern PHP coding techniques. Until I saw it here:
http://www.contrastsweb.com/switcher/
Again, it’s eerie how similar the code is. I’m going to start reading Rob’s blog because it’s nice to find someone who thinks similarly. I would recommend the code above, with only two minor changes based on experience I’ve had.

First, Netscape (bah!) has trouble with cookies whose domain has less than two periods in it. The nice way to fix this is to write your domain like “.example.com” (note the leading period!) which also has the nice side effect of making the cookie valid for any sub-domains you may have. Even if you don’t use sub-domains, this allows the same cookie to be used for people accessing your site through either yourdomain.com or www.yourdomain.com.

I’ve also had trouble with PHP’s built-in setcookie function, so if that’s giving you trouble, you can always fall back on using straight headers to take care of things. Such as:
header(“Set-Cookie: theme=$theme; path=/; domain=.photomatt.net; expires=”.gmstrftime(”%A, %d-%b-%Y %H:%M:%S GMT”, time()+10960000));

For more information on cookies in general, and for a little trip down memory lane, check out the original cookie specification from Netscape at http://wp.netscape.com/newsref/std/cookie_spec.html. Partly I think because of their sadly lacking version 4 release, people forget how much Netscape really expanded technology behind the web. Sometimes for better, sometimes for worse. On that same vein it’s not a flaw in PHP that allows things like injection attacks, but rather coding that doesn’t consider as many possibilities as possible. I’ve found that coding for security in turn makes my code cleaner, more maintainable, and less likely to have to be rewritten after a while. Think of it as forward compatibility on the backend :)

Meta: Could someone take a look at the regex (or whatever) is parsing the URLs for the forums? It works fine with most everything, but chokes on a few notable common URL characters.

posted at 12:40 am on October 14, 2002 by Matthew Mullenweg

17 Excuse the mess

Arg, it ate the period in the URL I posted above, here’s a clean version:
http://wp.netscape.com/newsref/std/cookie_spec.html
That’s really my fault though; I should have put a space after the URL. Maybe it would just be easier to allow just anchor tags. The web is all about links. Sanitizing for one tag should be fairly trivial as well. Another solution would be the option to preview a post, so you can tell how things are going to turn out.

posted at 12:44 am on October 14, 2002 by Matthew Mullenweg

18 Solution to a lack of $_SERVER['HTTP_REFERER']

One solution to the problem with using $_SERVER[‘HTTP_REFERER’] would be to send the current URL to switcher.php along with the stylesheet like this:

switcher.php?set=red&ref;=<?=$_SERVER[‘PHP_SELF’]?>

Then use $ref instead of $_SERVER[‘HTTP_REFERER’].

Stephanie: You get those errors when you try to call the header() function after some html has been sent to the browser. Make sure that you don’t have any content (even a single space) before your opening <?php tag. Good luck.

Simon

posted at 06:50 am on October 14, 2002 by Simon Coggins

19 cleaning input

michel v,

Any reason you’re using the regular expression instead of PHP’s built in strip_tags?

posted at 07:58 am on October 14, 2002 by Alan

20 Re: cleaning input

Alan, that’s just to ensure the script gets data that it could still use. If someone uses the evil.js method that Simon showed, strip_tags() will still put a remaining closing angle bracket as a cookie, and that can break the HTML that the page produces.
Just removing anything that’s not alphanumeric ensures that the cookie set in the evil way isn’t going to break the HTML :)

posted at 08:16 am on October 14, 2002 by michel v