1BO4r2U

Recommendations

Info

57 58 Web Application Penetration Testing Web Application Penetration Testing Considering the importance of this security measure it is important to verify that the web site is using this HTTP header, in order to ensure that all the data travels encrypted from the web browser to the server. The HTTP Strict Transport Security (HSTS) feature lets a web application to inform the browser, through the use of a special response header, that it should never establish a connection to the the specified domain servers using HTTP. Instead it should automatically establish all connection requests to access the site through HTTPS. The HTTP strict transport security header uses two directives: • max-age: to indicate the number of seconds that the browser should automatically convert all HTTP requests to HTTPS. • includeSubDomains: to indicate that all web application’s subdomains must use HTTPS. Here’s an example of the HSTS header implementation: Strict-Transport-Security: max-age=60000; includeSubDomains The use of this header by web applications must be checked to find if the following security issues could be produced: • Attackers sniffing the network traffic and accessing the information transferred through an unencrypted channel. • Attackers exploiting a man in the middle attack because of the problem of accepting certificates that are not trusted. • Users who mistakenly entered an address in the browser putting HTTP instead of HTTPS, or users who click on a link in a web application which mistakenly indicated the http protocol. How to Test Testing for the presence of HSTS header can be done by checking for the existence of the HSTS header in the server’s response in an interception proxy, or by using curl as follows: $ curl -s -D- https:/domain.com/ | grep Strict Result expected: Strict-Transport-Security: max-age=... References • OWASP HTTP Strict Transport Security - https:/www.owasp.org/ index.php/HTTP_Strict_Transport_Security • OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security - http:/www.youtube.com/watch?v=zEV3HOuM_Vw • HSTS Specification: http:/tools.ietf.org/html/rfc6797 Test RIA cross domain policy (OTG-CONFIG-008) Summary Rich Internet Applications (RIA) have adopted Adobe’s crossdomain. xml policy files to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user. What are cross-domain policy files? A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. use to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe’s crossdomain.xml, and additionally created it’s own cross-domain policy file: clientaccesspolicy.xml. Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain to determine if performing cross-domain requests, including headers, and socket-based connections are allowed. Master policy files are located at the domain’s root. A client may be instructed to load a different policy file but it will always check the master policy file first to ensure that the master policy file permits the requested policy file. Crossdomain.xml vs. Clientaccesspolicy.xml |ªMost RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used. Policy files grant several types of permissions: • Accepted policy files (Master policy files can disable or restrict specific policy files) • Sockets permissions • Header permissions • HTTP/HTTPS access permissions • Allowing access based on cryptographic credentials An example of an overly permissive policy file: How can cross domain policy files can be abused? • Overly permissive cross-domain policies. • Generating server responses that may be treated as cross-domain policy files. • Using file upload functionality to upload files that may be treated as cross-domain policy files. Impact of abusing cross-domain access • Defeat CSRF protections. • Read data restricted or otherwise protected by cross-origin policies. How to Test Testing for RIA policy files weakness: To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application’s root, and from every folder found. For example, if the application’s URL is http:/www.owasp.org, the tester should try to download the files http:/www.owasp.org/crossdomain.xml and http:/www.owasp.org/clientaccesspolicy.xml. After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with “*” in them should be closely examined. Example: Result Expected: • A list of policy files found. • A weak settings in the policies. Tools • Nikto • OWASP Zed Attack Proxy Project • W3af References Whitepapers • UCSD: “Analyzing the Crossdomain Policies of Flash Applications” - http: /cseweb.ucsd.edu/~hovav/dist/crossdomain.pdf • Adobe: “Cross-domain policy file specification” - http: /www. adobe.com/devnet/articles/crossdomain_policy_file_spec.html • Adobe: “Cross-domain policy file usage recommendations for Flash Player” - http: /www.adobe.com/devnet/flashplayer/ articles/cross_domain_policy.html • Oracle: “Cross-Domain XML Support” - http: /www. oracle.com/technetwork/java/javase/plugin2-142482. html#CROSSDOMAINXML • MSDN: “Making a Service Available Across Domain Boundaries” - http: /msdn.microsoft.com/en-us/library/cc197955(v=vs.95). aspx • MSDN: “Network Security Access Restrictions in Silverlight” - http: /msdn.microsoft.com/en-us/library/cc645032(v=vs.95). aspx • Stefan Esser: “Poking new holes with Flash Crossdomain Policy Files” http: /www.hardened-php.net/library/poking_new_holes_ with_flash_crossdomain_policy_files.html • Jeremiah Grossman: “Crossdomain.xml Invites Cross-site Mayhem” http: /jeremiahgrossman.blogspot.com/2008/05/ crossdomainxml-invites-cross-site.html • Google Doctype: “Introduction to Flash security “ - http: /code. google.com/p/doctype-mirror/wiki/ArticleFlashSecurity Identity Management Testing Test Role Definitions (OTG-IDENT-001) Summary It is common in modern enterprises to define system roles to manage users and authorization to system resources. In most system implementations it is expected that at least two roles exist, administrators and regular users. The first representing a role that permits access to privileged and sensitive functionality and information, the second representing a role that permits access to regular business functionality and information. Well developed roles should align with business processes which are supported by the application. It is important to remember that cold, hard authorization isn’t the only way to manage access to system objects. In more trusted environments where confidentiality is not critical, softer controls such as application workflow and audit logging can support data integrity requirements while not restricting user access to functionality or creating complex role structures that are difficult to manage. Its important to consider the Goldilocks principle when role engineering, in that defining too few, broad roles (thereby exposing access to functionality users don’t require) is as bad as too many, tightly tailored roles (thereby restricting access to functionality users do require). Test objectives Validate the system roles defined within the application sufficiently define and separate each system and business role to manage appropriate access to system functionality and information. How to test Either with or without the help of the system developers or administrators, develop an role versus permission matrix. The matrix should enumerate all the roles that can be provisioned and explore the permissions that are allowed to be applied to the objects including any constraints. If a matrix is provided with the application it should be validated by the tester, if it doesn’t exist, the tester should generate it and determine whether the matrix satisfies the desired access policy for the application. Role Administrator Manager Staff Customer Permission Read Read Read Read Object Customer records Customer records Customer records Customer records Constraints Only records related to business unit Only records associated with customers assigned by Manager Only own record Example A real world example of role definitions can be found in the Word- Press roles documentation [1]. WordPress has six default roles ranging from Super Admin to a Subscriber.
59 60 Web Application Penetration Testing Web Application Penetration Testing Tools While the most thorough and accurate approach to completing this test is to conduct it manually, spidering tools [2] are also useful. Log on with each role in turn and spider the application (don’t forget to exclude the logout link from the spidering). References • Role Engineering for Enterprise Security Management, E Coyne & J Davis, 2007 • Role engineering and RBAC standards Remediation Remediation of the issues can take the following forms: • Role Engineering • Mapping of business roles to system roles • Separation of Duties Test User Registration Process (OTG-IDENT-002) 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 [1] Verify that the identity requirements for user registration are aligned with business and security requirements. [2] Validate the registration process. How to test Verify that the identity requirements for user registration are aligned with business and security requirements: [1] Can anyone register for access? [2] Are registrations vetted by a human prior to provisioning, or are they automatically granted if the criteria are met? [3] Can the same person or identity register multiple times? [4] Can users register for different roles or permissions? [5] What proof of identity is required for a registration to be successful? [6] Are registered identities verified? Validate the registration process: [1] Can identity information be easily forged or faked? [2] 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 User Registration Design Remediation Implement identification and verification requirements that correspond to the security requirements of the information the credentials protect. Test Account Provisioning Process (OTG-IDENT-003) Summary The provisioning of accounts presents an opportunity for an attacker to create a valid account without application of the proper identification and authorization process. Test objectives Verify which accounts may provision other accounts and of what type. How to test Determine which roles are able to provision users and what sort of accounts they can provision. • Is there any verification, vetting and authorization of provisioning requests? • Is there any verification, vetting and authorization of de-provisioning requests? • Can an administrator provision other administrators or just users? • Can an administrator or other user provision accounts with privileges message similar to: Using WebScarab, notice the information retrieved from this unsucgreater than their own? • Can an administrator or user de-provision themselves? • How are the files or resources owned by the de-provisioned user managed? Are they deleted? Is access transferred? Example In WordPress, only a user’s name and email address are required to provision the user, as shown below: De-provisioning of users requires the administrator to select the users to be de-provisioned, select Delete from the dropdown menu (circled) and then applying this action. The administrator is then presented with a dialog box asking what to do with the user’s posts (delete or transfer them). Tools While the most thorough and accurate approach to completing this test is to conduct it manually, HTTP proxy tools could be also useful. Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) Summary The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for brute force testing, in which the tester verifies if, given a valid username, it is possible to find the corresponding password. Often, web applications reveal when a username exists on system, either as a consequence of mis-configuration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong. The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username and password attack. The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server when the user provide a valid username is different than when they use an invalid one. In some cases, a message is received that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, testers can enumerate the existing users by sending a username and an empty password. How to Test In black box testing, the tester knows nothing about the specific application, username, application logic, error messages on log in page, or password recovery facilities. If the application is vulnerable, the tester receives a response message that reveals, directly or indirectly, some information useful for enumerating users. HTTP Response message Testing for Valid user/right password Record the server answer when you submit a valid user ID and valid password. Result Expected: Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response). Testing for valid user with wrong password Now, the tester should try to insert a valid user ID and a wrong password and record the error message generated by the application. Result Expected: The browser should display a message similar to the following one: or something like: against any message that reveals the existence of user, for instance, Login for User foo: invalid password
Page 1 and 2: 1 2 THE ICONS BELOW REPRESENT WHAT
Page 3 and 4: 3 4 Testing Guide Frontispiece Test
Page 5 and 6: 7 8 Testing Guide Introduction Test
Page 7 and 8: 11 12 Testing Guide Introduction Te
Page 9 and 10: 15 16 Testing Guide Introduction Te
Page 11 and 12: 19 20 Testing Guide Introduction of
Page 13 and 14: 23 24 Web Application Penetration T
Page 29: 55 56 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 81 and 82:
159 160 Web Application Penetration
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
211 212 Reporting Appendix Test ID
Page 109 and 110:
215 216 Appendix Appendix Testing -
Page 111:
219 220 LDAP Injection For details
show all

1BO4r2U

Create successful ePaper yourself

Delete template?

Save as template?