Bypassing Client-Side Controls

Transmitting Data Via the Client

• Commonly, applications pass hidden forms to be sent in subsequent requests.
  • Developers often expect this will not be tainted.
  • This is still in the user's control. Assumptions that hidden content will remain untainted only leaves the application vulnerable.
• Reasons this method is used:
  • Improves the application performance as less information needs to be stored or processed server-side.
  • Easier to implement with a distributed system with regard to authentication.
  • Sometimes server-side changes require way more overhead than hashing out a client-side solution.

Hidden Form Fields

• Common mechanism of transferring data from the client while retaining 'integrity'.
  • Hidden fields are not displayed on the application page.
  • Field names and values are stored in the form and returned back to the application when submitting a form.
• Methods of circumventing this 'protection'
  • Save the source code, alter it, click the submit button in a reloaded instance.
  • Use an intercepting proxy and modify the data right away.
• The proxy sits between the browser and the application. One example would is Burp Suite.

HTTP Cookies

• Just like hidden forms, these are not presented to the user and can be modified by an intercepting proxy.

URL Parameters

• These are some of the easiest to modify by altering the address bar content.
• Some URL's are hidden using:
  • Embedded images
  • Named hyperlinks
  • Parameters in the POSTrequest of a form
  • Frames/windows with hidden address bars

The RefererHeader

• Developers may assume this is untainted and is reliable as a source for telling the URL that generated the request.
• Multi-stage forms may use this header to assure the URL came from the correct stage.
• Still, because this is completely alterable by the user, this security mechanism can easily be circumvented using an intercepting proxy.
• Process:
  1. Locate all hidden forms fields, cookies, and URL parameters used for transmitting client data.
  2. Identify the role of this hidden content.
  3. Modify the values of the data to determine if values are processed and whether the processing results in vulnerabilities.

Opaque Data

• Data may be encrypted or obfuscated before it is sent from the client.
• Once sent to the server, the obfuscated or encrypted data may go through some sort of processing.
• This data can be used as a session-handling mechanism component.
• Process:
  • If plaintext value is known, attempt to decipher the algorithm used to obfuscate or encrypt the value.
  • Leverage known functions used elsewhere that can return this opaque string. By this method, one can retrieve the expected opaque string for a desired value.
  • If the algorithm cannot be deciphered, known opaque strings of certain values may be used in replay attacks using their values.

The ASP.NET ViewState

• The ASP.NET ViewStateis commonly used to transmit opaque data.
• This is a hidden field containing serialized information of the state of a page.
• It is used for server performance reasons whereby subsequent requests can have information stored throughout them.
• This ViewStateparameter is a Base64-encoded string.
• Process:
  1. Check if MAC protection is enabled for the ViewState.
     • This can be done by checking if a 20-byte hash is at the end of the ViewStatestructure.
  2. Decode the ViewState to see if sensitive data is transferred via the client by this method.
  3. Modify the value without altering the structure and check if an error message is generated.
  4. If this is modifiable without resulting in an error, try to submit new values to check for vulnerabilities.
  5. Repeat for each page, as MAC protection may be employed only on certain pages.

Capturing User Data: HTML Forms

• HTML forms are common for retrieving user input that will be transferred to the server. These may use validation checks or restrictions on the user-input.

Length Limits

• Process:
  1. Alter a request submitted by the form and enter any arbitrary value.
     • (Alternative) Alter the initial response and remove a maxlengthattribute.
  2. If the server accepts the data despite these client-side restrictions, validation might not be done on the server.
• Note:
  • With cached copies of web pages, one may need to remove If-Modified-Sinceor If-None-Match headers to receive a full version of a resource.

Script-Based Validation

• Forms may use client-side script-based validation, whereby an onsubmitattribute of the formtag calls a form validation script.
• Ways to circumvent script-based validation:
  • disable JavaScript
  • alter the script
  • alter the onsubmitattribute
  • Use a proxy to alter the values in the request prior to sending the data to the application
• Process:
  • Identify when client-side script-based validation is used.
  • Test that the validation actually blocks invalid data. Then, submit data that would normally be blocked to check if the server performs validation checks (via the many methods listed above)
  • Test if the server handles invalid data properly.
  • Repeat for each input field. Mix and match.

Disabled Elements

• Input fields in a form may be disabled. This means they are not changeable nor sent to the server on form submission.
• Process:
  • If a disabled form field is identified, try submitting a request with the disabled form field re-enabled.
  • If the submit field is disabled, attempt to still submit the request by re-enabling the field.

Capturing User Data: Browser Extensions

• Browser extensions are another method for retrieving, validating, and submitting user data from the client-side.
• Methods of capturing data:
  • Input forms
  • Interacting with an operating system's file-system or registry
• These can similarly be altered. So, relying on validation or restrictions employed by browser extensions is dangerous and insecure.

Common Browser Extension Technologies

• Similarities:
  • Compiled to intermediate bytecode.
  • Execute in a virtual machine.
  • Might use remoting frameworks to send data strictures or objects over HTTP.

Java

• Runs in a Java Virtual Machine (JVM). Uses sandboxing applied by the Java Security Policy.

Flash

• Runs in a Flash virtual machine; sandboxed by the host computer.

Silverlight

• The Microsoft alternative to Flash, it provides desktop-like applications in the browser. Developed in any .Net-compliant language.

Approaches to Browser Extensions

• Methods of targeting applications using browser extensions:
  1. Intercept and modify requests from browser extensions. Also, intercept and modify responses from the server.
     • Data may be obfuscated or encrypted. Data could also be serialized based on the application.
  2. Target the extension and attempt to decompile the extension bytecode to view the source code or interact with it in a debugger.

Intercepting Traffic from Browser Extensions

• Utilize an intercepting proxy to view requests/responses.
• Data validated on the client but left in cleartext can be altered and sent to the server. Otherwise, one may need to employ the following techniques to handle serialized data or other obstacles.

Handling Serialized Data

• An attacker may need to unpack serialized content, edit it, and reserialize it.
• Each browser extension may employ different serialization methods.

Java Serialization

• Java has native support for object serialized. Java applets often use this to serialize data structures.
• If a Content-Type header has a value of application/x-java-serialized-object, then this method is used to serialize data.
• By intercepting the seraliazed data, Java can be used to deserialize, alter, and reserialize it.
  • In Burp, DSer is a plug-in with this functionality.

Flash Serialization

• Just like Java, Flash has its own serialization format. The Action Message Format (AMF) can be recognized whenever a Content-Type header has the value application/x-amf.

  • Burp natively supports this format, streamlining data interception and alteration.

Silverlight Serialization

• These may use Windows Communication Foundation (WCF) remoting framework built into the .NET platform. If so, they will use Microsoft’s **.NET Binary Format for SOAP (NBFS)**. This can be identified whenever theContent-Type header has the value application/soap+msbin1.

Obstacles to Intercepting Traffic from Browser Extensions

• Requests made by browser extensions might not be intercepted by a proxy or fail.
  • Possible result of how the extension handles HTTP proxies or SSL.
    • Extension does not accept the proxy configuration.
      • Need to perform invisible proxying or automatic redirection.
    • Extension does not accept the SSL certificate provided by the proxy.
      • Configure the proxy to use a master CA certificate; installing the CA certificate to the computer's trusted certificate store.
    • Extension uses a protocol besides HTTP.
      • Use a network sniffer or function-hooking tool.
        • One tool, Echo Mirage, injects into a process and intercepts calls to socket APIs.

Decompiling Browser Extensions

Downloading the Bytecode

• Bytecode is loaded in a single file from a URL specified in the HTML source code.
• Wrapper scripts may be used to load bytecode.
• If using a proxy to identify bytecode sources:
  1. Filters may need to be turned off to include 'less interesting' content to identify the source of the bytecode.
  2. If the browser cached the bytecode, the cache might need to be cleared to receive the bytecode source.

Java Tools

• Java applets use the <applet> tag to specify code to be loaded.
• Java bytecode can be decompiled using the Java decompiler, Jad.
  • To modify and recompile source code, Jad decompiled source code files will need their file extensions changed from .jad to .java.

Flash Tools

• Flash bytecode can be decompiled into ActionScript source code.
• Can be usually identified by <object> tags.
• Flash bytecode can also be disassembled using:
  • Flasm
  • Flare
  • SWFScan

Silverlight Tools

• Silverlight bytecode can be decompiled by using .NET Reflector.
• Identifiable by <object> tags, just like Flash bytecode.

Working on the Source Code

• Logic to look for:
  • Input validation and other security-related logic.
  • Obfuscation or encryption methods.
  • Hidden client-side functionalities.
  • References to server-side functionalities.

Recompiling and Executing Within the Browser

• Tools for recompiling:
  • Java: javac
  • Flash: flasm
  • Silverlight: Visual Studio
• If necessary, repackage the file(s). For Java and Silverlight, change the extension(s) from .jarto .xap.
• Then, load the component in the browser. To do so, do any of the following:
  1. Replace a cached copy with the modified version and restart the browser.
  2. Use an intercepting proxy, modify the source code of the page loading the component and specify a different URL (pointing at the modified file).
  3. Force the browser to reload the component and replace it in an intercepted response.
     • In Burp Proxy, a Paste from File menu can be used for this.

Recompiling and Executing Outside the Browser

• Some components just receive some input and output it obfuscated or encrypted.
• In these cases, in-browser execution may not be required.

Manipulating the Original Component Using JavaScript

• It may not be necessary to modify an extension's bytecode. Instead, sometimes the same result can be achieved by altering the JavaScript of a page.
• If all functions are JavaScript, an intercepting proxy can be used to alter the component or the component can be changed by inspecting the page.

Process of Working on the Source Code:

1. Download the bytecode, unpack it, and decompile it.
2. Review the source code to understand how it works.
3. If public methods are called, intercept an HTML response and add JavaScript to use certain functions using your input.
   • If not, alter the source code, itself, then recompile and execute it.
4. If it is used to obfuscate or encrypt data and submit it to the server, use a modified version to test for vulnerabilities.

Coping with Bytecode Obfuscation

• Methods of obfuscation:
  • Replacing meaningful variable, function, and class names with random expressions.
  • Altering reserved keywords that can still be processed by a VM.
  • Stripping debug and meta-information like source filenames and line numbers.
  • Adding redundant code.
  • Using jump instructions to disguise the actual path of execution.

Attaching a Debugger

• In large components, attaching a debugger is much faster than attempting to understand an entire component. By observing the component in execution, important methods and classes can be identified.
• Useful debuggers:
  • Java:
    • JavaSnoop, a debugger integrated Jad to decompile source code, trace variables, and set breakpoints.
    • JSwat, another debugger that handles projects with many .class files better.
  • Silvelight: Silverlight Spy

Native Client Components

• Client-side security controls often use native client components.
• Client-side security controls:
  • Verifying up-to-date virus scanner
  • Verifying proper proxy settings and configuration
  • Integration of a smartcard reader
• Tools:
  • OllyDbg, a windows debugger for stepping through native executable code.
  • IDA Pro, a disassembler producing human-readable assembly code.

Handling Client-Side Data Securely

Transmitting Data Via the Client

• Try to avoid sending critical data via the client.
• If there is no alternative to this method, sign and encrypt to preserve its integrity.
  • Two issues:
    • Signing and encrypting methods may be vulnerable to replay attacks.
    • If plaintext values are known, users may perform cryptographic attacks to find out the cryptographic key used by the server.
• ViewStateshould never be used to hold customized data.

Validating Client-Generated Data

• Validation on the client-side should be used, but never depended upon.
• Always validate client data on the server-side. Assume the data is tainted.

Logging and Alerting

• Integrate length limits and script-based validation restrictions into an intrusion detection system. If data is received that should have been prevented from client-side validation functions, assume the user to be malicious.
• Log anomalies and alert administrators of attempted attacks.
  • If JavaScript is disabled, these measures can be accidentally circumvented. So, this may be a consideration when setting up alerts.