Presentation is loading. Please wait.

Presentation is loading. Please wait.

Security and Related Topics Willem Visser RW334. Overview Validation and Escaping (again) Cookies Passwords.

Similar presentations


Presentation on theme: "Security and Related Topics Willem Visser RW334. Overview Validation and Escaping (again) Cookies Passwords."— Presentation transcript:

1 Security and Related Topics Willem Visser RW334

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 Issues Buffer Overflows Buffer overflows 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 Overflow Heartbleed http://xkcd.com/1354/ 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

6 Security Issues Careful 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 alert(’Hacked!') 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.zawww.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.za Set-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): def get(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): def get(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 def hash_str(s): return hashlib.md5(s).hexdigest() def make_secure_val(s): return "%s|%s" % (s, hash_str(s)) def check_secure_val(h): val = h.split('|')[0] if h == make_secure_val(val): return val

17 Loyalty Program class MainPage(webapp2.RequestHandler): def get(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 def hash_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 https://crackstation.net/hashing-security.htm

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/


Download ppt "Security and Related Topics Willem Visser RW334. Overview Validation and Escaping (again) Cookies Passwords."

Similar presentations


Ads by Google