 certain their Rails application is 100% security. Yes, Rich, I believe anybody else may be not. This is us, we've got a great introduction, so we'll just skip that. I started thinking about security seriously this past fall, but I ran into this article by Patrick Mackenzie, and he's writing the Diaspora code base, which is a Facebook replacement that respects your privacy. That code just went out on Alpha release, and he was interested in it, so he checked it out and thought he would look it over, and he was surprised to find several, he says numerous severe security errors, and in the summary he says the bottom line is currently there is nothing that you cannot do to someone's Diaspora account, absolutely nothing. In other words, the site is entirely hackable, you can take over, anybody's account quite easily. I don't know, but that scared me. Because I'm thinking, I said why don't I do Rails development? I know the basics of security, I've gone through all the security lessons and I know all that stuff, and it was scary to me, it bothered me a lot. Let me just give you a first instance here, this is some code that we were playing around back in Edgecase. We did the Ruby coins, and someone had the great idea of let's put the coins online so you can actually go through the coins on a web page, and you can go through here, and you can see these are tests, we are starting equal, you can fill these things out, and when you fill them out with the right thing, the test turns green. Well we're actually typing in Ruby code at that point, and evaluating it in the browser, yeah you're laughing already, you know what's coming, right? Within two minutes of the guy who did this, he published it in our campfire room, within two minutes of that, someone did this. The answers which you seek are, and that's the Etsy password file. What he did, he typed in system Etsy password into the text box there. Well he thought, ha ha, that's clever, I'll fix you guys. I'll just disable the system command. No. So we switched to using back ticks. Okay, okay smart guys, we'll just disable back ticks. At this point he decided, alright I need a real sandbox to put this stuff in, and actually we're working on putting this online for real right now, and it's in a real sandbox. Theoretically you're not going to be able to break into it once we actually release it, but we're still playing around with these ideas. But the question is, you know we were playing around with this and we knew it wasn't secure, it was an internal thing, and we were just having fun with it. But in real life, what are the security concerns in real life? Just two, maybe three days ago, I saw this post from Martin Fowler. Anybody see this one? This is on ThoughtWorks.com, and if these guys don't know what they're doing, what hope is there for the rest of us? Evidently they have some malware on their website, it's transient, they can't track it down, it shows up sometimes in their Google reports. Sometimes not, they're not quite sure where it is. It might even be a problem with our passion. We don't know for sure, they are tracking this down. They're not suspicious and they think they've tracked it down and they're working at it. And if you see anything suspicious, let them know. But this is a tough problem to solve, absolutely. We've used five minutes now of our 30 minute talk. We are not going to be able to cover anywhere near all the security concerns that you have to think about when you're doing a website in the next 30 minutes. Absolutely no way. And I want to say, first of all, I am not a security expert. I did not study these things. These are just things I got interested in when I saw that posting. So I thought it would be a good idea to share with you some of the basics. These are the basics that you should be doing. First of all, you have a reading assignment. After you hear this talk, every one of you should go and read the Rail Security Guide. This is really comprehensive and really good. They cover things specifically with Rails. Another thing is that you can Google for this. Guidesrubionrails.orgsecurity.html. That's easy to find. The other one is the OWASP Ruby on Rails Security right up. This is a PDF. This is a hunking 48 pages of stuff that you need to know if you're doing a public website. And I'll say public website. If you're doing an internal website, there's vulnerabilities in those as well, too. This was a good guide to point that out. So that's your reading assignment after you get done here. But now for the fun. This is your typical setup for a Rails application. You got your server, you got your browser, you got your database. Out of these components, which of them do you trust? Obviously not the browser. So that is totally out of your control completely. So anything coming in from the browser is suspect. You need to validate it, you need to check it for bad things, and you need to treat that data with the utmost respect. That includes not only data in forms, but also cookie values and URLs. Do not put critical data in URLs because they can be easily hacked. All of this stuff can be easily hacked. I've demoed that today for you. What else shouldn't you trust? Well, the database. You may think you have complete control of that database, but it is quite easy for a hacker to slip in data past your application. And just because it's in the database you control doesn't mean that it's good data and it's safe to display however you want to. Cross-site scripting attacks often come from storing stuff in the database that is later displayed to other users. So out of all these things, maybe you can trust the Rails server because that's where your code is running. If you can't trust your code, you've probably got bigger security issues than we want to talk about right here. But in particular, browser and database are the things you need to be concerned with. So we're going to start with the basic vulnerability. I call this the little Bobby Tables vulnerability. And we have in our application, we picked an application that Matt and Jerry, in that case, did. It's a very nice movie night reservation. You want to watch a movie? You send advice to some friends and tell them what movies you want to watch. We played around with this application, and we have, let me preface this, all the vulnerabilities we're going to display today was not in his original code. We had to either change the code base or disable things in Rails for us to actually do this. So that is the good news in all of this, that Rails is actually doing a very good job of implementing security, but you need to be aware of what it's doing for you. So let's start with this. This is a simple finder, and we're filtering some text over all the users. We want to find all the users with a name like whatever the filter text is. And we're just interpolating that text right there. Do you see the problem? Everyone should see the problem with this. If you're doing anything like this in your application, you are at security level zero. Your PHP program, I might give you a pass on that, but in Rails, Zing, do not ever do this in SQL statements. I'm going to turn this over to my hacker in residence, Matt, and he's going to actually show you what it looks like. Okay, so there's a real quick demo. This is a general reference. The example app here is this Movie9 application. You make a movie, not a schedule movie, nice to be friends. We had to kind of bring in sort of an interface here that lets expose some of the exploits that we're showing. And one here, so we created this listing of users which you can kind of see. And adding in this filter that we're referencing here. So we can filter by name. So if I say I want to filter by, say, Jerry, and I click filter, and there we go. Now we only see Jerry, which is, you know, eminently useful. But what if we change this up a bit and if we decide that we're going to change what we passed in as our filter here? Notice he's hacking the URL directly into the URL. So just a little bit of extra, but what it looks like could be possibly some SQL in here. Sarah wanted this one. Oh, look at that. And actually our list is a little longer. And now you can see that administrator on our site is the electric which we're talking about. So we actually got Sarah's finished backing this and that. Hey, did you see how simple that was? That was just maybe six, seven characters that he had to type in to do SQL injection. And you could have done that directly in the filter box too. Could have typed that straight in. Yeah. Which, yeah, that's interesting. We could actually do something a little more complex with this here. And let's just give our filter a little more, a little more, I guess, so I can try to name this. And... You have two question marks now. Thank you. Oh, look at that. And then we see the administrator's encrypted password. We have got encrypted password from the database. Ouch. And you take off the encrypted password. We're safe. You can crack that. And if the password is not a very good password, that is actually quite easy for hackers to crack. Sorry. Yeah. Yeah, he's got it down there. Actually, I don't know what man set up for his demo, but when I was doing this, all my passwords were passed with P-A-S-S-W-O-R-D. So that would have been really easy to hack anyways. Okay, so what has happened? We intended for a string like this to be interpolated by clever use of input from the command line, the commenting out of the remaining SQL and putting in a condition that's always true. We were able to dump the entire user database. We were able to use union commands within SQL to pull in fields that were not normally pulled in and get that data out as well. So if you can do SQL injection, essentially your database is open for any piece of information to be pulled out of it. Okay. This is the solution. Use the question marks and the built-in SQL-based interpolation here, where you pass it as a separate piece that is filled in. The database driver knows about question marks and it will fill that in without danger of SQL injection. It will quote the comments that will quote it, it quotes correctly, and you don't have to worry about that. So please, please, please do this. This is the most basic level of security. This is a big problem in Rails and this is one that I was aware of but not really worried about. And it turns out the way I write code, I would probably fall to this vulnerability. And now that I'm aware of it, I can code around it. I'm aware of that. But you do this a lot in Rails. User update attributes and you just pass all the parameters in the form that come in like that. We do this a lot. Matt, would you demonstrate? So we can click here and go into edit my profile and see how I can update a couple of fields here. I could change my name, which I probably won't, or I could change my email address, which actually does stay the same. But what I could do is bring in one of our favorite tools, a DOM inspector, and go into a little bit of direct DOM manipulation and possibly get around the intended security or the intended use of the app this morning. So go down and find one field. So we're going to find the email address field. And by editing this, say instead of email, if you recognize the standard Rails cram name, and we'll just say that it's true. So admin is the flag in the database that tells whether you're an administrator or not. Not a good update. He's gone from the regular user's list. Let's view the ad health variance. Mark and I hang out. Parameter hacking is trivial to do with debugging tools that are in Firefox and Safari and in Chrome. So what you need to do is if there are parameters in your class that need to be protected from general update, you need to do one of two things. Either this, you can use adder accessible and declare all the fields that a form is allowed to change. Or you use adder protective and declare all the fields that the form should not change. So two ways of going. Accessible or protected? Which should we do? Why? Why accessible? Byte lists are better. Byte lists are better if you forget something. You're still protected. Now a lot of people like to use protected because I've added a field and now my form won't change and I'm annoyed for a few minutes while I figure out why I throw up. I'm annoyed for a few minutes or you can suffer a major security problem. I would go for protecting myself against security problems and deal with the annoyance. The danger with doing adder accessible and that is what we do but the danger with it is if you forget to add it to any model it defaults to everything accessible. So if you're going to do adder accessible it's highly recommended to put something in config initializers that sets in just active record base and another issue is how do you decide which fields need to be accessible and which fields need to be protected and that's a choice you have to make. Essentially if the data is not owned by the person editing the field for example in user form I own my name, I own my password I can specify that to be anything I want it doesn't change, doesn't hurt the program for me to change it to anything that can be validated. The admin flag is not something that the user owns. So that's not something the user should be able to change really nearly in a regular form. So anything dealing with permissions anything dealing with roles anything dealing with security should be protected. Anything that is not determined by the person editing the form should probably be detected and that's kind of a rule of thumb Again, white list versus black list we're going to come across this time and time again I always prefer to white list the things that are permitted rather than black listing things that are not permitted because there are a lot of things that can't think of everything that should not happen because a hacker will think of something that you didn't think of white list only the things that are good. Cross-site scripting this is another common one and this deals with data in the database Let's go ahead and demo our cross-site Okay, I can do So I wanted to go ahead and create a new movie night here to fight all my friends plays, movies related to turtles that was a classic alright I could write in the notes scale I might do something like popcorn that might make sense make popcorn bold make popcorn bold that's true because everybody loves popcorn and it makes sense it's more strong I suppose I could do that it would be show this nice bold feel except for the styling that's actually turned out well I'll pick something else we really want to make sure people know that the popcorn will be provided we could get it all up in their face about it it's the spelling error because it would be okay it would be okay did we accidentally unhack our maybe did we remove the raw I don't think we did actually this is nice feature but you could pop up Java words from your notes right next movie night let's try that again so that's funny in all that jazz but we could do something more malicious I mean better with me acting is hard acting is hard I tell you usually just write jazz so there we go see what we've done we have dumped the entire cookie database for this site in this browser and we had to work really hard to do this actually notice that we have movie night session long session ID that is the critical piece by default now normally you can't do this in a Rails program we had to actually go into Rails and tell it hey it's okay to let javascript get your session ID Rails by default will prevent that so again this is a place where we had to work around Rails default handling to get that but if you can get the session ID you have control of the user you can copy that session ID to a different browser and take over that account yeah still that we were really just writing that cookie out to the user screen and that might confuse or perplex them but it's probably not going to get them hacked but we could take it one step further and instead of just writing out the cookie value right into the DOM in the image tag and in that image tag we point to the hacker's web server that we control writing in the cookie value this is part of that string so we loaded up we get a bad image showing up right there okay yeah so the image didn't show up but the request for that image went out to the hacker's web server and let's look at the web server's log right now oh look the log of the hacker's web server now has our session token inside of it that is how easy it is to grab session IDs and cookies if you have cross-site scripting enabled okay so the key is there are a couple things that enabled this I mentioned one thing earlier that we had to go and tell Rails it was okay for session cookies to be grabbed by JavaScript by default Rails says JavaScript cannot get to session cookies and that's a good thing do not disable that like we did that's one layer of protection the other layer of protection what really killed us though is that we were outputting raw data from the database without filtering it without doing anything now there are times you might want to do this if you want to allow markups such as bold or block codes or image tags or anything like that you want some HTML to filter through you might want to use raw you might want to use text style or markdown to go out like that or if you're working on an old Rails system you might just forget to put the h command on that you know the HTML escape command that's easy to forget Rails 3 defaults to putting that escape in which is a good thing so solution don't use raw if you need to use some htl markup use a flood list of HTML that is allowed do not use a blacklist and don't try to correct bad input right so here we're saying we'll just remove script commands well if the user input is something like this and you remove the script don't try to correct it reject it and look out for javascript that might appear in attributes that you wouldn't normally expect sanitize is a good method in Rails this is actually pretty robust OWASP the OWASP document actually gives praise to sanitize it says it's fairly robust you give it a white list of tags that you allow these are things that you might allow these are pretty safe you say okay only allow href and title attributes I don't know if sanitize checks those for javascript or not hopefully it does it's probably worth checking in sanitize if you don't if you ever use raw output sanitize cross-site scripting instance they are real in 2006 34,000 usernames and passwords were stolen from MySpace the cross-site scripting script that they used essentially used javascript to hide the entire contents of the page and then to insert a login form that was fake and sent the username and password to the hackers website he grabbed 34,000 names and passwords before they stopped that you want to mention talk about this one? I'm probably a member much more recently just last September Twitter was hit with the rainbow tweets worm it was a amusing someone using software for getting worm and had an on-mouser event that effectively was e-mailing some arbitrary script that could be entered via the tweet form which wound up sending a lot of people to some adult-oriented sites which is always good time that was very recent so it's still out there I mean even sites like Twitter fault-created that so check, check, check your output if you're using raw sanitize it okay this is a fun one privilege escalation suppose I have some code that looks like this I want to display a particular movie note so I grab the ID off of the list and I look it up and I display it in the form let's demo this so we go back to our friendly interface here you can see that I'm logged in like it was Matt for convenience I have accessible to me you can see a couple links to some of Jim's movie nights which he didn't see fit to invite me to but because we're not you wouldn't be interested in the movies I love Star Wars and that hurts me despite the fact that I'm not a number 4 not feel bad I would have been offended further had it been prequels but even though I'm not actually invited to this movie I can view it and in fact I could go ahead and vote but since I don't want you to watch Star Wars you're going to have to watch the movie actually what happened there is a very simple hack and even if we didn't put up that list of URLs there for him to easily click on he could have gone up to the URL bar and hacked in any ID for some night in there happen that you'll be watching later on February 9 so even if I don't tell about movies I'm watching he can hack the URL and get to it this is a called privilege escalation he's getting to data that he's not privileged to see supposedly would only give him URLs for his own he can hack in any URL he wants just go ahead and pull up those things ok so instead of doing this what I really should have done instead of doing a night find I should have started with the current user and asked for all the nights and then done a find based upon the nights of the current user if I had done this and he had entered in a night that did not belong to the logged in user he would have gotten a validation error and it would have failed for him so this is one that I tend not to use finders on associations maybe because I like to think of associations as just arrays and the fact that also active record stuff kind of messes with my mind so I tend not to do this and I think we're going to change that behavior because of this very fact alright we're at 30 minutes let's finish I think we're doing good here cross-site request forgery this is a big one how many people have ever seen the authenticity token in your Rails form how many people know what that does for you let's ask this how many people don't know what it does yeah exact this is a really really interesting one imagine that you're in your browser and you point your browser to the hacker webpage of course it's not called the hacker webpage he has some innocuous name like a bunnies and rainbow webpage very exciting yes and you pull down a page and within that page is embedded an image tag that whose source is themovieknight.com and lists a destroy URL for one of the movie nights so that gets loaded in the browser the browser that asks for the image by going out to movie night website and destroying one of the movie nights notice because your browser is still logged into movie night website it still has the session now the hacker website doesn't have your session ID he has no idea what your session idea is so he cannot delete it directly but by giving you an image tag he asks you indirectly to delete that to modify data for yourself without you knowing it let's go ahead and demo this one okay so we've done constructed a another page here which has been to entice you but there is the key aspect is there is an embedded form which is pointing across the movie night site this is on the hacker website this is on the hacker website but the hacker being enterprise knows a little bit about how Rails apps works and is embedded a hidden delete property there so if I go over to this awesome page like me to win I would like to win and I click the big red button oh Blade Runner Blade Runner 9 9 I think I actually that was a show now the problem is this is hacking is hard hacking is really hard I swear he did this right before the talk there it is there it is okay there we go cross site reference forgery it's different than cross site scripting where you load scripts in is using image tags directed to sites not necessarily belonging to you to actually do harm to the data okay so counter measures number one write your websites to be rustful if you do so then things like image tags will not work because the browser issues a get to do that you shouldn't use get to modify your data that's level one security however a hacker could very easily do this in fact that's exactly what Matt did in the demo he set up a form that issued the proper thing and so if you look at rails form that's generated with the helpers you will see a field called authenticity token and it's this really long kind of random looking value and that is generated based upon crypto security stuff within rails it's unique to this session and the hacker will not be able to get it remember the hackers on a separate website he has no idea what your authenticity token is so he cannot include it in any form that he will generate so when he issues this it'll fail because the authenticity token is not even found or not the correct one so that prevents that that is why you have authenticity tokens in your rails web forms now how many people seeing all this work which is using image tags I have to ask you how many people use a mail browser a mail client that automatically displays images for any email coming in anybody do that do you want to think about that for a little bit ok cross-site scripting since cross-site scripting runs a script in your browser you can actually access that authenticity token so cross-site scripting can still defeat this issue but that's a little bit different so you still need to guard against that this is really interesting in Mexico there tends to be a particular brand of router that is commonly used someone set up a CSRF attack that sent out a get request that went to the router reconfigured the router so the DNS entries for a particular bank in Mexico was redirected to a hacker site where he had a fake website set up that collected a whole bunch of bank accounts by using this cross-site reference forgery technique. Gmail assets someone once changed some administrators emails using this technique ok you want to talk about sessions moving? yeah I'll just talk about it really quickly I think we all probably recognize this fire sheep it's very notorious anybody running fire sheep in here right now inventory sessions moving right someone wrote that he sold it to basically an open wireless network would do packet sniffing and would look for recognizable session tokens being passed over the wire looking for common social media sites and you then could spoof service authenticate sessions by basically piggybacking your live session we could do a demo of this right now but no we're not actually going to basically around this you want to require SSL it's becoming more and more advocated for that you basically are just going to protect any portion of your site that is authenticated in session days by requiring SSL and then specifying to use secure cookies just like HTTP only is an option you can as well they be secure which means that they're only going to be passed back and forth if over HTTPS there's a rack SSL this is kind of a dropping solution but it is across the board it will force all of your requests and everything assets and whatnot to use HTTPS and it will automatically mark all cookies as secure okay that's a good time we're actually got about three minutes left here so let's just do a quick summary of things that you need to be aware of number one trust nothing this is the primary goal when you're doing security auditing I'm a very trusting fellow I do not think about people hacking on URLs or putting strange things in image source tags or anything that just doesn't occur to me my mind doesn't work like that but if you want to think about security you've got to get to the point where you don't trust anything that comes in from outside the program stay up to date on all the plugins and frameworks that you use they often put out security updates and if you get behind we've done some security audits on software that we have delivered and one of the things they ding us on is we're not using the latest security patches in the plugins and frameworks that we're using so keep up to date on that don't bypass the Rails built-in security measures 90% of the stuff we did here we were able to do because I went in and disabled the HTTP only thing we took off the protected attribute features we turned off authenticity tokens because that we were able to get by that don't do that there's a reason that all that stuff is there always scope your find by the proper privileges this is a habit I need to develop avoid using RAW and if you do use RAW you sanitize with white lists I would recommend you have an outside firm who specializes in security to monitor your program you as a developer don't think about security the same way these guys who do security audits do and it is well worth your money especially if you have a large public-facing site we've done it on several of our programs that we've delivered and it was very very useful and finally just be aware don't blindly do things because everybody else has done it think about what you're doing and be aware of the security implications of everything that you're doing in your website it was a little discouraging reading all the things that Packers can do but it was very encouraging to see that our software for the most part is protecting us and we need to be aware of it and work with it alright any questions in a minute or so we have left yes back there now the question is just a statement guys thank you very very much for this really important topic but let's sort of make aware there's an amazing resource called NetSploit if you've never heard of this it basically lets you do penetration testing on your own systems using a very nice rail interface interface go check it out Aaron Bedra has worked with that and Aaron is the one who actually did our security audit so yeah good recommendation anyone yes over here one other quick thing to inject and maybe we can talk about this afterwards but our team has recently learned in working with an external security audit company that many people now consider even Rails 3's default CSRF protection to be insufficient really and insecure and maybe we can talk afterwards about it because I just now learned about what it does the basic reason is that you only generate one authenticity token per user session and you keep reusing that for every form every submission and so if you're logged into the site for an hour that's an hour in which an attacker can sniff it with fire sheath or packet sniffing or something else generate a big red hot with your authenticity token and trick you into doing that you want to generate a new one every form so right but then there are difficulties and challenges with that so yeah that's a good point but it's also one more reason not that it's a catch all but to advocate for us so we're all definitely going to request read the documents that we put up there there's a lot of suggestions on how to manage sessions that we did not even talk about resetting sessions often changing the session IDs to keep that giving time to hackers to find that lots and lots and lots of good advice one more question yes so when you're trying to protect to get something like fire sheath does that implicitly until you upgrade your hardware since there might be a significant increase in degradation of performance and so everything has to be questions, protecting this fire sheath does that mean increasing your hardware because there's a degradation in performance because you're using each of them yes right you know what I don't know I don't know how big that performance degradation is right there's going to be a white paper actually that they did a study and related to gmail implementing and going into it and based on their conclusion was it's not costing us too much so it's not going to cost you too much certainly one way to be doubtful is to start with I tend not to use public conference wifi if I can avoid it seriously we had we were at a conference in January and I'm going to share this we had someone hack into some edge case laptops that were there at the conference and they came forward and they said hey we were bound your laptops were kind of open and we browsed them a bit we found some data that really shouldn't have been available there and we we were embarrassed and we sent around some memos and made sure that people tend to close down ports in their laptops in their conferences personally if I can avoid getting on a public wifi a Panera wifi or a conference wifi I try to tend to avoid it these days there's fire sheep I don't know if everyone's ever looked at that that's dirt easy to install in the firefox and it just you know if you're on a public wifi it just grabs all kinds of things there's a plugin from HTTPS everywhere for firefox it plugs a lot of those whenever I'm on a public wifi I always use that you can use a VPN when you're on a public wifi if you can set up a VPN that's an excellent thing to do and just use that explosively whenever you're on a public wifi there are things that we we really need to be aware of as developers we need to be on the cutting edge of this not be left-footed just to say real quick and then force tls is another one but the problem again like those things there's always a moment when it's going to fall down you know it's like forgetting login with the browser or something like that and really personally I much that's to start implementing just just force us to sell ok well thank you very much