Alena, what are you talking about? O_o

if PHPSESSID is by default stored in cookies, and cookies are insecure, would that not mean that by default, sessions are insecure?

Samuel, no, that mean, that cookies are insecure, but not sessions. And by the way, Alena said, that's possible to get access to session via JavaScript, what is absolutely wrong

I assumed Alena Holligan meant they could access PHPSESSID (if they could compromise your javascript or some you rely upon) and then use this to access the session (indirectly). The owasp link seemed to indicate the attack was possible, but didn't seem to specify a preferred strategy to deal with it.

I did link to a couple full articles that go into explanations in more details since it's not an easy discussion to have in the notes.

Check out:

• Cookies vs Session
• Cross Site Scripting (XSS) - which links to a couple more detailed examples of exploits

Alena, did you read the links you have provided to me?

first the attacker uses a sniffer to capture a valid token session called “Session ID”, then he uses the valid token session to gain unauthorized access to the Web Server.

You could get a session, only if you will hijack Session ID, which is sent with every HTTP request, but you couldn't fetch session directly via JavaScript

The attacker can compromise the session token by using malicious code or programs running at the client-side. The example in figure 3 uses an XSS attack to show the cookie value of the current session; using the same technique it's possible to create a specific JavaScript code that will send the cookie to the attacker. <SCRIPT>alert(document.cookie);</SCRIPT>

The attacker can only compromise the session token (not session), which is stored in cookies. So cookies are insecure, because cookies stored on client-side, so only cookies are accessible via JavaScript, not sessions

If you store JWT in cookie, you do manualy the same, that web server do automaticaly. Webserver store Session ID in cookies, which can be easily grabbed, you store JWT in cookies, which can be easily grabbed. So where is security? Instead of 32 characters Session ID with each HTTP request you send JWT, which is usualy much longer. What about performance?

By the way, JWT ideally should be sent in Authorization: Bearer <token> header

Simon, yes, indirecly you can get session, if you will know Session Id, which by default stored in cookies. But in this course Alena explain, how to use JWT instead of session. Unfortuanly, she does the same vulnerability, but instead of storing in cookies and sending with each HTTP request 32 characters Session ID, she created JWT (base64 encoded JSON), which is much longer, then Session ID

I'm a noob, so correct me if I'm wrong, but I believe she said sessions are prone to XSS and cookies are prone to CSRF. Or at least that's what was on the quiz.