1BO4r2U

Recommendations

Info

181 182 Web Application Penetration Testing Web Application Penetration Testing allow users 5 minutes to complete a transaction or the transaction is invalidated. Example 4 Suppose a precious metals e-commerce site allows users to make purchases with a price quote based on market price at the time they log on. What if an attacker logs on and places an order but does not complete the transaction until later in the day only of the price of the metals goes up? Will the attacker get the initial lower price? How to Test • Review the project documentation and use exploratory testing looking for application/system functionality that may be impacted by time. Such as execution time or actions that help users predict a future outcome or allow one to circumvent any part of the business logic or workflow. For example, not completing transactions in an expected time. • Develop and execute the mis-use cases ensuring that attackers can not gain an advantage based on any timing. Related Test Cases • Testing for Cookies attributes (OTG-SESS-002) • Test Session Timeout (OTG-SESS-007) References None Remediation Develop applications with processing time in mind. If attackers could possibly gain some type of advantage from knowing the different processing times and results add extra steps or processing so that no matter the results they are provided in the same time frame. Additionally, the application/system must have mechanism in place to not allow attackers to extend transactions over an “acceptable” amount of time. This may be done by cancelling or resetting transactions after a specified amount of time has passed like some ticket vendors are now using. Test number of times a function can be used limits (OTG-BUSLOGIC-005) Summary Many of the problems that applications are solving require limits to the number of times a function can be used or action can be executed. Applications must be “smart enough” to not allow the user to exceed their limit on the use of these functions since in many cases each time the function is used the user may gain some type of benefit that must be accounted for to properly compensate the owner. For example: an eCommerce site may only allow a users apply a discount once per transaction, or some applications may be on a subscription plan and only allow users to download three complete documents monthly. Vulnerabilities related to testing for the function limits are application specific and misuse cases must be created that strive to exercise parts of the application/functions/ or actions more than the allowable number of times. Attackers may be able to circumvent the business logic and execute a function more times than “allowable” exploiting the application for personal gain. Example Suppose an eCommerce site allows users to take advantage of any one of many discounts on their total purchase and then proceed to checkout and tendering. What happens of the attacker navigates back to the discounts page after taking and applying the one “allowable” discount? Can they take advantage of another discount? Can they take advantage of the same discount multiple times? How to Test • Review the project documentation and use exploratory testing looking for functions or features in the application or system that should not be executed more that a single time or specified number of times during the business logic workflow. • For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times. For example, can a user navigate back and forth through the pages multiple times executing a function that should only execute once? or can a user load and unload shopping carts allowing for additional discounts. Related Test Cases • Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) • Testing for Weak lock out mechanism (OTG-AUTHN-003) References • InfoPath Forms Services business logic exceeded the maximum limit of operations Rule - http://mpwiki.viacode.com/default.aspx- ?g=posts&t=115678 • Gold Trading Was Temporarily Halted On The CME This Morning - http://www.businessinsider.com/gold-halted-on-cme-for-stoplogic-event-2013-10 Remediation The application should have checks to ensure that the business logic is being followed and that if a function/action can only be executed a certain number of times, when the limit is reached the user can no longer execute the function. To prevent users from using a function over the appropriate number of times the application may use mechanisms such as cookies to keep count or through sessions not allowing users to access to execute the function additional times. Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006) Summary Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application/system in a way that will allow them to circumvent (not follow) the designed/intended workflow. “A workflow consists of a sequence of connected steps where each step follows without delay or gap and ends just before the subsequent step may begin. It is a depiction of a sequence of operations, declared as work of a person or group, an organization of staff, or one or more simple or complex mechanisms. Workflow may be seen as any abstraction of real work.” (https://en.wikipedia.org/wiki/ Workflow) The application’s business logic must require that the user complete specific steps in the correct/specific order and if the workflow is terminated without correctly completing, all actions and spawned actions are “rolled back” or canceled. Vulnerabilities related to the circumvention of workflows or bypassing the correct business logic workflow are unique in that they are very application/system specific and careful manual misuse cases must be developed using requirements and use cases. The applications business process must have checks to ensure that the user’s transactions/actions are proceeding in the correct/acceptable order and if a transaction triggers some sort of action, that action will be “rolled back” and removed if the transaction is not successfully completed. Examples Example 1 Many of us receive so type of “club/loyalty points” for purchases from grocery stores and gas stations. Suppose a user was able to start a transaction linked to their account and then after points have been added to their club/loyalty account cancel out of the transaction or remove items from their “basket” and tender. In this case the system either should not apply points/credits to the account until it is tendered or points/credits should be “rolled back” if the point/ credit increment does not match the final tender. With this in mind, an attacker may start transactions and cancel them to build their point levels without actually buy anything. Example 2 An electronic bulletin board system may be designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on a “black” the list is found in the user entered text the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity/black list since on edit the posting is never compared again. Keeping this in mind, attackers may open an initial blank or minimal discussion then add in whatever they like as an update. How to Test Generic Testing Method • Review the project documentation and use exploratory testing looking for methods to skip or go to steps in the application process in a different order from the designed/intended business logic flow. • For each method develop a misuse case and try to circumvent or perform an action that is “not acceptable” per the the business logic workflow. Testing Method 1 • Start a transaction going through the application past the points that triggers credits/points to the users account. • Cancel out of the transaction or reduce the final tender so that the point values should be decreased and check the points/ credit system to ensure that the proper points/credits were recorded. Testing Method 2 • On a content management or bulletin board system enter and save valid initial text or values. • Then try to append, edit and remove data that would leave the existing data in an invalid state or with invalid values to ensure that the user is not allowed to save the incorrect information. Some “invalid” data or information may be specific words (profanity) or specific topics (such as political issues). Related Test Cases • Testing Directory traversal/file include (OTG-AUTHZ-001) • Testing for bypassing authorization schema (OTG-AUTHZ-002) • Testing for Bypassing Session Management Schema (OTG- SESS-001) • Test Business Logic Data Validation (OTG-BUSLOGIC-001) • Test Ability to Forge Requests (OTG-BUSLOGIC-002) • Test Integrity Checks (OTG-BUSLOGIC-003) • Test for Process Timing (OTG-BUSLOGIC-004) • Test Number of Times a Function Can be Used Limits (OTG-BUS- LOGIC-005) • Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007) • Test Upload of Unexpected File Types (OTG-BUSLOGIC-008) • Test Upload of Malicious Files (OTG-BUSLOGIC-009) References • OWASP Detail Misuse Cases - https://www.owasp.org/index.php/ Detail_misuse_cases • Real-Life Example of a ‘Business Logic Defect - http://h30501. www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581 • Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf • CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html Remediation The application must be self-aware and have checks in place ensuring that the users complete each step in the work flow process in the correct order and prevent attackers from circumventing/skipping/or repeating any steps/processes in the workflow. Test for workflow vulnerabilities involves developing business logic abuse/misuse cas-
183 184 Web Application Penetration Testing Web Application Penetration Testing es with the goal of successfully completing the business process while not completing the correct steps in the correct order. Test defenses against application mis-use (OTG-BUSLOGIC-007) Summary The misuse and invalid use of of valid functionality can identify attacks attempting to enumerate the web application, identify weaknesses, and exploit vulnerabilities. Tests should be undertaken to determine whether there are application-layer defensive mechanisms in place to protect the application. The lack of active defenses allows an attacker to hunt for vulnerabilities without any recourse. The application’s owner will thus not know their application is under attack. Example An authenticated user undertakes the following (unlikely) sequence of actions: [1] Attempt to access a file ID their roles is not permitted to download [2] Substitutes a single tick (‘) instead of the file ID number [3] Alters a GET request to a POST [4] Adds an extra parameter [5] Duplicates a parameter name/value pair The application is monitoring for misuse and responds after the 5th event with extremely high confidence the user is an attacker. For example the application: • Disables critical functionality • Enables additional authentication steps to the remaining functionality • Adds time-delays into every request-response cycle • Begins to record additional data about the user’s interactions (e.g. sanitized HTTP request headers, bodies and response bodies) If the application does not respond in any way and the attacker can continue to abuse functionality and submit clearly malicious content at the application, the application has failed this test case. In practice the discrete example actions in the example above are unlikely to occur like that. It is much more probable that a fuzzing tool is used to identify weaknesses in each parameter in turn. This is what a security tester will have undertaken too. How to Test This test is unusual in that the result can be drawn from all the other tests performed against the web application. While performing all the other tests, take note of measures that might indicate the application has in-built self-defense: • Changed responses • Blocked requests • Actions that log a user out or lock their account These may only be localised. Common localized (per function) defenses are: • Rejecting input containing certain characters • Locking out an account temporarily after a number of authentication failures Localized security controls are not sufficient. There are often no defenses against general mis-use such as: • Forced browsing • Bypassing presentation layer input validation • Multiple access control errors • Additional, duplicated or missing parameter names • Multiple input validation or business logic verification failures with values that cannot be the result user mistakes or typos • Structured data (e.g. JSPN, XML) of an invalid format is received • Blatant cross-site scripting or SQL injection payloads are received • Utilising the application faster than would be possible without automation tools • Change in continental geo-location of a user • Change of user agent • Accessing a multi-stage business process in the wrong order • Large number of, or high rate of use of, application-specific functionality (e.g. voucher code submission, failed credit card payments, file uploads, file downloads, log outs, etc). These defenses work best in authenticated parts of the application, although rate of creation of new accounts or accessing content (e.g. to scrape information) can be of use in public areas. Not all the above need to be monitored by the application, but there is a problem if none of them are. By testing the web application, doing the above type of actions, was any response taken against the tester? If not, the tester should report that the application appears to have no application-wide active defenses against misuse. Note it is sometimes possible that all responses to attack detection are silent to the user (e.g. logging changes, increased monitoring, alerts to administrators and and request proxying), so confidence in this finding cannot be guaranteed. In practice, very few applications (or related infrastructure such as a web application firewall) are detecting these types of misuse. Related Test Cases All other test cases are relevant. Tools The tester can use many of the tools used for the other test cases. References • Resilient Software, Software Assurance, US Department Homeland Security • IR 7684 Common Misuse Scoring System (CMSS), NIST • Common Attack Pattern Enumeration and Classification (CAPEC), The Mitre Corporation • OWASP_AppSensor_Project • AppSensor Guide v2, OWASP • Watson C, Coates M, Melton J and Groves G, Creating Attack-Aware Software Applications with Real-Time Defenses, CrossTalk The Journal of Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008) Summary Many application’s business processes allow for the upload and manipulation of data that is submitted via files. But the business process must check the files and only allow certain “approved” file types. Deciding what files are “approved” is determined by the business logic and is application/system specific. The risk in that by allowing users to upload files, attackers may submit an unexpected file type that that could be executed and adversely impact the application or system through attacks that may deface the web site, perform remote commands, browse the system files, browse the local resources, attack other servers, or exploit the local vulnerabilities, just to name a few. Vulnerabilities related to the upload of unexpected file types is unique in that the upload should quickly reject a file if it does not have a specific extension. Additionally, this is different from uploading malicious files in that in most cases an incorrect file format may not by it self be inherently “malicious” but may be detrimental to the saved data. For example if an application accepts Windows Excel files, if an similar database file is uploaded it may be read but data extracted my be moved to incorrect locations. The application may be expecting only certain file types to be uploaded for processing, such as .CSV, .txt files. The application may not validate the uploaded file by extension (for low assurance file validation) or content (high assurance file validation). This may result in unexpected system or database results within the application/system or give attackers additional methods to exploit the application/system. Example Suppose a picture sharing application allows users to upload a .gif or .jpg graphic file to the web site. What if an attacker is able to upload an html file with a tag in it or php file? The system may move the file from a temporary location to the final location where the php code can now be executed against the application or system. How to Test Generic Testing Method • Review the project documentation and perform some exploratory testing looking for file types that should be “unsupported” by the application/system. • Try to upload these “unsupported” files an verify that it are properly rejected. • If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated. Specific Testing Method • Study the applications logical requirements. • Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or html files containing script. • In the application navigate to the file submission or upload mechanism. • Submit the “not approved” file for upload and verify that they are properly prevented from uploading Related Test Cases • Test File Extensions Handling for Sensitive Information (OTG-CON- FIG-003) • Test Upload of Malicious Files (OTG-BUSLOGIC-009) References • OWASP - Unrestricted File Upload - https://www.owasp.org/ index.php/Unrestricted_File_Upload • File upload security best practices: Block a malicious file upload - http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload • Stop people uploading malicious PHP files via forms - http:// stackoverflow.com/questions/602539/stop-people-uploadingmalicious-php-files-via-forms • CWE-434: Unrestricted Upload of File with Dangerous Type - http://cwe.mitre.org/data/definitions/434.html • Secure Programming Tips - Handling File Uploads - https:// www.datasprings.com/resources/dnn-tutorials/artmid/535/ articleid/65/secure-programming-tips-handling-file-uploads?AspxAutoDetectCookieSupport=1 Remediation Applications should be developed with mechanisms to only accept and manipulate “acceptable“ files that the rest of the application functionality is ready to handle and expecting. Some specific examples include: Black or White listing of file extensions, using “Content-Type” from the header, or using a file type recognizer, all to only allow specified file types into the system. Test Upload of Malicious Files (OTG-BUSLOGIC-009) Summary Many application’s business processes allow for the upload of data/information. We regularly check the validity and security of text but accepting files can introduce even more risk. To reduce the risk we may only accept certain file extensions, but attackers are able to encapsulate malicious code into inert file types. Testing for malicious files verifies that the application/system is able to correctly protect against attackers uploading malicious files. Vulnerabilities related to the uploading of malicious files is unique in that these “malicious” files can easily be rejected through including business logic that will scan files during the upload process and reject those perceived as malicious. Additionally, this is different from uploading unexpected files in that while the file type may be accepted the file may still be malicious to the system. Finally, “malicious” means different things to different systems, for example Malicious files that may exploit SQL server vulnerabilities may not be considered a “malicious” to a main frame flat file environment. The application may allow the upload of malicious files that include exploits or shellcode without submitting them to malicious file scanning. Malicious files could be detected and stopped at various points of the application architecture such as: IPS/IDS, application server anti-virus software or anti-virus scanning by application as files are uploaded (perhaps offloading the scanning using SCAP).
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 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42: 79 80 Web Application Penetration T
Page 51 and 52: 99 100 Web Application Penetration
Page 91: 179 180 Web Application Penetration
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?