In this section, we saw how to hack Web applications and even the Web servers underlying them to mess
with the database, make it impossible to load a webpage, redirect to site to another location, all
by using just two of the most common types of attacks across site scripting attacks and a sequel injection
attack.
Well, we did the sequel injection.
The first one here, the second one down here is just behind.
It means it doesn't show anything to the screen, right?
Well, come back up here to the set up and create or reset the database that would clear out any of
the bad stuff that we might have done there.
But we were even able to compromise the passwords in this database, the hashed username and password
values, so that we were able to go out to the web, find out what the password was, and log in is
a different user.
Well, as I promised, I'm going to show you a couple of ways that you can protect against this.
If you're programming a Web server, you need to understand cross site scripting and SQL injection a
lot.
So Devoir is a great way to test different things.
And then you go to your own Web page that you're designing and you test to see if you can do the same
kinds of things.
If you're reflecting what someone's typed in a text field to the screen, you need to check for Croci
scripting.
If you're storing in a database, you need to check for stored cross site scripting.
If you're interacting with the database from user entered text at all, you need to check for all kinds
of sequel injection and you can see under Mutilate or under the OS project O.W. Aspey, the Open Web
Application Security Project.
You can find some common tests that you can do to check the security of your web application.
But let's take a look at cross scripting and sequel injection specifically.
If you just go to W three schools and come down to their come to their tutorial, come down to form
validation, you'll see some information about the HTML special chars function and it will actually
show a real script, a real cross scripting attack script alert hacked here.
And it tells you that the HTML special chars function can render that.
And two special characters that will not get run on the server, so if I run this, the less than greater
than script alert hacked, that will not do anything on a Web server.
It'll just get stored as plain text.
So let's take a look at the e-mail special charge.
Now, this is just for me, but is one of the most popular platforms for Web application development
out there.
They use it at Facebook, powers, their servers.
So it's a good language for us to understand.
And there are equivalents in most other languages as well.
So whether you're developing Web pages, using ASPE, IP, Ruby, you name the the language, you need
to understand how to make string's that the user enters much safer before you store them a database
or even print them back to the screen.
So if we go to a net and do a search for HTML special chars, it'll give us the manual page of Dot Net
for each HTML special chars.
And what it does is it converts any of these common symbols.
We saw the single quote, that's how we broke into the school database and we saw the greater than less
than tags those get.
Let us do a script for cross site scripting.
This HTML special chars or HTML entities will help convert those strange symbols quotes ampersands less
than symbols, double quotes into a safe character that can be stored, that can still be shown on a
web page.
So if you want to enter some code and show someone how to do something, you use e-mail, special chars
or HTML entities and it'll encode it in such a way that it can be shown on a Web page safely.
Like Stack Overflow is really popular for this, but it will not allow an attacker to try those cross
site scripting tags with the angle brackets around script.
It will not allow somebody to run an attack on your SQL database because it'll change that single quote
into a safe character.
So make sure you understand how to protect your inputs on your Web server.
If you are not a web developer yet, that's OK.
You at least know how to test for those two really common vulnerabilities cross site scripting and SQL
injection so that you can work with your Web team or the person who develops or maintains your website
and make sure that they understand how to employ HTML special characters.
There's also strip tags.
If you know there's not supposed to be any HTML inside a document, then you can use the strip tags
option and they'll just remove all those tags.
You don't even have to worry about encoding them so they can be shown on the screen for usernames,
for comments on a web page.
Stripped tags may even be better, but you also still need to use the HTML entities or HTML special
chars so that you can't practice the cross site scripting or SQL injection from that form.
There are other things that you need to know if you're a web developer, things like using prepared
statements to avoid some of these SQL injection attempts, for example.
And there's a whole world of security under any type of development that you try to go into.
But because Web application security is so important, I wanted to make sure to cover it in a section
here and show you a few ways to protect against it when you start building your own Web applications
or if you've already built some Web apps, go back and test them for these cross site scripting and
sequel injection vulnerabilities as well as others, and make some changes.
If you find that your site is vulnerable, I hope you've enjoyed.
This is a good tutorial on Web application security.
Think we've got one more special section coming up for you.
We'll see in the next section.