1 / 66

Bypassing Client-Side Controls

Bypassing Client-Side Controls . By: Tony Cimo. Client-side. refers to operations that are performed by the client in a client–server relationship in a computer network

denzel
Télécharger la présentation

Bypassing Client-Side Controls

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Bypassing Client-Side Controls By: Tony Cimo

  2. Client-side • refers to operations that are performed by the client in a client–server relationship in a computer network • Typically, a client is a computer application, such as a web browser, that runs on a user's local computer or workstation and connects to a server as necessary • The user has complete control over the client when submitting information

  3. Transmitting Data via the Client • Very common to see an application passing data to the client in a form that is not directly visible or modifiable by the end user, in the expectation that data will be sent back to server in a subsequent request • Application’s developers assume the transmission mechanism used will ensure the data transmitted via the client will not be modified along the way

  4. Transmitting Data via the Client • User has full control of everything submitted from the client, the assumption that the data will not be changed is false, therefore leaving the application vulnerable to attacks

  5. Hidden Form Fields • Hidden HTML form fields are a common mechanism for transmitting data via the client in a un-modifiable way • When a field is flagged as hidden, it’s not displayed on-screen • The field’s name and value are still stored within the form and sent back to the application when the user submits the form

  6. Hidden Form Fields Example • Retailing application that stores prices of products within hidden form fields Typical HTML form

  7. Hidden Form Fields example (cont.) • The code is as follows: • <form action=”order.asp” method=”post”> <p>Product: Sony VAIO A217S</p> <p>Quantity: <input size=”2” name=”quantity”> <input name=”price” type=”hidden” value=”1224.95”> <input type=”submit” value=”Buy!”></p> </form>

  8. Hidden Form Fields example (cont.) • The code that will be sent to the server is now: POST /order.asp HTTP/1.1 Host: wahh-app.com Content-Length: 23 quantity=1&price=1224.95

  9. How to edit the price • One way is to save the source code for the HTML page, edit the value of field, reload the source back into the browser and click the Buy button. • Easier method is to use an intercepting proxy to modify the data

  10. Intercepting Proxy • Proxy sits between the web browser and the target application • Intercepts every request sent to the application and every response • It can trap any intercepted message for inspection or modification

  11. Intercepting Proxy Tools • Burp Proxy • WebScarab • Paros

  12. Burp Proxy, WebScarab, Paros • Fine-grained rules to control which messages are trapped • Regex-based replacement of message content • Automatic updating of the Content-Length header when messages are modified • Browsing history and message cache • Ability to replay and remodify individual requests • Integration with other tools such as spiders and fuzzers

  13. Intercepting Proxy (cont)

  14. HTTP cookies • Common method for transmitting data via the client • Not normally displayed on-screen or directly modifiable by the user • Can be modified with an intercepted proxy • Changing the server response that sets them • Subsequent client requests that issue them

  15. HTTP Cookie example HTTP/1.1 302 Found Location: /home.asp Set-Cookie: SessId=191041-1042 Set-Cookie: UID=1042 Set-Cookie: DiscountAgreed=25

  16. HTTP Cookie example (cont) • Changing discount rate: POST /order.asp HTTP/1.1 Host: wahh-app.com Cookie: SessId=191041-1042; UID=1042; DiscountAgreed=99 Content-Length: 23

  17. URL Parameters • Applications frequently transmit data via the client using preset URL parameters • Example: product catalogue https://wahh-app.com/browse.asp?product=VAIOA217S&price=1224.95 • URL containing parameters is displayed in browser’s location, any parameters can be changed by user without the use of tools

  18. URL Parameters • Many instances when an application may expect that ordinary users can’t view or modify URL parameters • For example: • Where embedded images are loaded using URLs containing parameters • Where URLs containing parameters are used to load the contents of a frame • Where a form uses the POST method and its target URL contains preset parameters • Where an application uses pop-up windows or other techniques to conceal the browser location bar

  19. The Referer Header • Used to indicate the URL of the page from which the current request originated • Can be leveraged as a mechanism for transmitting data via the client

  20. Referer Header example • Consider a mechanism that enables users to reset their passwords if forgotten: POST /customer/ResetForgotPassword.asp HTTP/1.1 Referer: http://wahh- app.com/customer/ForgotPassword.asp Host: wahh-app.com Content-Length: 44

  21. Common Myth “It is often assumed that HTTP headers are somehow more “tamper-proof” than other parts of the request, such as the URL. This may lead developers to implement functionality that trusts the values submitted in headers such as Cookie and Referer, while performing proper validation of other data such as URL parameters. This perception is false —given the multitude of intercepting proxy tools that are freely available, any amateur hacker who targets an application can change all request data with trivial ease. It is rather like supposing that when the teacher comes to search your desk, it is safer to hide your water pistol in the bottom drawer, because she will need to bend down further to discover it.”

  22. Hack Steps • Locate all instances within the application where hidden form fields, cookies, and URL parameters are apparently being used to transmit data via the client. • Attempt to determine or guess the purpose that the item plays in the application’s logic, based on the context in which it appears and on clues such as the parameter’s name. • Modify the item’s value in ways that are relevant to its purpose in the application. Ascertain whether the application processes arbitrary values submitted in the parameter, and whether this exposes the application to any vulnerabilities.

  23. Opaque Data • Sometimes data transmitted by client is not transparently intelligible: encrypted or obfuscated • Example: <form action=”order.asp” method=”post”> <p>Product: Sony VAIO A217S</p> <p>Quantity: <input size=”2” name=”quantity”> <input name=”enc” type=”hidden” value=”262a4844206559224f456864206668643 265772031383932654448a352484634667233683277384f22455565 333272 33666455225 242452a526674696f6471”> <input type=”submit” value=”Buy!”></p> </form>

  24. Opaque Data Hack Steps • Faced with opaque data being transmitted via the client, there are several possible avenues of attack: • If you know the value of the plaintext behind the opaque string, you can attempt to decipher the obfuscation algorithm being employed. • Even if the opaque string is completely impenetrable, it may be possible to replay its value in other contexts, to achieve some malicious effect. For example, the enc parameter in the previously shown form may contain an encrypted version of the product’s price. Although it is not possible to produce the encrypted equivalent for an arbitrary price of your choosing, you may be able to copy the encrypted price from a different, cheaper product and submit this in its place.

  25. ASP.NET ViewState • Method for transmitting opaque data via the client • Hidden field created by default in all ASP.NET web applications, and contains serialized information about the web page • ASP.NET platform employs ViewState to enhance server performance- enables server to preserve elements within the user interface across successive requests without needing to maintain all the information on the server side

  26. ViewStateExample • Also, used to store arbitrary information across successive requests • Instead of saving product’s price in a hidden field, an app may save to ViewState as follows: string price = getPrice(prodno); ViewState.Add(“price”, price);

  27. Example cont • Form returned to user will now look like this: <form method=”post” action=”order.aspx”> <input type=”hidden” name=”__VIEWSTATE” id=”__VIEWSTATE” value=”/wEPDwUKMTIxNDIyOTM0Mg8WAh4FcHJpY2UFBzEyMjQuOTVkZA==” /> <p>Product: Sony VAIO A217S</p> <p>Quantity: <input name=”quantity” id=”quantity” /> <input type=”submit” name=”buy” value=”Buy!” /> </form>

  28. Cont. • When the user submits the form, their browser will send: POST /order.aspx HTTP/1.1 Host: wahh-app.com Content-Length: 95 __VIEWSTATE=%2FwEPDwUKMTIxNDIyOTM0Mg8WAh4FcHJpY2UFBzEyMjQuOTVkZA%3D%3D&quantity=1&buy=Buy%21

  29. Base64-encoded string • FF 01 0F 0F 05 0D 0A 31 32 31 34 32 32 39 33 34 ; ÿ......121422934 • 32 0F 16 02 1E 05 70 72 69 63 65 05 07 31 32 32 ; 2.....price..122 • 34 2E 39 35 64 64 ; 4.95dd • Base64 is a block-based format in which each 4 bytes of encoded data translates into 3 bytes of decoded data

  30. Cycling through Base64 • First four offsets into:Hh4aGVsbG8gd29ybGQu and generates the following results: — — [ È ÛÜ> ‡††VÆÆò v÷&Æ á¡•±±¼ ´Y½É± hello world.

  31. ViewState Format • Version 1.1: simple text-based format that is effectively a compressed form of XML • Version 2: a binary format FF 01 0F 0F 05 0D 0A 31 32 31 34 32 32 39 33 34 ; ÿ......121422934 32 0F 16 02 1E 05 70 72 69 63 65 05 01 31 64 64 ; 2.....price..1dd • Then re-encode modified Base64 with the new parameters: • POST /order.aspx HTTP/1.1 • Host: wahh-app.com • Content-Length: 87

  32. Problem with Hacking ASP.NET • Option within ASP.NET to include a keyed hash • EnableViewStateMacoption is a parameter that cannot be tampered with without breaking the hash • Trying to change the price will result in an error and you will need the security key stored on the server to hack the system

  33. Hack Steps for ASP.NET • If you are attacking an ASP.NET application, verify whether the EnableViewStateMacoption is activated. This is indicated by the presence of a 20-byte hash at the end of the ViewState structure, and you can use the decoder in Burp Proxy to confirm whether this is present. • Even if the ViewState is protected, decode the ViewState parameter on various different application pages to discover whether the application is using the ViewState to transmit any sensitive data via the client. • Try to modify the value of a specific parameter within the ViewState, without interfering with its structure, and see whether an error message results.

  34. Hack Steps cont • If you can modify the ViewState without causing errors, you should review the function of each parameter within the ViewState, and whether the application uses it to store any custom data. Try to submit crafted values as each parameter, to probe for common vulnerabilities, as you would for any other item of data being transmitted via the client. • Note that the keyed hash option may be enabled or disabled on a per-page basis, so it may be necessary to test each significant page of the application for ViewState hacking vulnerabilities.

  35. Capturing User Data: HTML Forms • Simplest and most common mechanism for capturing input from the user and submitting it to the server • Users type data into named text fields, which are submitted to the server as name/value pairs • When an application employs client-side controls as a security mechanism, the controls can be hacked and the app is vulnerable

  36. Length Limits • Consider this HTML form: <form action=”order.asp” method=”post”> <p>Product: Sony VAIO A217S</p> <p>Quantity: <input size=”2” maxlength=”3” name=”quantity”> • Browser prevents user from entering more than 3 characters • Can be bypassed by intercepting the request containing the form submission to enter a new value, or you can remove the maxlength attribute to hack the system

  37. Hack Steps for Length Limit • Look for form elements containing a maxlength attribute. Submit data that is longer than this length but that is validly formatted in other respects (e.g., is numeric if the application is expecting a number). • If the application accepts the overlong data, you may infer that the client-side validation is not replicated on the server. • Depending on the subsequent processing that the application performs on the parameter, you may be able to leverage the defects in validation to exploit other vulnerabilities such as SQL injection, cross-site scripting, or buffer overflows.

  38. Script-Based Validation • Input validation mechanisms built into HTML forms are simple and fine-grained to perform relevant validation for many kinds of input • Example: a user registration form might contain fields for name, email, telephone, and ZIP code • Therefore, common to see customized client-side input validation implemented within scripts

  39. <script> function ValidateForm(theForm) { varisInteger = /^\d+$/ if(!isInteger.test(theForm.quantity.value)) { alert(“Please enter a valid quantity”); return false; } return true; } </script> <form action=”order.asp” method=”post” onsubmit=”return ValidateForm(this)“> <p>Product: Sony VAIO A217S</p> <p>Quantity: <input size=”2” name=”quantity”> <input name=”price” type=”hidden” value=”1224.95”> <input type=”submit” name=”buy” value=”Buy!”></p> </form> Variation of previous example:

  40. Hack Steps • Identify any cases where client-side JavaScript is used to perform input validation prior to form submission. • Submit data to the server that the validation would ordinarily have blocked, either by modifying the submission request to inject invalid data or by modifying the form validation code to neutralize it. • As with length restrictions, determine whether the client-side controls are replicated on the server, and if not, whether this can be exploited for any malicious purpose. • Note that if multiple input fields are subjected to client-side validation prior to form submission, you need to test each field individually with invalid data, while leaving valid values in all of the other fields. If you submit invalid data in multiple fields simultaneously, it is possible that the server will stop processing the form when it identifies the first invalid field, and so your testing is not reaching all possible code paths within the application.

  41. Disabled Elements • Element on an HTML form is flagged as disabled, it appears on-screen but is grayed out and is not editable or usable • Consider the following form:

  42. Disabled Elements <form action=”order.asp” method=”post”> <p>Product: <input disabled=”true” name=”product” value=”Sony VAIO A217S”></p> <p>Quantity: <input size=”2” name=”quantity”> <input name=”price” type=”hidden” value=”1224.95”> <input type=”submit” value=”Buy!”></p> </form>

  43. Capturing User Data: Thick-Client Components • Capture data in various different ways, both via input forms and in some cases by interacting with the client operating system’s file system or registry • Perform complex validation and manipulation of captured data prior to submission to the server • Because their internal workings are less transparently visible than HTML forms and JavaScript, developers are more likely to assume that the validation they perform can’t be circumvented

  44. Java Applets • Popular for implementing thick-client components because they are cross-platform and run in a sandboxed environment, prevents against various security problems • Can’t access operating system resources such as the file system • Main use: to capture user input or other in-browser information

  45. Java game example • <script> • function play() • { • alert(“you scored “ + TheApplet.getScore()); • document.location = “submitScore.jsp?score=” + • TheApplet.getObsScore() + “&name=” + • document.playForm.yourName.value; • } • </script> • <form name=playForm> • <p>Enter name: <input type=”text” name=”yourName” value=”“></p> • <input type=”button” value=”Play” onclick=JavaScript:play()> • </form> • <applet code=”https://wahh-game.com/JavaGame.class” • id=”TheApplet”></applet>

  46. Java example • URL entry that is returned after playing game: https://wahh-game.com/submitScore.jsp?score= c1cc3139323c3e4544464d51515352585a61606a6b&name=daf • Want to cheat the game, one way is to harvest a large number of scores and attempt to reverse engineer the algorithm

  47. Decompiling Java Bytecode • Better approach to hack Java • To decompile: first save a copy of file/URL to disk • Use browser to request the URL specified in the code attribute of the applet tag

  48. Jad • Tool for decompiling Java bytecode • Once Jad has decompiled the applet back to its source code, you can start to bypass the client-side controls

  49. Jad examples • You can modify the decompiled source to change the behavior of the applet, recompile it to bytecode, and modify the source code of the HTML page to load the modified applet in place of the original. For example, you could change the getObsScore method to: return obfuscate(“99999|0.123456789”); • To recompile your modified code, you should use the Java compiler javacprovided with Sun’s Java SDK.

  50. Another Jad example • You can add a main method to the decompiled source to provide the functionality to obfuscate arbitrary inputs: • public static void main(String[] args) • { • System.out.println(obfuscate(args[0])); • } • You can then run the recompiled byte code from the command line to obfuscate any score you like: • E:\>java JavaGame “99999|0.123456789“ • 6ca4363a3e42468d45474e53585d62676c7176

More Related