Security and Related Topics

Willem VisserRW334

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

• 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

Security IssuesBuffer 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

<form name=”login" action=”/login" method="POST"> ... <input type="text" name="input" maxsize=”32"> ...

Buffer OverflowHeartbleed

http://xkcd.com/1354/

No check on size of characters to be returnedin 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

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

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

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/

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

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!

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!

Cookie Exampleimport 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

Loyalty Programimport 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)

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

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

Hashing Codeimport hashlibdef 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

Loyalty Programclass 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?

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

Hashing Code + SecretSECRET = '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

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…

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

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

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/