This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Test User Registration Process (OTG-IDENT-002)"
(Final edit) |
|||
| Line 3: | Line 3: | ||
== Summary == | == Summary == | ||
| − | Some websites offer a user registration process that automates (or semi-automates) the provisioning of | + | Some websites offer a user registration process that automates (or semi-automates) the provisioning of system access to users. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. Many public applications completely automate the registration and provisioning process because the size of the user base makes it impossible to manage manually. However, many corporate applications will provision users manually, so this test case may not apply. |
| + | |||
== Test objectives == | == Test objectives == | ||
| − | Verify the identity requirements for user registration | + | #Verify that the identity requirements for user registration are aligned with business and security requirements. |
| + | #Validate the registration process. | ||
| − | |||
== How to test == | == How to test == | ||
| − | + | Verify that the identity requirements for user registration are aligned with business and security requirements: | |
| − | + | # Can anyone register for access? | |
| − | + | # Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met? | |
| − | + | # Can the same person or identity register multiple times? | |
| − | + | # Can users register for different roles or permissions? | |
| − | + | # What proof of identity is required for a registration to be successful? | |
| − | + | # Are registered identities verified? | |
| + | |||
| + | Validate the registration process: | ||
| + | # Can identity information be easily forged or faked? | ||
| + | # Can the exchange of identity information be manipulated during registration? | ||
| − | |||
| − | |||
| − | |||
=== Example === | === Example === | ||
| − | In the | + | In the WordPress example below, the only identification requirement is an email address that is accessible to the registrant. |
| + | |||
[[File:Wordpress_registration_page.jpg|700px]] | [[File:Wordpress_registration_page.jpg|700px]] | ||
| − | In contrast, the Google example below | + | |
| + | In contrast, in the Google example below the identification requirements include name, date of birth, country, mobile phone number, email address and CAPTCHA response. While only two of these can be verified (email address and mobile number), the identification requirements are stricter than WordPress. | ||
| + | |||
[[File:Google_registration_page.jpg|700px]] | [[File:Google_registration_page.jpg|700px]] | ||
| + | |||
== Tools == | == Tools == | ||
| − | HTTP | + | A HTTP proxy can be a useful tool to test this control. |
| + | |||
== References == | == References == | ||
| − | [http://mashable.com/2011/06/09/user-registration-design/] | + | [http://mashable.com/2011/06/09/user-registration-design/ User Registration Design] |
| + | |||
== Remediation == | == Remediation == | ||
Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect. | Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect. | ||
Latest revision as of 14:32, 14 May 2014
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project
Summary
Some websites offer a user registration process that automates (or semi-automates) the provisioning of system access to users. The identity requirements for access vary from positive identification to none at all, depending on the security requirements of the system. Many public applications completely automate the registration and provisioning process because the size of the user base makes it impossible to manage manually. However, many corporate applications will provision users manually, so this test case may not apply.
Test objectives
- Verify that the identity requirements for user registration are aligned with business and security requirements.
- Validate the registration process.
How to test
Verify that the identity requirements for user registration are aligned with business and security requirements:
- Can anyone register for access?
- Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met?
- Can the same person or identity register multiple times?
- Can users register for different roles or permissions?
- What proof of identity is required for a registration to be successful?
- Are registered identities verified?
Validate the registration process:
- Can identity information be easily forged or faked?
- Can the exchange of identity information be manipulated during registration?
Example
In the WordPress example below, the only identification requirement is an email address that is accessible to the registrant.
In contrast, in the Google example below the identification requirements include name, date of birth, country, mobile phone number, email address and CAPTCHA response. While only two of these can be verified (email address and mobile number), the identification requirements are stricter than WordPress.
Tools
A HTTP proxy can be a useful tool to test this control.
References
Remediation
Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect.
