Top 10 2007-Broken Authentication and Session Management - Revision history

Wichers at 02:44, 19 April 2010

2010-04-19T02:44:31Z

Husky: Removing vandalism

2009-05-26T14:02:53Z

Removing vandalism

Deleted user at 12:04, 26 May 2009

2009-05-26T12:04:01Z

Deleted user at 15:20, 22 May 2009

2009-05-22T15:20:57Z

SteveChristey: /* References */ fixed typo in CWE ID - 301, not 311

2008-08-26T05:01:16Z

‎References: fixed typo in CWE ID - 301, not 311

Dan Harkless: RSNAKE01 article does not talk about sending secrets to email addresses--it talks about not trusting IP addresses. Added RSNAKE02 that's presumably the intended article. Also fixed "RSNAKE01RSnake01".

2008-01-03T10:36:26Z

RSNAKE01 article does not talk about sending secrets to email addresses--it talks about not trusting IP addresses. Added RSNAKE02 that's presumably the intended article. Also fixed "RSNAKE01RSnake01".

Agocke: /* References */

2007-06-26T18:19:47Z

‎References

Agocke at 18:19, 26 June 2007

2007-06-26T18:19:16Z

Neil Smithline at 04:04, 15 May 2007

2007-05-15T04:04:03Z

Neil Smithline at 00:52, 14 May 2007

2007-05-14T00:52:02Z

← Older revision		Revision as of 02:44, 19 April 2010
Line 60:		Line 60:
	*RSNAKE02 - http://ha.ckers.org/blog/20061109/email-as-half-factor-authentication		*RSNAKE02 - http://ha.ckers.org/blog/20061109/email-as-half-factor-authentication

		+	{{Top_10_2007:BottomTemplate\|usenext=NextLink\|next=-Insecure Cryptographic Storage\|useprev=PrevLink\|prev=-Information Leakage and Improper Error Handling\|usemain=MainLink\|main=}}

−	~~{{Top_10_2007~~:~~BottomTemplate\|usenext=NextLink\|next=-Insecure Cryptographic Storage\|useprev=PrevLink\|prev=-Information Leakage and Improper Error Handling\|usemain=MainLink\|main=}}~~	+	[[Category:OWASP Top Ten Project]]

← Older revision		Revision as of 14:02, 26 May 2009
Line 1:		Line 1:
−	~~[http://s1.shard.jp/galeach/new189.html asian ezine~~
−	~~] [http://s1.shard.jp/olharder/autosurf-site.html auto diego part san used~~
−	~~] [http://s1.shard.jp/losaul/alloys-australian.html alloys australian money coins] [http://s1.shard.jp/bireba/download-norton.html antivirus free trial download~~
−	~~] [http://s1.shard.jp/olharder/44-auto-trader-nz.html 900 auto part saab~~
−	~~] [http://s1.shard.jp/galeach/new151.html infinite limit asian love lyrics~~
−	~~] [http://s1.shard.jp/olharder/3-auto-geneva.html automotive trim screws~~
−	~~] [http://s1.shard.jp/bireba/kaspersky-antivirus.html avg antivirus key generator~~
−	~~] [http://s1.shard.jp/olharder/1-44961stepsystemcom.html autocratic country government~~
−	~~] [http://s1.shard.jp/frhorton/lpujl5mms.html parrots african grey~~
−	~~] [http://s1.shard.jp/galeach/new57.html multiple endocrine neoplasia type ii~~
−	~~] [http://s1.shard.jp/olharder/value-of-groucho.html auto baby monitor~~
−	~~] [http://s1.shard.jp/frhorton/y8fj1syi7.html star news paper in south africa~~
−	~~] [http://s1.shard.jp/olharder/autoroll-654.html links] [http://s1.shard.jp/olharder/autoroll-654.html webmap] [http://s1.shard.jp/frhorton/mxbohv5lf.html national olympic committee south africa~~
−	~~] [http://s1.shard.jp/bireba/install-software.html antivirus for worms~~
−	~~] [http://s1.shard.jp/galeach/new171.html asian fashion magazine~~
−	~~] [http://s1.shard.jp/galeach/new49.html world war 2 in asia~~
−	~~] [http://s1.shard.jp/olharder/autoroll-654.html domain] [http://s1.shard.jp/galeach/new161.html anastasia tilbury~~
−	~~] [http://s1.shard.jp/bireba/antivirus-check.html norton antivirus keygen download~~
−	~~] [http://s1.shard.jp/losaul/1999-australian.html air australia conditioning policy refrigeration~~
−	~~] [http://s1.shard.jp/bireba/download-antivirus.html nod32 antivirus download free~~
−	~~] [http://s1.shard.jp/bireba/avast-antivirus.html norton antivirus free download full version~~
−	~~] [http://s1.shard.jp/galeach/new154.html asian groups.msn.com site woman~~
−	~~] [http://s1.shard.jp/losaul/seven-nightclub.html teaching hospitals australia~~
−	~~] [http://s1.shard.jp/losaul/police-federation.html gove australia map~~
−	~~] [http://s1.shard.jp/losaul/tenders-australian.html average weekly earnings australia~~
−	~~] [http://s1.shard.jp/olharder/auto-calculator.html bales automotive~~
−	~~] [http://s1.shard.jp/frhorton/glos5k8jt.html 4th south african infantry regiment~~
−	~~] [http://s1.shard.jp/galeach/new15.html tight little asians~~
−	~~] [http://s1.shard.jp/galeach/new158.html asian man and white woman~~
−	~~] [http://s1.shard.jp/losaul/used-car-price.html sydney australia suburbs map~~
−	~~] [http://s1.shard.jp/galeach/new27.html asian anorexic~~
−	~~] [http://s1.shard.jp/olharder/audi-automotive.html b and d auto lincoln~~
−	~~] [http://s1.shard.jp/frhorton/3otvgvzdn.html south african drummer music music~~
−	~~] [http://s1.shard.jp/olharder/autoroll-654.html domain] [http://s1.shard.jp/losaul/emmigrating-australia.html australia gyms home~~
−	~~] [http://s1.shard.jp/olharder/autoroll-654.html url] [http://s1.shard.jp/frhorton/9df15nbui.html african writer series~~
−	~~] [http://s1.shard.jp/bireba/5-antivirus.html e trust antivirus free download~~
−	~~] [http://s1.shard.jp/bireba/computer-antivirus.html avg antivirus new~~
−	~~] [http://s1.shard.jp/galeach/new63.html beuthanasia d~~
−	~~] [http://s1.shard.jp/bireba/panda-online-antivirus.html download keygen norton antivirus 2005~~
−	~~] [http://s1.shard.jp/losaul/travel-shows-in.html department of immigration australia~~
−	~~] [http://s1.shard.jp/galeach/new196.html pictures of the money of asia~~
−	~~] [http://s1.shard.jp/frhorton/z7u5veip8.html a map of east africa~~
−	~~] [http://s1.shard.jp/galeach/new187.html bird flue asia~~
−	~~] [http://s1.shard.jp/olharder/concession-auto.html autocad 2004 serial numbers~~
−	]
−	~~http://www.textbasdardomc.com~~
	{{Top_10_2007:TopTemplate\|usenext=NextLink\|next=-Insecure Cryptographic Storage\|useprev=PrevLink\|prev=-Information Leakage and Improper Error Handling\|usemain=MainLink\|main=}}		{{Top_10_2007:TopTemplate\|usenext=NextLink\|next=-Insecure Cryptographic Storage\|useprev=PrevLink\|prev=-Information Leakage and Improper Error Handling\|usemain=MainLink\|main=}}
−

	Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.		Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.

@@ Line 1: / Line 1: @@
 http://www.textbasdardomc.com
 {{Top_10_2007:TopTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}
@@ Line 23: / Line 68: @@
 == Protection ==
-Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 â Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 â Insecure Cryptographic Storage).
+Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 Ã¢ÂÂ Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 Ã¢ÂÂ Insecure Cryptographic Storage).
 Preventing authentication flaws takes careful planning. Among the most important considerations are:
@@ Line 36: / Line 81: @@
 *'''Use a timeout period''' that automatically logs out an inactive session as per the value of the data being protected (shorter is always better).
 *'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. Apply a one-One way hash to answers to prevent disclosure attacks.
-*'''Do not expose any session identifiers or any portion of valid credentials in URLs or logs (no session rewriting or storing the userâs password in log files)'''
+*'''Do not expose any session identifiers or any portion of valid credentials in URLs or logs (no session rewriting or storing the userÃ¢ÂÂs password in log files)'''
 *'''Check the old password when the user changes to a new password'''
 *'''Do not rely upon spoofable credentials as the sole form of authentication''', such as IP addresses or address range masks, DNS  or reverse DNS lookups, referrer headers or similar''' '''

@@ Line 1: / Line 1: @@
 {{Top_10_2007:TopTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}
@@ Line 22: / Line 23: @@
 == Protection ==
-Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 – Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 – Insecure Cryptographic Storage).
+Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 â Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 â Insecure Cryptographic Storage).
 Preventing authentication flaws takes careful planning. Among the most important considerations are:
@@ Line 35: / Line 36: @@
 *'''Use a timeout period''' that automatically logs out an inactive session as per the value of the data being protected (shorter is always better).
 *'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. Apply a one-One way hash to answers to prevent disclosure attacks.
-*'''Do not expose any session identifiers or any portion of valid credentials in URLs or logs (no session rewriting or storing the user’s password in log files)'''
+*'''Do not expose any session identifiers or any portion of valid credentials in URLs or logs (no session rewriting or storing the userâs password in log files)'''
 *'''Check the old password when the user changes to a new password'''
 *'''Do not rely upon spoofable credentials as the sole form of authentication''', such as IP addresses or address range masks, DNS  or reverse DNS lookups, referrer headers or similar''' '''

@@ Line 53: / Line 53: @@
 == References ==
-*CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol), others.
+*CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-301 (Reflection attack in an authentication protocol), others.
 *WASC Threat Classification:
 ** [http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml]

@@ Line 38: / Line 38: @@
 *'''Check the old password when the user changes to a new password'''
 *'''Do not rely upon spoofable credentials as the sole form of authentication''', such as IP addresses or address range masks, DNS  or reverse DNS lookups, referrer headers or similar''' '''
-*'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE01 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change
+*'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE02 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change
 == Samples	 ==
@@ Line 58: / Line 58: @@
 ** [http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml]
 ** [http://www.webappsec.org/projects/threat/classes/session_fixation.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml]
-*RSNAKE01RSnake01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
+*RSNAKE01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
 {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}

@@ Line 45: / Line 45: @@
 *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229]
 *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528]
 == References ==

@@ Line 1: / Line 1: @@
 {{Top_10_2007:TopTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}
@@ Line 15: / Line 10: @@
 == Vulnerability ==
-Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such aslogout, password management, timeout, remember me, secret question, and account update.
+Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update.
 == Verifying Security ==
@@ Line 38: / Line 33: @@
 *Consider '''regenerating a new session upon successful authentication''' or privilege level change.
 *'''Ensure that every page has a logout link.''' Logout should destroy all server side session state and client side cookies. Consider human factors: do not ask for confirmation as users will end up just closing the tab or window rather than logging out successfully.
 *'''Use a timeout period''' that automatically logs out an inactive session as per the value of the data being protected (shorter is always better).
-*'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. One way hash answers to prevent disclosure attacks.
+*'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. Apply a one-One way hash to answers to prevent disclosure attacks.
-*'''Do not expose any session identifiers''' or any portion of valid credentials in URLs or logs (no session rewriting or storing the user's password in log files).
+*'''Do not expose any session identifiers or any portion of valid credentials in URLs or logs (no session rewriting or storing the user’s password in log files)'''
-*'''Do not rely upon spoofable credentials as the sole form of authentication,''' such as IP addresses or address range masks, DNS  or reverse DNS lookups, referrer headers or similar.
+*'''Check the old password when the user changes to a new password'''
-*'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE01 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change.
+*'''Do not rely upon spoofable credentials as the sole form of authentication''', such as IP addresses or address range masks, DNS  or reverse DNS lookups, referrer headers or similar''' '''
 *'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE01 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change
 == Samples	 ==
@@ Line 54: / Line 49: @@
 *CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol), others.
 *WASC Threat Classification:
-**[http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml]
+** [http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml]
-**[http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml]
+** [http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml]
-**[http://www.webappsec.org/projects/threat/classes/session_fixation.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml]
+** [http://www.webappsec.org/projects/threat/classes/session_fixation.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml]
-*OWASP, [http://www.owasp.org/index.php/Guide_to_Authentication http://www.owasp.org/index.php/Guide_to_Authentication]
+*OWASP Guide, [http://www.owasp.org/index.php/Guide_to_Authentication http://www.owasp.org/index.php/Guide_to_Authentication]
-*OWASP, [http://www.owasp.org/index.php/Reviewing_Code_for_Authentication http://www.owasp.org/index.php/Reviewing_Code_for_Authentication]
+*OWASP Code Review Guide,, [http://www.owasp.org/index.php/Reviewing_Code_for_Authentication http://www.owasp.org/index.php/Reviewing_Code_for_Authentication]
-*OWASP, [http://www.owasp.org/index.php/Testing_for_authentication http://www.owasp.org/index.php/Testing_for_authentication]
+*OWASP Testing Guide,, [http://www.owasp.org/index.php/Testing_for_authentication http://www.owasp.org/index.php/Testing_for_authentication]
-*RSnake01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
+*RSNAKE01RSnake01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
 {{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}

← Older revision		Revision as of 00:52, 14 May 2007
Line 3:		Line 3:

	{{FIXUP\|Neil Smithline\|Insert Text Here}}		{{FIXUP\|Neil Smithline\|Insert Text Here}}
		+
		+
		+
		+
		+	Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.
		+
		+	== Environments Affected ==
		+
		+	All web application frameworks are vulnerable to authentication and session management flaws.
		+
		+	== Vulnerability ==
		+
		+	Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such aslogout, password management, timeout, remember me, secret question, and account update.
		+
		+	== Verifying Security ==
		+
		+	The goal is to verify that the application properly authenticates users and properly protects identities and their associated credentials.
		+
		+	Automated approaches: Vulnerability scanning tools have a very difficult time detecting vulnerabilities in custom authentication and session management schemes. Static analysis tools are also not likely to detect authentication and session management problems in custom code.
		+
		+	Manual approaches: Code review and testing, especially in combination, are quite effective at verifying that the authentication, session management, and ancillary functions are all implemented properly.
		+
		+	== Protection ==
		+
		+	Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 – Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 – Insecure Cryptographic Storage).
		+
		+	Preventing authentication flaws takes careful planning. Among the most important considerations are:
		+
		+	*'''Only use the inbuilt session management mechanism.''' Do not write or use secondary session handlers under any circumstances.
		+	*'''Do not accept new, preset or invalid session identifiers''' from the URL or in the request. This is called a session fixation attack.
		+	*'''Limit or rid your code of custom cookies for authentication or session management '''purposes, such as "remember me" type functionality or home grown single-sign on functionality. This does not apply to robust, well proven SSO or federated authentication solutions.
		+	*'''Use a single authentication mechanism''' with appropriate strength and number of factors. Make sure that this mechanism is not easily subjected to spoofing or replay attacks. Do not make this mechanism overly complex, which then may become subject to its own attack.
		+	*'''Do not allow the login process to start from an unencrypted page.''' Always start the login process from a second, encrypted page with a fresh or new session token to prevent credential or session stealing, phishing attacks and session fixation attacks.
		+	*Consider '''regenerating a new session upon successful authentication''' or privilege level change.
		+	*'''Ensure that every page has a logout link.''' Logout should destroy all server side session state and client side cookies. Consider human factors: do not ask for confirmation as users will end up just closing the tab or window rather than logging out successfully.
		+	*'''Use a timeout period''' that automatically logs out an inactive session as per the value of the data being protected (shorter is always better).
		+	*'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. One way hash answers to prevent disclosure attacks.
		+	*'''Do not expose any session identifiers''' or any portion of valid credentials in URLs or logs (no session rewriting or storing the user's password in log files).
		+	*'''Do not rely upon spoofable credentials as the sole form of authentication,''' such as IP addresses or address range masks, DNS or reverse DNS lookups, referrer headers or similar.
		+	*'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE01 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change.
		+
		+
		+	== Samples ==
		+
		+	*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145]
		+	*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229]
		+	*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528]
		+
		+	== References ==
		+
		+	*CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol), others.
		+	*WASC Threat Classification:
		+	**[http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml]
		+	**[http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml]
		+	**[http://www.webappsec.org/projects/threat/classes/session_fixation.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml]
		+	*OWASP, [http://www.owasp.org/index.php/Guide_to_Authentication http://www.owasp.org/index.php/Guide_to_Authentication]
		+	*OWASP, [http://www.owasp.org/index.php/Reviewing_Code_for_Authentication http://www.owasp.org/index.php/Reviewing_Code_for_Authentication]
		+	*OWASP, [http://www.owasp.org/index.php/Testing_for_authentication http://www.owasp.org/index.php/Testing_for_authentication]
		+	*RSnake01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
		+



	{{Top_10_2007:BottomTemplate\|usenext=NextLink\|next=-Insecure Cryptographic Storage\|useprev=PrevLink\|prev=-Information Leakage and Improper Error Handling\|usemain=MainLink\|main=}}		{{Top_10_2007:BottomTemplate\|usenext=NextLink\|next=-Insecure Cryptographic Storage\|useprev=PrevLink\|prev=-Information Leakage and Improper Error Handling\|usemain=MainLink\|main=}}