Web Security Session Management

Transcription

1 Web Security Session Management websec 1

2 Recall from many weeks ago: the web On the web, servers and clients, ie. web applications and browsers, communicate by HTTP requests and responses HTTP request are usually GET or POST requests GET: parameters in URL POST: parameters in HTTP body websec 2

3 Fundamental shortcomings of the web 1. No security is provided No confidentiality: all traffic is public, as it can be observed by nodes in the network No integrity: traffic can be altered by these nodes No authentication browser and server don't really know who they are talking to, apart from an IP address websec 3

4 Fundamental shortcomings of the web 2. HTTP is stateless and has no notion of session No state is recorded about previous requests (Hence) no notion of a sequence of requests belonging together in one conversation between client and server like not using conservation view aka threading in your client This is very clumsy if we want some ongoing interaction, or users logging in. websec 4

5 Today: two notions of sessions 1. HTTPS at the network layer, ie using TLS/SSL sessions to provide confidentiality integrity authentication (of the server, at least) 2. Session management at the application layer by web-application using sessions IDs and/or cookies server HTTP HTTPS DNS TCP... websec 5 IP UDP

6 HTTPS websec 6

7 HTTPS runs HTTP over TLS HTTPS HTTP TLS TLS is highly configurable, and security guarantees depend on configuration: Typically, integrity and confidentiality of the session attacker on the network can still see that two IP addresses communicate (the meta-data), but not what also URLs and parameters are protected inside TLS tunnel attacker cannot change any traffic, or replay bits of traffic, without this being detected Nearly always also server authentication ie client authenticates the server Possibly, but hardly ever, also client authentication ie server authenticates the client websec 7

8 Aside: name confusion TLS vs SSL Is it SSL, TLS, SSL/TLS, or TLS/SSL? The newer versions of SSL (Secure Sockets Layer) are called TLS (Transport Layer Security) TLS version 1.0 is SSL version 3.1 In practical usage, SSL and TLS are synonyms. Eg X509 certificates used for TLS are typically called SSL certificates, and a leading TLS implementation is OpenSSL. websec 8

9 HTTPS 1. Server sends X509 server certificate to client, which includes server s public key PK is digitally signed by Certificate Authority (CA), or self-signed browsers come pre-configured with a list of trusted CAs 2. Client checks that certificate has not been revoked by requesting Certificate Revocation List (CRL) from CA 3. Client authenticates the server, with a challenge-response protocol client sends random nonce encrypted with public key PK, and checks response that includes nonce that proves knowledge of the private key 4. Client and server then agree a session key typically an AES key, based on nonce and a random chosen by server 5. Subsequent HTTP traffic in a secure tunnel encrypted and MACed with session key encryption for confidentiality, MACing for integrity periodically the session key is refreshed websec 9

10 DV, OV and EV SSL certificates CAs can validate who is requesting a certificate for a domain in different ways: DV (Domain Validation) certificates check to validate that this is the owner of that domain, using whois information (eg via Free via Let'sEncypt since April 2016 OV (Organisation Validation) certificates Additional check on identity & existence of the organisation eg against Chamber of Commerce records EV (Extended Validation) certificates More rigorous check on identity of the organisation How much extra security EV gives over OV brings is debatable... Certificates can be wild-card certificates, eg for *.ru.nl instead of websec 10

11 EV certificates recognisable in browser websec 11

12 What are we trusting? eg some_ca.com abnamro.com websec 12

13 Trusted Computing Base (TCB) The Trusted Computing Base (TCB) is the smallest amount of software (and hardware, people, organisations,...) that you MUST trust for some security property. The TCB for HTTPS is huge: we must trust that the TLS software is correct (recall HeartBleed, ios goto bug,...) the web-server protects its private key the browser checks the certificate correctly, including the CRL the Certificate Authority (CA) the user checks for lock icon (and maybe the content of the certificate?) there is no malware in our browser or on our machine that is faking the display... websec 13

14 Things that go wrong... Certificate Authority DigiNotar was hacked in Fake certificates for google.com were issued, presumably for use in Iran. DigiNotar provided all the certificates for the NL government... The Chrome browser checks for suspicious certificates for google.com sws2 14

15 Things that go wrong... March 2012: ING banking app does not check SSL certificate December 2012: ABN-AMRO app does not check SSL certificate Better to use a web browser, with (hopefully correct) built-in HTTPS support, rather than implementing SSL/TLS support yourself in an app websec 15

16 Session management by the web application websec 16

17 Lack of state in HTTP HTTP is a stateless protocol It does not remember if there were previous requests This is bad for web applications Eg has this user logged in? Has the user put items in online shopping basket? Most web applications need the notion of a session: a sequence of HTTP requests & responses that belong together Why can t we use IP address for this? Different clients can share the same IP address Eg different users on lilo.science.ru.nl, or different users on a local wifi network Multiple servers can share the same IP address Clients and servers can change IP address esp. clients on mobile devices websec 17

18 Session & session data There is usually some session data associated with a session that needs to be remembered. Eg: content of online shopping basket Ways of keeping track of such data: 1. send it back & forth between server and browser with each request and response eg using hidden parameters 2. record it at the client side eg eg using HTML5 local storage 3. record it at the server side and just send back & forth a unique dentifier (Dis)Advantages? Pro of 1: server does not have to record lots of info for many sessions Con of 2: client could mess with this data websec 18

19 Things that can go wrong Classic security flaw: the price is recorded in a hidden form field, as shown by the proxy output above. The client can change this... websec 19

20 Misplaced trust in the client For data for which integrity is important (eg prices) the server should never trust the client to provide this data or to return this data unaltered Instead, the server should store such data server-side, as part of the data associated with a session or add a cryptographic integrity check eg using a MAC (Message Authentication Code) or Digital Signatur websec 20

21 Sessions managed by the web application Web application creates & manages sessions Session data is stored at server and associated with a unique session ID Client is informed of session ID and client attaches session ID to subsequent requests Hence server knows about previous requests Web application frameworks usually provide built-in support for session management, but a web application developers can implement their own NB it is better to use existing solutions than inventing your own. Still, don t underestimate the complexity of using these correctly. websec 21

22 Sessions & authentication The notion of session close tied with authentication Eg after logging in with a username & password, you will often have certain access rights for the rest of the session While the session lasts, any information that can be used by an attacker to spoof the session (eg a session ID) is just as valuable as the username/password! So such info should not be sent via HTTP but via HTTPS. How can a website mitigate this risk? by having a time-out to terminate inactive sessions by having a prominent LogOut button on every webpage ways to link a session to a machine will be discussed later websec 22

23 Example: session ID in URL Web page returned by the server contains links with session ID as extra parameter <html> Example web page with session IDs in the URL. The user can now click <a href= >here</a> or <a href= >here</a> passing on its session id back to the server wherever he goes next. </html> Hence: every user gets their own unique copy of a web page. websec 23

24 Example: session ID in hidden parameter <htm> The form below uses a hidden field <form method= POST" action= <input type="text" name= Your address"> <input type="hidden" name= sid" value= s1234"> <input type="submit" value= Click here to submit"> </form> Hidden means hidden by default by browser, not hidden from a proxy like WebScarab. Browser plugins will show hidden fields and let them be edited. A hidden form field could also be used to track user preferences, eg <input type="hidden" name="language" value="dutch"> websec 24

25 Session ID in URL vs hidden parameter Can you think of a downside of a session ID in the URL? If you give a link with your session ID to someone else, then that person might continue with your session! Also, bookmarking a URL incl. the session ID does not (or should not) make sense, as the next time you use the bookmark you should start a different session websec 25

26 Cookies Standard solution for dealing with session info in HTTP Cookie is piece of information that is set by the server & stored by the browser namely when HTPP response includes Set-Cookie field in header It belongs to some domain, eg It includes expiry date, domain name, optional path, optional flags eg secure and HTTPOnly flags Cookie is automatically included in any HTTP request by the browser, for any request to that domain in the Cookie field of HTTP request Effectively, provides state information about the current session Cookie can include any type of information sensitive information, such as session ID less sensitive information, such as language preferences Almost all websites use cookies. websec 26

27 Example cookie traffic Setting a cookie set with an HTTP response HTTP/ OK Content-type text/html Set-Cookie: language=dutch Set-Cookie: sessionid=123; Expires=Tue, 26 Apr :30:00 GMT... Cookie included in an HTTP request GET someurl.html HTTP/ OK Host: example.com Cookie: language=dutch, sessionid=123 websec 27

28 Different types of cookies non-persistent cookies only stored while current browser session lasts good for sessions persistent cookies preserved between browser sessions useful for maintaining user preferences across sessions lousy for privacy... websec 28

29 Domains, subdomain, and top level domains The domain in a cookie can be a subdomain of a website, eg cs.ru.nl is a subdomain of ru.nl Complex set of rules restrict cookie access across (sub)domains subdomains can access cookie for domain, but not vice versa subdomains can set cookie for direct superdomain, but not vv Rationale: subdomains need not trust their superdomain For top level domains, eg.nl, there are additional rules, to prevent ru.nl from setting a cookie for.nl But does all this work as intended for countries that use 3 level domain names? Eg for somecompany.co.uk, where co.uk is not a top level domain websec 29

30 Different ways to provide session ID 1. Encoding it in the URL Downsides: 1) stored in logs (eg browser history), 2) can be cached & bookmarked, 3)visible in the browser location bar. 2. Hidden form field Better: won t appear in URLs, so cannot be bookmarked, and less likely to be logged 3. Cookies Best choice: automatically handled by browser; easier & more flexible. But: slight security disadvantage when it comes CSRF, as cookie is automatically included by browser for security, session cookie must be made HttpOnly (to prevent XSS attack stealing cookies) and preferable Secure websec 30

31 Some session attacks Aim of attacker: get the session ID this can be session cookie, or other form of session ID if the victim is logged in, this is just as good as stealing his username and password! 1. Stealing the session ID a) sniffing network traffic (eg on unprotected wifi) b) injecting client-side scripts in browser (discussed later) 2. Session Prediction try to guess a session ID 3. Brute Force try many guesses for the session ID, until you get lucky 4. Session Fixation make the victim use a known session ID websec 31

32 Session ID prediction example Suppose you can check your grades in blackboard on page blackboard.ru.nl/grades.php?s=s where s is your session id, in the URL in this case, which happens to be your student number. Then you could try other student IDs or better still the university employee number of the teacher. Als de session ID wel random is, maar niet lang genoeg, kan de aanvaller hem nog proberen te brute forcen. websec 32

33 Session fixation example If the sessionid is in URL (or hidden form field), then an attacker can 1. start a session and obtain a session ID; 2. craft a link (or a webpage) for the victim, and try to get the victim to click that link (or visit that page and click links on it), with that session ID included; 3. the victim now goes to the website using a known session ID; 4. if the victim logs in, and the session ID is not changed, then the attacker can abuse the user s rights! If the session-id is a hidden form field, the sessionid is not in the URL. Then the attacker cannot use links for this. but has to use a webpage. websec 33

34 Making attacks on sessions harder Use long enough, random session IDs ie with enough entropy prevents session prediction and brute forcing Change session ID after any change in privilege level eg after logging in prevents session fixations Expire sessions eg by setting expiration on cookies reduces the attack surface in time Let clients re-authenticate before important actions reduces the value of any stolen session ID Use HTTPS for all requests & responses that include session ID, not just the login prevents networking sniffing websec 34

35 Additional defense mechanism Associate the session ID to other characteristics to detect an attacker using the session ID from a different machine Possible characteristics to use for this SSL identifier makes it impossible for attacker to use the session ID from a different machine browser agent or other characteristic of the browser of course, an attacker can easily spoof this IP address makes it impossible for attacker to use the session ID from a different IP address, downside: if legitimate user changes IP address during session (common for mobile device) the session breaks websec 35

36 Cookie stealing without breaking the TLS tunnel Without breaking the HTTPS tunnel, a Man-in-the-Middle attacker may be able to steal cookies HTTPS namely if bank.com fails to set the secure flag for its cookie bank.com websec 36

37 insecure cookie stealing without breaking the TLS tunnel Attack steps 1. user logs on to 2. server sets session ID for bank.com in cookie which is encrypted in HTTPS-traffic 3. user ask for an unencrypted HTTP request (eg for 4. MitM attacker replies with a redirect to 5. Browser follows redirect and sends the bank s cookie over HTTP 6. Bingo! Attacker has the cookie HTTP HTTPS bank.com websec 37

38 Making attacks on session cookies harder 1. secure cookies Only ever sent over encrypted HTTPS connections Encrypting the cookie itself, when it is sent over HTTP, is pointless. Why? Attackers can simply replay a stolen encrypted cookie! 2. HTTPonly cookies Makes cookie inaccessible to scripts NB these mechanisms protect against different types of attacks: 1. protects against eavesdropping or 2. protects against client-side scripts (discussed in later lecture) websec 38

39 Attacking HTTPS websec 39

40 Attacking HTTPS Attacker model: Man-in-the-Middle (MitM) attacker capabilities of the attacker eavesdrop on traffic (think of wireshark) modify traffic (think of a proxy) goals of the attacker seeing plaintext data modifying traffic without user noticing or just: seeing the cookie Example scenarios to realise this attack: malicious wireless access point fake website, and phishing s to lure victim to it via the ISP, e.g. by a nation state intercepting all internet traffic websec 40

41 Would you trust these URLs? Recall that a URL has the form So what is the domain we are accessing? How do you know that the first p is not a Cyrillic character? websec 41

42 URL obfuscation An attacker can try to confuse the user by including a username before the domain name Eg which translates to the IP address using strange Unicode characters in a homograph attacks Eg with a Cyrillic p To prevent this, modern browsers can use Punycode which encodes Unicode as ASCII to reveal funny characters in URLs Eg Domain highlighting to make it clear which part of the URL is the domain name Bugs in the browser software can also be exploited to confuse the user. Famous Internet Explorer bug: a URL with a null character, for example would not display properly... websec 42

43 Browser warnings use of strange character sets websec 43

44 Last homograph attack: April Some browsers display as apple.com Problem: puny encoding is only used when different characters sets are mixed, not if all characters are in the same (misleading) character set [See websec 44

45 Browser warnings domain highlighting websec 45

46 Browser warnings websec 46

47 Securing the last 30 centimeter... We can secure connections between computers 1000s of miles apart, eg using TLS/SSL, but the remaining 30 cm between user and laptop remain a problem websec 47

48 Attacking HTTPS: SSL stripping websec 48

49 Attacking HTTPS: (2) SSL stripping HTTP HTTPS simple SSL stripping bank.com HTTPS HTTPS advanced SSL stripping bank.com websec 49

50 Simple SSL stripping : HTTP + HTTPS The idea: the attacker forces the browser to fall back to an HTTP session, and hopes the user won t notice the missing s HTTP HTTPS When can the attacker do this? If the user a) types in rabobank.nl, without https in front of it bank.com b) begins a HTTPS session by clicking on a link in a webpage that was retrieved with HTTP websec 50

51 Start of HTTPS session with HTTP request (a) user user types in rabobank.nl request for website redirect (302) to browser follows redirect user connected with HTTPS websec 51

52 MitM attack on this start of HTTPS session (a) user MitM website user types in rabobank.nl request for redirect (302) to attacker follows redirect careful user would notice missing s in browser toolbar change HTTPS links to HTTP links server thinks there is nothing wrong! websec 52

53 MitM attack on start of HTTPS session (b) user MitM website some HTTP request change HTTPS links to HTTP links user clicks a replaced link change HTTP request back to HTTPS request careful user will notice missing s in browser toolbar change HTTPS links to HTTP links server thinks there is nothing wrong! websec 53

54 Simple SSL stripping The MitM attacker strips S from HTTPS in links in traffic from server to user puts this S back in traffic from the user to the server The result bank.com HTTP HTTPS The attacker can now intercept a username and password that the user sends (typically in a POST request) After intercepting this information, the attacker could stop the MitM attack, so that a secure tunnel between user & server is established and the user can then no longer see anything wrong! websec 54

55 Won t secure cookies help? Secure cookies won t be sent by the client s browser over HTTP Attacker can defeat this by removing the secure bit from Set Cookie instructions when forwarding traffic from the server to user websec 55

56 Spotting this attack? A careful user can spot this attack the URL misses the s in https the little lock is missing in the browser corner Nice improvement: the attacker can add as flavicon websec 56

57 The original secure site websec 57 [source: Moxie Marlinspike, Blackhat 2009]

58 SSL stripped version websec 58 [source: Moxie Marlinspike, Blackhat 2009]

59 The original secure site websec 59 [source: Moxie Marlinspike, Blackhat 2009]

60 The SSL stripped version websec 60 [source: Moxie Marlinspike, Blackhat 2009]

61 This window will pass username/password by https, but attacker can strip this, and reestablish the TLS session directly afterwards. Can the user still spot this? websec 61 [source: Moxie Marlinspike, Blackhat 2009]

62 Mixing http & https Moral of the last example: Never use https for a frame inside a http page Never issue https requests from an http page Web browsers nowadays warn about (or even block) mixed http/https content. websec 62

63 Other countermeasures to SSL stripping use HSTS (HTTP Strict Transport Security) use HTTPS Everywhere browser plugin websec 63

64 HSTS (HTTP Strict Transport Security) Protection against SSL stripping 1. website (e.g. bank.nl) tells the browser that it only ever wants to be approached with SSL, in HTTP response header Strict-Transport-Security: max-age= ; includesubdomain 2. the browser remembers this, and will in future turn http requests for that domain into https requests Eg browser will turn into HSTS is now supported by all mainstream browsers. Firefox & Chrome since 2011, Internet Explorer since websec 64

65 HSTS redirecting to https HSTS means that HTTP requests by user will be turned into HTTPS requests, for a specific domain But this is not the same as redirecting to https not the same in how in works not the same in the security it offers websec 65

66 Redirecting to https user user types in bank.nl request for redirect (302) to bank.nl browser follows redirect user connected with HTTPS websec 66

67 HSTS On very first visit to bank.com, the browser stores some information, recording that bank.com wants to talk HTTPS only. For subsequents visits user types in bank.nl, or clicks http link browser changes this to HTTPS request for bank.nl user connected with HTTPS websec 67

68 HSTS vs redirecting to https HSTS requires client-side storage of information With HSTS, the first HTTP requests never happens Hence MitM attacker cannot trick browser into revealing a session cookie plaintext over HTTP of course, a careful site would make its session cookie secure MitM attacker cannot starts an SSL stripping attack Note: these security advantages are only relevant in a setting where the attacker controls the network, as a Man-in-the-Middle, eg. an attacker that controls the Wifi access point, eg by setting up a fake eduroam access point. websec 68

69 Checking for HSTS usage In browser In Firefox: check for a file SiteSecurityServiceState.txt on Linux, this is in.mozilla/firefox/<random>profile or find it using locate SiteSecurityServiceState.txt on Windows, it is in %APPDATA%\Mozilla\Firefox\Profiles\ In Chrome: type chrome://net-internals/#hsts in address bar In HTTP traffic: look for HSTS field in HTTP header, of the form Strict-Transport-Security: max-age= ; preload On Linux, with curl -si " grep Strict websec 69

70 Attacking HTTPS: Advanced SSL stripping websec 70

71 Advanced SSL stripping Can we improve things? Ideally we want to get HTTPS HTTPS bank.com so the user cannot notice he is not having a TLS session For this, we have to to trick the browser into setting up a TLS tunnel to the attacker, believing it to be bank.com websec 71

72 Advanced SSL stripping: HTTPS+HTTPS Different ways for attacker to set up TLS tunnel from himself to victim 1. Use a self-signed certificate for bank.com but warnings will scare most users away 2. Attacker can buy domain name that looks like bank.com with international characters browser using puny-code may reveal this to user 3. Attacker can redirect to mafia.com, for which he has a certificate a) and hope the user does not notice the mafia.com in address bar b) better, use characters that look like / and? to make URL that looks like the bank s, eg browser that highlights domain part of URL may warn user websec 72

73 Advanced SSL stripping: HTTPS+HTTPS Different ways for attacker to set up TLS tunnel from himself to victim 4. Exploit browser bugs (1): Older TLS implementations in browsers had a bug that allowed attackers to create certificate for any site by extending the certificate chain, incorrectly but without the browser noticing [See Moxie Marlinspike's talk at Blackhat websec 73

74 Advanced SSL stripping: HTTPS+HTTPS Different ways for attacker to set up TLS tunnel from himself to victim 5. Exploit browser bugs (2): Buy a certificate for the domain CA will contact owner of mafia.com to validate the organisation but many SSL implementations would accept this certificate for Root cause: the complex format of X509 certificates [See Moxie Marlinspike's talk at DEFCON 17 websec 79

75 To do Check out some contents of SSL certificates, if you never have done that before Installing a browser plugin for inspecting cookie Eg CookieManager+ for Firefox and have a look at the cookies that you collect after some surfing For another explanation of SSL stripping, see the video of Moxie Marlinspike s presentation at DEFCON 2009 websec 80