Instructor: Web application vulnerabilities. 2 2
In this lesson, we're going to go through 3 3
and do a little bit of analysis 4 4
on the impact of web application vulnerabilities. 5 5
Now, as we do this, we're going to take a look 6 6
at a sample e-commerce website 7 7
that's going to involve a web front end and a database backend. 8 8
So we're first going to assess the database functionality 9 9
then we're going to look at the website functionality. 10 10
After that, we're going to test some injection vulnerabilities 11 11
and then test some authentication vulnerabilities. 12 12
And by doing this, we're going to be able to see 13 13
if this website has any vulnerabilities 14 14
that we need to address as a cybersecurity analyst. 15 15
All right, let's jump into the lab environment. 16 16
First, I need to test my database and my web server. 17 17
So to do this, I need to make sure they're running. 18 18
So I'm going to type in service, MySQL, start and hit enter. 19 19
Then I'm going to type in service apache2 start and hit enter. 20 20
This is going to start both the database server 21 21
and the web server on my staging environment. 22 22
Now from here, I'm going to open up the database 23 23
administration using Firefox. 24 24
To do this, I'll type in Firefox 25 25
http://localhost/phpmyadmin and then Enter. 26 26
At this point, Firefox will load up 27 27
and I'll be brought to the login screen for php my admin. 28 28
This is a web front end to interact 29 29
with the backend database. 30 30
From here, we'll be able to look at the tables 31 31
inside the database and even run SQL queries. 32 32
So all I'm going to do here is log in. 33 33
Now that I'm in the backend 34 34
I can click on dev tech_store 35 35
which is the database that I want to look at. 36 36
In here, you can see there is new, categories, products 37 37
and users, and under categories, products and users. 38 38
Those are my different tables. 39 39
If I click on categories, I can see here the different rows 40 40
that I'm going to have inside that table. 41 41
Essentially, inside this table is a list 42 42
of different product categories. 43 43
Inside the ID column 44 44
that's going to be our primary key 45 45
and then the name column is going to list the name 46 46
of each of the different product categories. 47 47
There are a total of nine different categories here. 48 48
Notice you can see the SQL statement at the top. 49 49
It says select * from categories. 50 50
That is what we're doing here. 51 51
We're selecting everything from the categories table. 52 52
Next, let's select the products table and review that data. 53 53
Again, this is another table 54 54
and it lists all the different products. 55 55
Instead of looking at the categories 56 56
we're looking at the individual products here, though. 57 57
Each product has its own product code, description, price 58 58
and whether or not it's going to be in stock 59 59
and what category it belongs to. 60 60
If we go and look at the user's table 61 61
we can look at that data. 62 62
Inside of here, we have a list of all the users 63 63
who can sign into our website. 64 64
Each user has a username, a password, 65 65
a first name, a last name, and a level of permission. 66 66
Now, notice one major vulnerability here. 67 67
We are storing our usernames 68 68
and passwords in plain text. 69 69
So if you look in the password column 70 70
you can see each person's password. 71 71
This is a very dangerous practice. 72 72
Instead, those passwords should have been hashed 73 73
and then the hash should have been stored 74 74
inside the database. 75 75
Now look at the URL that's used to access this data. 76 76
Notice it calls sql.php 77 77
and that's a script that we're going to use, it's a PHP script. 78 78
Now, when it does this it actually gives you parameters 79 79
from the database. 80 80
This is going to be something like the database, the table 81 81
and the position within the table. 82 82
So if we look under the SQL statement again here 83 83
we can click the edit link, 84 84
and from here we can change this SQL statement 85 85
to say whatever we want. 86 86
For example, if I wanted to see who has admin permissions 87 87
I can type in select * from users 88 88
where permissions equals admin. 89 89
And this will actually return just one record for us. 90 90
This website is going to go into that database 91 91
using scripting languages like PHP 92 92
to pass those SQL statements in a secure way 93 93
so the user can't inject additional parameters. 94 94
Now, as we see this php my admin, this is an admin tool. 95 95
This is not where our users are going to be inputting data. 96 96
Instead, they're going to do it from the website. 97 97
So let's go ahead and take a look at the website itself. 98 98
First, we're going to open the browser 99 99
and go to http://devtech, 100 100
which is a sample e-commerce website 101 101
here inside my lab environment. 102 102
Now, this is the website for the store 103 103
and it's running on my local Apache web server 104 104
that I started up at the beginning of this video. 105 105
If you select the catalog tab, you're going to be able to see 106 106
all the products inside the monitors category. 107 107
They're all listed here from a table. 108 108
Note that the URL here that's used to serve this webpage. 109 109
It doesn't have that SQL query anymore. 110 110
Instead, it says catalog.php:category=1 111 111
which is selecting the first category, which was monitors. 112 112
Now, there are better ways of doing this 113 113
and this isn't necessarily the most secure way 114 114
or the least secure way, it's just one way of doing things. 115 115
Now, here we're actually passing in a parameter directly 116 116
by saying category equals one. 117 117
That means if this was something that was 118 118
behind a secure paywall, for instance, 119 119
we wouldn't want to do this because somebody could easily 120 120
change that one to a two 121 121
and that would select a different category directly. 122 122
Next, I want to go ahead 123 123
and try testing injection vulnerabilities. 124 124
To do this, I'm going to put the website 125 125
on the right side of my screen 126 126
and the php my admin on the left side of my screen. 127 127
Now from here, what we're going to do is we're going to verify 128 128
the URL that's passing the parameters, 129 129
in this case, category equals N, 130 130
in this case, it was category equals one, 131 131
to make sure that we're viewing the right category. 132 132
So what I'm going to do is I'm actually going to go 133 133
to the insertion point at the end of the URL 134 134
and I'm going to add a space, and then I'm going to type 135 135
or one equals one, which as you remember from our lessons 136 136
one equals one is a very common way 137 137
of doing an SQL injection. 138 138
Now, once we do this, we're going to see what happens. 139 139
Notice here that the listing page 140 140
still says we're in the monitors category 141 141
but we're not seeing just monitors. 142 142
We're seeing every single product that this company has. 143 143
That's because we just injected this or one equals one 144 144
making every statement true 145 145
and not just to display category one. 146 146
This is a basic SQL injection. 147 147
Now notice in the SQL query section 148 148
we can verify the query that we executed based 149 149
on the URL we inserted from the webpage. 150 150
Notice the query is selecting four columns 151 151
from the products table. 152 152
Anytime it finds the product category is N, 153 153
in our case one, or where one equals one. 154 154
And because one equals one every single time, guess what? 155 155
It's going to dump every single category 156 156
all at once to the screen. 157 157
Now that we've tested injection vulnerabilities 158 158
let's go ahead and test an authentication vulnerability. 159 159
We're going to go into the sign-in tab 160 160
and we're going to attempt to sign in as Kevin. 161 161
Now, when we try to sign in, if we don't know his password 162 162
we're going to get an error and it's not going to let us sign in. 163 163
Now, we don't have the ability to crack his password 164 164
at this point, so instead, let's try an SQL injection. 165 165
Now here we're going to put Kevin as the username 166 166
and try to put something in the password field 167 167
to cause a malicious SQL statement to be formed. 168 168
This is an SQL injection. 169 169
So if I do something like X and then a quote space 170 170
or space quote X quote equals quote x, 171 171
that will be able to do an SQL injection for us 172 172
because the quote is going to break apart from that password 173 173
and then test the second half of the statement, 174 174
or something equals something. 175 175
And so let's see how this looks. 176 176
Now to see what I actually typed in, we're going to go 177 177
and right click on the field and do inspect element. 178 178
This will allow us to see what was there 179 179
inside of the field. 180 180
In HTML when it's a password field, 181 181
it's going to show up with stars or dots instead of the text. 182 182
So I'm going to change that password field to text 183 183
and that will allow us to see what I actually put in. 184 184
So now we'll go ahead and click on the sign-in button 185 185
and you'll see that it sends that to the MySQL database. 186 186
And we get back an error 187 187
inside the database giving us a warning saying 188 188
that there was a perimeter of one to be expected 189 189
but instead we got the results 190 190
of /var/www/devtech_store 191 191
/html/sign in.php on line 37. 192 192
Essentially, we caused an error in the program 193 193
by doing this injection 194 194
but we were still able to successfully sign in. 195 195
Now notice we are logged in 196 196
but we're not logged in as Kevin. 197 197
It says Welcome comma space period. 198 198
It doesn't say Welcome, Kevin. Why is that? 199 199
Well, because our malicious query took advantage 200 200
of the default apostrophe formatting, 201 201
and because there was no sanitized input 202 202
because they didn't do input validation, 203 203
I was able to do an SQL injection. 204 204
By doing that, it's going to go and look 205 205
for the first authentication in the table. 206 206
In our case, that first person 207 207
is actually going to be Laura Anderson 208 208
and that's the person who has administrative privileges. 209 209
So we are now logged in as Laura Anderson, 210 210
the database administrator. 211 211
So you can see how powerful SQL injections can be 212 212
and how easy they are to conduct 213 213
when somebody doesn't do the right protections 214 214
on their website 215 215
either on the front end using input validation 216 216
through the website, or on the backend 217 217
when they don't have things configured quite right. 218 218
Now in CySA+, it's not your job to figure out 219 219
how to fix all these things 220 220
but it is your job to figure out 221 221
if they're vulnerable to these types of attacks. 222 222
And so you need to understand what an SQL injection is, 223 223
and usually when you see something like one equals one 224 224
or X equals x, that's a dead giveaway. 225 225
Now on the exam, if you're asked how to fix something 226 226
like this, the best answer is going to be input validation. 227 227
If they had done input validation on the website 228 228
and took away my ability to insert that apostrophe 229 229
it would've prevented this SQL injection 230 230
from occurring in the first place.