The next question we had was about security--cross-site scripting attacks, DDoSs,
SQL injection, how to deal with those, what those are--
really kind of a big question. >>Sure.
Actually, I wanted to almost spend--I could probably spend an entire lecture on this.
We can talk for a few minutes about some of the high-level stuff right now. >>Great.
Security--this is a really big concept.
When I was originally doing the notes for this class, I really wanted to spent a lot of time
talking about a couple of major vulnerabilities, but I was getting the sense
that it wouldn't fit in very well with the level of knowledge you guys had at the time.
But I can't talk about a few of the high-level things now that you should get smart about.
The first is XXS or cross-site scripting.
This basically when you accept data from a user, and you're displaying it in your webpage,
and you're not escaping it.
We did talk about escaping, and we quizzed you on escaping.
But say you had take some data from a user, and then you return it to the user in a text area.
In here goes whatever the user typed in. Maybe you're editing a blog entry, and this is the old blog entry.
Well, if the code they actually typed in has some HTML in it--
in particular if it uses the script tag, which we haven't talked about at all in this class.
This is how you would include some JavaScript.
They can actually put code in here that might fetch all of your cookies, using document.cookie--
remember we saw that in Unit 4, I think--
and make a request to another URL, sending your cookie there.
If I view this page--if me, Steve, loaded this page that has this other content,
it could cause a browser to load my cookies and send it to some other site.
That guy could then look at that request, put his cookies in his browser,
and then start browsing the site as me.
This is the basis for cross-site scripting.
If you escape your HTML, you don't have to worry about it.
There are cases, however, where you don't want to escape the HTML.
For example, in a blog.
If you trust your users and you want them to be able to enter HTML--
for example, if they want to put in links and that sort of thing,
then you've got to think carefully. Do I trust the user?
Or do I want to write some fancy escaping that escapes some HTML,
like it allows links for example.
That's a big tradeoff.
On Reddit, we use a piece of technology called markdown,
which is a simplified language good for allowing users to leave comments and that sort of thing.
It's got syntax for leaving links and images, but not just random HTML.
Actually what we did is we allowed links and image, and then we broke all other HTML.
Basically, the name of the game for preventing cross-site scripting is escaping HTML.
There's another classes of attacks we haven't talked about,
and they haven't come upin this class, which is SQL Injection.
What's happening here--this is very similar to cross-site scripting.
There's another--well, let's talk about SQL injection first.
If you have a piece of SQL--select * from link--where id = %s.
This is why you shouldn't use %s in SQL statements.
In App Engine they've been using that colon syntax, which is really nice,
because they do the escaping for you.
If you were to generate some SQL in Python using the string substitution syntax,
where you just put in this id variable, and maybe this id comes from the URL or from the user.
If this is a number, this works fine.
But what if this were the string quote, semicolon, this makes a comment.
I'm forgetting some of my SQL here, but effectively you put in a drop table.
It's just like cross-site scripting where if you allow them to put in arbitrary HTML,
they can close your old tag--through some syntax it's often a closing quote and a semicolon
or dash-dash basically means comment.
Some combination of things here allows you to just put in arbitrary SQL into the database.
Generally, you want to make sure you're always using a wrapper around your SQL.
App Engine provides that using their GQL query object that we've been using in this class.
Another really popular library I use all the time in Python is called SQLAlchemy.
It is spelled like this maybe.
SQLAlchemy is one of my favorite libraries.
In its simplest use case, the way I've always used it, it's basically got a procedural language for generating SQL,
much like the way App Engine has that language where you can say .all and .filter and that sort of stuff.
SQLAlchemy provides a very similar interface.
It goes one step further and has what's called a ORM, which is an object relational mapping,
Which basically converts a Python object into SQL so you don't have to think about SQL,
but I hate using these things because it disconnects you from the queries you're running,
the queries are what cause your web application often to be slow,
and if you don't have direct control of your queries,
you're not going to be able to scale quite as consistently.
But SQLAlchemy is a really nice library.
Just like this SQL injection, you can just as easily have memcached injection.
If you're taking input from the user and you're converting that into like a cache key,
depending on what memcacher library you're using,
if it's not validating the key, they could put something in a URL or something for example
that would finish the memcache statement and create a new one and pollute your cache with stuff.
We had a really clever guy try to do that to us at Reddit once.
Fortunately, he was a friend, and he told us.
There is one other huge class of attacks, and this is actually a relatively modern thing.
It's called CSRF. This one's really fun.
The general idea is remember how we talked about forms.
Forms have an action attribute that is where you want to submit the form.
We've always been doing things like slash or not specifying it, which submits the current URL.
But you could put a full URL in here, and this could just have a completely different site--
ASCII Chan, which Incidentally has this vulnerability in it.
Or it could be forums.udacity.com, which also has this vulnerability in it.
You could build a webpage on your own domain.
Let's say you're at badguy.com,
and you made a hidden form, use CSS to hide it, and then you have some JavaScript
that automatically submits this form, what's going to happen is a user will load your page,
their browser will render this form, and then you'll submit it for them, sneakily.
This will submit to some other URL.
ASCII Chan won't be able to detect that the request is coming from badguy.com.
They'll see that as coming from this user's browser with their IP and with their cookies.
CSRF what's happening here is you are doing something on behalf of a user.
They've got their cookies that basically identify them. You're logged in as spez.
So somebody can trick my browser into making a request to another site as me.
They can do things like submit a form as me or vote up on a story as me
or enter a bunch of bogus content in the forums as me, which is really frustrating.
If you're enterprising enough and can trick me into clicking on a link that you control,
You can make me submit something to ASCII Chan, or you could make me
submit something to the Udacity forums.
If you do that, we'll reward you or something.
Now, the way you prevent against this is one your own site
you have to include basically hashes or some sort of secret in your own forms.
If I've got a URL, let's say it's a new page. This is my blog submitting URL.
The handler for this URL needs to look for a hidden input
that only exists on the form itself.
It's going to be hard to explain this in this format, so what I would advise you to do
is just Google for CSRF, but you already understand the concepts required to implement
the solution to this, which is basically hashing and secrets.
You need to include some secret that is only included on new page,
so that when some guy at badguy.com submits a form directly to this URL,
they don't have the secret, and the secret would have to come along with the rest of the data.
CSRF--it's a really fun attack.
You can find it on just about every website online--not Reddit anymore,
but there was a time--the way I learned about this is somebody made a link on Reddit
that when you clicked it would automatically vote up on that link for who as looking at the page.
All of a sudden this link just skyrocketed to the front of our page,
and it was like freelimosines.info or something like that.
We were like, hmmm. Something's fishy. That's when I learned about this attack.
Hopefully, you can learn about it in not quite so public of a fashion.
Anyway, those are the major security issues.
There's a whole lot to do there.
Maybe we can do like an extra one-off lecture at some point where we break the Udacity forums,
but this is enough to get you started right now.