<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: PHP function to Redirect a user with a message</title>
	<atom:link href="http://xavisys.com/php-function-to-redirect-a-user-with-a-message/feed/" rel="self" type="application/rss+xml" />
	<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/</link>
	<description>Control Your Internet</description>
	<pubDate>Sat, 10 May 2008 18:00:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Aaron D. Campbell</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-502</link>
		<dc:creator>Aaron D. Campbell</dc:creator>
		<pubDate>Thu, 12 Jul 2007 13:52:46 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-502</guid>
		<description>&lt;blockquote&gt;&lt;strong&gt;Session poisoning&lt;/strong&gt; (also referred to as "Session data pollution" and "Session modification") is to exploit insufficient input validation in server applications which copies user input into session variables.&lt;/blockquote&gt;

&lt;p&gt;I'm often guilty of forgetting some of the things that can cause these kinds of problems.  Chalk it up to being spoiled.  I work with custom written software (mine) on dedicated Rackspace servers.  However, there are a few ways that you can cause session poisoning.&lt;/p&gt;
&lt;p&gt;First, you can insufficiently validate content that you store in it.  To fix this, simply be careful about what you put in it, making sure it is what you mean to put there.  Don't assume a user put a number into the "total cost" field.  Assume your users are malicious.&lt;/p&gt;
&lt;p&gt;Secondly, you could have scripts or applications that use overlapping session variables.  I see this as a worse possibility because "joe no coder" could download and install two conflicting scripts without even knowing it.  To solve this, check out the applications you are using.  If you can't understand the code, at LEAST do some serious research.&lt;/p&gt;
&lt;p&gt;Lastly, you could have a poorly configured shared server.  Again, this is dangerous because people often don't have control over this.  Again, however, research is your friend.  Please like &lt;a href="http://www.webhostingtalk.com/" rel="nofollow" onclick=""&gt;Web Hosting Talk&lt;/a&gt; often have hundreds of reviews on hosts.&lt;/p&gt;

&lt;p&gt;Jem: this isn't aimed at you.  This is aimed at filling in the gaps in the article above, for the users that need it.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<blockquote><p><strong>Session poisoning</strong> (also referred to as &#8220;Session data pollution&#8221; and &#8220;Session modification&#8221;) is to exploit insufficient input validation in server applications which copies user input into session variables.</p></blockquote>
<p>I&#8217;m often guilty of forgetting some of the things that can cause these kinds of problems.  Chalk it up to being spoiled.  I work with custom written software (mine) on dedicated Rackspace servers.  However, there are a few ways that you can cause session poisoning.</p>
<p>First, you can insufficiently validate content that you store in it.  To fix this, simply be careful about what you put in it, making sure it is what you mean to put there.  Don&#8217;t assume a user put a number into the &#8220;total cost&#8221; field.  Assume your users are malicious.</p>
<p>Secondly, you could have scripts or applications that use overlapping session variables.  I see this as a worse possibility because &#8220;joe no coder&#8221; could download and install two conflicting scripts without even knowing it.  To solve this, check out the applications you are using.  If you can&#8217;t understand the code, at LEAST do some serious research.</p>
<p>Lastly, you could have a poorly configured shared server.  Again, this is dangerous because people often don&#8217;t have control over this.  Again, however, research is your friend.  Please like <a href="http://www.webhostingtalk.com/" rel="nofollow" onclick="pageTracker._trackPageview('/outgoing/www.webhostingtalk.com/?referer=');">Web Hosting Talk</a> often have hundreds of reviews on hosts.</p>
<p>Jem: this isn&#8217;t aimed at you.  This is aimed at filling in the gaps in the article above, for the users that need it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jem</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-496</link>
		<dc:creator>Jem</dc:creator>
		<pubDate>Thu, 12 Jul 2007 09:18:16 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-496</guid>
		<description>&lt;p&gt;I hope you didn't type all that out for my benefit :p&lt;/p&gt;
&lt;p&gt;"However, if you simply don’t put bad data in, you won’t get bad data out." - obviously only an idiot do that, but that doesn't cover the risks of sessions on badly configured shared hosting coupled with possibility of session poisoning (I only realised it had it's own term last night, hehe): http://en.wikipedia.org/wiki/Session_poisoning&lt;/p&gt;
&lt;p&gt;A shared host user manipulates the session and then calls it using using $_GET? Sounds perfectly feasible to me. &lt;/p&gt;
&lt;p&gt;Call me paranoid but I would say ALWAYS sanitise, rather than simply "when in doubt". Better safe than sorry, no?&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>I hope you didn&#8217;t type all that out for my benefit :p</p>
<p>&#8220;However, if you simply don’t put bad data in, you won’t get bad data out.&#8221; - obviously only an idiot do that, but that doesn&#8217;t cover the risks of sessions on badly configured shared hosting coupled with possibility of session poisoning (I only realised it had it&#8217;s own term last night, hehe): <a href="http://en.wikipedia.org/wiki/Session_poisoning" rel="nofollow" onclick="pageTracker._trackPageview('/outgoing/en.wikipedia.org/wiki/Session_poisoning?referer=');">http://en.wikipedia.org/wiki/Session_poisoning</a></p>
<p>A shared host user manipulates the session and then calls it using using $_GET? Sounds perfectly feasible to me. </p>
<p>Call me paranoid but I would say ALWAYS sanitise, rather than simply &#8220;when in doubt&#8221;. Better safe than sorry, no?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron D. Campbell</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-501</link>
		<dc:creator>Aaron D. Campbell</dc:creator>
		<pubDate>Wed, 11 Jul 2007 19:32:17 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-501</guid>
		<description>Having said all that, when in doubt...SANITIZE!</description>
		<content:encoded><![CDATA[<p>Having said all that, when in doubt&#8230;SANITIZE!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron D. Campbell</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-500</link>
		<dc:creator>Aaron D. Campbell</dc:creator>
		<pubDate>Wed, 11 Jul 2007 19:31:55 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-500</guid>
		<description>$_SESSION isn't really "unsanitary" ...it only contains what you put in it.  Think of all your variables (specifically all the superglobals in this case) as lockers that you store stuff in.  $_GET, $_POST, $_REQUEST, and $_COOKIE have no lock on them, so anyone (your users) can put stuff in them.  They are UNSAFE, and should be sanitized thoroughly.  $_SERVER is a two part locker, the top has no lock, and the bottom does.  Things like PHP_SELF can contain undesired user input (read &lt;a href="http://blog.phpdoc.info/archives/13-XSS-Woes.html" rel="nofollow" onclick=""&gt;XSS Woes&lt;/a&gt; over at &lt;a href="http://blog.phpdoc.info/" rel="nofollow" onclick=""&gt;PeeaycHPee&lt;/a&gt;).  Those also need to be sanitized.  However, the $_SESSION locker has a lock, and only contains what you put in there.  If you dump stuff from another area in there without looking at it, it COULD contain dangerous data.  However, if you simply don't put bad data in, you won't get bad data out.</description>
		<content:encoded><![CDATA[<p>$_SESSION isn&#8217;t really &#8220;unsanitary&#8221; &#8230;it only contains what you put in it.  Think of all your variables (specifically all the superglobals in this case) as lockers that you store stuff in.  $_GET, $_POST, $_REQUEST, and $_COOKIE have no lock on them, so anyone (your users) can put stuff in them.  They are UNSAFE, and should be sanitized thoroughly.  $_SERVER is a two part locker, the top has no lock, and the bottom does.  Things like PHP_SELF can contain undesired user input (read <a href="http://blog.phpdoc.info/archives/13-XSS-Woes.html" rel="nofollow" onclick="pageTracker._trackPageview('/outgoing/blog.phpdoc.info/archives/13-XSS-Woes.html?referer=');">XSS Woes</a> over at <a href="http://blog.phpdoc.info/" rel="nofollow" onclick="pageTracker._trackPageview('/outgoing/blog.phpdoc.info/?referer=');">PeeaycHPee</a>).  Those also need to be sanitized.  However, the $_SESSION locker has a lock, and only contains what you put in there.  If you dump stuff from another area in there without looking at it, it COULD contain dangerous data.  However, if you simply don&#8217;t put bad data in, you won&#8217;t get bad data out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jem</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-499</link>
		<dc:creator>Jem</dc:creator>
		<pubDate>Wed, 11 Jul 2007 18:53:10 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-499</guid>
		<description>I replied to your email with the correction to my above comment; I can only blame a long day and a lack of coffee for my typing $_GET instead of $_SESSION! 0:)</description>
		<content:encoded><![CDATA[<p>I replied to your email with the correction to my above comment; I can only blame a long day and a lack of coffee for my typing $_GET instead of $_SESSION! 0:)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron D. Campbell</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-498</link>
		<dc:creator>Aaron D. Campbell</dc:creator>
		<pubDate>Wed, 11 Jul 2007 18:32:17 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-498</guid>
		<description>I'm never echoing $_GET data to the browser.  I use a $_GET variable as a key to access and echo a value stored in the session, and I redirect to the current page (using all the current $_GET variables), but I don't echo them to the browser.</description>
		<content:encoded><![CDATA[<p>I&#8217;m never echoing $_GET data to the browser.  I use a $_GET variable as a key to access and echo a value stored in the session, and I redirect to the current page (using all the current $_GET variables), but I don&#8217;t echo them to the browser.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jem</title>
		<link>http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-497</link>
		<dc:creator>Jem</dc:creator>
		<pubDate>Wed, 11 Jul 2007 18:26:19 +0000</pubDate>
		<guid isPermaLink="false">http://xavisys.com/php-function-to-redirect-a-user-with-a-message/#comment-497</guid>
		<description>What, no mention of the security risks behind echoing unsanitised $_GET contents back to the browser? Tut tut :p</description>
		<content:encoded><![CDATA[<p>What, no mention of the security risks behind echoing unsanitised $_GET contents back to the browser? Tut tut :p</p>
]]></content:encoded>
	</item>
</channel>
</rss>
