4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
62<br />
Web Application Penetration Testing<br />
- http: /msdn.microsoft.com/en-us/library/cc197955(v=vs.95).<br />
aspx<br />
• MSDN: “Network Security Access Restrictions in Silverlight” -<br />
http: /msdn.microsoft.com/en-us/library/cc645032(v=vs.95).<br />
aspx<br />
• Stefan Esser: “Poking new holes with Flash Crossdomain Policy<br />
Files” http: /www.hardened-php.net/library/poking_new_<br />
holes_with_flash_crossdomain_policy_files.html<br />
• Jeremiah Grossman: “Crossdomain.xml Invites Cross-site<br />
Mayhem” http: /jeremiahgrossman.blogspot.com/2008/05/<br />
crossdomainxml-invites-cross-site.html<br />
• Google Doctype: “Introduction to Flash security “ - http: /code.<br />
google.com/p/doctype-mirror/wiki/ArticleFlashSecurity<br />
Test Role Definitions (OTG-IDENT-001)<br />
Summary<br />
It is common in modern enterprises to define system roles to<br />
manage users and authorization to system resources. In most<br />
system implementations it is expected that at least two roles exist,<br />
administrators and regular users. The first representing a role<br />
that permits access to privileged and sensitive functionality and<br />
information, the second representing a role that permits access<br />
to regular business functionality and information. Well developed<br />
roles should align with business processes which are supported<br />
by the application.<br />
It is important to remember that cold, hard authorization isn’t the<br />
only way to manage access to system objects. In more trusted<br />
environments where confidentiality is not critical, softer controls<br />
such as application workflow and audit logging can support data<br />
integrity requirements while not restricting user access to functionality<br />
or creating complex role structures that are difficult to<br />
manage. Its important to consider the Goldilocks principle when<br />
role engineering, in that defining too few, broad roles (thereby exposing<br />
access to functionality users don’t require) is as bad as too<br />
many, tightly tailored roles (thereby restricting access to functionality<br />
users do require).<br />
Test objectives<br />
Validate the system roles defined within the application sufficiently<br />
define and separate each system and business role to manage<br />
appropriate access to system functionality and information.<br />
How to test<br />
Either with or without the help of the system developers or administrators,<br />
develop an role versus permission matrix. The matrix<br />
should enumerate all the roles that can be provisioned and explore<br />
the permissions that are allowed to be applied to the objects including<br />
any constraints. If a matrix is provided with the application<br />
it should be validated by the tester, if it doesn’t exist, the tester<br />
should generate it and determine whether the matrix satisfies the<br />
desired access policy for the application.<br />
Example<br />
Role<br />
Permission<br />
Object<br />
Constraints<br />
RoStaff<br />
Customer<br />
Read<br />
Read<br />
Customer<br />
records<br />
Customer<br />
records<br />
Only records associated with<br />
customers assigned by Manager<br />
Only own record<br />
A real world example of role definitions can be found in the Word-<br />
Press roles documentation [1]. WordPress has six default roles<br />
ranging from Super Admin to a Subscriber.<br />
Tools<br />
While the most thorough and accurate approach to completing<br />
this test is to conduct it manually, spidering tools [2] are also useful.<br />
Log on with each role in turn and spider the application (don’t<br />
forget to exclude the logout link from the spidering).<br />
References<br />
• Role Engineering for Enterprise Security Management, E Coyne<br />
& J Davis, 2007<br />
• Role engineering and RBAC standards<br />
Remediation<br />
Remediation of the issues can take the following forms:<br />
• Role Engineering<br />
• Mapping of business roles to system roles<br />
• Separation of Duties<br />
Test User Registration Process<br />
(OTG-IDENT-002)<br />
Summary<br />
Some websites offer a user registration process that automates (or<br />
semi-automates) the provisioning of system access to users. The<br />
identity requirements for access vary from positive identification to<br />
none at all, depending on the security requirements of the system.<br />
Many public applications completely automate the registration and<br />
provisioning process because the size of the user base makes it impossible<br />
to manage manually. However, many corporate applications<br />
will provision users manually, so this test case may not apply.<br />
Test objectives<br />
[1] Verify that the identity requirements for user registration are<br />
aligned with business and security requirements.<br />
[2] Validate the registration process.<br />
How to test<br />
Verify that the identity requirements for user registration are aligned<br />
with business and security requirements:<br />
[1] Can anyone register for access?<br />
[2] Are registrations vetted by a human prior to provisioning, or are<br />
they automatically granted if the criteria are met?<br />
[3] Can the same person or identity register multiple times?<br />
[4] Can users register for different roles or permissions?<br />
[5] What proof of identity is required for a registration to be successful?<br />
[6] Are registered identities verified?<br />
Administrator<br />
Manager<br />
Read<br />
Read<br />
Customer<br />
records<br />
Customer<br />
records<br />
Only records related<br />
to business unit<br />
Validate the registration process:<br />
[1] Can identity information be easily forged or faked?<br />
[2] Can the exchange of identity information be manipulated during<br />
registration?