Saltar al contenido principal
CargarIdioma (ES)Atención al cliente
EmpresarialesMóvilRedes socialesMarketingTecnologíaArte y fotografíaEmpleoDiseñoEducaciónPresentaciones y charlas públicasGobierno y org. sin ánimo de lucroAtención sanitariaInternetDerechoLiderazgo y gestiónMotorIngenieríaSoftwareReclutamiento y RR. HH.Venta al por menorVentasServiciosCienciasPYMES y liderazgoAlimentaciónMedio ambienteEconomía y finanzasDatos y análisisRelaciones con inversoresDeportesMeditaciónNoticias y políticaViajesDesarrollo personalSector inmobiliarioEntretenimiento y humorSalud y medicinaDispositivos y hardwareEstilo de vida
Sam Bowne, profile picture
Subido porSam Bowne
2,299 vistas

CNIT 129S: Ch 5: Bypassing Client-Side Controls

Chapter 5 discusses how client-side controls in web applications can be bypassed, highlighting vulnerabilities in data handling, hidden form fields, cookie fields, and URL parameters. It emphasizes that client-side validation can improve user experience but cannot be trusted, as malicious users can exploit weaknesses to perform unauthorized actions. Additionally, the chapter addresses various methods for intercepting and modifying traffic from browser extensions and native client components, stressing the importance of secure data handling and server-side validation.

Educación◦
Descargado 62 veces
CNIT 129S: Securing Web Applications Ch 5: 
 Bypassing Client-Side Controls
Clients Repeat Data • It's common for a server to send data to a client • And for the client to repeat that same data back to the server • Developers often assume that the client won't modify the data
Why Repeat Data? • Avoids storing a lot of data within the user's session; can improve performance • An app deployed on many servers may not have the required data available at each step • Third-party components, such as shopping carts, may be difficult to deploy without repeating data • Getting approval to modify server-side API code may be difficult and slow; storing data on the client may be fast and easy
Hidden Form Fields • Server sends hidden price field to client
Changing Price with Burp
Cookie Fields • Discount amount in cookie
Demonstration • Alter cookie value with Burp Repeater
URL Parameters • No proxy needed • Just modify the URL
Hidden URL Parameters • <img src="http://foo.com?price=449"> • <iframe src="http://foo.com?price=449"> • <form action="http://foo.com?price=449" method="POST"> • Pop-up windows or other techniques that hide the URL bar • All are unsafe; can be exploited with a proxy
Referer Header • Shows the URL that sent the request • Developers may use it as a security mechanism, trusting it
Demo
Opaque Data • Data may be encrypted or obfuscated
Handling Opaque Data • If you know the plaintext, you may be able to deduce the obfuscation algorithm • App may contain functions elsewhere that you can leverage to obfuscate plaintext you control • You can replay opaque text without deciphering it • Attack server-side logic with malformed strings, such as overlong values, different character sets, etc.
ASP.NET ViewState • A hidden field created by default in all ASP.NET web apps • This code adds a price to the ViewState
ViewState • Form sent to the user will now look like this
User Submits Form • ViewState is Base64 Encoded
Decoded ViewState Burp contains a ViewState parser (next slide) Some ASP.NET apps use MAC protection A 20-byte keyed hash at the end of the ViewState structure
HTML Forms • Only allows one character • Intending to set max. of 9
Defeated with a Proxy
Refreshing a Page • If you see a 304 server response like this • Page not sent from server, because browser has already cached it • Etag string is a sort of version number
If-Modified-Since: • Browser sent a request like this • May also use "If-None-Match" header
Forcing a Full Reload • Use Shift+Refresh in browser • Use Burp to remove the "If-Modified-Since" and "If-None-Match" headers
Script-Based Validation
Defeated with Burp • Replace value after script runs • Could also disable JavaScript, or modify the script
Tips • Where JavaScript is used for input validation • Submit data that would have failed validation • Using a proxy, or with modified source code • Determine whether validation is also performed on the server • If multiple fields are validated, enter valid data in all fields except one at a time, to test all the cases
Proper Use • Client-side validation can improve performance and user experience • Faster response and no wasted server time on invalid entries • But the validation cannot be trusted and must be repeated on the server
Disabled Elements
Disabled Elements • Cannot be changed • Not sent to server
Add Parameter in Burp • Use Add button to insert the disabled field • It may still be used on server-side
Burp Response Modification
Form is Easy to Hack
Browser Extensions • Flash or Java client-side routines can collect and process user input • Internal workings are less transparent than HTML forms and JavaScript • But still subject to user modification
Example: Casino App • Client could • Tamper with game state to gain an advantage • Bypass client-side controls to perform illegal actions • Find a hidden function, parameter, or resource to gain illegitimate access to a server-side resource • Receive information about other players to gain an advantage
Common Browser Extensions • Java applets, Flash, and Silverlight • All have these features • Compiled to bytecode • Execute in a virtual machine that provides a sandbox • May use remoting frameworks employing serialization to transmit complex data structures or objects over HTTP (link Ch5c)
Java • Java applets run in the Java Virtual Machine (JVM) • Sandboxed by Java Security Policy
Flash • Runs in Flash virtual machine • Sandvoxed from host computer • ActionScript 3 adds remoting capability with Action Message Format (AMF) serialization
Silverlight • Microsoft's alternative to Flash • Provides a scaled-down .NET experience within the browser • In a sandboxed environment • Apps most commonly written in C#, but other languages like Python can be used
Approaches to Browser Extensions • Intercept requests and responses in a proxy • May be obfuscated or encrypted • Cannot explore all business logic • Decompile bytecode and read source, or run it in a debugger • Time-consuming and requires detailed understanding of the technologies and programming languages used
Intercepting Traffic from Browser Extensions • Allows you to defeat server-side controls, same as earlier in this chapter • Serialized data may be tricky to modify • Must unpack it, edit it, and repack it correctly
Java Serialization • Content-type header indicates serialized data • DSer is a Burp plug-in handles such data
DSer in Action • Raw request on left, unpacked version on right • Link Ch 5d
Flash Serialization • Content-type header • Burp natively handles AMF format
Silverlight Serialization • Uses two instances of Burp (Link Ch 5e)
Obstacles to Intercepting Traffic from Browser Extensions • Some requests may bypass the proxy settings in your browser • Components may issue their own HTTP requests, outside browser APIs • Solution: modify hosts file and use invisible proxying
Obstacles to Intercepting Traffic from Browser Extensions • Client component may reject the SSL certificate from the proxy • Because browser extension does not pick up browser's configuration for temporarily trusted certificates • Or component is programmed not to accept untrusted certificates • Solution: set proxy to use a master CA certificate; install in your trusted certificate store
Obstacles to Intercepting Traffic from Browser Extensions • Client uses a non-HTTP protocol • You can use a sniffer like Wireshark • Or a function-hooking tool like Echo Mirage • Can inject into a process and intercept its calls to socket APIs • So you can modify data before it's sent over the network • But it seems to be gone
Tips • Ensure that your proxy is correctly intercepting all traffic; check with a sniffer • Use appropriate serialization unpacker • Review responses from the server that trigger client-side logic; you may be able to unlock the client GUI to reveal privileges actions • Look for correlation between critical actions and communications with the server • Does rolling the dice in a gambling app take place on server or client?
Decompiling Browser Extensions • Most thorough method • Extensions are compiled into bytecode • High-level platform-independent binary representation • Some apps use defensive measures to obfuscate bytecode
Downloading the Bytecode • Find link to bytecode in HTML source code • Java applets generally use <applet> tag • Others use <object> tag • Once you find the URL, put it in browser address bar to donload the bytecode
Downloading the Bytecode • If URL is not easy to find, look in proxy history after loading the app • Some proxies filter the history to hide items such as images and style sheet files; the object might be filtered • Browsers cache bytecode aggressively, and even a full refresh won't request component again • Must clear cache and restart browser
Decompiling the Bytecode • Java applets are usually .jar files • Containing .class files with bytecode • Silverlight objects are .xap files • Containing .dll files with bytecode • Both are Zip archives; rename them to .zip and unzip them with any unzip utility • Flash objects are .swf files; no unpacking required
Decompilers • Jad for Java (link Ch 5f) • For Flash: Flasm or Flare (links Ch 5g, 5h) • SWFScan was bundled into WebInspect • 15-day trial at link Ch 5i • Silverlight: use .NET Reflector • Free trial at link Ch 5j
Example: Bank of America Android App • Pull from phone with adb • Unpack with apktool
Files and Folders • Unpacked app is many .smali files (Android Java bytecode)
Java v. Bytecode
Modifying Smali Code
Pack and Sign
Trojaned App Leaks Credit Card Numbers
Working on the Client-Side Source Code • Input validation or other security-relevant logic • Obfuscation or encryption • "Hidden" functionality, not visible in user interface • You might be able to unlock it by modifying code • References to server-side functionality you haven't already found via mapping
Recompiling • For Java, use javac from the JDK • For Flash, use flasm, or a Flash development studio from Adobe • For Silverlight, use Visual Studio • For Java or Silverlight, zip the code and change file extension to .jar or .xap
Loading Modified Component into a Browser • Find original component within the browser cache and replace it • Use a proxy to modify the source code of the page that loads the component and specify a different URL pointing to your modified component • Difficult--may violate same-origin policy
Loading Modified Component into a Browser • Use a proxy to intercept the response containing the executable and replace the body of the message with your modified version • Burp has "Paste from File" option for this
Recompiling and Executing Outside the Browser • Modify app to run as a standalone program • For Java, just implement a "main" method
Manipulating the Original Component using JavaScript • Using a proxy, intercept and edit responses • To add JavaScript that unlocks hidden parts of the interface
Bytecode Obfuscation • Difficult to read
Obfuscation Methods • Meaningful names replaced with meaningless expressions such as a, b, c, ... • Replace names with reserved keywords such as "new" and "int" • Most VMs tolerate such technically illegal code, but it cannot be recompiled
Obfuscation Methods • Strip unnecessary debug and meta-information from bytecode, such as • Source filenames and line numbers • Local variable names • Inner class information • Add redundant code that confuses the reverse engineer
Obfuscation Methods • Modify path of execution, make it convoluted • Using "jump" instructions • Add illegal programming constructs • Unreachable statements • Missing "return" statements • VMs tolerate them, but decompiled source cannot be recompiled without correcting them
Tips • Some components will remain readable even if source is obfuscated, such as methods called from JavaScript • Many Integrated Development Environments (IDE's) can make code more readable by "refactoring" it (link Ch 5k) • Running code through an abfuscator a second time can remove a lot of the obfuscation (see JODE, link Ch 5l)
Example: Shopping Java Applet • This portion of the code defines a hidden field named "obfpad"
Example Continued • JavaScript validator
Example Continued • This code loads the Java applet "CheckQuantity.class"
Example Continued • Form is submitted with quantity of 2 • It sends this POST request • quantity is obfuscated
Download Applet and Decompile with Jad
Decompiled Java • Header
Decompiled Java • Verifies tha qty is between 0 and 50 • Prepares a string to hold obfuscated text
Decompiled Java • XORs text with obfpad
Modified Applet • Remove input validation from "doCheck" • Add a "main" method that calls "doCheck" and prints the obfuscated result • Code on next page outputs obfuscated string for quantity of 999 • Try various values, including strings, to find vulnerabilities
Recompile with javac
JavaSnoop • Free Java Debugger (Links Ch 5m, 5n) • Example: Java Login Applet
Attach to Process
Hook Classes
Edit Credentials
Canary Mode • Follow "canary" values through app • Works with Burp
Native Client Components • Some actions cannot be done from a sandbox • Verifying that the user has up-to-date antivirus • Verifying proxy settings • Integrating with a smartcard reader • For these, native code components like ActiveX are used; they run outside the sandbox
Reverse-Engineering Native Code • OllyDbg to debug • IDA Pro or Hopper to disassemble
Handing Client-Side Data Securely • Don't send critical data like prices from the client • Send product ID and look up price on server • If you must send important data, sign and/or encrypt it to avoid user tampering • May be vulnerable to replay or cryptographic attacks
Validating Client-Generated Data • All client-side validation methods are vulnerable • They may be useful for performance, but they can never be trusted • The only secure way to validate data is on the server
Logs and Alerts • 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's session, or suspend user's account