<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>developing Archives - Jim Dolby</title>
	<atom:link href="https://jim.dolby.id.au/tag/developing/feed" rel="self" type="application/rss+xml" />
	<link>https://jim.dolby.id.au/tag/developing</link>
	<description>A Geek and still proud of it!</description>
	<lastBuildDate>Tue, 07 Jan 2020 10:21:58 +0000</lastBuildDate>
	<language>en-AU</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
<site xmlns="com-wordpress:feed-additions:1">195341223</site>	<item>
		<title>Make PHP&#8217;s $_POST data more secure</title>
		<link>https://jim.dolby.id.au/projects/web-app-development/make-phps-post-data-more-secure.html</link>
		
		<dc:creator><![CDATA[YTS_Jim]]></dc:creator>
		<pubDate>Tue, 07 Jan 2020 08:10:03 +0000</pubDate>
				<category><![CDATA[Projects]]></category>
		<category><![CDATA[Web App Development]]></category>
		<category><![CDATA[developing]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[webapp]]></category>
		<guid isPermaLink="false">https://www.securetech.com.au/?p=213</guid>

					<description><![CDATA[<p>we are providing an alternative function to the $_GET vavriable, which returns the same data after filtering (sanitizing) it. Explainations are below, but here is the function ...</p>
<p>The post <a href="https://jim.dolby.id.au/projects/web-app-development/make-phps-post-data-more-secure.html">Make PHP&#8217;s $_POST data more secure</a> appeared first on <a href="https://jim.dolby.id.au">Jim Dolby</a>.</p>
]]></description>
										<content:encoded><![CDATA[
<p><a href="https://www.securetech.com.au/tag/php">PHP</a> is a great programming language, but it is not a framework like many of the newer &#8220;languages&#8221; and as such its basic functions are not as secure as required in a modern <a href="https://www.securetech.com.au/tag/webapp">web application</a>. Trusting PHP&#8217;s <em><strong>$_POST</strong></em> is risky but we have functions that can help make PHP&#8217;s <em><strong>$_POST</strong></em> data more secure. This is done by using a few of PHPs functions to get and filter the variable data and provide it in a somewhat more secure manor.</p>



<p>Web application security, nowadays, is quite different to when <a href="https://www.php.net/manual/en/history.php.php">PHP first started as &#8220;Personal Home Page&#8221;</a> and you need to ensure that any &#8220;web application&#8221; published is as secure as possible. Using Posted data (via <em><strong><a href="https://www.securetech.com.au/projects/make-phps-get-data-more-secure.html">$_GET</a></strong></em> or <em><strong>$_POST</strong></em>) directly without filtering is not a good idea in almost any situation. There are a few exemptions where we think this is acceptable, and we cover this below.</p>



<p>So we are providing an alternative function to the <em><strong>$_POST</strong></em> variable, which returns the same data after we make PHP&#8217;s <em><strong>$_POST</strong></em> data more secure by filtering (sanitizing) it for naughty stuff. Explanations are below, but here is the function &#8230;</p>



<h3 class="wp-block-heading">Function to make PHP&#8217;s <em><strong>$_POST</strong></em> data more secure</h3>



<pre class="wp-block-code"><code>function Input_Post($par, $parType = '')
{
	if($parType == '')
	{
		$parType = gettype($par);
	}
	$return = '';
	switch ($parType) {
		case 'email':
			$return = filter_input(INPUT_POST, $par, FILTER_SANITIZE_EMAIL);
			break;
		case 'int':
			$return = filter_input(INPUT_POST, $par, FILTER_SANITIZE_NUMBER_INT);
			break;
		case 'float':
			$return = filter_input(INPUT_POST, $par, FILTER_SANITIZE_NUMBER_FLOAT);
			break;
		case 'double':
			$return = filter_input(INPUT_POST, $par, FILTER_SANITIZE_NUMBER_FLOAT);
			break;
		case 'url':
			$return = filter_input(INPUT_POST, $par, FILTER_SANITIZE_URL);
			break;
		default: // 'string'
			$return = filter_input(INPUT_POST, $par, FILTER_SANITIZE_STRING);
			break;
	}
	if($par != $return)
	{
		//Log error to SQL and ban if more than predefined amount of errors in predefined amount of time ...
	}
	return $return;
}
</code></pre>



<h3 class="wp-block-heading">Explanation</h3>



<p>The function name should be short and succinct. we think <em><strong>input_post()</strong></em> is about as good as we need it, but you may also like <em><strong>_post()</strong></em>.</p>



<p>We also need two parameters (<em><strong>$par</strong></em> &amp; <em><strong>$parType</strong></em>) in some situations, to check for email addresses for example.</p>



<p>Next we need to make the second parameter <em><strong>$parType</strong></em> optional and check the type of the first variable (using <em><strong>gettype()</strong></em>). This is important to ensure we are providing the correct type of sanitizing and filtering of the input data so we do not filter any important data out and filter any harmful data.</p>



<p>Now comes the critical part, sanitizing any data based on the type and storing that in <em><strong>$return</strong></em> variable. </p>



<p>Using a switch (or case) is more efficient than if/elseif when dealing with many options and it just looks better.</p>



<p>Last test is if the return data <em><strong>$return</strong></em> is different to input data <em><strong>$par</strong></em> (eg, if we did any filtering / sanitizing), then we can call a logging function to ensure this is logged for auditing / banning users (we run functions that log to an SQL table and check how many failures in X days for this session footprint), but this is beyond the scope of this post.</p>



<p>Then, return the filtered data <em><strong>$return</strong></em>.</p>



<h3 class="wp-block-heading">Implementation</h3>



<p>Using STG&#8217;s <em><strong>Input_Post()</strong></em> function is as simple as replacing occurrences of:<br><em><strong>$_POST[&#8216;variable&#8217;]</strong></em><br>with<br><em><strong>Input_Post(&#8216;variable&#8217;)</strong></em></p>



<h3 class="wp-block-heading">Exceptions</h3>



<p>As stated above, there are exceptions to when you can use <em><strong>$_POST</strong></em> variables directly. We only use submitted data directly when testing, such as if it equals a value:</p>



<pre class="wp-block-code"><code>if($_POST['me'] == 'you') 
{
echo 'you';
}
elseif($_POST['me'] == 'me')
{
echo 'me';
}
else
{
echo 'you and me';
}</code></pre>



<p>Unless you make PHP&#8217;s <em><strong>$_POST</strong></em> data more secure, you should <strong><span style="text-decoration: underline;">NEVER EVER</span></strong> trust any <em><strong>$_GET</strong></em> or <em><strong>$_POST</strong></em> variable as trusting PHP&#8217;s <em><strong>$_GET</strong></em> is risky and using it directly should be avoided. We rather using submitted data to make decisions from. </p>
<p>The post <a href="https://jim.dolby.id.au/projects/web-app-development/make-phps-post-data-more-secure.html">Make PHP&#8217;s $_POST data more secure</a> appeared first on <a href="https://jim.dolby.id.au">Jim Dolby</a>.</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">213</post-id>	</item>
		<item>
		<title>Make PHP&#8217;s $_GET data more secure</title>
		<link>https://jim.dolby.id.au/projects/web-app-development/make-phps-get-data-more-secure.html</link>
		
		<dc:creator><![CDATA[YTS_Jim]]></dc:creator>
		<pubDate>Tue, 07 Jan 2020 06:16:00 +0000</pubDate>
				<category><![CDATA[Projects]]></category>
		<category><![CDATA[Web App Development]]></category>
		<category><![CDATA[developing]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[webapp]]></category>
		<guid isPermaLink="false">https://www.securetech.com.au/?p=208</guid>

					<description><![CDATA[<p>we are providing an alternative function to the $_GET vavriable, which returns the same data after filtering (sanitizing) it. Explainations are below, but here is the function ...</p>
<p>The post <a href="https://jim.dolby.id.au/projects/web-app-development/make-phps-get-data-more-secure.html">Make PHP&#8217;s $_GET data more secure</a> appeared first on <a href="https://jim.dolby.id.au">Jim Dolby</a>.</p>
]]></description>
										<content:encoded><![CDATA[
<p><a href="https://www.securetech.com.au/tag/php">PHP</a> is a great programming language, but it is not a framework like many of the newer &#8220;languages&#8221; and as such its basic functions are not as secure as required in a modern <a href="https://www.securetech.com.au/tag/webapp">web application</a>. Trusting PHP&#8217;s <em><strong>$_GET</strong></em> is risky but we have functions that can help make PHP&#8217;s <em><strong>$_GET</strong></em> data more secure. This is done by using a few of PHPs functions to get and filter the variable data and provide it in a somewhat more secure manor.</p>



<p>Web application security, nowadays, is quite different to when <a href="https://www.php.net/manual/en/history.php.php">PHP first started as &#8220;Personal Home Page&#8221;</a> and you need to ensure that any &#8220;web application&#8221; published is as secure as possible. Using Posted data (via <em><strong><a href="https://www.securetech.com.au/projects/make-phps-get-data-more-secure.html">$_GET</a></strong></em> or <em><strong>$_POST</strong></em>) directly without filtering is not a good idea in almost any situation. There are a few exemptions where we think this is acceptable, and we cover this below.</p>



<p>So we are providing an alternative function to the <em><strong>$_GET</strong></em> variable, which returns the same data after we make PHP&#8217;s <em><strong>$_GET</strong></em> data more secure by filtering (sanitizing) it for naughty stuff. Explanations are below, but here is the function &#8230;</p>



<h3 class="wp-block-heading">Function to make PHP&#8217;s <em><strong>$_GET</strong></em> data more secure</h3>



<pre class="wp-block-code"><code>function Input_Get($par, $parType = '')
{
	if($parType == '')
	{
		$parType = gettype($par);
	}
	$return = '';
	switch ($parType) {
		case 'email':
			$return = filter_input(INPUT_GET, $par, FILTER_SANITIZE_EMAIL);
			break;
		case 'int':
			$return = filter_input(INPUT_GET, $par, FILTER_SANITIZE_NUMBER_INT);
			break;
		case 'float':
			$return = filter_input(INPUT_GET, $par, FILTER_SANITIZE_NUMBER_FLOAT);
			break;
		case 'double':
			$return = filter_input(INPUT_GET, $par, FILTER_SANITIZE_NUMBER_FLOAT);
			break;
		case 'url':
			$return = filter_input(INPUT_GET, $par, FILTER_SANITIZE_URL);
			break;
		default: // 'string'
			$return = filter_input(INPUT_GET, $par, FILTER_SANITIZE_STRING);
			break;
	}
 	if($par != $return)
	{
		//Log error to SQL and ban if more than predefined amount of errors in predefined amount of time ...
	}
	return $return;
}</code></pre>



<h3 class="wp-block-heading">Explanation</h3>



<p>The function name should be short and succinct. we think <em><strong>input_get()</strong></em> is about as good as we need it, but you may also like <em><strong>_get()</strong></em>.</p>



<p>We also need two parameters (<em><strong>$par</strong></em> &amp; <em><strong>$parType</strong></em>) in some situations, to check for email addresses for example.</p>



<p>Next we need to make the second parameter <em><strong>$parType</strong></em> optional and check the type of the first variable (using <em><strong>gettype()</strong></em>). This is important to ensure we are providing the correct type of sanitizing and filtering of the input data so we do not filter any important data out and filter any harmful data.</p>



<p>Now comes the critical part, sanitizing any data based on the type and storing that in <em><strong>$return</strong></em> variable. </p>



<p>Using a switch (or case) is more efficient than if/elseif when dealing with many options and it just looks better.</p>



<p>Last test is if the return data <em><strong>$return</strong></em> is different to input data <em><strong>$par</strong></em> (eg, if we did any filtering / sanitizing), then we can call a logging function to ensure this is logged for auditing / banning users (we run functions that log to an SQL table and check how many failures in X days for this session footprint), but this is beyond the scope of this post.</p>



<p>Then, return the filtered data <em><strong>$return</strong></em>.</p>



<h3 class="wp-block-heading">Implementation</h3>



<p>Using STG&#8217;s <em><strong>Input_Get()</strong></em> function is as simple as replacing occurrences of:<br><em><strong>$_GET[&#8216;variable&#8217;]</strong></em><br>with<br><em><strong>Input_Get(&#8216;variable&#8217;)</strong></em></p>



<h3 class="wp-block-heading">Exceptions</h3>



<p>As stated above, there are exceptions to when you can use <em><strong>$_GET</strong></em> variables directly. We only use submitted data directly when testing, such as if it equals a value:</p>



<pre class="wp-block-code"><code>if($_GET&#91;'me'] == 'you') 
{
echo 'you';
}
elseif($_GET&#91;'me'] == 'me')
{
echo 'me';
}
else
{
echo 'you and me';
}</code></pre>



<p>Unless you make PHP&#8217;s <em><strong>$_GET</strong></em> data more secure, you should <strong><span style="text-decoration: underline;">NEVER EVER</span></strong> trust any <em><strong>$_GET</strong></em> or <em><strong>$_POST</strong></em> variable as trusting PHP&#8217;s <em><strong>$_GET</strong></em> is risky and using it directly should be avoided. We rather using submitted data to make decisions from. </p>
<p>The post <a href="https://jim.dolby.id.au/projects/web-app-development/make-phps-get-data-more-secure.html">Make PHP&#8217;s $_GET data more secure</a> appeared first on <a href="https://jim.dolby.id.au">Jim Dolby</a>.</p>
]]></content:encoded>
					
		
		
		<post-id xmlns="com-wordpress:feed-additions:1">208</post-id>	</item>
	</channel>
</rss>

<!--
Performance optimized by W3 Total Cache. Learn more: https://www.boldgrid.com/w3-total-cache/?utm_source=w3tc&utm_medium=footer_comment&utm_campaign=free_plugin

Page Caching using Disk: Enhanced 
Lazy Loading (feed)

Served from: jim.dolby.id.au @ 2026-05-08 16:23:03 by W3 Total Cache
-->