4.0

More documents

Recommendations

Info

176Web Application Penetration Testingpath=/; domain=example.com; httponlyLocation: private/X-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINContent-Length: 0Keep-Alive: timeout=1, max=100Connection: Keep-AliveContent-Type: text/html----------------------------------------------------------http: /example.com/privateGET /private HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;rv:25.0) Gecko/20100101 Firefox/25.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: https: /secure.example.com/loginCookie: JSESSIONID=BD99F321233AF69593ED-F52B123B5BDA;Connection: keep-aliveHTTP/1.1 200 OKCache-Control: no-storePragma: no-cacheExpires: 0Content-Type: text/html;charset=UTF-8Content-Length: 730Date: Tue, 25 Dec 2013 00:00:00 GMT----------------------------------------------------------Tools• [5] curl can be used to check manually for pagesReferencesOWASP Resources• [1] OWASP Testing Guide - Testing for Weak SSL/TLS Ciphers,Insufficient Transport Layer Protection (OTG-CRYPST-001)• [2] OWASP TOP 10 2010 - Insufficient Transport LayerProtection• [3] OWASP TOP 10 2013 - Sensitive Data Exposure• [4] OWASP ASVS v1.1 - V10 Communication Security VerificationRequirements• [6] OWASP Testing Guide - Testing for Cookies attributes(OTG-SESS-002)Testing for business logicSummaryTesting for business logic flaws in a multi-functional dynamicweb application requires thinking in unconventional methods.If an application’s authentication mechanism is developed withthe intention of performing steps 1, 2, 3 in that specific order toauthenticate a user. What happens if the user goes from step 1straight to step 3? In this simplistic example, does the applicationprovide access by failing open; deny access, or just error outwith a 500 message?There are many examples that can be made, but the one constantlesson is “think outside of conventional wisdom”. This typeof vulnerability cannot be detected by a vulnerability scannerand relies upon the skills and creativity of the penetration tester.In addition, this type of vulnerability is usually one of the hardestto detect, and usually application specific but, at the sametime, usually one of the most detrimental to the application, ifexploited.The classification of business logic flaws has been under-studied;although exploitation of business flaws frequently happensin real-world systems, and many applied vulnerability researchersinvestigate them. The greatest focus is in web applications.There is debate within the community about whether theseproblems represent particularly new concepts, or if they are variationsof well-known principles.Testing of business logic flaws is similar to the test types usedby functional testers that focus on logical or finite state testing.These types of tests require that security professionals think abit differently, develop abused and misuse cases and use manyof the testing techniques embraced by functional testers. Automationof business logic abuse cases is not possible and remainsa manual art relying on the skills of the tester and their knowledgeof the complete business process and its rules.Business Limits and RestrictionsConsider the rules for the business function being provided bythe application. Are there any limits or restrictions on people’sbehavior? Then consider whether the application enforces thoserules. It’s generally pretty easy to identify the test and analysiscases to verify the application if you’re familiar with the business.If you are a third-party tester, then you’re going to have touse your common sense and ask the business if different operationsshould be allowed by the application.Sometimes, in very complex applications, the tester will not havea full understanding of every aspect of the application initially.In these situations, it is best to have the client walk the testerthrough the application, so that they may gain a better understandingof the limits and intended functionality of the application,before the actual test begins. Additionally, having a directline to the developers (if possible) during testing will help outgreatly, if any questions arise regarding the application’s functionality.Description of the IssueAutomated tools find it hard to understand context, hence it’s upto a person to perform these kinds of tests. The following twoexamples will illustrate how understanding the functionality ofthe application, the developer’s intentions, and some creative“out-of-the-box” thinking can break the application’s logic. Thefirst example starts with a simplistic parameter manipulation,whereas the second is a real world example of a multi-step processleading to completely subvert the application.
177Web Application Penetration TestingExample 1:Suppose an e-commerce site allows users to select items to purchase,view a summary page and then tender the sale. What if anattacker was able to go back to the summary page, maintainingtheir same valid session and inject a lower cost for an item andcomplete the transaction, and then check out?Example 2:Holding/locking resources and keeping others from purchasesthese items online may result in attackers purchasing items at alower price. The countermeasure to this problem is to implementtimeouts and mechanisms to ensure that only the correct pricecan be charged.Example 3:What if a user was able to start a transaction linked to their club/loyalty account and then after points have been added to theiraccount cancel out of the transaction? Will the points/credits stillbe applied to their account?Business Logic Test CasesEvery application has a different business process, applicationspecific logic and can be manipulated in an infinite number ofcombinations. This section provides some common examples ofbusiness logic issues but in no way a complete list of all issues.Business Logic exploits can be broken into the following categories:4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)In business logic data validation testing, we verify that the applicationdoes not allow users to insert “unvalidated” data intothe system/application. This is important because without thissafeguard attackers may be able to insert “unvalidated” data/informationinto the application/system at “handoff points” wherethe application/system believes that the data/information is“good” and has been valid since the “entry points” performeddata validation as part of the business logic workflow.4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)In forged and predictive parameter request testing, we verifythat the application does not allow users to submit or alter datato any component of the system that they should not have accessto, are accessing at that particular time or in that particular manner.This is important because without this safeguard attackersmay be able to “fool/trick” the application into letting them intosections of thwe application of system that they should not beallowed in at that particular time, thus circumventing the applicationsbusiness logic workflow.4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)In integrity check and tamper evidence testing, we verify that theapplication does not allow users to destroy the integrity of anypart of the system or its data. This is important because withoutthese safe guards attackers may break the business logic workflowand change of compromise the application/system data orcover up actions by altering information including log files.4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)In process timing testing, we verify that the application does notallow users to manipulate a system or guess its behavior basedon input or output timing. This is important because without thissafeguard in place attackers may be able to monitor processingtime and determine outputs based on timing, or circumvent theapplication’s business logic by not completing transactions oractions in a timely manner.4.12.5 Test Number of Times a Function Can be Used Limits(OTG-BUSLOGIC-005)In function limit testing, we verify that the application does notallow users to exercise portions of the application or its functionsmore times than required by the business logic workflow.This is important because without this safeguard in place attackersmay be able to use a function or portion of the applicationmore times than permissible per the business logic to gain additionalbenefits.4.12.6 Testing for the Circumvention of Work Flows (OTG-BUS-LOGIC-006)In circumventing workflow and bypassing correct sequencetesting, we verify that the application does not allow users toperform actions outside of the “approved/required” businessprocess flow. This is important because without this safeguardin place attackers may be able to bypass or circumvent workflowsand “checks” allowing them to prematurely enter or skip“required” sections of the application potentially allowing theaction/transaction to be completed without successfully completingthe entire business process, leaving the system with incompletebackend tracking information.4.12.7 Test Defenses Against Application Mis-use (OTG-BUS-LOGIC-007)In application mis-use testing, we verify that the applicationdoes not allow users to manipulate the application in an unintendedmanner.4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOG-IC-008)In unexpected file upload testing, we verify that the applicationdoes not allow users to upload file types that the system is notexpecting or wanted per the business logic requirements. This isimportant because without these safeguards in place attackersmay be able to submit unexpected files such as .exe or .php thatcould be saved to the system and then executed against the applicationor system.4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)In malicious file upload testing, we verify that the applicationdoes not allow users to upload files to the system that are maliciousor potentially malicious to the system security. This isimportant because without these safeguards in place attackersmay be able to upload files to the system that may spread viruses,malware or even exploits such as shellcode when executed.ToolsWhile there are tools for testing and verifying that business processesare functioning correctly in valid situations these toolsare incapable of detecting logical vulnerabilities. For example,tools have no means of detecting if a user is able to circumventthe business process flow through editing parameters, predictingresource names or escalating privileges to access restrictedresources nor do they have any mechanism to help the human
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: 125Web Application Penetration Test
Page 177: 175Web 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?