A Web Application Hacker's Methodology

General Guidelines

  • Special characters have special meanings in different parts of an HTTP request.
  • URL-encoded data entered into form may add another layer of encoding
  • Previous requests may affect the responses and state of app in future requests.
  • Load-balanced web apps may pass HTTP requests to different servers.

Map the Application Content

  1. Linked Content
    1. Explore Visible Content
      1. Configure browser for proxy/spider tool like Burp and WebScarab
      2. Configure browser to use extension like IEWatch for monitoring and analyzing content
      3. Browse entire app in normal manner
      4. Use login to access protected functionalities
      5. Monitor responses and requests to further understand submitted data
      6. Review site map from passive spidering and ID content not walked through normally
      7. Use active spidering tool
    2. Consult Public Resources
      1. Use search engines and archives (like Wayback Machine) for indexed content
      2. Use advanced search options when using a search engine
      3. Perform searches on names and emails in the website content
      4. Review published WSDL files to generate list of function names and parameters
  2. Other Content
    1. Discover Hidden Content
      1. Confirm how app handles requests for nonexistent items
      2. Obtain list of common file, directory names, and common file extensions.
      3. Review client-side code
        • Look for hidden server-side information from comments
      4. Use automation techniques to make a large number of requests for enumeration.
      5. Perform content-discovery exercises recursively.
    2. Discover Default Content
      1. Run Nikto/Wikto against web server to detect default or publicly known content that is present.
      2. Verify potentially interesting findings manually
      3. Request server root directory specifying the address in the Host header to see if different content arises
      4. Make requests to the server root directory with many different user-agents
  3. Non-standard access methods
    1. Enumerate Identifier-Specified Functions
      1. Identify instances where functions are accessed by passing identifier parameters
      2. Apply content discovery techniques
      3. Compile a map of application content based on functional paths
    2. Test for Debug Parameters
      1. Choose 1+ app pages/functions where hidden debug parameters are implemented.
      2. Use listings of common debug names and common values.
      3. Review application responses for anomalies.

Analyze the Application

  1. Identify Functionality
    • Identify core functionality app was created for.
    • Identify core secure mechanisms used in the app.
      • Authentication, session management, access control
    • Identify peripheral functions and behaviours.
      • Redirects, off-site links, error messages, admin and logging functions
    • Identify functionality diverging from standard GUI appearance, parameter names, etc.
  2. Identify Data Entry Points
    • Identify different entry points existing for user input into application processing.
      • URLs, query strings parameters, POST data, cookies, HTTP headers
    • Examine any customized data transmission or encoding mechanisms
      • e.g. nonstandard query string format
  3. Identify the Technologies Used
    • Identify each of the technologies used on the server side
      • e.g. forms, scripts, cookies, Java applets, ActiveX controls, Flash objects
    • Establish which technologies are used on the server side
      • scripting languages, application platforms, interactions with backend parts
    • Check HTTP Server header returned in application responses
      • Look for software identifiers
    • Run Httprint tool to fingerprint web server
    • Review results from content-mapping exercises
      • Identify interesting file extensions, directories, etc.
    • Identify interesting script names and query string parameters related to third-party code components.
      • Search using 'inurl:' qualifier in a google search.
  4. Map the Attack Surface
    • Try to understand internal structure and functionality of server-side application
    • For each functionality component, identify relevant and associated common vulnerabilities.
    • Form a plan of attack, prioritizing most interesting functions and most serious vulnerabilities associated with them.

Test Client-Side Controls

  1. Test Transmission of Data Via the Client
    1. Locate hidden form fields, cookies, and URL parameters used to transmit data via client.
    2. Attempt to determine purpose items play in app logic, based on their context.
    3. Modify item values in ways relevant to their apparent roles.
    4. If app transmits opaque data via client, you may be able to:
      • Decipher the obfuscation algorithm
      • Replay the item in other contexts
    5. If ASP.NET ViewState is used, test whether it can be tampered with or if it contains sensitive information
      • Use ViewState analyzer in Burp Suite to confirm if EnableViewStateMac is enabled to check if it can be modified.
      • View the decoded ViewState to find any sensitive data
      • Modify the decoded parameter values and reencode and submit the ViewState.
  2. Test Client-Side Controls Over User Input
    1. Identify any client-side controls like length limits and JavaScript checks that validate user input.
    2. Test each input field by submitting input that would normally be blocked.
    3. Review what validation is performed and confirm whether the application is relying upon client-side validation.
    4. Review each HTML form for disabled elements.
  3. Test Browser Extension Components
    1. Understand the Client Application's Operation
      • Setup a local intercepting proxy for the client technology and monitor traffic passing between it and the server.
      • Step through functionality presented in the client to find any sensitive or powerful functions.
    2. Decompile the Client
      • Identify any applets in the application
        • .class, .jar : Java
        • .swf : Flash
        • .xap : Silverlight
      • Review all calls made to applet methods to determine whether data returned from the applet is submitted to the server
      • Download the applet bytecode by entering the URL into your browser and save the file locally
      • Use a tool to decompile the bytecode into source code
        • Java: Jad
        • Flash: SQFScan, Flasm/Flare
        • Silverlight: .NET Reflector
      • Review source code to understand what processing is performed
      • Determine if applet contains public methods that can be used to perform the same obfuscation of input.
        • If not, modify the applet source to neutralize validation performed or allow your own obfuscation.
    3. Attach a Debugger
      • For large client-side apps, sometimes hard to decompile a whole app, modify it, and repackage it without many errors, so just attach a runtime debugger to the process
        • JavaSnoop, Silverlight Spy
      • Locate key functions and values the app employs to drive security-related business logic and set breakpoints by them.
    4. Test ActiveX Controls
      • Identify any ActiveX controls used in the app.
      • Try to subvert input validation by attaching a debugger to the process and modify data being processed.
      • Try to guess the purpose of different methods based on names and parameters.
      • If purpose it to get or verify certain information about the client computer, use Filemon or Regmon tools to monitor the information the control gathers.
      • Test controls for vulnerabilities that can be exploited to attack other users of the app.

Testing the Authentication Mechanism

  1. Understand the Mechanism
    1. Establish authentication technologies used
      • Forms, certificates, multifactor
    2. Locate all authentication-related functionality
      • e.g. login, registration, account recovery
    3. If no automated self-registration found, determine if any other means exists of obtaining several user accounts
  2. Data Attacks
    1. Test Password Quality
      • Review app for description on minimum password requirements.
      • Try to set many kinds of weak password using self registration or password change functionalities
        • Checks whether its actually enforced.
      • Test for incomplete validation of credentials
      • Having established the minimum requirements, identify the range of values a password guessing attack would need to employ for a probability of success.
    2. Test for Username Enumeration
      • Identify locations in authentication functions where usernames are submitted
        • e.g. login, self-registration, password change, logout, and account recovery
      • For each location, submit a valid and invalid username -- then review every detail of the server responses
      • If any differences between responses exist, repeat the test with a different pair of values to confirm systematic difference
      • Check for sources of info leakage that would allow for compiling a list of valid usernames
        • e.g. login functionality, actual user listings, direct mentions
    3. Test Reliance to Password Guessing
      • Identify locations where user credentials are submitted
      • At each location, use an account you control and manually send several requests containing the username and an invalid credential.
      • If no accounts are controlled, attempt to enumerate or guess a valid username and make several invalid requests using a guess. Monitor the output for errors
  3. Special Functions
    1. Test Any Account Recovery Function
      • Identify if app has means for users to regain control of an account if they forgot their credentials.
      • Establish how it works by doing a complete walkthrough.
      • If a challenge is used, like a challenge question, determine if users can set or select their own challenge during registration.
      • If there is a password hint, try to harvest a list of password hints and ID any that may be easily guessable
      • If function involves sending an email, look for weaknesses allowing you to take control of other accounts.
    2. Test Any Remember Me Function
      • If there is a remember me function, activate it and review the effects.
      • Inspect persistent cookies that are used.
      • Compare results among many users and passwords
      • Modify the contents of the cookie in meaningful ways to attempt to masquerade as other users.
    3. Test Any Impersonation Function
      • If impersonation is a functionality, review it closely to see if there are vulnerabilities allowing for it without proper authorization.
      • Look for user-supplied data used to determine the target and attempt to manipulate it to impersonate other users.
      • Look for accounts that appear to have more than one valid passwords or multiple accounts with the same password.
  4. Credential Handling
    1. Test Username Uniqueness
      • Attempt to register for the same username twice.
      • If the second attempt is blocked, you can use it to enumerate usernames.
      • If the app registers both accounts, probe further to determine when a collision of username and password occurs. Try to change the password such that they both match, such as registering two users with identical usernames and passwords.
      • If the app alerts you or causes an error upon this collision, this can be used for an automated guessing attack.
      • If the app allows the collision, log in using the colliding credentials and see what happens now.
    2. Test Predictability of Autogenerated Credentials
      • If automatically generated usernames and passwords are used, try to get many values in succession.
      • If usernames are predictable, extrapolate backwards to get a list of possible usernames
      • If passwords are predictable, extrapolate the pattern to get a list of possible passwords given to other users.
    3. Check for Unsafe Transmission of Credentials
      • Walk through all authentication-related functions involving the transmission of credentials
      • Identify every case where credentials are transmitted in either direction
      • If credentials are transmitted via the URL query string, these may be vulnerable to a disclosure in browser history, on screen, in server logs, and the Referer header of third-party links
      • If credentials are stored in a cookie, they may be vulnerable to disclosure via XSS or local privacy attacks
      • If transmitted from server to client, these may be compromised via vulnerabilities in session management or access controls or XSS
      • If transmitted over unencrypted connection, they may be vulnerable to an eavesdropper
      • If submitted via HTTPS but the login form uses HTTP, it may be vulnerable to a MitM attack.
    4. Check for Unsafe Distribution of Credentials
      • If created using an out-of-band channel, or self-registration does not determine initial credentials, find out how credentials are distributed to new users.
      • If the app generates user activation URLs distributed out-of-band, try to register several users in close succession to identify a pattern.
      • Try to reuse an activation URL multiple times.
    5. Test for Insecure Storage
      • If you can get access to hashed passwords, check for accounts that share the same hashed value.
      • Use an offline rainbow table for the hashing algorithm to determine the cleartext value
  5. Test for Logic Flaws
    1. Test for Fail-Open Conditions
      • For each function where the app checks the user credentials, walk through the process with a controlled account.
      • Repeat the process multiple times, changing each parameter in unexpected ways to see how it interferes with the app logic.
        • Submit empty string for the value
        • Remove the name/value pair
        • Submit very long and very short values
        • Submit strings instead of numbers
        • Submit the same named parameter multiple times, with same and different values
      • Review the responses to the previous requests closely.
    2. Test Any Multistage Mechanisms
      • If authentication functions involve submitting credentials in a series of different requests, identify the purpose of each distinct stage and note each parameter used
      • Repeat the process multiple times, modifying the sequence of requests in ways that may interfere with app logic
        • Process through all stages, but in a different sequence
        • Jump to a stage then continue normally
        • Try skipping a stage and then continuing normally
      • Determine if any piece of info is submitted at more than one stage
      • Look for data transmitted via the client that has not been captured from a user at any point.
      • If any part contains a given challenge
        • If parameter specifying the challenge is submitted in a user response, check if you can choose your own challenge by changing the value
        • Try going up to the challenge many times and see if a different challenge is given each time.
  6. Exploit Any Vulnerabilities to Gain Unauthorized Access
    1. Review vulnerabilities identified in various authentication functions and identify any that can be leveraged to attack the app
    2. ote any account lockout defenses.
    3. Take account of password quality rules and completeness when creating wordlists
    4. Use techniques from chapter 14 to automate as much work as possible.

Test the Session Management Mechanism

  1. Understand the Mechanism
    1. Analyze how the app manages sessions and state.
      • Session tokens or another method?
    2. If session tokens used, confirm which pieces of data are used to re-identify users.
    3. Very which items are employed as session tokens by finding a page or function that is session dependent.
    4. With each token, confirm if it is validated in its entirety or just its subcomponents.
  2. Token generation
    1. Test Tokens for Meaning
      • Login using several users at different times, recording tokens received.
      • Analyze tokens you receive for correlations related to username or other user controllable data
      • Analyze tokens for detectable encoding or obfuscation
      • Check if meaningful data found is sufficient to mount an attack to guess tokens issues to app users.
    2. Test Tokens for Predictability
      • Get a large set of session tokens
      • Identify any patterns in your sample of tokens.
      • If pattern found, get a second sample of tokens from a different IP and a different username.
      • If exploitable sequences or time dependencies found, consider if sufficient to perform password guessing.
      • If session ID appears to be custom-written, use a bit flipper payload from Burp Intruder to modify each bit in the session token in turn.
  3. Token handling
    1. Check for Insecure Transmission of Tokens
      • Walk through the app normally. Make note of when a new session token is issued.
      • If HTTP cookies used as transmission mechanism for session tokens, verify if the secure flag is set.
      • Determine if session tokens are transmitted over HTTP connection.
      • If HTTP used for unauthenticated areas but HTTPS used for authenticated areas, check if a new token is issued.
      • If HTTPS are contains HTTP URL links, follow these and check if the session token is submitted.
    2. Check for Disclosure of Tokens in Logs
      • If app mapping identified any logging, monitoring, or diagnostic functionality, identify where these functions to see if session tokens are disclosed in them.
      • Identify any instances where session tokens are transmitted in a URL.
      • If a method is found to gather valid session tokens for other users, look for means to test each token to see if it is an admin user.
    3. Check Mapping of Tokens to Sessions
      • Log in twice using the same user. Check if both sessions remain concurrently.
      • Login and logout many times. Check if a new session token is issued each time and whether the same token is issued every time the same account logs in.
      • If tokens appear to contain structure or meaning, try to separate components out that can identify the user
    4. Test Session Termination
      • Focus on server handling of sessions and tokens, rather than client event occurrences.
      • Check if session expiration is implemented on the server:
        • Login to get a valid session token.
        • Wait a while of not using the token, then submit a request to a protected page using the same token
        • If it displays fine, the token is still active
        • Use trial and error to find out how long session expiration timeout is.
      • Check if the logout function exists, and if it does whether it invalidates the user session on the server.
    5. Check for Session Fixation
      • If the app issues session tokens to unauthenticated users, try and get one and perform a login. If it doesn't issue a new one, session fixation vulnerabilities exist.
      • If it does not issue session tokens to unauthenticated users, obtain a token by logging in and return to the login page. Try logging in as another user if you can, and if a new session token is not given, session fixation still exists.
      • Identify session token format; modify it to another valid formed value.
      • If the app does not support login, but processes sensitive user info and allows it to be displayed after submission, carry out the previous three tests on the sensitive page.
    6. Check for CSRF
      • If the app only uses HTTP cookies, it may be vulnerable to CSRF.
      • Review the app key functionality and identify specific, sensitive requests
      • Create an HTML page that will issue the desired request without any user interaction
      • If the app uses additional tokens within requests in an attempt to prevent CSRF, test these additional tokens like what was previously explained.
    7. Check Cookie Scope
      • If the app uses HTTP cookies, review Set-Cookie headers and check for domain and path attributes for their relevant scope.
      • If the app liberalizes its cookies scope to a parent domain or directory, it may be vulnerable to attacks from other web apps hosted on the parent domain.
      • If the app sets the cookie domain to its own domain name, it may still be exposed to attacks via any apps on the subdomain.
      • Determine reliance on segregation by path.
      • Identify all possible domain names and paths that will receive the cookies that the app issues.

Test Access Controls

  1. Understand the Access Control Requirements
    • Understand requirements for access control
      • Vertical segregation
      • Horizontal segregation
    • Review application mapping results to recognize areas relevant to privilege escalation attacks
    • Perform testing for access control vulnerabilities. Try to get multiple accounts with multiple privilege levels both horizontal and vertical.
  2. Test with Multiple Accounts
    • If vertical segregation is enforced, use a powerful account to locate all functionalities.
      • Using burp, browse app context with a user context
      • Review contents of Burp site map to be certain all functionalities is identified that you want to test.
    • If horizontal segregation exists, perform the same test on two different accounts with the same privilege levels and try to access the other's data.
    • Perform manual checks of access control logic
      • With each user privilege, review available resources. Try to access unauthorized user data by replaying requests.
    • When performing an access control test, test all steps of multistage functions to check that access control is used at each stage.
  3. Test with Limited Access
    • If no prior access to accounts with different privilege levels is obtainable, or each account has different data, test for broken access controls.
    • Consider that the app mapping using a low privilege user might show urls that require admin access
    • Decompile all compiled clients and extract references to server-side functionality
    • Test whether access controls are effective using an account and guess or discover identifiers for content of other user data.
    • If identifiers are predictable, try to enumerate through them and automate it to try and harvest interesting data
  4. Test for Insecure Access Control Methods
    • Access control in some apps is implemented using request parameters, like 'edit=false'. Try to modify these.
    • Some apps base access control decisions on the "Referer" header, try to modify these too.
    • If HEAD is an allowed method, test for insecure container managed access control to URLs.

Test for Input-Based Vulnerabilities

  1. Fuzz All Request Parameters
    1. Review results of app mapping and identify every unique client request that submits parameters.
    2. Fuzz these parameters using custom scripts or a fuzzing tool.
      • Using the payloads tab in Burp Intruder, create a set of attack payloads to probe for vulnerabilities.
      • Make sure to try URL encoding special characters too, or do so normally if its in the request rather than in a POST body.
      • Using the grep function in Burp Intruder, get a set of strings denoting error messages in responses.
      • Select the Payload Grep option to recognize responses containing the payload itself.
      • Setup a web server or netcat listener on the host specified in the file inclusion payload.
      • Launch the attack and review the results for anomalies in responses.
    3. For each potential vulnerability, attempt further testing as needed.
    4. Repeat the Burp Intruder custom test on other parts of the app as needed
    5. If out-of-band input channels were recognized in previous mapping, perform similar fuzzing on those.
    6. Run an automated vulnerability scan and compare with your own results.
  2. Test for SQL Injection
    1. If SQLi fuzz attack strings cause anomalous responses, test this parameter manually to see if the vulnerability exists.
    2. If database errors are returned, look up their meaning.
    3. If submitting a single quotation mark causes an error or weird behavior, try submitting two question marks.
      • If the error goes away, it might be vulnerable to SQLi
    4. Try using SQL string concatenator functions to create a string equivalent to some input.
    5. If the original input is numeric, try using a math expression equivalent to the original value.
      • If this works, it might be vulnerable to SQL mathematical expression injections
    6. If fuzz test cases using waitfor result in a time delay, it is MS-SQL and might be vulnerable to SQLi
    7. If the app is vulnerable to SQLi, consider what attacks can be performed to achieve any objectives.
  3. Test for XSS and Other Response Injection
    1. Identify Reflected Request Parameters
      • Sort results of fuzz testing by using Payload Grep column, and identify matches for XSS payloads (if using Burp Intruder)
      • For each case, review the app response to find location of supplied input.
    2. Test for Reflected XSS
      • For each place in response body where value of request parameter appears, review surround HTML to identify how to craft input to execute arbitrary JavaScript.
      • Use methods of beating signature-based filters.
      • Try submitting many possible exploits to the app and monitor responses for filtering and sanitization.
      • If the app blocks input with certain characters or expressions, or HTML encodes it, try some filter bypasses
      • If an XSS vulnerability is found in a POST request, this may still be exploited by a malicious website.
    3. Test for HTTP Header Injection
      • For each place within response headers where the request parameter appears, verify the app accepts data with a URL-encoded carriage-return (%0d) and line-feed (%0a) characters.
      • If a new line appears in the server response headers, the app is vulnerable to HTTP header injection.
      • If only one of two newline characters is returned, it may be possible to create a working exploit.
      • If the app blocks input with a newline character, try bypassing the filter.
    4. Test for Open Redirection
      • If the reflected input is used to specify the target of a redirect, test if supplying crafted input resulting in an arbitrary redirect is possible.
      • If the app transmits an absolute URL as the parameter value, modify the domain name in the URL and test if the app redirects to the new domain.
      • If the parameter contains a relative URL, modify it into an absolute URL of a different domain and test if it redirects.
      • If the app uses some validation on the parameter, try to bypass the filter.
    5. Test for Stored Attacks
      • If the app stores items from user input and alter displays then, you may recognize them being returned in responses from the fuzzing tests.
        • Sometimes user supplied data is stored successfully only after a multistage process, which cannot be recognized from fuzzing tests.
      • Review any admin functionalities where data from low privileged users is rendered to higher privileged users.
      • Test instances where user supplied data is stored and displayed to users.
      • If vulnerabilities are found where input is displayed to other users, determine any effective attack payloads for session hijacking or request forgery.
      • If the app allows uploading and downloading of files, probe the functionality for stored XSS attacks.
      • If Stored XSS is not possible, try on-site request forgery attacks.
  4. Test for OS Command Injection
    1. If command injection attack strings cause a time delay, the app is likely vulnerable to OS command injection.
    2. Try injecting more interesting commands and check the response.
    3. If responses cannot be retrieved directly, try an out-of-band channel or creating a file in the web root.
    4. If responses can be retrieved directly, determine the privilege level.
    5. If input is passed to an OS command, see if use of greater than or less than signs direct contents of a file to the command input. If so, file contents may be usable for executing commands.
    6. If certain characters are escaped, try using an escape character before the sanitized or filtered characters.
  5. Test for Path Traversal
    1. for each fuzz test, check for path traversal attack string results that are interesting.
    2. In the mapping of the app attack surface, note functionality supporting the reading and writing of files based on user input
    3. If parameters appear to contain a file name, directory, or other relevant part, modify that value and check the response.
      • If this is successful, try additional sequences to step through the base directory and access OS files.
    4. If the app filters based on files that are accessed, try using a null byte
      • e.g. boot.ini%00.jpg
    5. If the app checks the user specified file path start, try appending traversal sequences using an acceptable stem
    6. If these attacks fail, try combining multiple bypasses
    7. If these succeed in gaining file access, it may be possible to escalate the attack.
  6. Test for Script Injection
    1. If the fuzz test of 111111 from Burp Intruder works, script injection of commands may be possible
    2. Review test cases using script injection strings and identify corresponding error messages
    3. If the app appears vulnerable, verify by injecting interesting commands
  7. Test for File Inclusion
    1. If any HTTP connections form the target app are received during fuzzing, there might be a vulnerability for remote file inclusion
    2. Review results of file inclusion test cases, identifying any causing an anomalous delay
    3. If a remote file inclusion vulnerability is found, deploy a web server with a malicious script for the target language and use commands like those used to test for the vulnerability.

Test for Function-Specific Input Vulnerabilities (836 - 852)

  1. Test for SMTP Injection
    1. For each request related to email functionality, submit test strings as each parameter or use Burp Intruder to automate the process.
      • examples given: (replace 'youremail' with your own email)
        • <youremail>%0aCc:<youremail>
        • <youremail>%0d%0aCc:<youremail>
        • <youremail>%0aBcc:<youremail>
        • <youremail>%0d%0aBcc:<youremail>
        • %0aDATA%0afoo%0a%2e%0aMAIL+FROM:+<youremail>%0aRCPT+TO:+<youremail>
        • %0aDATA%0aFrom:+<youremail>%0aTo:+<youremail>%0aSubject:+test%0afoo%0a%2e%0a
        • %0d%0aDATA%0d%0afoo%0d%0a%2e%0d%0aMAIL+FROM:+<youremail>%0d%0aRCPT+TO:+ <youremail>%0d%0aDATA%0d%0aFrom:+<youremail>%0d%0aTo:+<youremail>%0d%0aSubject:+test%0d%0afoo%0d%0a%2e%0d%0a
    2. Review results for any error messages.
    3. Monitor the email address specified for emails
    4. Review the HTML form generating the request.
  2. Test for Native Software Vulnerabilities
    1. Test for Buffer Overflows
      • For each item of data being targeted, submit a range of long strings longer than common buffer sizes.
        • Example sizes:
          • 1100
          • 4200
          • 33000
      • Monitor app responses to identify anomalies.
        • examples:
          • HTTP 500 status code
          • Informative message of a failure
          • Partial or malformed response
          • TCP connection closed without returned response
          • App no longer responds
          • Unexpected data returned
    2. Test for Integer Vulnerabilities
      • Identify any integer-based data, possibly with with length indicators
      • In each target item, send suitable payloads to trigger vulnerabilities.
        • Example payloads:
          • 0x7f and 0x80 (127 and 128)
          • 0xff and 0x100 (255 and 256)
          • 0x7ffff and 0x8000 (32767 and 32768)
          • 0xffff and 0x10000 (65535 and 65536)
          • 0x7fffffff and 0x80000000 (2147483647 and 2147483648)
          • 0xffffffff and 0x0 (4294967295 and 0)
      • When data modified is in hex form, send little and big endian versions for each test case
      • Monitor app responses for anomalous events.
    3. Test for Format String Vulnerabilities
      • Identify each parameter and submit strings with long sequences of different format specifiers
        • %n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n
        • %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
        • %1!n!%2!n!%3!n!%4!n!%5!n!%6!n!%7!n!%8!n!%9!n!%10!n! etc...
        • %1!s!%2!s!%3!s!%4!s!%5!s!%6!s!%7!s!%8!s!%9!s!%10!s! etc…
      • Make sure to URL-encode % as %25
      • Monitor app responses for anomalous events
  3. Test for SOAP Injection
    1. Target each parameter that you suspect is processed via a SOAP message. Submit a random XML closing tag.
      • No error = Input probably not inserted in a SOAP message or is sanitized
      • Error = Submit a valid opening and closing pair.
        • No error = App is vulnerable
    2. If item submitted is returned in responses, submit the following to see if its being inserted into XML-based message:
      • test<foo/>
      • test<foo></foo>
    3. If HTTP request contains many parameters that may be placed into a SOAP message, try inserting an opening and closing comment character in two different parameters:
      • x=<!--&y=!-->
  4. Test for LDAP Injection
    1. In functionality where user-supplied data retrieved from a directory service, attack each parameter
    2. Submit the * character. If a large set of results is returned -- likely an LDAP query
    3. Try entering a lot of closing parentheses, which will invalidate the query syntax and cause weird behavior.
      • ))))))))))
    4. Try various expressions to interfere with different types of queries:
      • )(cn=*
      • *))(|(cn=*
      • *))%00
    5. Try adding extra attributes to the end of your input, using commas to separate each item
      • examples:
        • cn
        • c
        • mail
        • givenname
        • o
        • ou
        • dc
        • l
        • uid
        • objectclass
        • postaladdress
        • dn
        • sn
  5. Test for XPath Injection
    1. Try submitting the following and check if they cause weird behavior without an error:
      • ' or count(parent::*[position()=1])=0 or 'a'='b
      • ' or count(parent::*[position()=1])>0 or 'a'='b
    2. If the parameter is numeric, try the following:
      • 1 or count(parent::*[position()=1])=0
      • 1 or count(parent::*[position()=1])>0
    3. If these do cause weird behavior without an error, you might be able to get arbitrary data by crafting test conditions to get 1 byte of info at a time:
      • e.g. substring(name(parent::*[position()=1]),1,1)='a'
    4. If the parent node name is extracted using the previous method, use some conditions to extract all data in the XML tree:
      • e.g. substring(//parentnodename[position()=1]/child::node()[position()=1]/text(),1,1)='a'
  6. Test for Back-End Request Injection
    1. Locate instances where internal server names or IP addresses are specified in a parameter.
      • Submit a random server and port and check for a timeout.
      • Submit localhost or your own IP address to check for connections on that port
    2. Target a request parameter that returns a specific page for a specific value
      • Try appending a new injected parameter using some syntax
        • %26foo%3dbar (URL-encoded &foo=bar)
        • %3bfoo%3dbar (URL-encoded ;foo=bar)
        • %2526foo%253dbar (Double URL-encoded &foo=bar)
      • If the app behaves as if the original parameter is unmodified, it may be vulnerable to HTTP parameter injections
  7. Test for XXE Injection
    1. If users submit XML, an external entity injection attack may be possible.

Test for Logic Flaws

  1. Identify the Key Attack Surface
    • Logic flaws can take many forms and exist in many components.
      • Narrow down the attack surface to a reasonable area.
    • Review results from mapping exercises, identifying any of the following:
      • Multistage processes
      • Critical security functions
      • Transitions across trust boundaries
      • Context-based functionality presented to a user
      • Checks and adjustments to transaction prices/quantities
  2. Test Multistage Processes
    • If multistage process involves a sequence of requests, attempt to submit these requests out of sequence
    • Try taking parameters submitted from previous requests in requests in later stages
    • Try taking each parameter submitted by one user and submit it as another
    • Try understanding what assumptions the developers may have made and where the attack surface mainly lies.
    • When functions are accessed out of sequence, it's common to encounter weird behavior. Look for weird error messages for weird behavior.
  3. Test Handling of Incomplete Input
    • For critical security functions involving many items of input, test for incomplete input validation.
    • For each parameter, remove both the name and value of the parameter from the request.
    • If requests you are manipulating is part of a multistage process, follow the process through to completion.
  4. Test Trust Boundaries
    • Check how the app handles transitions between different types of trust of the user.
    • Try to find ways to make improper transitions across trust boundaries by getting a relevant state in one area and jumping to a new area that wouldn't normally happen.
    • Try to determine if you can harness higher-privileged function directly or indirectly
  5. Test Transaction Logic
    • When the app imposes transaction limits, test effects of submitting negative values
      • If accepted, beating the limits of making large transactions in the opposite direction may be possible.
    • Check if a series of successive transactions brings a state that can be exploited.
      • e.g. Perform MANY transactions between two accounts to get a large balance that logic was meant to prevent.
    • If the app adjusted prices or other sensitive values based on criteria derived from user-controllable data or actions, try and understand the underlying algorithms and where the adjustments are made.
    • Try to find ways to manipulate the app behavior in such a way that adjustments do not correspond to those intended by design.

Test for Shared Hosting Vulnerabilities

  1. Test Segregation in Shared Infrastructures
    • If the app is hosted on shared infrastructure, examine access methods provided for customers to update and manage content and functionality.
      • Does remote access use a secure protocol with a hardened infrastructure
      • Can customers access files and data that they don't have legit access for
      • Can customers get an interactive shell in the host environment and execute arbitrary commands
    • If the proprietary app is used to allow customers to configure and customize a shared environment, consider targeting the app to compromise the environment itself and apps running in it.
    • If command execution, SQLi, or arbitrary file access is possible in one app, check if methods of escalation are possible through it.
  2. Test Segregation Between ASP-Hosted Applications
    • If the app belongs to an ASP-hosted service of many shared and customized parts, identify any shared components.
      • Try to leverage these to compromise the shared part of the app
    • If a common database is used, perform a comprehensive audit of the database configuration, patch level, table structure, and permissions.
      • Can be done using a database scanning tool like NGSSquirrel.

Test for Application Server Vulnerabilities

  1. Test for Default Credentials
    • Review results of app mapping to identify web server and other technologies
    • Perform a port scan on the web server to identify admin interfaces on different ports
    • For identified interfaces, consult manufacturer documentation and common default password listings to obtain default credentials
    • If default credentials don't work, try to guess valid credentials
    • If access is gained for an admin interface, review the available functionality and check if it can be used to compromise the host and attack the main app.
  2. Test for Default Content
    • Review Nikto scan results to identify default content present on the server.
    • Use search engines and resources like expoint-db and osvdb to identify default content.
    • Examine the default content for functionality or vulnerabilities that can be leveraged.
  3. Test for Dangerous HTTP Methods
    • Use the OPTIONS method to list all HTTP methods.
      • Note different methods enabled on different directories
    • Try each method manually to confirm it can be used.
    • If WebDAV methods are enabled, use a WebDAV enabled client for investigating it further:
      • e.g. Microsoft FrontPage or Open as Web Folder option in IE.
  4. Test for Proxy Functionality
    • Use GET and CONNECT requests
      • Try to use the web server as a proxy to connect to other servers on the internet and get content
      • Try to connect to different IP addresses and ports in the infrastructure
      • Try to connect to common port numbers on the server by specifying 127.0.0.1
  5. Test for Virtual Hosting Misconfiguration
    • Submit GET requests to the root directory using:
      • Correct Host header
      • Bad Host header
      • Server IP as the Host header
      • No Host header (only HTTP/1.0)
    • Compare responses to these requests
    • If different behavior is observed, repeat the app mapping exercised using the hostname generating different results
  6. Test for Web Server Software Bugs
    • Run Nessus or similar scanners to identify known vulnerabilities
    • Review resources in Security Focus , Bugtraq , and Full Disclosure to find details of recently discovered vulnerabilities.
    • If the app was developed by a third party, investigate if it ships with its own web server that is likely open source.
    • If possible, consider a local installation of the software to test for new vulnerabilities
  7. Test for Web Application Firewalling
    • Submit a random parameter name with an obvious attack payload.
      • If the attack is blocked, its probably due to a WAF.
      • If the variable is returned in the response, submit some fuzz strings and encoded variants to test the behavior of defenses
      • Confirm the behavior by submitting the same attacks on variables in the app
    • For all fuzzing strings and requests, use payload strings that are unlikely to exist in the signature database
    • If a request is blocked, try submitting the same parameter in a different loction or context
    • On ASP.NET, try submitting the parameter as a cookie
    • Review all methods of introducing user input
    • Determine locations where user input is or can be submitted in a nonstandard format, like serialization or encoding.

Miscellaneous Checks

  1. Check for DOM-Based Attacks
    • Perform a code review of every piece of JavaScript received form teh app.
      • Identify possible XSS or redirection vulnerabilities
    • Identify all uses of the following APIs, which might be used to access DOM data:
      • document.location
      • document.URL
      • document.URLUnencoded
      • document.referrer
      • window.location
    • Trace relevant data through code to identify actions performed with it. If data passed to the following, it might be vulnerable to XSS:
      • document.write()
      • document.writeln()
      • document.body.innerHtml
      • eval()
      • window.execScript()
      • window.setInterval()
      • window.setTimeout()
    • If data is passed to one of the following APIs, a redirection attack vulnerability might exist:
      • document.location
      • document.URL
      • document.open()
      • window.location.href
      • window.navigate()
      • window.open()
  2. Check for Local Privacy Vulnerabilities
    • Check logs created by the intercepting proxy to identify all Set-Cookie directives.
      • If any contain an expires attribute with a date, they will persist until then.
        • Check these for sensitive data
    • If a persistent cookie is set and contains sensitive data, a local attacker might be able to capture the data.
    • If an app page contains sensitive data and is accessed over HTTP, look for cache directives in the server responses.
      • If they don't exist, the page may be cached
    • Identify instances in the app in which sensitive data is transmitted via a URL parameter.
      • Examine browser history to check if its stored.
    • For all forms used to capture sensitive data, review the form's HTML source.
    • Check for technology specific local storage:
      • Check for Flash local objects
        • Can be done using the BetterPrivacy Firefox plug-in
      • Check Silverlight isolated storage in the following directory:
        • C:\Users{username}\AppData\LocalLow\Microsoft\Silverlight\
      • Check any HTML5 local storage
  3. Check for Weak SSL Ciphers
    • If the app uses SSL, use the THCSSLCheck took to list ciphers and protocols supported
    • If weak or obsolete ciphers are supported, a well positioned attacker can downgrade or decipher SSL communications of another user and get sensitive data
    • Some web servers advertise weak cipher and protocol support but refuse completing the handshake if a client requests them.
      • False positives possible.
  4. Check Same-Origin Policy Configuration
    • Check for /crossdomain.xml file
      • If the app allows unrestricted access, flash objects from any other site can perform two-way interaction and thus perform session rides
    • Check for /clientaccesspolicy.xml file
      • Just like Flash, if this is too liberal, other sites can perform two-way interaction
    • Test handling of cross-domain requests using XMLHttpRequest by adding an Origin header with a different domain and examine Access-Control headers returned.

Follow Up Any Information Leakage

  • If probing of target app, monitor responses for error messages with useful info about:
    • Cause of error
    • Technologies used
    • Internal structure
    • Functionalities
  • If unusual error messages received, look these up via search engines
  • Review search results, looking for discussions about the error message
  • Use Google code search to locate publicly available code possibly responsible for the error message
  • If error messages contain stack traces with names of libraries and third-party code components, look these both up too.

results matching ""

    No results matching ""