4.0

More documents

Recommendations

Info

184Web Application Penetration TestingSuppose an eCommerce site allows users to take advantage ofany one of many discounts on their total purchase and then proceedto checkout and tendering. What happens of the attackernavigates back to the discounts page after taking and applyingthe one “allowable” discount? Can they take advantage of anotherdiscount? Can they take advantage of the same discountmultiple times?How to Test• Review the project documentation and use exploratory testinglooking for functions or features in the application or systemthat should not be executed more that a single time or specifiednumber of times during the business logic workflow.• For each of the functions and features found that should onlybe executed a single time or specified number of times duringthe business logic workflow, develop abuse/misuse cases thatmay allow a user to execute more than the allowable number oftimes. For example, can a user navigate back and forth throughthe pages multiple times executing a function that should onlyexecute once? or can a user load and unload shopping cartsallowing 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)ReferencesInfoPath Forms Services business logic exceeded the maximumlimit of operations Rule - http://mpwiki.viacode.com/default.aspx?g=posts&t=115678Gold Trading Was Temporarily Halted On The CME This Morning- http://www.businessinsider.com/gold-halted-on-cme-forstop-logic-event-2013-10RemediationThe application should have checks to ensure that the businesslogic is being followed and that if a function/action can only beexecuted a certain number of times, when the limit is reachedthe user can no longer execute the function. To prevent usersfrom using a function over the appropriate number of times theapplication may use mechanisms such as cookies to keep countor through sessions not allowing users to access to execute thefunction additional times.Testing for the Circumvention of Work Flows(OTG-BUSLOGIC-006)SummaryWorkflow vulnerabilities involve any type of vulnerability that allowsthe attacker to misuse an application/system in a way thatwill allow them to circumvent (not follow) the designed/intendedworkflow.“A workflow consists of a sequence of connected steps whereeach step follows without delay or gap and ends just before thesubsequent step may begin. It is a depiction of a sequence ofoperations, declared as work of a person or group, an organizationof 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 completespecific steps in the correct/specific order and if the workflowis terminated without correctly completing, all actions andspawned actions are “rolled back” or canceled. Vulnerabilities relatedto the circumvention of workflows or bypassing the correctbusiness logic workflow are unique in that they are very application/systemspecific and careful manual misuse cases must bedeveloped using requirements and use cases.The applications business process must have checks to ensurethat the user’s transactions/actions are proceeding in the correct/acceptableorder and if a transaction triggers some sort ofaction, that action will be “rolled back” and removed if the transactionis not successfully completed.ExamplesExample 1Many of us receive so type of “club/loyalty points” for purchasesfrom grocery stores and gas stations. Suppose a user wasable to start a transaction linked to their account and then afterpoints have been added to their club/loyalty account cancelout of the transaction or remove items from their “basket” andtender. In this case the system either should not apply points/credits to the account until it is tendered or points/credits shouldbe “rolled back” if the point/credit increment does not match thefinal tender. With this in mind, an attacker may start transactionsand cancel them to build their point levels without actuallybuy anything.Example 2An electronic bulletin board system may be designed to ensurethat initial posts do not contain profanity based on a list that thepost is compared against. If a word on a “black” the list is foundin the user entered text the submission is not posted. But, once asubmission is posted the submitter can access, edit, and changethe submission contents to include words included on the profanity/blacklist since on edit the posting is never comparedagain. Keeping this in mind, attackers may open an initial blank orminimal discussion then add in whatever they like as an update.How to TestGeneric Testing Method• Review the project documentation and use exploratory testinglooking for methods to skip or go to steps in the applicationprocess in a different order from the designed/intendedbusiness logic flow.• For each method develop a misuse case and try to circumventor perform an action that is “not acceptable” per the thebusiness logic workflow.Testing Method 1• Start a transaction going through the application past thepoints that triggers credits/points to the users account.• Cancel out of the transaction or reduce the final tender so thatthe point values should be decreased and check the points/
185Web Application Penetration Testingcredit system to ensure that the proper points/credits wererecorded.Testing Method 2• On a content management or bulletin board system enter andsave valid initial text or values.• Then try to append, edit and remove data that would leave theexisting data in an invalid state or with invalid values to ensurethat 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(OTGSESS-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-BUSLOGIC-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/indexphp/Detail_misuse_cases• Real-Life Example of a ‘Business Logic Defect - http://h30501www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/bap/22581• Top 10 Business Logic Attack Vectors Attacking and ExploitingBusiness Application Assets and Flaws – Vulnerability Detectionto Fix - http://www.ntobjectives.com/go/business-logicattack-vectors-white-paper/and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf• CWE-840: Business Logic Errors - http://cwe.mitre.org/datadefinitions/840.htmlRemediationThe application must be self-aware and have checks in place ensuringthat the users complete each step in the work flow processin the correct order and prevent attackers from circumventing/skipping/orrepeating any steps/processes in the workflow.Test for workflow vulnerabilities involves developing businesslogic abuse/misuse cases with the goal of successfully completingthe business process while not completing the correct stepsin the correct order.Test defenses against application mis-use(OTG-BUSLOGIC-007)SummaryThe misuse and invalid use of of valid functionality can identifyattacks attempting to enumerate the web application, identifyweaknesses, and exploit vulnerabilities. Tests should be undertakento determine whether there are application-layer defensivemechanisms in place to protect the application.The lack of active defenses allows an attacker to hunt for vulnerabilitieswithout any recourse. The application’s owner will thusnot know their application is under attack.ExampleAn authenticated user undertakes the following (unlikely) sequenceof actions:[1] Attempt to access a file ID their roles is not permitted todownload[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 pairThe application is monitoring for misuse and responds after the5th event with extremely high confidence the user is an attacker.For example the application:• Disables critical functionality• Enables additional authentication steps to the remainingfunctionality• 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 responsebodies)If the application does not respond in any way and the attackercan continue to abuse functionality and submit clearly maliciouscontent at the application, the application has failed thistest case. In practice the discrete example actions in the exampleabove are unlikely to occur like that. It is much more probable thata fuzzing tool is used to identify weaknesses in each parameterin turn. This is what a security tester will have undertaken too.How to TestThis test is unusual in that the result can be drawn from all theother tests performed against the web application. While performingall the other tests, take note of measures that mightindicate the application has in-built self-defense:• Changed responses• Blocked requests• Actions that log a user out or lock their account
Page 1 and 2:
1Testing Guide4.0Project Leaders: M
Page 3 and 4:
Testing Guide Foreword - Table of c
Page 5 and 6:
3Testing Guide Foreword - Table of
Page 7 and 8:
5Testing Guide Foreword - By Eoin K
Page 9 and 10:
7Testing Guide Frontispiece1Testing
Page 11 and 12:
9Testing Guide Introduction2The OWA
Page 13 and 14:
11Testing Guide Introductionvide en
Page 15 and 16:
13Testing Guide IntroductionTesting
Page 17 and 18:
15Testing Guide Introductionlaid on
Page 19 and 20:
17Testing Guide Introductionvalidat
Page 21 and 22:
19Testing Guide IntroductionUSERthe
Page 23 and 24:
21Testing Guide Introductionment wh
Page 25 and 26:
23Testing Guide Introductionoffendi
Page 27 and 28:
25The OWASP Testing Frameworksectio
Page 29 and 30:
27Web Application Penetration Testi
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
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:
101Web Application Penetration Test
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136: 133Web Application Penetration Test
Page 185: 183Web Application Penetration Test
Page 211 and 212: 209same code can be applied to sess
Page 213 and 214: 211ReportingTest IDLowest versionIn
Page 215 and 216: 213ReportingTest IDBusiness Logic T
Page 217 and 218: 215Appendixkajfghlhfkcocafkcjlajldi
Page 219 and 220: 217AppendixTesting - http:/www.nist
Page 221 and 222: 219Cross Site Scripting (XSS)For de
Page 223 and 224: 221LDAP InjectionFor details on LDA
show all

4.0

Create successful ePaper yourself

Delete template?

Save as template?