Chapter 4_ MAPPING THE APPLICATION_.md

Chapter 4: MAPPING THE APPLICATION:

Chapter 4: MAPPING THE APPLICATION:

User Directed Spidering:

1. Configure your browser to use Burp as local proxy..(see Chapter 20)
2. Browse the entire application normally, attempting to visit every link/URL you discover, submitting every form and proceeding through all multi-step functions to completion. Browse with JavaScript enabled and disabled and with cookies enabled and disabled. Many applications can handle various browser configurations and you may reach differenct content and code paths within the application
3. Review the site map generated by the proxy/spider tool, and identify any application content or functions that you did not browse manually. Establish how the spider enummerated each item. For example, in Burp spider, check the Linked From details. Using your browser, access the item manually so that the response from the server is parsed by the proxy/spider tool to identify any further content. Continue this step recursively until no further content or functionality is identified.
4. Optionaly, tell the spider tool to spider all of the already enummerated content as a starting point. To do this, first identify any URLs that are dangerous or likely to break the application session, and configure the spider to exclude these from its scope. Run the spide and review the results for any additional content that it discovers.

Discover Hidden Content:

1. Make some manual requests for know valid and invalid resources and identify how the server handles the invalid ones.
2. Uwe the site map generated through the spidering phase as a basis for automated discovery of hidden content.
3. Make automated requests for common filenames and directories within each directory or path known to exist within the application. Use Burp Intruder or custom script together with wordlists of common files and directories, to quickly generate large numbers of requests. If you have identified a particular way in which the application handles requests for invalid resources(e.g. custom "file not found" page), configure Intruder or script to highlight these results soo that they can be ignored.
4. Capture the responses received from the server, and manually review them to identify valid resources.
5. Perform the exercise recursively as new content is discovered.

Inference From Published Content:

1. Review the results of user-directed browsing and basic brute-force exercises. Compile a list of the names of all enumerated subdirectories, file stems and file extensions.
2. Review these lists to identify any naming schemes in use. e.g.) if there are pages called AddDocument.jsp and ViewDocument.jsp, there may also be pages called EditDocument.jsp and RemoveDocument.jsp You can often get a feel for developers' naming habits just by reading a few examples. Depending on their personal style, developers may be vebose(AddANewUser.asp) succint(AddUser.asp), use abreviations (Addusr.asp), or even be more cryptic(AddU.asp). Getting a feel for the naming style may help you guess the precise names of content you have not identified already.
3. Sometimes, the naming scheme used for different content employs identifiers such as numbers and da†es, which can make inferring hidden content easy. ˇhis is most commonly encountered in the names of stå†ic resources, rå†her than dynamic scripts. For example... AnnualReport2009.pdf > AnnualReport2010.pdf etc...
4. Review all client-side code such as HTML and JavaScript to identify any clues about hidden server-side content. These may include HTML comments related to protected or unlinked functions, HTML forms with disabled SUBMIT elements etc... Often, comments are automatically generated by the software that has been used to generate web content, or by the platform on which the application is running. References to items such as server-side include files are of particular interest. These files may actually be publicly downloadable and may contain highly sensitive information such as database connection strings and passwords. In other cases, developers' comments may contain all kinds of useful tidbits, such as database connection strings and passwords. In other cases, developers' comments may contain all kinds of useful tidbits, such as database names, reference to back-end components, SQL query strings etc.. Thick-client components such as Java applets and ActiveX controls may also contain sensitive data that you can extract. See Chapter 15 for more ways in which the application may disclose information about itself.
5. Add to the lists of enumerated items any further potential names conjectured on the basis of the items that you have discovered. Add to the file extension list common extensions such as txt,bak,src,inc,old which may uncover the source to backup versions of live pages. Also add extensions associated with the development language in use, such as .java and .css which may uncover source files that have been compiled into live pages.
6. Search for temporary files tha may have been created inadvertently by developer tools and file editors. Examples include the .DS_Store file, which contains a directory index under OSX.file.php~1, which is a temporary file created when file.php is edited, and the .tmp file extension which is used by numerous tools.
7. Perform further automated exercises, combining the lists of directories, file stems, and file extensions to request large numbers of potential resources. For example, in a given directory, request each file stem combined with each file extension. Or request each directory name as a subdirectory of every known directory.
8. Where a consistant naming scheme has been identified, consider performing a more focused brute-forcing exercise based on this naming convention to find additional files and directories.
9. Peform each exercise recusively, using new enumerated content and patterns as the basis for further user-directed spidering and further automated content discovery.

Application Pages Versus Functional Paths:

1. Identify any instances where application functionality is accessed not by requesting a specific page for that function(such as /admin/editUser.jsp) but by passing the name of a function in a parameter (such as /admin.jsp?action=editUser).
2. Modify the automated techniques described for discovering URL-specified content to work on the content-access mechanisms in use within the application. For example, if the application uses parameters that specify servlet and method names, first determine its behavior when an invalid servlet and/or method is requested, and when a valid method is requested within other invalid parameters. Try to identify attributes of the server's responses that indicate "hits" --valid servlets and methods. If possible, find a way of attacking the problem in two stages, first enumerating servlets and then methods within these. Using a method similar to the one used for URL-specified content, compile lists of common items, add to these by inferring from the names actually observed, and generate large numbers of requests based on these.
3. If applicable, compile a map of application content based on functional paths, showing all the enumerated functions and the logical paths and dependencies between them.

Discovering Hidden Parameters:

1. Using lists of common debug parameter names (debug,test,hide,source,etc...) and common values(true,yes,on,1,etc..) make a large number of requests to a known application page or function, iterating through all permutations of name and value. For POST requests, insert the added parameter to both the URL query string and the message body.
   • Burp Intruder can be used to perform this test using multiple payload sets and the "cluser bomb" attack type (See Chapter 14)
2. Monitor all responses received to identify any anomalies that may indicate that the added parameter has had an effect on the application's processing.
3. Depending on the time available, target a number of different pages or functions for hidden parameter discovery. Choose functions where it is most likely that developers have implemented debug logic, such as login, search and file uploading and downloading.

Identifying Server-Side Technologies:

1. Identify all entry points for user input, including URLs, query string parameters, POST data, cookies, and other HTTP headers processed by the application.
2. Examine the query string format used by the application. If it does not employ the standard format described in Chapter 3, try to understand how parameters are being transmitted via the URL. Virtually all custom schemes still employ some variation on the name/value model, so try to understand how name/value pairs are being encapsulated into the non-standard URLs you have identified.
3. Identify any out-of-bound channels via which user-controllable or other third-party data is being introduced into the application's processing.
4. View the HTTP Server banner returned by the application. Note that in some cases, differnet areas of the application are handled by different back-end components, so different Server headers may be recieved.
5. Check for any other software identifiers contained within any custom HTTP headers or HTML source code comments.
6. Run the hhtprint tool to fingerprint the web server
7. If fine-grained information is obtained about the web server and other components, research the software versions in use to identify any vulnerabilites that may be exploited to advance an attack. (See Chapter 18).
8. Review you map of application URLs to identify any interesting-looking file extensions,directories or other sub-sequences that may provide clues about the technologies in use on the server.
9. Review the names of all session tokens issued by the application to identify the technologies being used.
10. Use lists of common technologies, or Google, to establish which technologies may be in use on the server, or discover other websites and applications that appear to employ the same technologies.
11. Perform searches on Google for the names of any unusual cookies, scripts, HTTP headers, and the like that may belong to third-party software components. If you locate other application in which the same components are being used, review these to identify any additional functionality and parameters that the components support, and verify whether these are also present in your target application. Note that third-party components may look and feel quite different in each implementation, due to branding customizations, but the core functionality, including any script and parameter names, is often the same. If possible, download and install the component and analyze it to fully understand its capabilites and, if possible, discover any vulnerabilities. Consult repositories of knownb vulnerabilites to identify any known defects with the component in question.

Identifying Server-Side Functionality:

1. Review the names and values of all parameters being submitted to the application in the context of the functionality they support.
2. Try to think like a programmer, and imagine what server-side mechanisms and technologies are likely to have been used to implement the behavior you can observe.

Extrapolating Application Behavior:

1. Try to identify any locations within the application that may contain clues about the internal structure and functionality of other areas.
2. It may not be possible to draw any firm conclusions here; however, the cases identified may prove useful at a later stage of the attack when you're attempting to exploit any potential vulnerabilities.

Isolating Unique Application Behavior:

1. Make a note of any functionality that diverges from the standard GUI appearance, parameter naming, or navigation mechanism used within the rest of the application.
2. Also make a note of functionality that is likely to have been added retrospectively. Examples include debug functions, CAPTCHA controls, usage tracking, and third-party code.
3. Perform a full review of these areas, and do not assume that the standard defenses used elsewhere in application apply.

Mapping the Application:

1. Understand the core functionality implemented within the application and the main security mechanisms in use.
2. Identify all features of the application's functionality and behavior that are often associated with common vulnerabilites.
3. Check any third-party code against public vulnerability databases such as whitesource or exploit-db to determine any known issues.
4. Formulate a plan of attack, prioritizing the most interesting-looking functionality and the most serious of the associated potential vulnerabilites.

Key Functionality and Potential Vulnerabilities:

• Client-side validation ==> Checks may not be replicated on the server.
• Database interaction ==> SQL injection
• File uploading and downloading ==> Path traversal vulnerabilites, stored XXS
• Display of user-supplied data ==> XXS
• Dynamic Redirects ==> Redirection and header injection attacks
• Social networking features ==> username enumeration, stored XSS
• Login ==> username enumeration, weak passwords, ability to use brute force
• Multistage Login ==> Logic flaws
• Session State ==> Predicatable tokens, insecure handling of tokens
• Access Controls ==> Horizontal and vertical privilege escalation
• User Impersonation Functions ==> Priv esc
• Use of cleartext communications ==> Session hijacking, capture of credentials and other sensitive data.
• Off-Site Links ==> Leakage of query string parameters in the Referer header
• Interfaces to External Systems ==> Shortcuts in the handling of sessions and/or access controls
• Error Messages ==> Information leakage
• E-mail Interaction ==> E-mail and/or command injection
• Native Code Components or Interaction ==> Buffer Overflows
• Use of third-party Application Components ==> Known vulnerabilities
• Identifiable Web Server Software ==> Common configuration weaknesses, know software bugs.