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


It is common for a server to send data to client and for client to repeat that same data back to server. Developers often assume that client wont modify the data. One might wonder why, server needs to transmit to client and get it back. Various reasons could be:

  • Removes the need of tracking all kind of data in user’s session, reducing amount of per session data stored on server, cam improve app’s performance.
  • If app is on multiple servers, user might interact with any of them, So sharing data between servers might not be straightforward than sending it to client.
  • Integration with third party component can also make it difficult.
  • Sometimes tracking a new piece of data might require updating core server-side API.

Hidden Form Fields – Capture with intercepting proxy, modify and replay.

HTTP Cookies – Capture with intercepting proxy, modify and replay.

URL Parameters – Capture with intercepting proxy, modify and replay.

The Referer Header –  Capture with intercepting proxy, modify and replay.
Opaque Data – Obfuscated or encrypted data i.e. session tokens, anti-csrf tokens, one-time access URLs.

  • If plaintext is known, decipher obfuscation algorithm.
  • By extrapolating app’s functionality, obtain required string.
  • If impenetrable, replay value in other context to achieve malicious effect.
    Else, attack server side logic that deobfuscate the opaque data by sending malformed variation i.e. containing overlong values, different character sets etc.

The ASP.NET ViewState – It contains serialized information about state of current page. Employed for server performance, it can also store arbitrary info across successive requests. It is base64 encoded string. Decoding from wrong position will show gibberish. Start from four adjacent offsets into encoded string. ViewState might be protected with MAC protection (indicated by presence of 20 byte hash at end of structure). MAC protection may be enabled or disabled on per page basis. Use burp to decode ViewState.


Client side validation can improve performance and user experience but validation should not be trusted and must be repeated on server.

Length Limits 

  • If ‘304 Not Modified’ is received, then remove the If-Modified-Since and If-None-Match headers.

Script-Based Validation

  • Replace value after script runs, or disable JavaScript or modify the script.
    To test all cases, put invalid data in one field at a time.

Disabled Elements

  • Value of disabled parameter is not sent to server, so you can add the same parameter and server might fall for it.

NOTE: In Burp, goto Proxy > Options in ‘Response Modification’ provide options to remove webpage defenses.

CAPTURING USER DATA: Browser Extensions

Browser extensions can capture data in various ways – input forms, OS file system, registry etc. Developers might assume that they cannot be circumvented. So they can be fruitful target for discovering vulnerabilities in webapps.

Common Browser Extension Technologies

  • Java applets, flash, silverlight are common extensions. They are compiled to an intermediate bytecode and they execute within VM that provides sandbox environment for execution. They may use remoting frameworks to transmit complex data structures or serialized objects over HTTP.
  • Java applets run in JVM, sandboxed by Java Security Policy.
  • Flash runs in flash virtual machine, sandboxed from host computer. AS3 adds remoting capability with Action Message Format serialization.

Approaches to attack Browser Extensions

  • Intercept requests and responses in proxy, which can be encrypted, obfuscated or serialized. One may not explore all business logic of component from intercept unless component is closely analyzed.
  • De-compile bytecode and read source code or run it in debugger. Time consuming and requires detailed understanding of technologies.

Intercepting Traffic from Browser Extensions

  • It allows to defeat server-side controls.
  • Serialized data is tricky to modify. Unpack it, edit it and repack it correctly to avoid parsing errors. Serialization format can be inferred by type of client component but evident by close inspection of HTTP messages.
  • HTTP messages containing java serialized objects can be identified with Content-Type header having value of ‘application/x-java-serialized-object’. It can be modified with DSer plugin of burp suite.
  • Flash serialization can be identified with Content-Type header with ‘application/x-amf’ value. Burp natively supports AMF format.
  • Silverlight uses WCF employing .NET binary format for SOAP (NBFS) identified with Content-Type header with ‘application/soap+msbin1’ value. WCF binary SOAP plugin by Brian Holyfield can be helpful.

Obstacle to intercepting traffic from browser extension-

  • Components might be handling HTTP proxies or SSL or both.
  • Components may issue own HTTP requests outside browser APIs. So it cant be intercepted. Modify the hosts file and use invisible proxying.
  • If component is rejecting proxy cert, then configure proxy to use master CA certificate (used to sign valid per-host certificates for each site one visit) and install CA cert in computer’s trusted certificate store.
  • If component is using protocol other than HTTP, network sniffer or function hooking tool might be required like Echo Mirage.

TIPS: Ensure proxy is correctly intercepting all traffic, check with sniffer. Use appropriate serialization unpacker. Review responses from server that trigger client-side logic, you may be able to unlock a client GUI to reveal privilege actions. Look for correlation between critical actions and communications with server.

De-compiling Browser Extensions

Most thorough method is to decompile object and perform review of source code. Change the code if necessary and recompile it. Apps may use defensive measures to obfuscate bytecode.

Extension objects and decompiler:

  • Java applets are usually .jar files containing .class files with bytecode. Silverlight objects are .xap files containing .dll files with bytecode. Both are zip archive, rename extension & unzip it. Flash objects are .swf files, no unpacking required.
  • Use Jad decompiler for java. Flasm or Flare for flash. SWFScan was bundled into WebInspect. Silverlight use .NET reflector.

Working with Source code:

Review source code, understand how component works and what functionality it contains. Look for:

  • Input validation or security relevant logic and events.
  • Obfuscation or encryption routines used to wrap user input before sent to server.
  • Hidden client side functionality or references to server side functionality.

Recompile and Execute:

  • Use javac for java program to recompile.
  • Use flasm for flash file to reassemble modified bytecode.
  • Use Visual Studio to recompile for silverlight.

One can undo a lot of obfuscation by running obfuscated bytecode through obfuscator second time. Useful obfuscator for java is Jode.

Attaching a Debugger

Decompilation is most complete method of understanding and compromising browser extension. Because debugger is working at bytecode level, it can be used to control and understand flow of execution.

  • JavaSnoop is java debugger that can integrate Jad to decompile source code, trace variables, set breakpoints on methods and modify parameters. Run JavaSnoop before target applet is loaded.
  • JSwat is alternative tool for debugging java. Decompile, modify and recompile key class file and use JSwat to hotwap into running app. Launch applet using appletviewer and then connect JSwat to it.

Native Client Components

  • Some actions cannot be conducted from inside sandbox i.e. if user has anti-virus or proxy settings etc.
  • Such actions require use of native code components which integrate local app functionality with web app. Native client components are often delivered via ActiveX controls. It can be little hard to decipher as there is no intermediate byte code.
  • OllyDbg is windows debugger that can be used to step through native executable code, set breakpoints and apply patches to executables.
  • IDA Pro is disassembler that can produce assembly code from native executable code.


Transmitting Data Via the Client

  • Don’t send critical data like prices from client. Send product id and lookup price on server.
  • If you must send, then sign and/or encrypt it to avoid user tampering. But it may be vulnerable to replay or other crypto attacks.

Validating Client-Generated Data

All client side validation methods are vulnerable. They can be useful for performance but they can never be trusted. So always validate on server.

Logging and Alerting

  • Server side intrusion detection defenses should be aware of client side validation.It should detect invalid data as probably malicious, triggering alerts and log entries.
  • May terminate user session or suspend user account.



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