Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
alright so my name is Bert Beckwith I worked for sprint store some on the Grails team I've done a lot of work with plugins and grails and specifically one of the more popular sets of plugins that I've worked on our the spring security plugins this
isn't a spring security talk this is something that I sort of realized that I had been very much focused on URL security and blocking access to certain parts of your application but less focused on the more general case of security like cross-site scripting
and sequel injection and things like that so I wanted to to learn for myself and also to share with the community information about how to really have a very holistic approach to securing your girls application not just URLs but the whole application so Wow
alright so a lot of what I will be talking about is based on information that the I don't know how to pronounce this I say in my head I say o us it's an organization that publishes a list every three years of the top ten most severe security risks
for web applications and the list changes every year primarily because the severity of each topic tends to be pretty much the same but an item can drop further down in the list once it becomes less prevalent so for example your URL based security is I think
number six and currently because although if you allow access to a section of your site that you shouldn't allow access to that's a potentially severe problem it's an easy one to to implement it's easy to do that so it's it's lower
lower on the list so it's a very big organization they have a lot of sub-projects they publish a library called auntie Sammy they also have their es api and they have testing tools like web scarab and they also do these code review cheat sheets it's
a wiki and I saw very recently that they have a there's not much information there yet but someone has started a grails security sort of checklist that you can go through so hopefully at some point that will be more fleshed out and that will have a lot
of useful information that's very Grail specific so the first the most severe currently this year's most severe risk is injection risks so the big one there is sequel injection that's that's the big risk so if you concatenate sequel parts together
into a string without escaping the data that's applied to you from the users you open yourself up to a 2 a sequel injection risk luckily you tend not to do that much in grails because you would use a dynamic finder you would use criteria queries you would
probably even use HQ l although if you dynamically build the HQ l string you can give yourself a sequel injection risk there this is sort of the classic XKCD comic about what not to do so you can do things like this right so if a user tries to log in and they
type in their username that's fine they're they're a good user but a hacker user can type in a little hard to see because of the quotes but I mean you can basically see what's going on here that by using an or either side can be true one equals
one is always true in sequel so this will return every user from the user from the database so if you have naive code a couple things will happen one this will be very slow so this is also sort of a a performance attack but also you'll get a lot of records
and if your code is very silly and it just takes the first result because it assumes you would only either have 0 or 1 results then you can log in without a password for the first user that comes up and if you are a little smarter about how you create this
this sequel you could probably login as the first admin that comes up so that's a query but you can also do you can also do if you're doing updates you can also get it to do really disastrous things on your updates and if if you would allow something
like this then they could actually damage your database drop your database drop a table truncate all the roads in it and then hopefully you've got a good backup strategy and you can go back to 12 hours ago worth of data so the obvious fix is in real sequel
regular sequel is to use prepared statement right so instead of concatenated in the actual values you use a question mark placeholder and then you let the you call set string set int set object whatever there's a bunch of methods you can call it on the
prepared statement class to let the driver escaped that appropriately so you don't deal with quotes and single quotes double quotes any of that stuff you just and this is not this may fail with an exception but it won't it cannot open you up to a sequel
injection risk so each qol has that same problem though because you can do the same thing its HQ L is not sequel but it looks about the same but you can concatenate strings together but you shouldn't you should use ? placeholders for your HQ l so in general
grails queries tend to be i think in order of preference dynamic finders and then probably criteria queries the where queries the new ones in 20 are really nice i think i think they're a lot more intuitive to me anyway than criteria queries and all of
those are backed under the hood by criteria queries so dynamic finders and where queries get turned into criteria queries and criteria queries in hibernate always use the prepared statement so you don't have to worry about signal injection for any of those
query types the only time you have to worry about it in grails is when you're doing dynamic HQ l or of course sequel so the big takeaway here and this is really for every every one of these topics is you can't trust your users unless you have the luxury
of having an Internet application where you've got maybe you know you know every person who uses your application that's very rare and even then if it's someone like me I'm a mess with your app just for fun right so if you have anyone who's
is it all evil or just creative you just can't trust your users so let me mention just quickly also the sequel injection is the big injection risk but there's also command injection so you know in groovy one of the really fun demos to do when you're
teaching groovy or when you show in groovy off to someone is how you can take a string and you can call the execute method on it so you can get a directory listing you can say el sol execute right and that'll just run that with a so if you allow a user
to provide any information that's included inside of an executable string like that you open up a real risk to a to commanded to command injection and they could delete directories they could do all sorts of damage so anytime you accept user input and
you use it to execute anything a query or a command you have to escape it somehow or clean it all right so cross-site scripting that that is number two so this is the same sort of a thing where you are allowing user input and you if you don't appropriately
escape it or clean it or process it somehow that things can happen so and this is conveys is that they used to describe cross-site scripting is that it's it's a it's like a it's like a injection attack so it's they call a script injection
so one sort of common use case is you have a query a search right like a google search and what you're going to tend to do is you'll have a search box then they can type whatever they want and then you'll show them you searched for this string
and here's your results so if you don't escape that and they do something this is a very very very simple example but it this will actually pop up that JavaScript pop up in your search results so this is silly this doesn't hurt anything this doesn't
break anything but you can use this technique in things like comments or if you allow editable wikis or things like that so if you have a discussion discussion threads and you don't escape what the users are using for their comments then they can inject
JavaScript into the page and you guys know how powerful javascript is I mean we've seen an event stuff and we've seen some really powerful JavaScript just this week so you can do Ajax calls you can inspect cookies you can if you allow that you can
[ ... ]
Nota: se han omitido las otras 4.079 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.