1 / 24

Web Application Attacks ECE 4112 Fall 2007

Web Application Attacks ECE 4112 Fall 2007. Group 9 Zafeer Khan & Simmon Yau. Motivation. SANS (SysAdmin, Audit, Network, Security) Top-20 2007 Security Risks (2007 Annual Update) No. 1 Client side vulnerability is web browsers No. 1 Server side vulnerability is web applications

kingashley
Télécharger la présentation

Web Application Attacks ECE 4112 Fall 2007

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. Web Application Attacks ECE 4112 Fall 2007 Group 9 Zafeer Khan & Simmon Yau

  2. Motivation • SANS (SysAdmin, Audit, Network, Security) Top-20 2007 Security Risks (2007 Annual Update) • No. 1 Client side vulnerability is web browsers • No. 1 Server side vulnerability is web applications • Common forms: • PHP Remote File Include (Remote Code Execution) • SQL Injection • Cross-site Scripting (XSS) • Cross-Site Request Forgeries (CSRF)

  3. Outline • URL Interpretation Attacks • HTTP Response Splitting – Cross Site Scripting • SQL Injection • Impersonation Attacks • Buffer Overflow • Remote Code Execution

  4. URL Interpretation Attacks • An attacker can take advantage of the multiple ways of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE).

  5. URL Interpretation Attacks • HTTP Response Splitting • http://website/redirect.php?page=http://website/welcome.html • http://website/redirect.php?page =0d%0aContent-Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a%3chtml%3eHello, world!%3c/html%3e • Result: • Content-Type: text/html • HTTP/1.1 200 OK • Content-Type: text/html • <html>Hello, world!</html>

  6. URL Interpretation Attacks • Cross Site Scripting • http://website/redirect.php?page=http://website/hacked.html • Runs a JavaScript popup asking for Credit Card Number

  7. URL Interpretation Attacks • SQL Injection • “login.asp”: SQLQuery = “SELECT preferences FROM logintable WHERE userid=’” & Request.QueryString(“userid”) & “’ AND password=’” & Request.QueryString(“password”) & “’;” • http://target/login.asp?userid=bob%27%3b%20update%20logintable%20set%20passwd %3d%270wn3d%27%3b--%00 • Result: • SELECT preferences FROM logintable WHERE userid=’bob’; update logintable set password=’0wn3d’;

  8. Defenses Against URL Interpretation Attacks • There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx). • Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input. • When client input is required from web-based forms, avoid using the “GET” method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the “POST method whenever possible.

  9. Impersonation Attacks An attack where someone pretends to be someone they are not Ability to gain access to private account information Large sums of money involved Hackers and organized crime alike would be interested

  10. PHP Session Http is a stateless protocol Sessions are needed to store information Sessions are different than cookies Example of a PHP session students will see in the lab http://www.simmonyau.com/session.php

  11. Session.php <?php session_start(); if ($PHPSESSID) { echo $PHPSESSID; } else { print('This is your first time visiting this site. A session has been created to track your information.'); session_register('PHPSESSID'); $PHPSESSID=rand(); } ?>

  12. Poorly Coded PHP Session Management Poorly coded PHP sessions can lead up to impersonation attacks. Although these kinds of attacks are unlikely to happen unless the web developer was an idiot, let’s look at an example. http://www.simmonyau.com/badsession.php

  13. Badsession.php

  14. Badsession.php (cont’d)

  15. Session Hijacking It’s also possible for a hacker to pretend to be a legit organization to trick you into giving them your account information. A malicious user could for example get a false certificate and place it on their website impersonating an organization or pretending to be a real organization.

  16. Session Hijacking Prevention • As a web developer, be sure to use the safest ways in coding. Sometimes the default settings may be the most secure. • For this lab, the following changes were made from the default settings just to hijack the session of the website: • register_globals was enabled (usually disabled for security purposes) • session_register() was used instead of $_SESSION['name']

  17. Session Hijacking Prevention (cont’d) 3. php.ini changes ; Whether to use cookies. session.use_cookies = 1 session.cookie_secure =0 ; This option enables administrators to make their users invulnerable to ; attacks which involve passing session ids in URLs; defaults to 1. session.use_only_cookies = 0 ; Name of the session (used as cookie name). session.name = PHPSESSID register_globals=on

  18. Session Hijacking Prevention (cont’d) 4. Protect the integrity of your session tokens/ids. 5. Do not ever use $_GET variables. 6. Do not register or input your information under shady websites. 7. If you are logging into a “secure” website, check to see if http changes to https.

  19. Buffer Overflow A buffer overflow attack can occur when a user inputs more data in a buffer than it can handle. As a result, this code flows over into other buffers and can corrupt or overwrite data in them. Although buffer overflows are harder for hackers to find, it is easily exploitable by anyone once it is found.

  20. Buffer Overflow Prevention Keep up to date with patches on programs. Invalidate stack execution so extra code that executes in the stack instead of the code can not run. Use good compliers because they usually catch unsafe structures like gets(), strcpy(), etc. Use the tool libsafe to provide secure calls to function. (it follows frame pointers to the correct stack frame when buffers are passed to unsafe functions.

  21. Remote Code Execution An exploit where a user could run some arbitrary code on a server. Example: When register_globals are turned on for php, if a webpage contained require($somepage . “.php”); Someone could then type in http://www.yoursite.com/index.php?somepage=http://

  22. Remote Code Execution Preventions There’s not much you can do besides be careful when coding your web applications.

  23. Resources http://searchsoftwarequality.techtarget.com/searchAppSecurity/downloads/Hacking_Exposed_ch06.pdf, Hacking Exposed http://capec.mitre.org, CAPEC (Common Attack Pattern Enumeration and Classification) http://www.sans.org/, SANS (SysAdmin, Audit, Network, Security) Institute http://www.securityfocus.com/infocus/1774 http://www.pcmag.com/article2/0,1759,34074,00.asp http://www.weberdev.com/ViewArticle/Exploring-Session-Security-In-PHP-Web-Applications http://www.tizag.com/mysqlTutorial/mysqltables.php http://phpsec.org/projects/guide/4.html http://www.ic.unicamp.br/~stolfi/urna/buffer-oflow/

  24. Questions? ECE 4112 – Don’t Learn To Hack, Hack To Learn

More Related