Generic notes

REST URLs use portions of the URL file path to uniquely identify data and other resources used within the application. Representational state transfer (REST) is a style of architecture for distributed systems in which requests and responses contain representations of the current state of the system’s resources. The term ‘REST-style URL’ is often used to signify a URL that contains its parameters within the URL file path, rather than the query string. Example:

Chapter 4: Mapping the Application

Enumerating Content and Functionality

Tip: Applications that employ REST-style URLs use portions of the URL file path to uniquely identify data and other resources used within the application. The traditional web spider’s URL-based view of the application is useful here.

Limitations of automatic spidering include:

  • Links in compiled client-side objects (JavaScript) may not be picked up
  • Web app (like banking) could implement every user action via a POST request to /account.jsp/ and use parameters to communicate actions.
  • Volatile data (parameters containing timers or random number seeds) is placed in URLs that do not identify resources or functions.
  • User-page tokens cause failure when the spider requests pages outside of the expected sequence, terminating the session.

Benefits of user-directed spidering:

  • user can follow unusual and complex mechanisms for navigation and map them
  • user controls all data submitted to the application
  • user can log in and ensure that the authenticated session remains active when mapping
  • dangerous functionality deleteUser.jsp is fully enumerated

Discovering hidden content:

  • identify backup copies of live files
  • backup archives that contain a full snapshot if files within (or outside) the web root
  • new functionality deployed for testing
  • default application functions in an off-the-shelf application
  • old versions of files
  • configuration and include files
  • source files
  • comments in source code that could contain secrets or information about the application’s state
  • log files that could contain sensitive information (valid usernames, session tokens, URLs visited, actions performed)

Infer naming scheme

  • Numeric values (/01)
  • case naming (ResetPassword, ForgotPassword)
  • Review client-side code (HTML, JavaScript) for comments, files, function names
  • Add common extensions to the list (.txt, .bak, .src, .inc, old) earch for temporary files (.DS_Store, file.php~1, .tmp)
  • Perform these exercises recursively and add new content to wordlist

Search engine use:

  • search tips (#google-dorks): site:website - returns resources within target website site:website expression - returns pages containing the expression link:website - returns pages on other websites and applications that contain a link to the target related: - returns pages that are ‘similar’ to the target
  • browse to the last page of search results and select ‘repeat with omitted results’
  • view cached version of interesting pages if possible
  • perform same queries on other domain names of the organization

Tips for using nikto:

  • server runs a nonstandard location for interesting content (/cgi/cgi-bin instead of /cgi/bin): specify alternate location with option -root /cgi)
  • server uses a custom ‘file not found’ page that does not return 404: specify a string that identifies this page with the -404 option

Application Pages Versus Functional Paths

In applications where functions are identified using a request parameter, rather than the URL, this has implications for the enumeration of application content. Steps to take:

  1. Identify instances where application functionality is accessed not by requesting a specific page but by passing name of a function in a parameter (/admin.jsp?action=editUser).
  2. Modify the automated techniques described above for discovering URL-specified. First determine when an invalid servlet or method is used and when a valid method is requested with invalid parameters.
  3. Compile a map of application content based on functional paths

Discovering hidden parameters Think of an application that behaves differently if the parameter debug=true is added to the query string of a URL. Steps to take:

  1. Use lists of common debug parameters (debug, test, hide, source) and common values (true, yes, on, 1). For POST requests, insert the added parameter to both the URL query string and the message body.
  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 time available target different pages or functions for hidden parameter discovery.