Will It Inject? A Look at SQL Injection and ActiveRecord
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 10 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31573 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Right angleMultiplication signDatabaseBitMixed realityWeb-DesignerInternetworkingType theoryGame theoryRow (database)Data storage deviceNeighbourhood (graph theory)Web crawlerWeb applicationInformation securityCASE <Informatik>Database transactionSequelVulnerability (computing)InjektivitätMathematicsOrder (biology)Information privacyPhysical lawVideo gameInductive reasoningSystem callLevel (video gaming)PhysicalismCompilation albumFluid staticsDoubling the cubeProcess (computing)Exploit (computer security)Moment (mathematics)Web 2.0Patch (Unix)Java applet
04:36
Hacker (term)WebsiteRainforestMoment (mathematics)InjektivitätWeb-DesignerSequelInformation security
05:08
Hacker (term)BitOrder (biology)RainforestGoogolComputer configurationElectric generatorComputer animation
05:40
DatabaseSequelMultiplication signStapeldateiInteractive televisionProjective planeMultiplicationInternetworkingGroup actionWebsiteScripting languageGoodness of fitElectronic mailing listRight angleVulnerability (computing)Web 2.0EmailNumberAddress spaceQuicksortInductive reasoning1 (number)Information securityWeb applicationAverageSoftware developerPrimitive (album)InjektivitätFormal languageDemosceneStudent's t-testPasswordRow (database)Product (business)Instance (computer science)Universe (mathematics)Profil (magazine)Inheritance (object-oriented programming)BitComa BerenicesForm (programming)Vector spaceArithmetic meanExpert systemType theoryCombinational logicThermodynamisches SystemData storage deviceQuery languageTable (information)outputVideoconferencingInformationMereologyEntire functionPoint (geometry)Computer programmingHacker (term)Identity managementMatching (graph theory)Civil engineeringDoubling the cubeWave packetStatement (computer science)Selectivity (electronic)Pattern languageCodeConnected spaceString (computer science)Open setCore dumpElectronic visual displayTelecommunicationComputer animation
14:45
Query languageIntegerEndliche ModelltheorieComputing platformRow (database)CASE <Informatik>Multiplication signSequelString (computer science)Online helpoutputGame theoryInstance (computer science)InjektivitätTouchscreenGoodness of fitStatement (computer science)Slide ruleData conversionSource codeObject (grammar)ResultantShape (magazine)BitInformation securityEntire functionDatabaseFree variables and bound variablesTable (information)Point (geometry)Rule of inferenceGrass (card game)PlanningFamilyNeuroinformatikStudent's t-testError messageCausalityToken ringQuicksortWeb 2.0Type theoryRevision controlAttribute grammarSoftware developerAutomationRoutingSelectivity (electronic)Natural numberEqualiser (mathematics)OnlinecommunityRight angleBit rateData storage deviceMessage passingMereologyObject-relational mappingSingle-precision floating-point formatMatching (graph theory)Mobile appCurvatureComputer animation
23:37
Query languageSequelStatement (computer science)MathematicsRuby on RailsRow (database)CodePattern languageChainString (computer science)DemosceneCASE <Informatik>Injektivität1 (number)Real numberReading (process)Local ringPatch (Unix)Product (business)Right angleInductive reasoningVulnerability (computing)Group actionCodeYouTubeInformation securityWordVideoconferencingWeb 2.0Coma BerenicesTelecommunicationInteractive televisionComputer programmingData conversionPrice indexMoment (mathematics)DampingSoftware testingFreewareRule of inferenceTwitterQuicksortMobile appForm (programming)PlastikkarteCore dumpElectronic program guideInformationType theoryInternet forumCompact CassetteHeegaard splittingMultiplication signDatabaseTheoryLevel (video gaming)GodUniform resource locatorScripting languageComputer configurationSound effectMixture modelBit ratePasswordMountain passSequenceCausalityGoodness of fitBitGame theoryArithmetic mean
32:29
Computer animation
Transcript: English(auto-generated)
00:02
Time has started, so I guess we'll slowly work our way into the talk. Did everyone enjoy lunch?
00:21
Anyone go out, grab some barbecue? I think we had barbecue here. Anyone go external? No? Anyone grab a coffee? Like this? Coffee? You guys are not giving me anything. Anyone grab a coffee? No? This guy grabbed a coffee. Nice. So, many lifetimes ago, I worked as a barista at a popular coffee shop.
00:44
And it was a mid-sized neighborhood store, there was a mix of traffic coming from the surrounding homes and business, and we were actually right across the street from one of the big game development studios, and business would just like skyrocket anytime a new Call of Duty game was supposed to launch.
01:00
And it was just a nice mix of customers, and most of them were great. But there was one. I mean, there's always one. And her name was Susie. And this name has been changed to protect her, even though she's totally guilty. Susie would come in three to four times a week, and she always had the exact same order.
01:22
A double espresso, please. And I'd make small talk as we finished the transaction. Oh, how's it going, Susie? Oh, you know, not so well. And she'd launch into some tale of woe, things that just weren't going well. Now, mind you, she was in three to four times a week, and it was always the same
01:42
story. I swear she never had a good day in her entire life. It was just always the same deal. But then, right as I'd hand her the change, she'd perk up a bit. And she'd say, but you know, if you made that a triple latte instead of a double espresso, my day would be a whole lot better.
02:01
Every single time. The problem was that a double espresso cost about this much. A triple latte with its extra shot and milk, well, it cost this much.
02:21
And she would wait until the exact moment that that register closed, signaling that the transaction had officially ended before she tried to sneak something else in there. And that brings us to the topic, safety and security in coffee shops. Okay. Maybe not. It's not quite right, it's probably something more for a Java conference.
02:44
Giving an active record talk, have to do a pun in honor of Tinder love. So actually, we are a room full of mostly web developers. And I'll just say, I looked all over the internet to find the least creepy spider I could find because I was not going to be like surrounded on all sides
03:02
by creepiness, so that's like a very friendly spider. And so like this very friendly spider, we're very friendly web developers. And maybe we want to talk about security in web apps instead. And at the risk of stretching that coffee shop metaphor just a bit too far, I'd like to argue that our web apps have a vulnerability that's actually very
03:23
similar to the one that Susie was exploiting. And that's SQL injection. Now, I'll go into more detail in a bit, but in brief, SQL injection is when someone closes out a legitimate transaction with your database and then immediately tries to sneak a little bit more SQL in there so that they can
03:42
interact with your database and walk off with something a whole lot more valuable than coffee. And I know what some of you are thinking, we are web developers, there is nothing more valuable than coffee. But in this case, there is. I'd argue that your customer's private data is actually slightly more valuable
04:01
than coffee. So, when we talk about security vulnerabilities, I think it's more common to think that we're talking about something new, a vulnerability that was maybe just discovered in the past few weeks, something that's like going to be on the nightly news, something like the Heartbleed, where it's announced publicly the very same day that a patch is released because
04:21
it's just that bad. But SQL injection is old enough to vote, at least in the U.S. I haven't checked everyone else's laws, don't know the ages, but in the United States, SQL injection could vote. It's 18 years old. It was first mentioned by Jeff Forrestal in an online hacker magazine
04:41
called Frack, and you can tell that's 90s graphics right there. That's actually still the logo on the website, did not update. So, Jeff Forrestal, who went by the hacker name of Rainforest Puppy, and I'd like to pause here for a moment, because when you start reading about SQL injection and security and all of those things,
05:01
you come across a lot of hacker names. And I realized I haven't got a hacker name, and I did what any web developer would do. I went to Google and I Googled hacker name generators, and I started trying out a few different options, including one dubious generator that insisted it needed to know my mother's maiden name and where I was born in order to generate
05:21
my hacker name. And I thought, nice try, and moved on to the next hacker generator. And after probably a bit too long on this, I was finally the proud owner of this doozy. And you know that's a legitimate hacker name because that is a four. That's not an A. So, back to my fellow hacker, Rainforest Puppy.
05:44
He had discovered that SQL databases, which were just at the time starting to replace the more popular Access database, they allowed batch commands. And so what that meant was that you opened up one interaction with the database and you could do one command.
06:01
But with batch commands, you open up that connection to the database a single time, and you can just send more and more and more requests in there. And that's not a big deal because multitasking is a good thing, right? I mean, let's say I want to take a look at all of my employees. This is a fine-looking group of employees.
06:21
But say that I want to select just the ones that are developers, so just these two. And then I want to sum up or find the average of their chips consumed. And because I like to be inclusive, we could also average their chips consumed if you speak one of those other Englishes, whatever.
06:42
But whether it's these chips consumed or those chips consumed, it's pretty high, and we'll leave it at that. And because you can put more than one command in, you can just open up that database opening once and run those extra queries. And in a closed system, that is all well and good because you're not going to attack your own database.
07:02
But when you have input coming in from outside, when you have outside user data heading straight into your database, things can get a tiny bit dicey. So let's say a shady character, maybe like this guy, wants to use your innocent little web form to gain access to parts of your database that you don't
07:22
want them to have. And they can do that by piggybacking their own SQL command onto your intended request, sort of like this. You have a SQL command and you give them the chance to... You provide them the ability to search for a restaurant where they can do sort of a match with the name. And so you, like, select star from restaurants where name is like,
07:43
and then you add in the user input. And your user, Shady McShadester, searches for the following restaurant, which honestly does not sound like they're going to have the best quality food to me, but, you know, whatever, this is what they search for. And this is the query you actually end up with. So you're selecting star from your restaurant table where name is like,
08:04
and that actually closes out that name, that select statement, and then starts delete from restaurants. And that double dash there is a SQL comment, which means everything after that is commented out. And so what you've done here is you've selected nothing from your restaurant
08:23
table because they didn't give anything, it's just like an empty string. And then they delete every single record in your restaurant table. And that is SQL injection. Your entire restaurant table is gone. And I'm not talking about your table at the restaurant, it's your restaurant table in your database.
08:41
It's actually still there, it's just completely empty, but you should also probably cancel this table because you're going to spend the rest of the night backing up and restoring your database. And you're all doing database backups, right? Yeah? No? So it's not the scope of this talk, but if you're not, you should be, because stuff happens.
09:02
And yeah, it's just a good idea. So let's talk OWASP, the Open Web Application Security Project. This group has...they only get together, and I think every three years, they update their top 10 list of web vulnerabilities.
09:20
And SQL injection, it's been out for 18 years. It's an old vulnerability, and yet it regularly ranks at the top of their 10 most critical web application security risks. And that's not really a top 10 list that you want to be at the top of. And honestly, if you look at, like, a recent scan of the news, you will find so many examples of companies, big and small, that have,
09:44
you know, kind of seen SQL injection from the bad side. For instance, Sony Pictures. In 2011, Sony Pictures lost the data of over 1 million users, including their passwords, which were reportedly stored in plain text.
10:04
So that really hurts. And, you know, you might think, oh, well, whatever, it's like Sony Pictures, big deal, but most people use the same password, and now you've got the password that the people use in their bank and all this stuff, and they can just go from site to site, build a profile on these people, and just, like, steal even more information because you did something that you should not have
10:24
and stored passwords in plain text. In October of 2012, hackers used SQL injection to get the personal records of thousands of students from over 53 universities around the world, including major universities like Harvard, Stanford, Princeton.
10:42
And the reason they like students, like, universities are actually a pretty big attack vector, which I didn't realize they were such a target, and that's because students tend to have a, like, wonderful combination of really clean credit records, and they don't pay attention to their credit score. So you just have, like, quite a few years of being able to, like,
11:01
totally trash their credit histories before their student loans do it for them. And that's, I guess, the one thing that we can say is good about crushing student debt is that by the time you graduate, no one wants to steal your identity anymore. All right, we're not done yet. But in August of 2014, Russian hackers stole 1.2 billion, that's with a B,
11:22
username and password combinations, and 500,000 email addresses from 400,000 websites. And these weren't all just, like, little mom-and-pop sites. Most of these were Fortune 500 sites. They're not sites made by your cousins, best friends, uncles, kids down the street who sort of knows how to develop a website. These were made by, like, professional developers,
11:42
like the people sitting in this room. And it wasn't pulled off by some, like, elite gang of movie hackers. It was a group of less than a dozen men living in a small town in Russia that actually got their start doing email spam. And one new guy moved into town and was like, I can show you how to do SQL injection.
12:00
And they became, like, the kings of SQL injection. And then I've got one more for you. This was actually mentioned in an earlier talk. And it's VTech, which is an electronic toy company. And they lost the data of over 5 million parents. So, like, email addresses, phone numbers, home addresses, because people had registered their products. They also lost the data of 200,000 children.
12:23
Now, this was just first names and email addresses. So it doesn't seem as severe until you realize that the data dump included the ability to link the parents with the kids. So now you've basically had, for 200,000 children, their first names, their last names, their parents' names, their home addresses.
12:42
I mean, that's pretty major. Like, that goes beyond just like, oh, they're going to have to change a password. Like, that actually puts children at risk. There's more. In the last five years, the New York Times has suffered a SQL injection attack. Target has suffered from a SQL injection attack.
13:01
Sony, yet again, suffered from SQL injection. The U.S. Army, and believe it or not, the U.S. Department of Homeland Security, all vulnerable to this 18-year-old SQL injection. So what's the deal? Is there, like, this elite hacker Harvard out there that's training up just,
13:22
like, code ninjas and teaching them how to sneak unwanted SQL commands into databases like there's no tomorrow? No. No. SQL injection is common for two reasons. The first reason is that it's really easy to automate. There are scripts that you can go out online and you can buy, and they just bounce around the internet looking for common patterns in websites,
13:44
looking for things that seem like they might be vulnerable, and they'll, like, pop up a little gooey display and say, oh, hey, do you want me to start attacking this website? It seems vulnerable. Like, you don't have to do anything. In fact, there's this guy, Troy Hunt, who's a web security expert, and he runs a website called haveibeenpwn.com,
14:01
and I think that's the best logo ever for a website that focuses on SQL injection. And he actually posted a video where he was teaching his three-year-old child to do SQL injection attacks using the most popular program. And this wasn't to show how brilliant his three-year-old was.
14:23
The point he was making is that SQL injection is just ridiculously easy. These people do not even have to know how to use the command line. It's a gooey interface. The other reason that they do it is that it keeps working. So they use it because even though we've known about it for 18 years and
14:41
even though there are very easy ways to avoid having this happen to your website, hackers year after year get gigs and gigs and gigs worth of valuable user data. So how do we put an end to this? It's kind of harder to make it like you can't make it impossible for people to
15:00
automate. Like they can crawl the web, they can do what they want. So you can't make it harder to automate. You could possibly give your table names like really weird names that are hard to guess. Most likely though, that's just going to drive your dev team crazy and make development harder and you're still going to suffer from injection attacks. So that's probably not the idea. And the easier route is just, you know,
15:23
make sure it doesn't work. Awesome. Talk over. Okay. You guys want to know how to make sure it doesn't work. Okay. All right. So my name is Jessica and I work at a place called the flat iron school and the platform that I work on is a platform called learn and we use this
15:42
platform to teach people how to code. And so we've got tons of students, tons of like brand new junior developers constantly on our platform learning things. And one of the things that we have as part of our teaching philosophy is that we like to have people step through and actually build, build basic versions of the tools they'll be using later.
16:01
So it helps ensure that they kind of know what's going on when they get to like the bigger magical platforms. And so we make them work with sequel and kind of build their own lightweight ORM's. And after suffering through that for awhile, we introduced them to active record and everything is like magic instead of having to do select star from restaurants where a type equals barbecue,
16:23
which is simple enough, but like still kind of like not super intuitive. You can use, Hey, I want the restaurant where the type is barbecue. And just, you know, active record does it for you. And it really seems like all this magic makes sure that the only thing that you have to worry about is whether or not the rule is that your model name
16:43
is supposed to be plural or singular and wait, is it restaurant dot where or restaurants dot where and that gets me every time. But it's like, if that's the worst thing you had to worry about things to active record, like game over SQL injection is gone, but it's actually a bit more complicated than that. So we're at rails conference and you guys came into a talk called will it
17:03
inject a look at SQL injection in active record and congratulations because we finally made it to the title screen. Woo. Yeah. I'm only 70 slides in and given this title, I think it's safe to assume that what you'd like to hear about is SQL injection and active record.
17:22
And I kind of think that having someone just like yak at you about SQL injection and security, especially right after lunch when you're feeling a bit sleepy and I'm talking to you, dad. It can be kind of boring. And so instead we're going to play a little game that I like to call, will it inject? All right, so the rules are simple.
17:44
I will show you an active record query. You guys are going to tell me whether or not you think it's vulnerable to injection and you can just sort of shout it out and you guys watching this later from home, you should feel free to play to shout at your computer screen. I'm not going to judge. I'm not even going to be there. So here is our first one and this guy find he's sort of the
18:05
heavyweight of active record. And if any of you use active record, if you've built even a tiny little app, you've probably used this quite a bit. So let's say you wanted to find the barbecue joint that has the record of one. So the record ID and the table of one.
18:23
Do you guys think that if you like left that open to user input that that's going to be vulnerable? Do you think, will it inject anyone? Who thinks it's going to inject? Just raise your hand. No. You guys think it's safe? Oh, all right. What's that? Let's use edge active record. No.
18:45
How about whichever one didn't just come out? Cause that's probably the one I'm using. Um, it won't inject. It is safe. So that one actually only works for an integer. It matches. It's like looking for an integer value. If you shove something in there that's not an integer value,
19:01
it's kind of gonna blow up cause an error. Now one of the things that someone could do is start messing around with those numbers and if you're not verifying that they should have access to that particular record, they can use this to see records that they shouldn't be able to see. But that is outside of scope of this talk. So you'll have to find someone else that can tell you how to avoid that.
19:22
All right. Find by, it's similar to find, but you pass in both the attribute you're searching for as well as the value that you want that attribute to have. And as you can see here, it will even let you look for more than one attribute at a time. So for instance, say your user is looking for barbecue that has the type of burnt ends and a
19:43
dad's rating of five. And if you know my dad, you know that this could only possibly mean one place. It's Arthur Brian's. But yeah, you guys, if you haven't tried it already, like before you leave Kansas city, stop, get some burnt ends at Arthur Brian's. It's great. Um, but whether you know my dad or not, do you know,
20:01
will this inject? Who thinks it's going to inject? Got, we've got a couple of hands, couple of hands. All right. Who thinks it's safe? Oh, snap. Yep. It's safe. It will not inject. When you pass the attributes in as a hash, active record actually escapes any of the special characters and treats the
20:21
entire thing like a string. So you can have your shady McShade store users pass in all the raw sequel that they want and it will not inject. Okay. What about this guy? If you wanted to write a query query that searched for records based on a SQL fragment. So in this case, and I mean, honestly you wouldn't need to use this particular SQL fragment because you
20:42
could obviously just do barbecue dot find, you know, name and then the input. But say you had a complicated query and you had to drop down to raw SQL. So barbecue dot where and then name equals and the user input. So you could say barbecue where name equals Oklahoma Joe's for instance.
21:01
And you would find another great barbecue joint, which became even greater when they dropped the Oklahoma and became Joe's Kansas city barbecue. Everything tastes better. But in any case, a great place for barbecue, but how does it fare against SQL injection who thinks that this one is going to inject? Oh yeah. A lot of hands up.
21:23
Anyone that's like, nah, we got this. This is safe. No. All right. You guys are right. That one does not fare so well because similar to that earlier conversation when we were just looking at SQL, your shade or your, your shady user could say that they want to find a restaurant called single
21:42
quote, semi colon delete from barbecue dash dash, which again doesn't sound like a tasty restaurant, but the end result is that your entire barbecue table is lost. And that's really sad. So how do we protect ourselves against this? Oh, look at this. Anytime you're using gross equal,
22:02
when you get to the point in the query where you are going to put the user supplied data, you can replace it with a question mark and then you just like comma and then put the input that you're going to put in after that. And then active record kicks off this thing that we like to call, you know, baby proofing the query. And the first thing it does is that it sanitizes his user input.
22:24
And that means that it escapes all the special characters so that the entire thing will be treated just like a string. It can't be executable. And all that magic happens if you're interested in reading any source code and sanitization dot RB with a little help from quoting dot RB.
22:41
Me, I just liked that it works. And no matter what nefarious thing people pass into my app, like if I've done it this way, it's sanitized and it's nothing more than a string and it can't do anything. And the other way that active record is protecting you there when you're using the parameterized queries. And that's what they call it when it's a question mark.
23:01
That's parameterized queries. It's that the SQL statement actually gets sent to the database with the placeholders and the database then parses a statement and it comes up with a query plan and it caches that query plan and sends the statement and a token back to your app. And when the actual values finally do come through,
23:20
if the statement that is trying to be executed differs from that query plan. So if somehow raw SQL did get in there and someone was trying to change the query that was being had initially been asked for, it can tell that it doesn't match with that token that was sent through like that initial plan. And it's like, no, we're, we're not doing that.
23:40
You cannot change the type of query that was already planned once you use the parameterized queries. So one thing you should know, not every database type supports this. The active record database adapter actually determines how it'll handle things when you use parameterized queries. So just if you are relying on this, make sure that you know how it works for the particular database you're
24:02
using. But most of the major SQL ones like Postgres and stuff, they do allow that. All right, moving right along back to the game. We're going to step it up a notch. Will this filter by statement inject? Who thinks it'll inject? Yeah. Who thinks, who thinks it won't?
24:24
Who here recognize that this is Python using SQL alchemy? I'm just trying to make sure you guys are awake. No, that's not even active record. Who even knows what all that stuff is? We're very confusing. But in case you're wondering, it kind of does the same thing as a find by and it turns everything into a
24:43
string. So even that weird statement will not inject. Okay. What if you wanted to search for all the barbecue joints that are not expensive, but to make it easier to determine which ones are delicious, you also want a group by dad's rating.
25:01
Is this vulnerable to SQL injection? Okay. Got some people. Yeah. Over there. I'm just going to tell you guys someone from rails core just raised their hands. So maybe all of us are like, Oh yeah, it's, it's vulnerable. You guys are right. That group method allows for SQL to be passed in. So if you're putting the user data directly into the query with that group
25:22
by you are going to be vulnerable. All right. I think we have time for one more. So let's take a look at having and this one actually almost always ends up at the end of a chain of like a lot of other queries. So in this case, you're looking for a barbecue restaurant that isn't expensive and you want to
25:41
group it by location and you want to give the user an option of saying that they want a certain level of dad's rating. So maybe some of them, you know, they're like, I'm not too picky, a dad's rating of two or more. But in this case, this user wanted a dad's rating greater than four. So will that inject? Yeah. Anybody know?
26:01
All right. Who thinks it's safe? No, it injects. It's actually a at greater risk than a lot of the other methods because it usually ends up at the end of the method chain. So because it's at the end and nothing follows it, it's even less likely with that particular one that just having something
26:21
else coming after it in the query chain will stop the injection. So you definitely want to be careful with having it just makes it easier for people to shove their own SQL in there. Um, and the thing is, is that once again, this is easily fixed with the parameterized queries. You just pop that question mark in, put the statement and active record takes care of it.
26:43
And you might be looking at this and say, that's very similar to how you fixed the other one that had injection. And that's one of the great things about active record is that it does have like a lot of patterns that are the same. So if you figure out a way to avoid injection in some methods, chances are you're going to be avoiding them in all the rest of them. Uh,
27:02
so it's just easy peasy. Now some of you might be thinking, look, if people are aware of these vulnerabilities and it's been 18 years and SQL injection seems pretty major, why haven't they fixed this yet? Maybe I'm going to go back to my hotel room tonight and I'm going to work really hard on a patch and I'm just going to get this pull request in and
27:22
then there's going to be no more SQL injection in Ruby and rails. It's not quite that simple. So the problem is it's another example of that age old tension between freedom and security. Those vulnerabilities are there because they allow us flexibility.
27:40
That coffee shop I worked at, they could easily have had a rule that said you were never allowed to give anyone anything for free ever. And if that had been the rule, we all would have followed it. Customers would have stopped asking, Susie's stick of, Oh, but my day would be better if you gave me a lot of free stuff wouldn't have worked. But there would have been a lot of magic moments that we would have
28:02
lost. There were a lot of like beautiful individual customer interactions where you're just like, Oh, Hey, the coffee is on us today. Do you like an extra shot that just wouldn't have been possible? And it's the same thing with active record. Like you don't want to lose the magic of being able to really like dig down
28:22
into the data and drop down to raw sequel and do like a really crafty query because as beautiful as active record is for probably 90% if not more of anything that you'd need to query it for, there's still the fact that sequel was made to talk to databases. And sometimes if you want to do some crazy complex query,
28:40
you could either spend like weeks figuring out how to do it in active record or you could do it in sequel and that's going to be the only straightforward way of getting it. And if active record didn't allow this flexibility, it would start to be less and less useful as our apps got more and more and more complex and we'd probably spend a lot of time starting to write our own methods to talk to databases and we'd write them from scratch.
29:02
And if the history of programming is any indication when we start writing our own things from scratch and it's not the core of what we're trying to do, chances are we're going to actually end up being more at risk than we would have if we had just figured out like the active records stuff. And then our apps would be in the news but for all the wrong reasons and we
29:21
should apparently leave that to Sony cause that's Sony's thing. They're the ones that are in the news for a sequel injection. Don't be Sony and look, I get it. I know that it's a bit tougher than ye good old days where security was literally like a heavy wooden door with a big guy in a metal slit and you didn't have to worry about automated scripts being run by precocious little
29:44
three year olds that were looking for the slightest vulnerabilities in your code and it was just a face to face interaction and you probably got one chance to get it right. So you couldn't even sit there spamming a password. Like is it one, two, three, four, five, six? No. Is it password? Like you had one chance and like you either got it or you got chased away by
30:04
the big guy. But the reality is that things aren't actually all that much more difficult now with the built in security and active record and just a tiny bit more knowledge of what's going on behind the scenes with those helper methods, we can all write code that keeps our customers data and our apps reputation
30:21
safe and secure. So, um, I want to give a quick shout out to my colleague Eric raffle off his Thursday code reading at work was actually the inspiration for this talk. He has since left us to go work in web security. So we're all safer for that though. We do miss him at work and I want to thank my husband Josh for hand drawing anything I asked him for and double checking my sequel coder animators are the
30:45
best. Um, if you guys would like to learn more, um, an amazing resources, this rail sequel.org, uh, just there are places that you can like test it, see how it works. He goes through all of them in detail. Like it's a beautiful resource. There's also guides dot Ruby on rails.org security dot HTML.
31:05
That's like actually the security guide from Ruby on rails and it has a lot of good information you should check out. It covers a lot more than just SQL injection. There's the OWASP Ruby on rails cheat sheet and you can also, this is crazy. Just look at your own code, go to your own web forums,
31:22
try to inject some SQL in there, see if it works. Don't do it in production, do it in local. Uh, but if it'll work in local, it'll work in production and you should probably shore that up. So, um, as I mentioned, I'm Jessica rudder. I make codes about, or I make videos rather about coding at youtube.com slash comp chop and if you
31:41
like code and videos, I'd love to have you check them out and let me know what you think. I would also love to continue this conversation on Twitter and if any of you are like new to programming and you want to talk about learning to code or sort of learning rails, um, I've borrowed the company credit card and we're going to be doing a dinner tonight for beginners. Um, so if you're just starting out and you want to like join us for that,
32:03
just hit me up after the talk and I'll give you the, uh, the details. So that's the talk. Are there any questions? And they, if they're mean questions, I'm just going to mad dog you. So pre warning, pre warning. Oh, no questions. Good. I answered everything.