Application Security


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Application Security

  1. 1. Application Security Bill Chu August 2002
  2. 2. Web applications <ul><li>Web applications is pervasive </li></ul><ul><li>Customers love it! (e.g. driver license renew, grade entry, banking, trading stocks, airline reservation, hotel reservation, buying books, library ….) </li></ul><ul><li>They are typically outside of fire walls </li></ul>
  3. 3. Anatomy of a web application Sanctum systems Data Database Backend systems frontend systems Web Server User interface code Valid Input Browser Custom code: e.g. html, forms, javascript Off the shelf application: e.g. websphere Custom code: e.g. servelet, jsp, asp Applications: e.g. SAP, ORACLE Applications: e.g. ORACLE, DB2
  4. 4. Web application threats Sanctum systems Data Database Backend systems frontend systems Web Server User interface code Invalid input Code Data Browser Code, Web server, Front end system, Back end system or database flaws resulting in unauthorized access of privileged accounts, the OS, network, or sensitive data and may result in denial of services.
  5. 5. Perfecto Technologies Survey
  6. 6. Hidden Field Manipulation <ul><li>Find vulnerable form with hidden input </li></ul><ul><li>Save HTML file to disk, modify hidden input </li></ul><ul><li>Execute HTML file from disk, submit form </li></ul><ul><li>Experience manipulated form results </li></ul>
  7. 7. Hidden Field Manipulation <ul><li>Open the html page within HTML editor </li></ul><ul><li>Locate the hidden field (e.g., “<type=hidden name=price value=99.95>” </li></ul><ul><li>Modify content (e.g., “<type=hidden name=price value=1.00>” </li></ul><ul><li>Save the html file locally and browse it </li></ul><ul><li>Click buy button to perform electronic shop lifting via hidden manipulation </li></ul>
  8. 8. Original HTML Form
  9. 9. Modified HTML Form
  10. 10. View Executed Results <ul><li>View “/etc/passwd” file as modifed form requested </li></ul><ul><li>Use Unix “crack” to break encrypted passwords </li></ul><ul><li>Obtain access to root accounts </li></ul>
  11. 11. Prevention of Example <ul><li>Never trust hidden input values </li></ul><ul><ul><li>Proved that it is easy to change values </li></ul></ul><ul><li>Never allow unsanitized inputs to be used for viewing other files via script </li></ul><ul><ul><li>in this case we viewed /etc/passwd instead of the normal guestbook results file </li></ul></ul>
  12. 12. Parameter Tampering <ul><li>Find vulnerable form with unchecked input </li></ul><ul><li>Add malicious input to input form </li></ul><ul><li>“Submit” form </li></ul><ul><li>Gain unauthorized access </li></ul>
  13. 13. Parameter Tampering <ul><li>Failure to confirm the correctness of CGI parameters embedded in a hyper link can be easily used to break the site security. For example, a search CGI may accept a “template” parameter </li></ul><ul><li>Search.exe?template=result.html&q=security </li></ul><ul><li>By replacing the template parameter, one may be able to obtain access to any file, e.g. </li></ul><ul><li>Search.exe?template=/etc/passwd&q=security </li></ul>
  14. 14. Input Malicious Values
  15. 15. Original / Attacked Account File Newly created user Injected user with admin priv.
  16. 16. Prevention of Example <ul><li>Always test all input parameters for validity </li></ul><ul><ul><li>Length of input (checked on server side, not <input size=xxx>) </li></ul></ul><ul><ul><li>Strip input characters (e.g.: no ‘|’ ‘ ’, etc) </li></ul></ul>
  17. 17. Cookie Poisoning <ul><li>Many web applications use cookies in order to save information (user id, time stamp, etc.) on the client's machine. </li></ul><ul><li>For example, when a user logs into many sites, a login web script validates his user name and password and sets a cookie with his numerical identifier. </li></ul><ul><li>When the user checks his preferences later, another web script (say, preferences.asp) retrieves the cookie and displays the user information records of the corresponding user. </li></ul><ul><li>Since cookies are not always cryptographically secure, a hacker can modify them by modifying the cookie file, thus fooling the application. </li></ul>
  18. 18. Cookie Poisoning <ul><li>Find web application which trusts cookie data </li></ul><ul><li>Modify cookie data </li></ul><ul><li>Exploit </li></ul><ul><ul><li>Hijack other sessions </li></ul></ul><ul><ul><li>Grant privileges </li></ul></ul>
  19. 19. Original Website
  20. 20. Cookie Modification
  21. 21. Gain Access of Other User
  22. 22. Prevention of Example <ul><li>Encrypt cookie contents </li></ul><ul><li>Hash cookie contents (risky w/o validation of session/user) </li></ul><ul><li>Always validate user by checking the session user was granted permissions </li></ul><ul><li>Store all data excluding session-id on server </li></ul><ul><li>Store session-id and hash in cookie </li></ul>
  23. 23. Stealth Commanding <ul><li>The use of server side executions (e.g. “eval” or “system” Perl commands, SQL queries) enable someone to plant Trojan-horses in form submissions and run malicious or unauthorized commands </li></ul><ul><li>Take a postcard site as an example. The user fills in a postcard sending form, including the recipient name. The site then emails the recipient with the postcard. The CGI used for this purpose was written in Perl, and it had the following statement in it: </li></ul><ul><li>open (MAIL, &quot;|$mailprog $recipient&quot;. It is easy to see how, by filling in the recipient field with &quot;</etc/passwd,&quot; the hacker will be mailed the password file. </li></ul><ul><li>Shell commands can be executed as well by sending &quot;x;rm -r /&quot;, deleting the entire site. </li></ul>
  24. 24. Forceful Browsing <ul><li>Forceful Browsing Web servers will send any file to a user, as long as the user knows the file name and the file is not protected. Therefore, a hacker may exploit this security hole, and &quot;jump&quot; directly to pages. For example, : </li></ul><ul><li>A registration page had an HTML comment mentioning a file named &quot;_private/customer.txt&quot;. Typing &quot;; sent back all customers' information. </li></ul><ul><li>Appending &quot;~&quot; or &quot;.bak&quot; or &quot;.old&quot; to CGI names may send back an older version of the source code. For example, &quot;; returns admin.jsp source code. </li></ul>
  25. 25. Debug Information Leakage <ul><li>Find Debug Code </li></ul><ul><li>Experiment with debug code and parameters </li></ul><ul><li>Experience “Information Leakage” </li></ul>
  26. 26. Debug Script Example
  27. 27. Debug Script Information Leak
  28. 28. Backdoors and Debug Options <ul><li>Many applications contain code left for debugging purposes, and some even contain code left by disgruntled employees. </li></ul><ul><li>In a certain site, parameter tampering with the session token produced a page saying &quot;we lost you, please re-login.&quot; </li></ul><ul><li>That page presented a link for re-login which actually was a debug option. It logged in the hacker with no password required — furthermore, it logged in the hacker as the site's QA person. </li></ul>
  29. 29. Debug Information Leakage <ul><li>Find Debug Code </li></ul><ul><li>Experiment with debug code and parameters </li></ul><ul><li>Experience “Information Leakage” </li></ul>
  30. 30. Debug Script Example
  31. 31. Debug Script Information Leak
  32. 32. Configuration Subversion <ul><li>Misconfiguring web servers and application servers is a very common mistake. The most common misconfiguration is one that permits directory browsing. </li></ul><ul><li>Hackers can utilize this feature in order to browse the application's directories (such as cgi-bin/) by simply typing in the directory name. </li></ul><ul><li>In the case of a misconfigured ColdFusion application server, accessing /CFIDE/administrator/index.cfm will invoke an administrator console without requiring a password. </li></ul>
  33. 33. Vendor-assisted Hacking <ul><li>Because product vulnerabilities are published quickly over the web today, and because installing the latest vendor patch usually is not a high-priority issue, it almost always is possible to exploit vulnerable products. </li></ul>
  34. 34. Secure Web programming techniques <ul><li>Do not trust client side data </li></ul><ul><li>Hidden HTML form elements are not hidden </li></ul><ul><li>Password form elements are still in the clear if not using SSL </li></ul><ul><li>Use solid cryptographic algorithms </li></ul><ul><li>Use trusted authentication mechanisms </li></ul><ul><li>Re-authenticate before issuing password or executing critical transactions </li></ul><ul><li>Do not host uncontrolled data on a protected domain </li></ul><ul><li>Never validate data client-side </li></ul><ul><li>Sanity check and qualify all incoming data (e.g.) </li></ul><ul><ul><li>If data is supposed to be only yes or no, through away other options </li></ul></ul><ul><ul><li>Check range and other data integrity rules </li></ul></ul><ul><ul><li>Check file paths </li></ul></ul><ul><ul><li>Don’t use anything you don’t understand </li></ul></ul><ul><ul><li>Pay particular attention to special characters (a major source of problems) e.g. </li></ul></ul><ul><ul><ul><li>../(directory traversal), & ? + (file grabbing), ; (command appending), > < ? (piping), </li></ul></ul></ul>
  35. 35. Cross-Site Scripting <ul><li>Most web browsers have the capability to interpret scripts embedded in web pages downloaded from a web server. Such scripts may be written in a variety of scripting languages and are run by the client's browser. Most browsers are installed with the capability to run scripts enabled by default. </li></ul><ul><li>Sites that host discussion groups with web interfaces have long guarded against a vulnerability where one client embeds malicious HTML tags in a message intended for another client. </li></ul><ul><li>For example, an attacker might post a message like </li></ul><ul><ul><ul><ul><li>Hello message board. This is a message. <SCRIPT>malicious code</SCRIPT> This is the end of my message. </li></ul></ul></ul></ul><ul><li>When a victim with scripts enabled in their browser reads this message, the malicious code may be executed unexpectedly. Scripting tags that can be embedded in this way include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>. </li></ul><ul><li>When client-to-client communications are mediated by a server, site developers explicitly recognize that data input is untrustworthy when it is presented to other users. Most discussion group servers either will not accept such input or will encode/filter it before sending anything to other readers. </li></ul>
  36. 36. Cross-Site Scripting (XSS) <ul><li>Hacker: </li></ul><ul><li>Locate web page with unchecked input </li></ul><ul><li>Embed ‘poisoned link’ to web page or embedding scripts </li></ul><ul><li>Innocent Victim: </li></ul><ul><li>Follow ‘poisoned link’ or the scripts executes upon page load </li></ul><ul><li>Automatic execution of script </li></ul><ul><li>Leakage of information (or worse!) </li></ul>
  37. 37. Distribute Poisoned Link
  38. 38. User Follows Poisoned Link
  39. 39. Real Attack <ul><li>Javascript ‘alert(“Hacked by Pony”)’ would be changed </li></ul><ul><li>Leak cookie data to hacker </li></ul><ul><ul><li>“ ”) </li></ul></ul>
  40. 40. Prevention of Example <ul><li>Web Server: </li></ul><ul><li>Always sanitize input data </li></ul><ul><li>Encrypt cookie data </li></ul><ul><li>User: </li></ul><ul><li>Turn off client-side scripting </li></ul>
  41. 41. Cross-site scripting examples <ul><li>“ Slemko's idea was to combine cross-site scripting vulnerabilities with the fact that, for up to 15 minutes after someone signs in to Hotmail , that person's authorization extends to every other Passport service, including Wallet. In this case, if a victim reads the specially crafted e-mail within 15 minutes of signing in, the code contained in the message retrieves all the person's cookies, bits of code that identify the user. The attacker can then use those cookies to access other services within those 15 minutes. “ -- Nov. 2001 </li></ul><ul><li>Cross-site scripting allows hackers to run dangerous code within a Net user's browser or email client. By exploiting the vulnerability, &quot;malicious users can fool other users' Web clients...which allows them to do things such as stealing that client/server's cookies,&quot; Basically an attack on a Schwab user could allow the hacker to have access to all of the customer's account actions--such as buying and selling stocks or transferring funds while the customer was logged on to his account. -- Dec. 2000 </li></ul>
  42. 42. Cross-Site Scripting Cont’d <ul><li>An attacker may construct a malicious link such as </li></ul><ul><ul><li><A HREF=&quot; mycomment=<SCRIPT>malicious code</SCRIPT>&quot;> Click here</A> </li></ul></ul><ul><li>When an unsuspecting user clicks on this link, the URL sent to includes the malicious code. If the web server sends a page back to the user including the value of mycomment , the malicious code may be executed unexpectedly on the client. This example also applies to untrusted links followed in email or newsgroup messages. </li></ul><ul><li>This actually have happened to reputable companies such as Microsoft, Schwab, (’s). </li></ul><ul><li>Abuse of other tags </li></ul><ul><li>In addition to scripting tags, other HTML tags such as the <FORM> tag have the potential to be abused by an attacker. For example, by embedding malicious <FORM> tags at the right place, an intruder can trick users into revealing sensitive information by modifying the behavior of an existing form. </li></ul><ul><li>Other HTML tags can also be abused to alter the appearance of the page, insert unwanted or offensive images or sounds, or otherwise interfere with the intended appearance and behavior of the page. </li></ul>
  43. 43. Cross-Site Scripting Cont’d <ul><li>SSL-Encrypted Connections May Be Exposed </li></ul><ul><ul><li>The malicious script tags are introduced before the Secure Socket Layer (SSL) encrypted connection is established between the client and the legitimate server. SSL encrypts data sent over this connection, including the malicious code, which is passed in both directions. While ensuring that the client and server are communicating without snooping, SSL makes no attempt to validate the legitimacy of data transmitted. </li></ul></ul><ul><ul><li>Because there really is a legitimate dialog between the client and the server, SSL reports no problems. Malicious code that attempts to connect to a non-SSL URL may generate warning messages about the insecure connection, but the attacker can circumvent this warning simply by running an SSL-capable web server. </li></ul></ul><ul><li>Attacks May Be Persistent Through Poisoned Cookies </li></ul><ul><ul><li>Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code. </li></ul></ul>
  44. 44. Cross-Site Scripting Cont’d <ul><li>Attacker May Access Restricted Web Sites from the Client </li></ul><ul><ul><li>By constructing a malicious URL an attacker may be able to execute script code on the client machine that exposes data from a vulnerable server inside the client's intranet. </li></ul></ul><ul><ul><li>The attacker may gain unauthorized web access to an intranet web server if the compromised client has cached authentication for the targeted server. There is no requirement for the attacker to masquerade as any particular system. An attacker only needs to identify a vulnerable intranet server and convince the user to visit an innocent looking page to expose potentially sensitive data on the intranet server. </li></ul></ul>
  45. 45. Cross-Site Scripting Solutions <ul><li>Solutions for Users </li></ul><ul><li>None of the solutions that web users can take are complete solutions. In the end, it is up to web page developers to modify their pages to eliminate these types of problems. </li></ul><ul><li>However, web users have two basic options to reduce their risk of being attacked through this vulnerability. The first, disabling scripting languages in their browser, provides the most protection but has the side effect for many users of disabling functionality that is important to them. Users should select this option when they require the lowest possible level of risk. </li></ul><ul><li>The second solution, being selective about how they initially visit a web site, will significantly reduce a user's exposure while still maintaining functionality. Users should understand that they are accepting more risk when they select this option, but are doing so in order to preserve functionality that is important to them. </li></ul>
  46. 46. Cross-Site Scripting Solution <ul><li>Web site administrators and developers can prevent their sites from being abused in conjunction with this vulnerability by ensuring that dynamically generated pages do not contain undesired tags. </li></ul>
  47. 47. Dangerous HTML tags <ul><li><APPLET> </li></ul><ul><li><BODY> </li></ul><ul><li><EMBED> </li></ul><ul><li><FRAME> </li></ul><ul><li><FRAMESET> </li></ul><ul><li><IFRAME> </li></ul><ul><li><ILAYER> </li></ul><ul><li><META> </li></ul><ul><li><OBJECT> </li></ul><ul><li><SCRIPT> </li></ul><ul><li><STYLE> </li></ul><ul><li><SRC> </li></ul><ul><li><HREF> </li></ul><ul><li><TYPE> </li></ul>
  48. 48. Script filtering considerations <ul><li>Replace all “script” tags </li></ul><ul><li><IMG SRC=“javascript:…”>, replace “javascript” string in all SRC & HREF attributes </li></ul><ul><li><IMG SRC=“javas </li></ul><ul><li>cript:…>, filter white spaces before key work string search </li></ul><ul><li><IMG SRC=“javasc ript:…>, many other characters will work also! Filter these characters before the key word search. </li></ul><ul><li><style TYPE=“text/javascript”> JS EXPRESSIOn </style>, replace all “javascript” with “java_script” </li></ul><ul><li><STYLE type=text/css> @import url( http://server/very_bad.css ); </style>. Filter and replace @import </li></ul><ul><li><P STYLE=“left:expression(eval(“…”));>, Filter left:, expression and eval </li></ul><ul><li><IMG SRC=“java<xxx>script:…> if <xxx> were to be removed, replace, don’t remove </li></ul>
  49. 49. Cross-site scripting cont’d <ul><li>XML and SOAP are going to increase these issues </li></ul>
  50. 50. Filter bypassing <ul><li>Client-side scripting attacks requires the execution of Javascript, Java, VBScript, ActiveX, Flash etc. </li></ul><ul><li>Assume web applications accept HTML </li></ul>
  51. 51. Cookie authentication guidelines <ul><li>Use SSL for username/password authentication </li></ul><ul><li>Do not store plain text or weakly encrypted password in a cookie </li></ul><ul><li>The cookie should not be re-used or re-used easily by another person </li></ul><ul><li>Password or other confidential info should not be able to be extracted from the cookie </li></ul><ul><li>Cookie authentication credential should NOT be valid for an over extended length of times </li></ul><ul><li>Set up “booby trapped” session tokens that never actually get assigned but will detect if an attacker is trying to brute force a range of tokens. </li></ul><ul><li>(Whenever possible) Tie cookie authentication to an IP address (part or all of the IP address) </li></ul><ul><li>Adding “salt” to your cookie (e.g. hashed http header of a particular browser, MAC address) </li></ul><ul><li>Re-authenticate whenever critical decisions are made </li></ul><ul><li>Over write tokens upon logout. </li></ul>
  52. 52. Re-password authentication <ul><li>When performing a critical action: </li></ul><ul><ul><li>Use password re-confirmation before the action is carried out </li></ul></ul><ul><ul><li>YES or NO button to confirm if the action is what was intended </li></ul></ul><ul><li>This prevents malicious scripts from quickly sending a CGI request and have an entire database cleared of its contents. </li></ul>
  53. 53. Direct SQL commands <ul><li>Example: Changing SQL values </li></ul><ul><ul><li>UPDATE usertable SET pwd=‘$INPUT[pwd]’ WHERE uid=‘$INPUT[uid]’; </li></ul></ul><ul><ul><li>Normal input: </li></ul></ul><ul><ul><li>Malicious input:’+or+uid+like’%25admin%25 ’; </li></ul></ul><ul><ul><li>Result: changed administrative password. </li></ul></ul><ul><ul><li>Mitigation: validate input </li></ul></ul>
  54. 54. URL manipulation <ul><li>Valid transaction: </li></ul><ul><li> </li></ul><ul><li>Malicious transaction: </li></ul><ul><li> </li></ul><ul><li>Mitigation: whenever parameters are sent, check session token </li></ul>
  55. 55. Back doors <ul><li>Debugging options </li></ul><ul><li>Comments </li></ul><ul><li>Default accounts </li></ul><ul><li>Remote administration options </li></ul>