Web Application Security Testing

WEB APPLICATION SECURITY TESTING – 4. APPLICATION MAPPING

This notes is for learning/educational purpose only. Use it at your own risks. 

First step to attack an application is to gather and examine some key information.

  • Enumerate application’s content and functionality.
  • Some functionality might be hidden requiring guesswork and luck to discover.
  • Examine every aspect of behavior, security mechanisms and technologies.
  • Helps in determining attack surface and vulnerabilities.

ENUMERATING CONTENT & FUNCTIONALITY

Majority of content and functionality can be identified via manual browsing. To perform rigorous inspection of enumerated content and to obtain comprehensive record of everything identified, more advanced techniques must be employed.

Web Spidering

  • Requesting web pages recursively by parsing.
  • Webapp Spiders can parse HTML forms, fill forms with preset or random values to submit.
  • Webapp Spiders can also parse client side JS to extract URLs.
  • Common web app spidering tools are – Burp Suite, WebScarab, ZAP and CAT.

Robots.txt

  • Intended to stop search engines from indexing urls.
  • May guide spiders to interesting content.

Limitations of Automatic Spidering

  • May fail to handle unusual navigation mechanisms i.e. Menus created dynamically.
  • Links buried in compiled client-side objects i.e. flash or java might be missed.
  • Forms may have validation checks.
  • Spiders fetch each URL once, but app using forms-based navigation may return different content and functions for same URL.
  • Some apps place volatile data within URLs i.e. timers or random number seeds. Spider will fetch same page over and over thinking its new and finally might freeze up.
  • Spiders must be able to submit valid credentials, perhaps using valid cookie. However, spiders often break authenticated session by requesting logout function or submitting invalid input to sensitive function or requesting pages out-of-sequence.
  • Spiders may find administrative page and click every link i.e. delete user, shut down db or server etc.

User directed Spidering

It is more sophisticated and controlled technique than automated spidering. User walks through app using browser connected to Burp. Proxy collects all requests and responses.

So user can follow complex navigation mechanisms. User can enter valid data where needed and avoid dangerous functionality.

TIP: Other tools useful during mapping are browser extensions performing HTTP and HTML analysis. i.e. IEWatch in IE. It analyzes every app page to display links, scripts, forms and think-client components.

HACKSTEPS For Spidering:

  1. Configure browser to use local proxy i.e. Burp or WebScarab
  2. Browse entire app normally, visit every link/url, submit every form, proceed with multistep functions. Try browsing with JS enabled and disabled, cookies enabled and disabled.
  3. Review sitemap generated. Identify if any app content/function you did not visit.
  4. Tell tool to actively spider site using already enumerated content. Identify URLs that are dangerous or likely to break app session & configure spider to exclude these from scope.

Discovering Hidden Content

  • Finding it requires automated testing, manual testing and luck.
  • It can be testing or debugging feature left in application. Or it can be feature for different category of users. There can be source files, backup copy of files, backup archive of entire source code, configuration files, log files or new functionality yet to be linked etc.

Brute Force Techniques
When the user-directed spidering has left with some URLs. Brute forcing the URLs for hidden directories or sub-directories using list of common directory names can be useful. This can be done with Brup Intruder.

NOTE: Some apps might respond to non-existent resource with 200 OK and error message and non-200 response for existent resource.

  • 302 Found – If redirect is to login page, resource might be accessible to authenticated users only. If redirect is to an error, this indicates a different reason. If redirect is to another location, redirect may be part of apps intended logic, & this should be investigated further.
  • 400 Bad Request – App may use custom naming scheme for directories and files within URLs. It is also possible that word list contains some whitespace or other invalid syntax.
  • 401 Unauthorized or 403 Forbidden – Requested resource exist but may not be accessed by any user.
  • 500 Internal Server Error – App expects certain parameters to be submitted when requesting resource.

HACKSTEPS for Discovering Hidden Content:

  1. Make manual requests for valid and invalid resources and identify how server handles
  2. Use sitemap as basis for automated discovery of hidden content
  3. Make automated requests for common filenames and directories to highlight results for invalid resources.
  4. Capture responses received from server and manually review them to identify valid resources.
  5. Perform exercise recursively as new content is discovered.

Inference from Published Content

  • Identify patterns if any from discovered URLs or content to customize enumeration exercise.
  • Names may use numbers or dates.
  • Comments may include DB names or SQL query strings.
  • Applets and ActiveX controls may have sensitive information.
  • Search for temp files created by tools and file editors. i.e. .tmp
  • .DS_Store – a directory index created by Mac OS X
  • Advanced search with site:, link:, related: google operators.

Dirbuster project

Useful when performing automated content discovery tasks. It includes large lists of directory names ordered by frequency of occurrence.

Google’s SkipFish

Vulnerability scanner but main strength is finding files and folders.

Nikto and Wikto

  • Scan servers for known vulnerable files and versions. Wikto is windows version and Nikto is Linux version.
  • Has false positives like other, verify results with manual testing.
# nikto -host blog.saurabh.world

Functional Paths

  • Different from old style tree-structured file system.
  • Every request goes to same URL, but parameters specify function.

HACKSTEPS for Enumerating Functional Paths:

  1. Identify any instance where functionality is accessed by passing name of function in parameter
  2. Identify system behavior with valid and invalid parameter values. Find attributes of responses that indicate ‘hits’. Breakdown enumeration in multiple steps if multiple parameters are used to access a function.
  3. Compile a map of app content based on functional paths, showing all enumerated functions and logical paths and dependencies between them.

Discovering Hidden Parameters

  1. Use list of common debug parameter names (debug, test, hide, source, etc.) and common values (true, yes, on, 1 etc.) to make requests to known app page or function. For POST requests, insert parameter to both URL query string and message body. Burp Intruder can do this using multiple payload set and cluster bomb attack type.
  2. Monitor all responses to identify any anomalies indicating any effect on app’s processing.
  3. Target different pages and functions, most likely to place like login, search, file upload and download etc. where debug logic might be implemented.

ANALYZING APPLICATIONS

The task of analyzing app’s functionality, behavior, and technologies employed to identify the key attack surfaces is also important.

Key areas are:

  • Core functionality
  • Peripheral behavior: off-site links, error messages, administrative and logging functions and redirects.
  • Core security mechanisms: session state, access control, authentication mechanism and supporting logic
  • Everywhere the app processes user-supplied input i.e. URL, query string, POST data, cookies
  • Client side technologies i.e. forms, scripts, thick-client components (Java applets, ActiveX controls and Flash) and cookies.
  • Server side technologies i.e. static & dynamic pages, request params, SSL, web server software, DB interactions, email systems and other backend components.

Entry Points for User Input

  • URL File paths
    • RESTful URLs put parameters where folder names would go.
  • Request Parameters
    • Some non standard parameter formats
      • /dir/file;foo=bar&foo2=bar2
      • /dir/file?foo=bar$foo2=bar2
      • /dir/file/foo%3dbar%26foo2%3dbar2
      • /dir/foo.bar/file
      • /dir/foo=bar/file
      • /dir/file?param=foo:bar
      • /dir/file?data=%3cfoo%3ebar%3c%2ffoo%3e%3cfoo2%3ebar2%3c%2ffoo2%3e
  • Placing payloads within embedded XML data fields may give critical bug like SQLi or path traversal
  • HTTP Headers
    • User-Agent is used to detect small screens and sometimes to modify content to boost search engine rankings. May allow XSS and other injection attacks. Also, may reveal different UI.
    • Apps behind load balancer or proxy may use ‘X-Forwarded-For’ header to identify source & log it.
    • Attacker can add additional headers too which app might process.

Out-Of-band Channels

Finding out of band channel from which app receives data can be difficult and usually requires understanding of wider context of functionality that app implements. Example-

  • Web mail app processes email received via SMTP.
  • Publishing app uses function to retrieve content via HTTP from another server.
  • IDS gathers data using sniffer and presents using web interface.
  • Application providing APIs.

Identifying Server-Side Technologies

  • Banner Grabbing
    • Version information of web server and other component might be disclosed.
    • Web page templates may have version information
    • Custom HTTP headers reveal possible web server software
    • URL query string parameters
  • HTTP Fingerprinting
    • Httprecon uses subtle clues to identify versions, not just banners.
  • Wapplyzer
  • File Extensions – Discloses platform or language
    • asp – Microsoft Active Server Pages
    • aspx – Microsoft ASP.NET
    • jsp – Java Server Pages
    • cfm – Cold Fusion
    • php – PHP language
    • d2w – WebSphere
    • pl – perl language
    • py – python language
    • dll – Compiled native code of C/C++
    • nsf/ntf – Lotus Domino
  • Error Messages
    • Error pages for known and unknown and invalid file extensions
  • Directory names
    • servlet – Java Servlets
    • pls – Oracle AppServer PL/SQL gateway
    • cfdocs/cfide – Cold Fusion
    • SilverStream – SilverStream Web server
    • WebObjects or {function}.woa – Apple WebObjects
    • rails – Ruby on Rails
  • Session Tokens
    • JSESSIONID – Java platform
    • ASPSESSIONID – Microsoft IIS Server
    • ASP.NET_SessionId – Microsoft ASP.NET
    • CFID/CFTOKEN – Cold Fusion
    • PHPSESSID – PHP
  • Third-Party Code components
    • Web app incorporate third party code to implement common functionality i.e. shopping carts, login mechanism etc. It can be open source or purchased. One can download and install to perform source code review or probe for defects in controlled way.

HACKSTEPS for Finding input points and identifying technologies employed:

  1. Identify all entry points for user input i.e. URLs, query string parameters, POST data, cookies, and HTTP headers
  2. Identify query string format; should be some variation on name/value pair.
  3. Identify out-of-bound channels for incoming data to app
  4. View HTTP Server banner.
  5. Check for software identifiers in HTTP header or HTML source code
  6. Run httprint to fingerprint web server
  7. Research software versions for vulnerabilities
  8. Review map of URLs and cookies to identify server side technologies

Identifying Server-Side Functionality

  • Dissecting Requests
    • Review names and values of all parameters being submitted to app in context to functionality
    • Think like programmer, imagine what server-side mechanism is likely being used to implement the behavior.
  • Extrapolating Application Behavior
    • Often application behaves consistently across range of its functionality. So if SQLi is filtered try somewhere else to see what filtering is done. If app obfuscates data, try somewhere original string is returned. Or try to deduce obfuscation scheme.
  • Isolating Unique Application Behavior
    • Note any functionality that diverges from standard appearance, parameter naming or navigation mechanism.
    • Note any functionality that have been added retrospectively i.e. debug functions, CAPTCHA controls, usage tracking and third-party code.
    • It is very much possible that standard defenses of framework might not be applied in such cases.

Mapping the Attack Surface

Identify attack surfaces exposed and possible vulnerabilities associated with each one.

  • Client side validation – Checks may not be replicated on server
  • Database interaction – SQLi
  • File upload/Download – Path traversal, Stored XSS
  • Display of user supplied data – XSS
  • Dynamic redirects – Redirection and Header injection
  • Social networking features – Username enumeration, Stored XSS
  • Login – Username enumeration, Weak passwords, Bruteforce
  • Multistage login – Logic flaws
  • Session state – Predictable tokens, Insecure handling of tokens
  • Access Controls – Horizontal and Vertical PE
  • User impersonation functions – PE
  • Cleartext communications – Session Hijacking, Credential/Sensitive data Sniffing
  • Off-Site Links – Leakage of query string parameters in ‘Referer’
  • Interface to external systems – Shortcuts in handling sessions and/or access controls
  • Error messages – Information leakage
  • E-mail interaction – Email and/or command injection
  • Native code components or interaction – Buffer overflow
  • Third party components – Known vulnerabilities
  • Identifiable web server software – Common config weakness, known software bugs

HACKSTEPS for Identifying functionality and mapping attack surface :

  1. Understand core functionality implemented within app and main security mechanism in use.
  2. Identify all features of apps functionality often associated with common vulnerabilities.
  3. Check third party code against public vulnerability database to determine any known issues.
  4. Formulate plan of attack, based on interesting functionality and serious vulnerability
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s