Instructor: Session Hijacking. 2 2
In this lesson, we are going to talk 3 3
all about session hijacking, but before we do, 4 4
we need to talk about session management 5 5
because session management is 6 6
a fundamental security component 7 7
in our web applications these days. 8 8
When we talk about session management, 9 9
this enables web applications to uniquely identify a user 10 10
across a number of different actions and requests 11 11
while keeping the state of the data generator 12 12
by that user and ensuring it's assigned to that user. 13 13
Now, when we do session management, for instance, 14 14
you log into my website and there's a lot 15 15
of other students who are logged into my website right now. 16 16
When you're logged in, 17 17
I need to know what lesson you're watching. 18 18
I need to know what quiz you've passed, and all 19 19
of that is session information while you're connected to me. 20 20
And then when you're done with that session, 21 21
I need to save that in my database 22 22
so that way when you log in next time, 23 23
we didn't lose your results. 24 24
Now, a lot of the way that people do this though is not just 25 25
in the database, but they also use cookies. 26 26
Hmm, delicious cookies. 27 27
No cookies aren't that delicious. 28 28
We're talking about cookies in the cyber sense. 29 29
And the reason we have to use cookies is 30 30
because web or HGTP is a stateless protocol. 31 31
This means that the server doesn't preserve any information 32 32
about the client by default. 33 33
So, if you want to store that information, 34 34
you have to either store it in a cookie or in your database. 35 35
Now, cookies allow web applications to retain 36 36
this information about the users of the website. 37 37
And normally these cookies are going to be stored 38 38
on your client. 39 39
Now, a cookie is essentially just a text file. 40 40
It's a text file that's used to store information 41 41
about a user when they visit the website. 42 42
Now that cookie is created when the server first sends 43 43
the HTTP response header with that cookie. 44 44
Then any subsequent request headers that are sent 45 45
by the client will also include the cookie. 46 46
So we can send that information back and forth. 47 47
Because of that, we want to make sure 48 48
that that cookie is protected 49 49
because it is being transmitted across the internet. 50 50
Now, when we talk about session cookies like these, 51 51
these are going to be non-persistent. 52 52
They reside in memory. 53 53
And when you're done 54 54
and you close out that browser instance, guess what? 55 55
That cookie would be deleted as well. 56 56
But not all cookies are just session cookies. 57 57
Some cookies are going to be more persistent 58 58
and these are known as persistent cookies 59 59
because they stay around for a while. 60 60
These cookies are stored 61 61
in the browser cache until they're deleted by the user 62 62
when you do the clearing your cookies 63 63
or when they pass a defined expiration date, for instance, 64 64
you might connect to my website and my cookie might say 65 65
this cookie is good for seven days. 66 66
And so if you came back in eight days, 67 67
that cookie would be gone and you'd be 68 68
like a new user doss if we were configured that way. 69 69
That's the way cookies work. 70 70
Now, when we talk about cookies, again, 71 71
they have to be protected. 72 72
And so when you're sending these cookies 73 73
or you're storing any kind of confidential information 74 74
in them, you should make sure they are encrypted. 75 75
By encrypting those cookies, 76 76
you can keep that information confidential because remember, 77 77
confidentiality and encryption go hand in hand. 78 78
Now the next thing we need to talk 79 79
about is session hijacking. 80 80
As I said, a lot of these cookies are session cookies. 81 81
And so, session hijacking relates to this really well. 82 82
When we talk about session hijacking, it's a type 83 83
of spoofing attack where the attacker disconnects a host 84 84
and then replaces it with his 85 85
or her own machine spoofing the original host IP address 86 86
or using some other mechanism. 87 87
For instance, a lot of session hijacking attacks occur 88 88
through the theft or the modification of cookies. 89 89
So if I can steal your cookie, 90 90
I can take over your session and pretend I'm you. 91 91
Now, another way 92 92
that this can be done is by doing session prediction. 93 93
If you remember from your security 94 94
plus or network plus days, every time you make a connection, 95 95
there is a session number that's associated 96 96
with that by the HGTP protocol. 97 97
And if I can guess what that number is, 98 98
I can jump in and take over. 99 99
Session prediction attacks are simply a type 100 100
of spoofing attack where the attacker attempts to predict 101 101
the session token to hijack that session. 102 102
Now, this session token has to be generated using 103 103
a non-predictable algorithm, and it must not reveal 104 104
any information about the session client. 105 105
Essentially, it's a one-time use ticket for the duration 106 106
of that session, and so it might be some long random number, 107 107
but how it's generated has to be non-predictable. 108 108
If it is predictable, somebody can guess it 109 109
and they can take over your session. 110 110
Now, the next thing we need to talk about here 111 111
is cross-site request forgery, which is XSRF or CSRF. 112 112
It's written both ways. 113 113
As an abbreviation, I tend to prefer CSRF 114 114
and you'll see me use that throughout the course. 115 115
Now, cross-site request forgery is 116 116
a malicious script that's being hosted 117 117
on the attacker site that can then exploit a session started 118 118
on another site within the same browser. 119 119
Now, as an attacker 120 120
if I want to conduct a cross-site request forgery, 121 121
I need to convince the victim to start a session 122 122
with the target website. 123 123
Now, the attacker can then pass the HCTP request 124 124
to the victim's browser and spoof this 125 125
as an action on the target site, such as changing a password 126 126
or an email address or something else like that. 127 127
Now, this request could be disguised 128 128
in a lot of different ways. 129 129
They can use things like image tags and other HTML coding 130 130
and this could also be accomplished 131 131
without the victim necessarily even having to click a link 132 132
if they do it successfully. 133 133
Now, if the target site is going to 134 134
assume the browser is authenticated, 135 135
this is because they have a valid session token 136 136
from that browser already from that victim, 137 137
it doesn't have to have any additional authorization 138 138
for the attacker to do what it wants to do. 139 139
So think of it this way. 140 140
You have two tabs in your browser. 141 141
One is the attacker's website and one is your bank. 142 142
You've already authenticated to your bank, 143 143
but now you connect it 144 144
to the attacker's website and another tab 145 145
they can use cross-site request forgery to try to manipulate 146 146
and be able to go and do things on your bank account as you 147 147
because you're already in that state. 148 148
And that's really what this cross-site request 149 149
forgery is going to do for them. 150 150
Now, how can you prevent cross-site request forgery 151 151
as a defender? 152 152
Let's say you are working for the bank 153 153
and you want to make sure that nobody's going to perform this 154 154
against your customers. 155 155
What do you do? 156 156
Well, you can use user specific tokens 157 157
in all the form submissions 158 158
to prevent cross-site request forgery 159 159
and this is something your web developers would be able 160 160
to do as part of their secure coding practice. 161 161
So the last thing I want to talk 162 162
about here is cookie poisoning. 163 163
I know we've talked a lot about cookies 164 164
and it's making me hungry, 165 165
but let's talk about cookie poisoning 166 166
and then we'll finish up this lesson. 167 167
When we talk about cookie poisoning, 168 168
this modifies the contents of a cookie 169 169
after it's been generated and sent by the web service 170 170
to the client's browser 171 171
so that newly modified cookie can then be used 172 172
to exploit vulnerabilities in a web application. 173 173
If you want to be able to counter cookie poisoning 174 174
on your systems, you want to make sure you validate the input 175 175
of your web app to account for any tampered with cookies. 176 176
By doing encryption of your cookies 177 177
during transmission and storage, you can help prevent this. 178 178
And if you delete cookies from the browser cash 179 179
when the client terminates their session, 180 180
it doesn't leave those cookies sitting there 181 181
being able to be poisoned by somebody else. 182 182
So this is all about good cookie management. 183 183
Now, I know a lot of people are against cookies and websites 184 184
and a lot of people turn off cookies, 185 185
but a lot of sites need these cookies to operate. 186 186
And so you have to be able to think about this. 187 187
If you're the guy or gal who's programming these websites, 188 188
do you have to use cookies to do this? 189 189
Can you do this as saving things in your own database? 190 190
Can you do this another way? 191 191
And if you can't and you have to use cookies, 192 192
make sure you're doing it securely 193 193
by making sure they're very time limited, 194 194
they're deleted when you're done 195 195
and they're encrypted anytime you're storing data in them.