1 / 23

Security and Related Topics

Security and Related Topics. Willem Visser RW334. Overview. Validation and Escaping (again) Cookies Passwords. Input Validation. Web validation Different topic, checks if websites conform to rules All inputs must be checked after being submitted Before doing DB actions

aurelia-bass
Télécharger la présentation

Security and Related Topics

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. Security and Related Topics Willem VisserRW334

  2. Overview • Validation and Escaping (again) • Cookies • Passwords

  3. Input Validation • Web validation • Different topic, checks if websites conform to rules • All inputs must be checked after being submitted • Before doing DB actions • Or any other external action • Before writing to the output again • Serious security exploits based on no validation • Escaping is a form of validation • Make sure HTML displays correctly • Use existing libraries to do this

  4. Security IssuesBuffer Overflows • Buffer overflows <form name=”login" action=”/login" method="POST"> ... <input type="text" name="input" maxsize=”32"> ... • Hacker can modify the page source to change the 32 and then submit something much bigger • If this is not checked server side a buffer overflow is possible • Or even just the “correct” output could be useful to hacker

  5. Buffer OverflowHeartbleed No check on size of characters to be returned in heartbeat message of OpenSSL Rouge user can ask for up to 64kb of data and it will happily return whatever is in that 64kb of memory after the short bit it was supposed to return http://xkcd.com/1354/

  6. Security IssuesCareful what you reveal in source • Don’t give anything away in the url for example • When you subscribe to a list or website check what the url looks like you click on to confirm your subscription • Watch out for hidden variables, those can contain info you don’t want anyone to know • But can be seen when viewing page source • Same with calling scripts and parameters • Can be manipulated to call different things

  7. Code Injection • Injecting code that can be executed by the application • Add this to any text input box that might get displayed back to the user • <script>alert(’Hacked!') </script> • Not working on GAE  • This code can be executed when input that is not well formed is returned to the user, as in our running examples • Cross-Site Scripting (XSS) • User clicks on “bad” code that is then executed to steal information etc. • Might be a link in a forum for example • SQL injection • Adding SQL to text to get it to execute on the DB

  8. XSS • Reflective • Executes code when user clicks on specially crafted link • This code then changes the location of some other link on a different website that is currently being accessed…for example a bank • Clicking on this link it might send back session id etc. and the hacker is in • Stored • Attacker gets to store info in a DB that it can then later exploit • For example setting an admin link when logged in as a normal user that sends the admin session data when next an admin logs in • Many more example on the web, see http://google-gruyere.appspot.com/

  9. SQL Injection • Classic example during login • Check if user is in the DB • Without any checks on the login name • SELECT * FROM users WHERE name = ‘n’ AND passwd = ‘pw’ • Enter ‘ OR 1=1 ; # as the username • SELECT * FROM users WHERE name = ‘’ OR 1=1; # AND passwd = ‘’ • Success you are in with no password • Note # is a comment symbol in MySQL

  10. Cookies • HTTP is stateless • Use sessions with the aid of Cookies to keep users “logged in” • That “Remember Me” box on a site is nothing more than allowing a Cookie to be stored in your browser for the site • Check under Developer Tools and Resources in Chrome for Cookies currently used for a domain • Can be used to track your surfing!

  11. Cookies (2) • Sent in HTTP headers • curl -- head -l www.google.co.za • Set-Cookie: PREF=ID=0f4f078de20efed5:FF=0:TM=1397564390:LM=1397564396:S=4LDlIg6_4L0NT05_; expires=Thu, 14-Apr-2016 12:19:51 GMT; path=/; domain=.google.co.zaSet-Cookie: NID=67=KYapL75YwuQDGpliMNfMq_uzpJTX1sH1x5BdqdXoJPFrLQkXsWu5bVtLGQbipUDSVxMGYHjF-XEKcd913PjeEjfCwK5HVKfFq1NU7e8Wu2VoXFQlzKgyT1Yu7GLJn-w3; expires=Wed, 15-Oct-2014 12:19:51 GMT; path=/; domain=.google.co.za; HttpOnly • Only valid for domain and subdomains of it • Cookie format • NAME=VALUE;NAME2=VALUE2… • Don’t use “;” in the cookie value!

  12. Cookie Example import webapp2 class MainPage(webapp2.RequestHandler): defget(self): self.response.headers['Content-Type'] = 'text/plain' visits = self.request.cookies.get('visits', '0') if visits.isdigit(): visits = int(visits) + 1 else: visits = 0 self.response.headers.add_header('Set-Cookie', 'visits=%s' % visits) self.response.out.write("You've been here %s times!" % visits) app = webapp2.WSGIApplication([('/', MainPage)], debug=True) Increments the counter on every page refresh

  13. Loyalty Program import webapp2 class MainPage(webapp2.RequestHandler): defget(self): self.response.headers['Content-Type'] = 'text/plain' visits = self.request.cookies.get('visits', '0') if visits.isdigit(): visits = int(visits) + 1 else: visits = 0 self.response.headers.add_header('Set-Cookie', 'visits=%s' % visits) if visits > 10: self.response.out.write("You are the best ever!") else: self.response.out.write("You've been here %s times!" % visits) app = webapp2.WSGIApplication([('/', MainPage)], debug=True)

  14. Hackers! • All was well until people thought of cheating the loyalty program • They can just edit the cookie value and don’t have to actually visit the site • document.cookie=”visits=10” in Dev Tools Console under Chrome • Oh well…we could make it more difficult to do that • We could hash the cookie value • Note that people tend to use SSL (more later) and don’t bother to hash cookies • Don’t follow the herd rather hash your cookies anyway! • That might save you in an XSS attack

  15. Hashing Cookies • Instead of just setting • Set-Cookie: visits = 5 • We add a hash • Set-Cookie: visits = 5 | [hash(5)] • Now if we get the Cookie back we check whether the hash(visits) = hash value

  16. Hashing Code import hashlib defhash_str(s): return hashlib.md5(s).hexdigest() defmake_secure_val(s): return "%s|%s" % (s, hash_str(s)) defcheck_secure_val(h): val = h.split('|')[0] if h == make_secure_val(val): returnval

  17. Loyalty Program class MainPage(webapp2.RequestHandler): defget(self): self.response.headers['Content-Type'] = 'text/plain' visits = 0 visit_cookie_str = self.request.cookies.get('visits') if visit_cookie_str: cookie_val = check_secure_val(visit_cookie_str) if cookie_val: visits = int(cookie_val) visits += 1 new_cookie_val = make_secure_val(str(visits)) self.response.headers.add_header('Set-Cookie', 'visits=%s' % new_cookie_val) if visits > 10: self.response.out.write("You are the best ever!") else: self.response.out.write("You've been here %s times!" % visits) Is the problem gone?

  18. Clever Hacker • Might guess which hashing function we are using! • Once they know it is md5 • Just hash the visits and add it to the cookie • We could add a secret string during the hashing • Hash(SECRET+visits) = [hash] • Without the hacker knowing the secret string they cannot construct the hash in the cookie

  19. Hashing Code + Secret SECRET = 'fluffybunny' import hmac defhash_str(s): return hmac.new(SECRET, s).hexdigest() Hash-based Message Authentication Code Good idea to keep the secret in separate module

  20. Password Hashing • You should never store passwords in readable form in a DB • Hash it and compare the hashed values • Having a plain text password DB stolen is beyond bad • Having a password hashed DB stolen is better • But…

  21. Rainbow tables • Problem is that with restricted inputs for the password field the number of options are not that big • If you can reverse all hashed options you will be able to crack the password • Hash all legal password options and compare the actual hashed password with your list to find the plain text password • Rainbow tables contain pre-computed hashes for words of restricted lengths that already exist and can be used to crack passwords

  22. Salt • In a similar solution to the secret string in the cookie examples, one can use a string to obfuscate the hash • Generate a random string for each password and hash it with, this is called (adding) salt • [Hash] = Hash(pw+salt) • DB entry now becomes • (username, [Hash]|salt) • Salt can be stored in the clear • Need to hash every password with every salt to build rainbow table • Also one hit cannot be used to reverse other passwords

  23. Other Considerations • SSL • So far we assumed passwords can be sniffed off the wire, but using encryption, i.e. https://… will make it impossible to do that • However one should not assume SSL is all you need…see heartbleed! • Use a slow hash for passwords • Want this to take longer to make it harder to crack • Use a fast hash for cookies • Do this all the time so it should be fast • Remember http://google-gruyere.appspot.com/

More Related