 I work at a company that makes this software for municipalities and hospitals and a lot more. It's called Centric. My role there is security specialist, ethical hacker, software architect. I break into all kinds of stuff just for fun and help people secure their applications. So, well, that's the context. So we need this. About session management. If you go to a website and log in and you tend to be logged in if you click the next page, the next page, the next page, that is a session. And when you click log out, you're not logged in anymore and the session is terminated. Very simple. So that's a session. And you can manage this by using the HTTP standards for cookies. If you have a lot of sensitive data, you need to do this correctly. And the rule of thumb is unauthorized access must be prevented the best way possible. And best way possible, there's a lot of text over there. It's like use everything available in the trade off and blah, blah, blah, blah that you can buy and do at a reasonable amount or unreasonable amount, maybe. And session cookies is just one thing in this big stack of things you need to do when building a secure web application. My tie is killing me slowly. So session cookies is just one thing. You need to correct headers. You need to do all kinds of things to get your application secure if it's a web application. The most frameworks for session management, like available on ASP.net by Microsoft or many, many, many other frameworks contain flaws. It's as simple as that. They are not complete like you might do session fixation and copy sessions of other people and just be them on their website, on those websites. It might be broken. It might have contained stupid values which we'll look at. There's also frameworks like ASP.net where you can determine your own session token. So you can say with this value, I am this person and you can just force it. And if somebody else types the same value, he's also that same person. So malware does not need to steal cookies. They only need to set the value, but that's going really far on this early hour. So session management. Some of the things that must be, sessions are only communicated in a secure protocol. Sessions tokens are valid for the entity that initiated the session. So your device or your browser. The end of life of the session is managed carefully. There are no loose ends. And the big thing is here, when doing sessions, you are the one in control. You are saying this person can visit this website for about 15 minutes and then it's terminated. And if he or she does not do anything for two minutes, then the session is terminated. Like all these rules. And you need to have the right server header set, et cetera, to prevent men in the middle, et cetera. So session cookies. The thing we're talking about. It does not look delicious. It looks quite boring actually. This is a session cookie. Oh well, this is a cookie. And what you do, if you go to a website, you send some text and the server sends some text back and it says, set cookie name is value, basically. It can be session and all kinds of attributes, but this is a cookie. So a cookie could be named logged in and the value could be one. That's stupid, but you can do this. So a cookie you use to authenticate to the server and say, this is me. You send it at every request. So every time you visit the page, you send a cookie and you get an answer from the server. Oh yes, this is indeed somebody I know. And you can have other sensitive data. So there are some other authentication methods available. There are a lot actually. You might have all seen them if you're using the web. There's basic authentication and that has the downside of sending your username and password on every request. So if there's one man in the middle or something or some insane logging, the username and password which does not change often is visible to this person. And you cannot log out on basic authentication. There's another problem. There's digest authentication. It's a little bit better. It sends a hash or encrypted value of your username and password on every request. So they cannot steal your value, your session or your credentials. And there are certificates, like you can install a certificate and then you go to a website and you're authenticated. This is actually very, very secure but you need a lot of setting up on the client side. And still, if you lose your device, then the device is authenticated and you still need, yeah, you're still logged in. So if you lose the device and somebody else can say, oh, this is a secure device and you can see everything. So you need still something with sessions or a pin or whatever. And there's something like Kerberos but I, oh, wow, I just skipped it. So I'm sorry for that. So what do these session cookies look like in a GUI? I hope everybody can see this. It's in Dutch, of course. I was lazy and made just Dutch screenshots. This is a very, very messy cookie. But this is what it looks like. This is the name. It's logged in an admin. This is the value. It's one. This is domain words given out. This is the path words valid on. And it has some check boxes. Basically, this is a nice GUI representation of a session cookie. And we can play with this. That's fun. The benefits of using session cookies are they're implemented correctly in all browsers or the major browsers. So you don't have to figure out how to do sessions by yourself. They're just a mechanism that works fine. They're customizable enough to be secure. And, well, that are the upsides. It's still user input. So if you do not validate the contents of the cookie, you can still have SQL injection and XSS and all the other nonsense if your website supports these features. So you have to be very carefully and only accept the things you have given out when using cookies. And, well, another thing is there's something called a session token. This is like a value that represents you. Like instead of you sending a username or password, there's a value that represents you. This is a session token. It can look like this on the left side. It's like a long text, very random complex. Well, actually this is not really random if you look at it closely. But it's long, it's random, it's complex, it's meaningless. And that's something that represents you for a session. So that's what you have on the client side. In your browser, if you're going to edit this cookie, which I will show, you need to have some weird thing that's called a session token. To do it right, you have this value on the client side. But you also do something on the server side. On the server side, you want to know when was the session initiated. One was the time it was last used. What is the IP address of the client? And what metadata or other information can I get from this client? These are very interesting things because what we want to do is make sure only one person that initiated the session has this particular value. So if you have a website that's not proxied and does not have complex network configuration, then you mostly see that if I visit a website, I have some IP address. And this value is associated with this IP address. So if I change IP address, I'm logged out. So if somebody steals my cookie, I am logged out, he is logged out, or she is logged out, it's whatever. There's ups and downsides. If we want to do applications that contain a lot of sensitive information, then we need to be as strict as possible. So if you switch networks, you will be disconnected. If you change or upgrade your browser, you will be disconnected. If somebody else is trying your session identifier, you are disconnected from the website. You have to log in again. So there is a series of things that can go wrong and you need something on the server side to manage if everything is going well. And if one thing is going not so well, this is like some sort of security alert and you just log the person out. Well, might try again, but if the same thing happens over and over again, you can see that there's something really wrong. So that is the contents of our basics on using a session cookie. On the client side, it's just a random number and hexadecimal or I don't know really what this format is. On the server side, you need start time, time loss used, IP address, metadata and everything else you can get. Screen resolution doesn't matter. The more, the better. So we just saw this GUI. I will go through all of these fields one by one, tell what they are and what they are not. So let's go to the worst example that you can have on a web application where you do admin session so you can manage user data or whatever or accounts or money or the system itself. I don't know. Preferably not too much. So we've got this name. It's logged in an admin. There's something wrong with this. What should be wrong with this name? Well, what is wrong with this name? Well, it's telling what it's for. The name should be something like ID or session or just something simple because now I know I have to look for this admin cookie and then if I steal it, I'm admin. That's stupid. So you should not ever use this name. Next to the value, this is the value one. So true. This person is an admin. It's true. That's also stupid because if this is a session, then everybody can make a cookie and say, I am an admin and then you are an admin. You can try this easily. So this value should be a long, complex thing. Then we've got a domain. This domain is for where the cookie is valid and where the cookie is sent to. And most of the time you will just see the cookie is from the website you've served to. Then there's a path on what directory on the server the cookie is valid. So if you have two applications, for example, example.com slash my application and admin application, then this path will definitely contain slash admin application. It doesn't. It's just valid everywhere. So you can have mixed scopes and everything so that will mess things up. And there's another nice thing. It's called expiration time. It's in the bottom. Verlobtheit. And the expiration time, if you set it, the cookie is stored on the client. So this information is stored on the device that it's used on. And it will be deleted after the expiration date or time. There are some flags in the bottom. Like host only. That's the one most on the left. The host only flag specifies where the cookie is sent to. So if you have all kinds of ad campaigns on your websites and you did not set the host only flag all these ad campaigns also receive all these cookies that you have set. That can be really nice, but if you do session management or want to be an admin or something you should make sure that your cookies are not sent to the ad agency. The second one is the most interesting one. It's the session flag. The session flag and expiration time do have something in common. If you set the session flag, the cookie will not be stored on the device. It will be only stored in memory on the device. And you cannot set the expiration time. So you have to do it on the server. That's why you need this value on the server. When you want to set the expiration time, you cannot set the session flag. So what should you do? Well, if you want to make it as secure as possible, you do not want to have a session stored on the computer. It can only be stolen by malware or something. So better just use the session flag and manage the expiration on the server side. Then we have the secure flag. It's called Veilig. And the secure flag makes sure that the cookies only send over HTTPS connections. Well, at least it should be sent only over HTTPS connection or secure HTTP connections. And the last one is HTTP only. And that means it cannot be accessed by scripts or JavaScript and everything. So you've probably heard of this cross-site scripting attack when this flag is not set. And this is like an admin session cookie and there's an cross-site scripting vulnerability on the website. You can just steal this session. Well, that's what it's for. And for most applications that must be secure, all these flags are just set. Simple as that. The path is set. The domain should be correct. The value should be complex. Not have understandable values should be long, random. And the name should be just ID. Not ASP.NET session ID. Not J session ID. Not PHP session ID. It should just be session. You shouldn't even be capable of determining what the technologies are behind the website if you're doing it right. But that's another story. So it's logged in and admin is wrong. You should just call it ID. So this is a better example. Here we've got this name. It's ID. Some value. It's very long and random. A domain is set. Where's the path? I cannot see the path anymore. Well, Velov probably. It's host only. It's session. It's secure. It's HTTP only. So it's got everything set. This is what you should do. Basically, it's that simple. Just for comparison, these two cookies next to each other, you cannot see it over here because it's far too bright. But on the screen and the presentation at home, you can. Then, let's do an example on how to manage session state. So now we have got a session cookie. You should all do this. So now let's manage this one. I'm giving an example. The blue bars are the periods that you're not logged in. The green bars are the periods that you're logged in. And this will be on a timeline. So left will be the starting time. Right will be the ending time. And the value of the session, an example value of the session will be inside this bar. So you can see that it changes on certain periods of time. So on a timeline, a very simple basic session is you visit the website. You might get a cookie that determines what kind of user you are, maybe what kind of ads you run. I don't know. You might get a cookie. Then you log into the website supplying your credentials and your token and your certificate and whatever. You'll see that after you've logged in, the value, this nonsensical value that's very long and random, changes. And that's interesting. It changes because what we want to do is make the scope or the time that somebody is logged in and the value, this session is valid as short as possible. You would not change it. And this all would be the same session value or token. If somebody doesn't attack here, it will be valid throughout the entire session. That will be a problem. It will be valid throughout logging in and logging out again. And it will be a problem because there's much more room for attacking and bugs in the websites to make sure that there are problems with this website. So we need to change this value often and as often as possible. So this is the very basic timeline. You log in and you log out and you see the token changes after logging in and after logging out. But in real life, it's a little bit more complex. This is an example that shows what can go wrong and should not go wrong. Well, you visited for the first time, then you logged in and you changed this session value. It's a nice other, a random value. And then things can happen. For example, the session can be terminated. And this can be terminated by a user clicking the log out button, which should be present on every page. The user can say, I'm done with my banking. I'm done with checking my records. I'm clicking log out and I'm logged out. So that means the session is terminated. You can log out by any action or something. When you're done with your work, you will be automatically logged out. The server says, well, you're logged out now. You're done. Come back next time. There's also things like there's a timeout. There's a relative timeout for like you click and when you do two minutes of idling, you're logged out as simple as that. Or when there's 15 minutes and there's a lot of sensitive application that only allow you to be online for 15 minutes in this application. It says, well, you've been here 15 minutes. You're logged out and the session token changed again. But you can also continue your session, maybe. And that's on the bottom. That's another branch. And the session token still changes. So on successful reauthentication, there's another session token. When there's a change of privilege, because I was now a user and I've authenticated or clicked something admin function, I don't really know what you want. But if there's a change of privilege, I become a super user. I get another session token because I have more powers than. And when I'm done, the session changes again. When I'm a user again, then the session changes again. So to minimize the duration of the value that's actually valid and accepted by the server. And there's another reason when it can change. And that's on every request. So every request you make, the session token changes. That's a lot of work to program. But yes, you can do this if you want. So if it's logged or something, the session token or somebody stole it, they should be up to par with your clicking behavior. Otherwise, they would not be able to get the first one or be the first one to change the session. So in the end of this change of privileges or reauthentication, you log out again or the application says you log out. And that's the same. So that's basically the more complex timeline of session management. If you want to do it right and you want to be more in control. Now for some live events, I've just shown them in these images. These are the texts you can read at home for if you don't want to listen to me, you can just read these live events that were just in the images before. And that's a wall of text, I know. So I'm talking about session lifespan, an example image that shows this lifespan for absolute timeout, relative timeout and rotation timeout is this image. It shows that, for example, these are four different types of sessions you might or might not want to support. The first one is just a simple session. You log in and you're valid, valid, valid and after 15 minutes you're logged out again. Here you see somebody that's not logged in, does not have a cookie, then it's logged in, has a cookie, then says I want to log out and then the cookie is gone, so it's empty. There's a relative timeout, like somebody is not doing anything, so no, does not have a cookie, then logs in, has a session cookie, then does five minutes of nothing and it's logged out. And there's an absolute timeout in the end, so after 15 minutes it's done, you're done, you cannot continue. Those are examples when you can change them, so this looks like an image that visualizes this scenario. So how should we test these cookies? Well, fortunately in all modern browsers there are nice plugins that help you with setting cookie values and doing security tests on them. There are also tools for doing this. The thing with these tools is that sessions can be very complex depending on all kinds of values, so they would not be likely to work in all cases, so you can do this by hand. If you want to test for the security of your sessions, this is basically one wall of text and this wall of text contains a lot of scenarios that you can test cookies for and we're going to test something like in a demo. For example, when you log into a website and you change IP address, you should be logged out. So what you do now is you get Tor browser, you log in to something, interesting, or you should change your IP over different networks or just change your IP from the command line or something and you see you're logged out. Make sure there's no proxy in between and something because that does not work. Is your metadata checked? So you have got these user agents which you send out. Hi, I'm Google Chrome, I'm this browser, this version. If you change it, you should be logged out. So you can just change it with a click of a button with some extensions in your browser. You can also test for all these live events. I'll not go through every one of these. You can check for the correct flags. You can just visually inspect them. It's easy. You can check for naming, for the value that's meaningless and long and complex and random and everything. You can see that if you can check, can I log out on any page that I see? So very easy. So let's do some live testing to show how you can test this and re-enact the scenarios that I've just given. This is going to be very interesting for me as a presenter because it should not be in presentation mode again or now. Here we go. I cannot see anything. So I will duplicate my screen. How does this work? Everything works fine. There's some website on the internet that does not have high security standards. It does not need to have high security standards. It's just a funny forum with all kind of retro gaming stuff. But this is how you can test the basics. So when I go to this forum, you see in the bottom there's a session. It's opened up with the debugger, Firebug. Every web developer has this or if you do not have it, you should. And here you see this session ID and a value that is somewhat long and meaningless. A domain, you see a session. So it's cached in my browser only, not stored to my desk. It's HTTP only, so JavaScript cannot access it. Very simple. Then we log in. So you can now copy my session because it's now. So if you're really quick, you can screw up my presentation too. Oh, here we are. We're logged in now. You can see this is logged in. So if you're really fast, you can copy it and you can just ruin my account and do everything defacement and whatever. It's illegal though. I will sue. Then we start Google Chrome. That's another browser. Just to show the metadata checking that you can copy things and such. So we go to retro forum, blah, blah, loads up. So let's log out here. I'm logged out here. I'm still logged in here. Yep. There's a lot of these cookies. So that's going to be very complex if you want to do it automatically. But oh, here's this edit this cookie plugin. It shows all the same cookies, the pass hash, the member ID. It's zero. Interesting. The session ID. So we can basically copy values from one browser to the next browser and see if this website prevents metadata changes. So let's do this. What we do is we've got this session ID. I've got a session ID here. I have to be quick because I know that the people from Camp Holland are trolling me like logging me out and everything with the same techniques I'm going to show here. So session value, session ID is now pasted. It's something else now. So paste and say was safe. We do the member ID. I'm member 620. Sure. Oh, I am. And then we do the pass hash. We also need this one. It's really small screen. It's interesting. Pass hash. I hope this is the one. Password hash. Okay. Well, so we've got all these things set with a little bit of luck. We should now be logged in. So if I click gallery, yeah, here it says welcome stage. So this is a basic test for how you copy cookies between browsers. You can do the same like this is a problem if there's, you can do this also on different IP addresses. So if I open this website in Tor browser, because it's a public website, just wanted to check if they have this IP check, which they don't. I can just go to the train and still be logged in and go to my work, still be logged in. I will be logged in till the end of time on this website. It's very nice and very friendly, but the secure application should not be that very nice and very friendly. So that's a basic way to just check for cookies. You can also check here in the bottom, you see this session ID. Well, let's check it. It has a session ID. I don't know what framework it is. I see a value. It's random. It's not long, but it's random. I think it has a domain set. It has a path set. So it's valid for retro forum slash everything. It has no expiration set because it's a session. So if I close this browser window, I should not be logged in anymore. It's host only. I will check this. So demoing it. It's host only. So only for this URL. It's HTTP only. So if this website or form will, it will contain security flaws, but it's HTTP only. So they cannot steal my session at least with scripting. And it's not secure. And that's true because I'm not connecting through a secure site. I don't know if they even have this. So that's how you do session. So you can just change everything and save it. This plugin is called edit this cookie. For every browser, there's... I'm closing it and just see if I'm still logged in. Demo effect pending. Close everything. It should not be because it was a session value. I'm still logged in. What's going on here? It's interesting. I have to figure this out. What's going on here? Well, that's a demo effect. So for every browser, there's these types of plugins where you can set your own session value. You can do like... It's usually input. So you can say, well, it's like... You can say, or one is one or something like that. Or you can do... Whatever. You can just try everything and see if the application dies or if it behaves like you do not want to have it behave. So that's what you can do. It's still okay. It still thinks it's I'm logged in. It's like crazy. So you can use these plugins. Use them. You can also do it by hand if you have Fiddler or Burp proxy or whatever. So some sources to wrap it all up. And even more sources. And I also strongly recommend you visit the website cookie clicker. If we're talking about cookies, it's a very nice website. It's a game and you get addicted to it quickly. So thank you all for listening to be here on this early morning. And I hope you have a great camp. Any questions are welcome. There's a question over there. The cookie is effectively used to supply the input as far as the website is concerned. Are there any fuzzing tools available? Are there any what kind of... Are there any fuzzing tools available? I have never used fuzzing tools for these types of things. I just do it manually. I know that Fiddler has an extension to do random input on whatever field you want. So yes, you can use just Burp proxy or Fiddler to replace something in your request. So yes, you can use any like of these tools to do fuzzing. Yeah, I was just thinking of the potential for bugs in the backend. Yeah, it's very interesting because they think it's secure. It's easy. Like it's cookies. Nobody can see them. That's like they're being... People tend to miss out on doing this correctly. Another question. Hi, so you suggested using metadata from the client to help increase security, something like the user agent. Yeah. So if I'm able to see the user's session cookie, I'm doing some sort of man in middle attack. I assume I'd be able to get that metadata as well. Well, yeah. So I guess my question is how does that add to security of your session authentication? It adds in the sense that it adds a little. It is not... You cannot prevent session fixation because if you have... Like you're working all in a big company behind one big proxy, you all have the same IP address too. So what you do is you just take everything you can to make it more secure. And preventing session fixation is impossible if you look at it really closely. So you just use everything that you can. So this is one measure. Thank you. Final question. So if you have... You have all the metadata and you have a user that is... You have the IP address and you have a fixated session. So what if something changes you use is logged out? But if you're using, for example, mobile phone, your IP address changes constantly. Yeah. That means that you can... If you have an application that is very secure and has very sensitive data on it, yeah, you better be on a fixed network or fixed IP address or something like that. And you have to provide your own service for this. Otherwise, you have a big risk of people man in the middle and everything else. So you basically... You cannot use it as just a normal consumer application. It's for specific purposes. And you know that this IP address... If it changes, you're being logged out. It's as simple as that. So it's not user-friendly. Any other questions? What do you recommend in some scenarios where the browser is not allowing any cookies to be set at all? Do you recommend that you don't log in at all? Or do you have a full-back position somehow that's... Interesting. If you need to log in... Well, there are four methods I know of that you can do. Authentication from basic authentication to Kerberos and a certificate. I would go for a certificate because it's fixed on the device. So this device is logged in. That would be the... It would be a lot of work to set it up, but you don't need cookies then. If the device gets stolen though, you need to have very good device management in place. But if it's a public site and then some browser... Some company is restricted to some access... The way that browsers are being set in the cookies or something... I don't know if there's a solution for that. If there is, I would like to know. But you would just not let them log in in that scenario, perhaps? If the browser does not support cookies, I currently do not know what are certificates or anything else. I currently do not know any way to give this person or this browser sensitive information. And I would not recommend it. I would recommend a strong security measure. Yeah, and that's a problem. It's just sad that you can just do... Instead of cookies, you can use this key, your token in every GET request. The reason that's not a good idea is that these GET requests get logged in every firewall and everything in the way. So you want to have as least people possible knowing your session. So not system administrators and everything that can look and do these logs. And just see, oh, it's this session key. I copy it and I'm logged in now. That's a recipe for disaster. Cookies, I don't know for sure, but cookies are less likely to be stored in firewall logs. So basically that's why you should not do this. And secondly, if you copy your URL and give it to someone else and you do no IP fixing and everything else, then the other person is just logged in. And that's a problem too. You cannot have this. So is there room for a question? Okay, one more question in the back. If you want to talk more, I'm available throughout the camp. I'm at Camp Holland as you can see. You mentioned mobile devices earlier. And if you're a mobile client and you don't want to store username and password on the device, you don't want the user to log in with their username and password every time they open your app. Can you use session management with cookies at all in a secure way? That's interesting. It's a very specific one. I like to think and discuss this with you. I think that's the best thing. The short answer is if you're doing mobile devices, you can do a lot of great device management stuff. And you should use that at least. So you are in control of your devices. That's the start. And then if you don't want to store user names and passwords or have to log in again, a session would be great. But if we're talking about sensitive data, then the session only lasts for 15 minutes or something. So yeah, you have to type it again somewhere or something, or you type in a token or something. So I would like to help you out with that. So thank you all. I hope you have a great camp.