4.0

86Web Application Penetration Testingfore vital in the overall security of the application. Being able to tamperwith cookies may result in hijacking the sessions of legitimateusers, gaining higher privileges in an active session, and in generalinfluencing the operations of the application in an unauthorized way.In this test the tester has to check whether the cookies issued to clientscan resist a wide range of attacks aimed to interfere with thesessions of legitimate users and with the application itself. The overallgoal is to be able to forge a cookie that will be considered validby the application and that will provide some kind of unauthorizedaccess (session hijacking, privilege escalation, ...).Usually the main steps of the attack pattern are the following:• cookie collection: collection of a sufficient number of cookie samples;• cookie reverse engineering: analysis of the cookie generationalgorithm;• cookie manipulation: forging of a valid cookie in order to performthe attack. This last step might require a large number of attempts,depending on how the cookie is created (cookie brute-force attack).Another pattern of attack consists of overflowing a cookie. Strictlyspeaking, this attack has a different nature, since here testers are nottrying to recreate a perfectly valid cookie. Instead, the goal is to overflowa memory area, thereby interfering with the correct behavior ofthe application and possibly injecting (and remotely executing) maliciouscode.How to TestBlack Box Testing and ExamplesAll interaction between the client and application should be tested atleast against the following criteria:• Are all Set-Cookie directives tagged as Secure?• Do any Cookie operations take place over unencrypted transport?• Can the Cookie be forced over unencrypted transport?• If so, how does the application maintain security?• Are any Cookies persistent?• What Expires= times are used on persistent cookies, and are theyreasonable?• Are cookies that are expected to be transient configured as such?• What HTTP/1.1 Cache-Control settings are used to protect Cookies?• What HTTP/1.0 Cache-Control settings are used to protect Cookies?Cookie collectionThe first step required to manipulate the cookie is to understand howthe application creates and manages cookies. For this task, testershave to try to answer the following questions:• How many cookies are used by the application?Surf the application. Note when cookies are created. Make a listof received cookies, the page that sets them (with the set-cookiedirective), the domain for which they are valid, their value, and theircharacteristics.• Which parts of the the application generate and/or modify thecookie?Surfing the application, find which cookies remain constant and whichget modified. What events modify the cookie?• Which parts of the application require this cookie in order to beaccessed and utilized?Find out which parts of the application need a cookie. Access a page,then try again without the cookie, or with a modified value of it. Try tomap which cookies are used where.A spreadsheet mapping each cookie to the corresponding applicationparts and the related information can be a valuable output of thisphase.Session AnalysisThe session tokens (Cookie, SessionID or Hidden Field) themselvesshould be examined to ensure their quality from a security perspective.They should be tested against criteria such as their randomness,uniqueness, resistance to statistical and cryptographic analysis andinformation leakage.• Token Structure & Information LeakageThe first stage is to examine the structure and content of a Session IDprovided by the application. A common mistake is to include specificdata in the Token instead of issuing a generic value and referencingreal data at the server side.If the Session ID is clear-text, the structure and pertinent data may beimmediately obvious as the following:http: /foo.bar/showImage?img=img00011If part or the entire token appears to be encoded or hashed, it shouldbe compared to various techniques to check for obvious obfuscation.For example the string “192.168.100.1:owaspuser:password:15:58”is represented in Hex, Base64 and as an MD5 hash:HexBase64MD53139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=01c2fc4f0a817afd8366689bd29dd40aHaving identified the type of obfuscation, it may be possible to decodeback to the original data. In most cases, however, this is unlikely. Evenso, it may be useful to enumerate the encoding in place from the formatof the message. Furthermore, if both the format and obfuscationtechnique can be deduced, automated brute-force attacks could bedevised.Hybrid tokens may include information such as IP address or User IDtogether with an encoded portion, as the following:owaspuser:192.168.100.1:a7656fafe94dae72b1e1487670148412Having analyzed a single session token, the representative sampleshould be examined. A simple analysis of the tokens shouldimmediately reveal any obvious patterns. For example, a 32 bittoken may include 16 bits of static data and 16 bits of variabledata. This may indicate that the first 16 bits represent a fixed attributeof the user – e.g. the username or IP address. If the second