Security – Web Development

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 forumsudacity

com, which also has this vulnerability in it You could build a webpage on your own domain Let's say you're at badguycom, 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 badguycom 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 badguycom 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

Free Email Updates
We respect your privacy.

wordpress themes for blogs

affiliate marketing