Web Application Security, Part 1 - Revision history

Todd: /* Escaping Output */

2018-07-18T21:05:10Z

Escaping Output

Shane: /* Git Exposed */

2015-08-02T18:55:23Z

Git Exposed

Shane: /* Server Configurations */ Don't expose .git

2015-08-02T18:54:08Z

Server Configurations: Don't expose .git

Todd: /* Real-Life Examples */

2014-09-18T11:25:54Z

Real-Life Examples

Shane: Moving DoS to Web Application Security, Part 3

2013-09-08T17:24:00Z

Moving DoS to Web Application Security, Part 3

Shane: Moving Packet Sniffing to Web Application Security, Part 3

2013-09-08T17:20:34Z

Moving Packet Sniffing to Web Application Security, Part 3

Shane: Moving CSRF to Web Application Security, Part 2

2013-09-08T17:18:00Z

Moving CSRF to Web Application Security, Part 2

Shane: /* Escaping Input */

2013-04-23T03:56:08Z

Escaping Input

Shane: /* Introduction to Application-Level Web Security */

2013-04-22T11:01:08Z

Introduction to Application-Level Web Security

Shane: /* Cross-Site Request Forgery */ DoctypeTV

2013-03-27T05:24:07Z

Cross-Site Request Forgery: DoctypeTV

@@ Line 41: / Line 41: @@
 </source>
-The "&lt;" is an '''HTML entity''' that will render as a less-than sign.  (For more information on HTML entities, [http://docs.webplatform.org/wiki/html/entities read this article on the WebPlatform wiki].)
+The "&lt;" is an '''HTML entity''' that will render as a less-than sign.  (For more information on HTML entities,
 PHP provides a function that, given a string, will convert special characters to their HTML entity equivalents.

← Older revision		Revision as of 18:55, 2 August 2015
Line 111:		Line 111:

	[[Category:Module 2]]		[[Category:Module 2]]
−	[[Category:Web Application ~~Secur~~	+	[[Category:Web Application Security]]

@@ Line 105: / Line 105: @@
 * Use a firewall system to block unnecessary ports from public access.  SSH and Web Server should really be the only ports you need.  You should keep the web serve on port 80, but you have the option of moving SSH to a port other than 22 to make it slightly more secure.
 [[Category:Module 2]]
-[[Category:Web Application Security]]
+[[Category:Web Application Secur

@@ Line 105: / Line 105: @@
 * Use a firewall system to block unnecessary ports from public access.  SSH and Web Server should really be the only ports you need.  You should keep the web serve on port 80, but you have the option of moving SSH to a port other than 22 to make it slightly more secure.
 [[Category:Module 2]]
 [[Category:Web Application Security]]

← Older revision		Revision as of 17:24, 8 September 2013
Line 70:		Line 70:

	This is why you should ''filter'' strings at the input stage but not ''escape'' them until the final output stage.		This is why you should ''filter'' strings at the input stage but not ''escape'' them until the final output stage.
−
−	~~== Denial of Service ==~~
−
−	Denial of Service (DoS) is probably the most widely used attack vector to date, and the one employed by hacktivist groups like Anonymous. The concept is simple: flood a target server with more requests than it can possibly handle, resulting in server downtime.
−
−	A ''Distributed'' Denial of Service (DDoS) attack is a special kind of Denial of Service attack that involves multiple, unrelated machines sending requests to the server simultaneously. DDoS attacks are more powerful than "un-distributed" DoS attacks because there are dozens, hundreds, even thousands of machines, all with different IP addresses, all requesting data from your server at the same time; in DoS attacks, there is only one computer doing the attacking. Hacking groups are known to have millions of machines around the world ready to perform a DDoS attack on command. It's a very interesting topic to Google about, but beware that you might spend several hours reading web sites if you start!
−
−	~~There are two flavors that a DoS attack can take:~~
−
−	* '''Bandwidth-based:''' Saturate the connectivity link.
−	* '''Packet-based:''' Saturate the processing capability of the equipment.
−
−	~~=== Mitigating DoS Attacks ===~~
−
−	~~Unlike the other types of attacks we've discussed (or will soon be discussing), DoS attacks cannot usually be prevented by good coding practices. Here are some tips that should help:~~
−
−	* Always keep the most up-to-date software on your server and firmware on your router (if applicable).
−	* If you represent a firm with a lot of resources, '''anycast''' may be an option. Rather than having your site hosted in just one server, the load of your site will be shared between many different servers. Anycast systems are expensive, but they help fend off non-hardcore DoS attacks.
−	* You can set up a ''constellation'' of reverse proxy nodes. You might also benefit from using a web server like Nginx instead of Apache. For more information on constellation reverse proxy nodes, see: http://blog.unixy.net/2010/08/the-penultimate-guide-to-stopping-a-ddos-attack-a-new-approach/
−	* Limit things like file upload size and CGI scripts. These are known to be easy targets for DoS attacks.
−
−	~~In short, DoS attacks are not pretty, and there's not any sure-fire way to prevent them. Just do your best and hope that you don't get attacked by DoS.~~
−
−	~~=== Real-Life Examples ===~~
−
−	* [http://www.theregister.co.uk/2012/05/21/india_anonymous_cert_ddos/ Indian CERT, May 2012 (DDoS)]
−	* [http://mashable.com/2012/05/20/anonymous-hackers-police-website/ Chicago Police Department, May 2012 (DDoS)]
−	* [http://torrentfreak.com/pirate-bay-under-ddos-attack-from-unknown-enemy-120516/ Pirate Bay, May 2012 (DDoS)]

	== Format String Injection ==		== Format String Injection ==

@@ Line 125: / Line 125: @@
 echo htmlentities($_GET['username']); // good example
 </source>
 == Server Configurations ==

← Older revision		Revision as of 17:18, 8 September 2013
Line 70:		Line 70:

	This is why you should ''filter'' strings at the input stage but not ''escape'' them until the final output stage.		This is why you should ''filter'' strings at the input stage but not ''escape'' them until the final output stage.
−
−	~~== Cross-Site Request Forgery ==~~
−
−	~~{{DoctypeTV~~
−	~~\|youtube_id=3IOKaIRg8V4~~
−	~~\|time=3m45s~~
−	~~\|desc=Cross Site Request Forgeries~~
−	}}
−
−	A cross-site request forgery (CSRF, pronounced ''sea-surf'') involves a victim, who is logged in to the targeted site, visiting an attacker’s site. The attacker has code on his site that forces the victim to unwittingly perform actions on the targeted site.
−
−	~~For example, suppose Mother Goose visited Dr. Evil's blog. Dr. Evil had the following tag embedded in his bloc:~~
−
−	~~<nowiki><img src="http://www.bank.com/transfer.php?dest=dr-evil&amount=5000" /></nowiki>~~
−
−	~~This would cause Mother Goose to authorize a $5000 transfer to Dr. Evil, completely without Mother Goose's knowledge!~~
−
−	Worse yet, Dr. Evil could just send an e-mail to Mother Goose with this image tag. All Mother Goose would need to do to be attacked is open the e-mail! (Now you know why sometimes your e-mail client turns off images from suspicious sources.)
−
−	~~=== Solution ===~~
−
−	The first precautionary measure is to always use POST requests (as opposed to GET requests) for actions that change something on your server. This will fend off all except the most hard-core CSRF attacks.
−
−	However, fully preventing CSRF attacks is not difficult. To do this, you can use a '''CSRF token'''. A CSRF token is a known string of text that is submitted in all of the forms on your site. If the string is not what you expect, then you can assume that the request was forged.
−
−	~~For example, consider this form:~~
−
−	~~<source lang="html4strict">~~
−	~~<form action="transfer.php">~~
−	~~<input type="text" name="dest" />~~
−	~~<input type="number" name="amount" />~~
−	~~<input type="submit" value="Transfer" />~~
−	~~</form>~~
−	~~</source>~~
−
−	~~We can easily add a hidden CSRF token field like so (as well as making the form POST rather than GET):~~
−
−	~~<source lang="html4strict">~~
−	~~<form action="transfer.php" method="post">~~
−	~~<input type="text" name="dest" />~~
−	~~<input type="number" name="amount" />~~
−	~~<input type="hidden" name="token" value="<?php echo $_SESSION['token'];?>" />~~
−	~~<input type="submit" value="Transfer" />~~
−	~~</form>~~
−	~~</source>~~
−
−	'''This assumes that <code>$_SESSION['token']</code> contains an alphanumeric string that was randomly generated upon session creation.''' For example, you could add this line ''beneath beneath where the user successfully authenticates'':
−
−	~~<source lang="php">~~
−	~~$_SESSION['token'] = substr(md5(rand()), 0, 10); // generate a 10-character random string~~
−	~~</source>~~
−
−	~~We can now test for validity of the CSRF token on the server side (in transfer.php):~~
−
−	~~<source lang="php">~~
−	~~<?php~~
−	~~$destination_username = $_POST['dest'];~~
−	~~$amount = $_POST['amount'];~~
−	~~if($_SESSION['token'] !== $_POST['token']){~~
−	~~die("Request forgery detected");~~
−	}
−	~~$mysqli->query(/* perform transfer */);~~
−	?>
−	~~</source>~~
−
−	~~Now, if Mother Goose were to view a page containing the malicious <img/> tag, the transfer would not take place.~~
−
−	~~=== Real-Life Examples ===~~
−
−	* [http://www.zdnet.com/no-data-breach-in-first-weibo-attack-2062301014/ Weibo (the Chinese Twitter), June 2011]
−	* [http://www.huffingtonpost.com/huff-wires/20110601/us-tec-google-hacking-attack/ Gmail, June 2011]
−	* [http://www.pcworld.com/businesscenter/article/228609/hackers_steal_hotmail_messages_thanks_to_web_flaw.html Hotmail, May 2011]
−	* [http://www.theregister.co.uk/2010/05/19/facebook_private_data_leak/ Facebook, May 2010]

	== Denial of Service ==		== Denial of Service ==

@@ Line 56: / Line 56: @@
 '''Note:''' ''htmlentities'' escapes a string for use in HTML, but it does ''not'' escape a string for use in other markup languages.  You need to use different methods when escaping strings for other languages.
-=== Escaping Input ===
+=== Why Not to Escape Input ===
 Filtering your input is important, as shown above.  However, it is bad practice to ''escape'' your input.  For example, don't do this:

← Older revision		Revision as of 11:01, 22 April 2013
Line 10:		Line 10:

	Here's the golden rule: Anything in your site that accepts user input, whether via a form, an AJAX request, a file upload, or even malformed links, can be used as an attack vector. '''NEVER TRUST USER INPUT!!!''' This can be summarized in the acronym FIEO, or ''Filter Input, Escape Output''.		Here's the golden rule: Anything in your site that accepts user input, whether via a form, an AJAX request, a file upload, or even malformed links, can be used as an attack vector. '''NEVER TRUST USER INPUT!!!''' This can be summarized in the acronym FIEO, or ''Filter Input, Escape Output''.
		+
		+	=== FIEO in PHP ===
		+
		+	==== Filtering Input ====
		+
		+	"Filter Input" means that you should check that input data is of the format that you are expecting. For example, if you are expecting a number, you should cast it to a float or an int. If you are expecting a phone number, you should run it through a regular expression (you will learn regular expressions in module 4). For example:
		+
		+	<source lang="PHP">
		+	<?php
		+	// Cast a number to a float or an int:
		+	$amount = (float) $_POST['amount'];
		+
		+	// Pass a phone number through a regular expression:
		+	$phone = preg_match('/\d{3}-\d{3}-\d{4}/', $_POST['phone']) ? $_POST['phone'] : "";
		+	?>
		+	</source>
		+
		+	==== Escaping Output ====
		+
		+	"Escape Output" means that you need to nullify, or ''escape'', characters that have special meaning in the markup language of interest. For example, consider the following string:
		+
		+	<source lang="html4strict">
		+	If a<b and b<c then a<c.
		+	</source>
		+
		+	Since a less-than sign means the start of a tag in HTML, and '''b''' is a valid tag name, the above string will ''not'' render as you might expect in HTML. Therefore, we need to ''escape'' our less-than signs by using HTML entities:
		+
		+	<source lang="html4strict">
		+	If a<b and b<c then a<c.
		+	</source>
		+
		+	The "<" is an '''HTML entity''' that will render as a less-than sign. (For more information on HTML entities, [http://docs.webplatform.org/wiki/html/entities read this article on the WebPlatform wiki].)
		+
		+	PHP provides a function that, given a string, will convert special characters to their HTML entity equivalents.
		+
		+	<source lang="PHP">
		+	<?php
		+	$str = "If a<b and b<c then a<c.";
		+
		+	// Convert special characters to HTML entities before outputting:
		+	echo htmlentities($str);
		+	?>
		+	</source>
		+
		+	'''Note:''' ''htmlentities'' escapes a string for use in HTML, but it does ''not'' escape a string for use in other markup languages. You need to use different methods when escaping strings for other languages.
		+
		+	=== Escaping Input ===
		+
		+	Filtering your input is important, as shown above. However, it is bad practice to ''escape'' your input. For example, don't do this:
		+
		+	<source lang="PHP">
		+	<?php
		+	$message = htmlentites($_POST['amount']); // bad practice
		+	// then store $message in a database, etc.
		+	?>
		+	</source>
		+
		+	The reason this is bad practice is that it permanently ties that string to its final output format. For example, what if some time down the road you want to support display of that message in a PDF? You'd need to go back and remove all the HTML entities again.
		+
		+	This is why you should ''filter'' strings at the input stage but not ''escape'' them until the final output stage.

	== Cross-Site Request Forgery ==		== Cross-Site Request Forgery ==

← Older revision		Revision as of 05:24, 27 March 2013
Line 12:		Line 12:

	== Cross-Site Request Forgery ==		== Cross-Site Request Forgery ==
		+
		+	{{DoctypeTV
		+	\|youtube_id=3IOKaIRg8V4
		+	\|time=3m45s
		+	\|desc=Cross Site Request Forgeries
		+	}}

	A cross-site request forgery (CSRF, pronounced ''sea-surf'') involves a victim, who is logged in to the targeted site, visiting an attacker’s site. The attacker has code on his site that forces the victim to unwittingly perform actions on the targeted site.		A cross-site request forgery (CSRF, pronounced ''sea-surf'') involves a victim, who is logged in to the targeted site, visiting an attacker’s site. The attacker has code on his site that forces the victim to unwittingly perform actions on the targeted site.