WIXLIB

Authentication testingTesting the authentication schema means understanding how the authenticationprocess works and using that information to circumvent the authenticationmechanism.Default or guessable accountWe test for leave backdoors to easily access and test the application andlater forgetting to remove them, non-removable default accounts with a preset username and password and blank passwords.Brute ForceSystematically enumerating all possible candidates for the solution andchecking whether each candidate satisfies the problem's statement.Brute force on username given a set of password, or bruteforce on passwordgiven a set of username.Bypassing authentication schemaTest if it’s possible to bypass authentication measures by tampering withrequests and tricking the application into thinking that we're alreadyauthenticated25 Jan 2007Pag. 27

Authentication testing (2)Bypassing authentication schema Direct page request Parameter Modification Session ID Prediction Sql InjectionDirectory traversal/file include Input Vectors Enumeration (a systematical evaluation of each inputvector)– http://example.com/getUserProfile.jsp?item ikki.html– http://example.com/getUserProfile.jsp?item ././././etc/passwd– http://example.com/index.php?file content– http://example.com/main.cgi?home index.htm25 Jan 2007Pag. 28

Authentication testingVulnerable remember password and pwd resetWe test the password reset schema (“security question”) and “cachepassword" functionLogout and Browser Cache Management Testing 25 Jan 2007Check that the application provides a logout functionCheck the session token at logout, and “back button”Re-set the original authc token to test tha application answerTest the time-out logoutCached pages: check for “Pragma: no-cache” directivePag. 29

Session Management TestingSession Management SchemaMario Rossi-- Authentication process --WebApplication[1] https://www.mia-banca.it[2] Sent authentication form over HTTPS25 Jan 2007Pag. 30

Session Management testingMario Rossi-- Authentication process --WebApplication[1] https://www.mia-banca.it[2] Send authentication form over HTTPSUsername/password[3] Insert username/password via HTTPSCredential verify: if ok client authenticated Cookie generation[4] Personal Welcome page and Set CookieCookie TWFyaW8123authenticationtoken25 Jan 2007Pag. 31

Session management testingMario Rossi--Following request--Cookie TWFyaW8123AuthenticationtokenWebApplicationCookie verifing:[5] Request “movimenti”Cookie TWFyaW8123 Identify userSend data to user[6] Response with user data25 Jan 2007Pag. 32

Session management testingSession Token Manipulation cookie collection: collection of a sufficient number of cookie samples; cookie reverse engineering: analysis of the cookie generationalgorithm; Unpredictability Tamper resistance Expiration “Secure” flag cookie manipulation: forging of a valid cookie in order to perform theattack.Exposed Session Variables HTTP Headers Message Body (e.g. POST or page content) Cookies25 Jan 2007Pag. 33

Session management testingCross Site Request ForgeryTest if it is possible to force a user to submit an undesirablecommand to the logged application: html body . img src ”https://www.company.example/action” width ”0” height ”0” . /body /html HTTP Exploit HTTP splitting HTTP smuggling25 Jan 2007Pag. 34

Data validation testingO.SHTTP RequestHTTP ResponseApplicationDataBaseLDAPWhen an HTTP request arrives from a client:the application must validate it before interact with all other application’scomponents: File System, output, HTTP methods, DB, LDAP, XML doc, IMAP/SMTPcommand, OS command, code25 Jan 2007Pag. 35

Data validation testingCross site scriptingCross Site Scripting (XSS) testing when we try to manipulate the parametersthat the application receive in input. A XSS breaks the following pattern:Input - Output cross-site scriptingHTTP Methods and XSTCheck that the web server is not configured to allow potentially dangerousHTTP methods and that XST is not possible. A XST breaks the followingpattern:Input - HTTP Methods XSTSQL InjectionThe goal is to simulate a manipulation of data in the database that representsthe core of every company. An SQL Injection breaks the following pattern:Input - Query SQL SQL injectionThe Guide analyze Oracle, MySql, Ms SQL Servers testing25 Jan 2007Pag. 36

Data validation testingLDAP InjectionSimilar to SQL Injection Testing: the differences are that we use LDAPprotocol instead of SQL and the target is an LDAP Server instead of an SQLServer. An LDAP Injection breaks the following pattern:Input - Query LDAP LDAP injectionXML Injectiontry to inject a particular XML doc to the application: if the XML parser fails tomake an appropriate data validation the test will results positive.An XMLInjection breaks the following pattern:Input - XML doc XML injectionSSI InjectionIf the web server's SSI support is enabled, the server will parse the directivesreceived by the HTML. It can enable an attacker to inject code into html pages,or even perform remote code execution.25 Jan 2007Pag. 37

Data validation testingIMAP/SMTP InjectionCode InjectionOS CommandingBuffer overflowIncubated vulnerability25 Jan 2007Pag. 38

Denial of Service TestingUsually not performed in “live” environment because you can cause service notavailable.DoS are types of vulnerabilities within applications that can allow a malicioususer to make certain functionality or sometimes the entire websiteunavailable. These problems are caused by bugs in the application, oftenresulting from malicious or unexpected user input.Locking Customer AccountsUser Specified Object AllocationUser Input as a Loop CounterWriting User Provided Data to DiskFailure to Release ResourcesStoring too Much Data in Session25 Jan 2007Pag. 39

Web Services TestingSOA (Service Oriented Architecture)/Web services applications are up-andcoming systems which are enabling businesses to interoperate and aregrowing at an unprecedented rate.The vulnerabilities are similar to other “classical” vulnerabilities such as SQLinjection, information disclosure ad leakage etc but web services also haveunique XML/parser related vulnerabilities. Envelope XML Structural Testing Header wsse:Security ?xml version "1.0" encoding "ISO-8859-1"? Hehehe I am a Large String (1MB) /Hehehe note id "666" Hehehe I am a Large String (1MB) /Hehehe to OWASP Hehehe I am a Large String (1MB) /Hehehe from EOIN /from Signature /Signature heading I am Malformed /to /wsse:Security /heading /Header body Example of XML Structural Test /body Body /note BuyCopy ISBN 0098666891726 /ISBN /BuyCopy /Body /Envelope 25 Jan 2007Pag. 40

WS TestingXML content-level TestingAn attacker can craft an XML document (SOAP message) that containsmalicious elements in order to compromise the target system. We test forproper content validation.HTTP GET parameters/REST r 12039475&userId asi9485jfuhe92The resultant response would be similar to: ?xml version "1.0" encoding "ISO-8859-1"? Account "12039475" balance 100 /balance body Bank of Banana account info /body userid myuser /userid password ' OR 1 1 /password /Account Testing the data validation on this REST web service.Try vectors such as:https://www.ws.com/accountinfo?accountnumber 12039475' execmaster.xp cmdshell 'net user Vxr pass /Add &userId asi9485jfuhe9225 Jan 2007Pag. 41

WS TestingNaughty SOAP attachmentsBinary files, including executablesand document types that can containPOST /Service/Service.asmxHTTP/1.1Host: somehostmalware, can be posted using a web service in several ways.Content-Type: text/xml; charset utf-8Content-Length: ice/UploadFile ?xml version "1.0"encoding "utf-8"? Is a "man-in-the-middle"type of test where a message is intercepted and soap:Envelope xmlns:xsi d by an attacker to impersonate the original sender.xmlns:xsd "http://www.w3.org/2001/XMLSchema"xmlns:soap "http://schemas.xmlsoap.org/soap/envelope/" soap:Body UploadFile xmlns "http://somehost/service" filename eicar.pdf /filename type pdf /type chunk X5O!P%@AP[4\PZX54(P )7CC)7} EICAR-STANDARD-ANTIVIRUS-TEST-FILE! H H* /chunk first true /first /UploadFile /soap:Body /soap:Envelope 25 Jan 2007Pag. 42

AJAX TestingAJAX (Asynchronous JavaScript and XML) is a web developmenttechnique used to create more responsive web applications.XMLHttpRequest object and JavaScript to make asynchronous requests forall communication with the server-side application.Security issue: AJAX applications have a greater attack surface because some logic is movedon the client Exposed internal functions of the application Client access to third-party resources with no built-in security and encodingmechanisms Failure to protect authentication information and sessions25 Jan 2007Pag. 43

AJAX TestingThe call endpoints for the asynchronous calls must be enumerated: parsing the HTML and JavaScript files and using a proxy to observetraffic Tool: OWASP Sprajax or Firebug for FirefoxThen you can test it as described before (SQL Inj, etc.)25 Jan 2007Pag. 44

Testing ReportThe OWASP Risk Rating Methodology Estimate the severity of all of these risks to your business This is not universal risk rating system: vulnerability that is critical to oneorganization may not be very important to anotherSimple approach to be tailored for every case standard risk model: Risk Likelihood * ImpactStep 1: identifying a riskYou'll need to gather information about: 25 Jan 2007the threat agent involvedthe attack they're usingthe vulnerability involvedthe impact of a successful exploit on your business.Pag. 45

Testing ReportStep 2: factors for estimating likelihoodGenerally, identifying whether the likelihood is low, medium, or high is sufficient.Rate 0-9.Threat Agent Factors: Skill levelMotiveOpportunitySizeVulnerability Factors: Ease of discoveryEase of exploitAwarenessIntrusion detection25 Jan 2007Pag. 46

Testing ReportStep 3: factors for estimating impactTechnical impact: Loss of confidentialityLoss of integrityLoss of availabilityLoss of accountabilityBusiness impact: 25 Jan 2007Financial damageReputation damageNon-compliancePrivacy violationPag. 47

Testing ReportStep 4: determining the severity of the riskIn the example above, the likelihood is MEDIUM, and the technical impact isHIGH, so from technical the overall severity is HIGH. But business impactis actually LOW, so the overall severity is best described as LOW as well.25 Jan 2007Pag. 48

Testing ReportStep 5: Deciding What To FixAs a general rule, you should fix the most severe risks first.Some fix seems to be not justifiable based upon the cost of fixingthe issue but may be reputation damage from the fraud that couldcost the organization much more than implement a security controlStep 6: Customizing Your Risk Rating Model Adding factors Customizing options Weighting factors25 Jan 2007Pag. 49

Writing ReportI. Executive SummaryII. Technical Management OverviewIII Assessment FindingsIV Toolbox25 Jan 2007Pag. 50

What’s nextYou should adopt this guide in your organizationContinuously reprioritizeWhat’s next: Continuously improve the Testing Guide: it’s a live document! OWASP and ISACA Procedures:(P8) Security Assessment – Penetration Testing and VulnerabilityAnalysis Procedure25 Jan 2007Pag. 51

Thank you!http://www.owasp.orghttp://www.owasp.org/OWASP Testing Projectmatteo.meucci@owasp.org25 Jan 2007Pag. 52

References :OWASP Foundation – “OWASP Building Guide v3” 2006http://www.owasp.org/index.php/OWASP Guide ProjectOWASP Foundation – “ OWASP Testing Guide v2 RC1” 2007http://www.owasp.org/index.php/OWASP Testing ProjectOWASP Foundation – “ OWASP ASP Top Ten ProjectOWASP Foundation Software:WebGoat – http://www.owasp.org/index.php/OWASP WebGoat ProjectWebScarab – http://www.owasp.org/index.php/OWASP WebScarab Project25 Jan 2007Pag. 53

The Open Web Application Security Project (OWASP) is dedicated to finding and fighting the causes of insecure software. The OWASP Foundation is a 501c3 not-for- . OWASP Testing Guide Release Candidate 1: 270 pages, 48 tests Feedback and review Feb 2007: OWASP Testing Guide v2 will be officially released