The State of Web Security
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 | 31 | |
| 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/31569 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201631 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
Speech synthesisComputing platformQuicksortOptical disc driveMaxima and minimaProduct (business)Multiplication signDependent and independent variablesComputer animation
00:55
Roundness (object)Closed setCollaborationismFormal languageTheoryInternetworkingIn-System-ProgrammierungCartesian coordinate systemMobile WebType theoryFunctional (mathematics)Medical imagingCodeQuery languageTouchscreenExpert systemInjektivitätVulnerability (computing)Information securityMultiplication signView (database)Row (database)Profil (magazine)Dependent and independent variablesWebsiteHacker (term)Single-precision floating-point formatContent (media)QuicksortLaptopSoftware frameworkProduct (business)Vector spaceMereologyWorld Wide Web ConsortiumServer (computing)Mobile appBuildingString (computer science)Software developerGroup actionGreen's functionoutputDatabaseRight angleVideo gameMassBitData structureCharge carrierSoftwareMetropolitan area networkPresentation of a groupFood energyResultantCellular automatonContext awarenessPoint (geometry)Exception handlingWater vaporRootSoftware testingDefault (computer science)LogicGame controllerElectronic GovernmentAuditory maskingSensitivity analysisMathematicsWeight functionCondition numberParameter (computer programming)Computer animation
09:29
FreewareAddress spaceInjektivitätMereologyWritingSubsetHacker (term)Vulnerability (computing)LaptopNumberEmailStatement (computer science)Inheritance (object-oriented programming)PasswordRow (database)BitUniform boundedness principleLecture/ConferenceMeeting/Interview
10:52
PasswordCodeGreatest elementDefault (computer science)View (database)VolumenvisualisierungIntegrated development environmentVariable (mathematics)InformationInjektivitätWritingQuicksortPhysical systemVulnerability (computing)WebsiteType theoryException handlingoutputTraverse (surveying)Latent heatExtension (kinesiology)Template (C++)NeuroinformatikFile systemString (computer science)Online helpBlogFunctional (mathematics)Interactive televisionCASE <Informatik>Directory serviceArtistic renderingFerry CorstenGUI widgetData storage deviceImplementationInformation securityContent (media)Gastropod shellParameter (computer programming)Sensitivity analysisFilm editingLeakMultiplication signServer (computing)Operator (mathematics)DatabaseCodeMatching (graph theory)Row (database)Observational studyWorld Wide Web ConsortiumBit rateToken ringHTTP cookiePublic-key cryptographyMobile app
16:42
Codierung <Programmierung>Computer wormMassTerm (mathematics)Server (computing)Electronic mailing listHacker (term)Vulnerability (computing)DatabaseSoftwareAcoustic shadow1 (number)InjektivitätKey (cryptography)WebsiteType theoryVideo gameACIDPrimitive (album)CodeCone penetration testMessage passingMobile appCASE <Informatik>BitGastropod shellPasswordInformation securityInformationMalwareDefault (computer science)Query languageScripting languageData loggerFile systemSingle-precision floating-point formatObservational studyMaxima and minimaLeakComputer clusterLoginProduct (business)Core dump
22:32
Sensitivity analysisWebsitePasswordType theoryCore dumpElectronic mailing listResultantHacker (term)CASE <Informatik>BitSystem administratorComputer animation
23:53
Line (geometry)CodeElectronic signatureFirewall (computing)Control flowMobile appHacker (term)Web applicationReal-time operating systemElectronic mailing listParameter (computer programming)Session Initiation ProtocolCausalityServer (computing)Vulnerability (computing)PlastikkarteBitNumberProxy serverInternetworkingMathematicsEmailSoftware developerQuicksortPoint cloudAddress spaceMathematical analysisAdditionInformation securityUniform resource locatorSoftwareType theoryPoint (geometry)CuboidClassical physicsSoftware testingFluid staticsReal numberRule of inference
27:54
MereologyCodeCartesian coordinate systemType theoryInformation securityQuery languageRun time (program lifecycle phase)Line (geometry)outputMultiplication signHookingHand fanMobile appGroup actionCuboidDirection (geometry)LoginProbability density functionLogicPublic-key cryptographyIP addressCondition numberGastropod shellDatabasePhysical systemVulnerability (computing)AuthenticationData structureQuicksortBit rateSoftware developerStatement (computer science)InjektivitätBit1 (number)Shift operatorScripting languageFlagPasswordSource codeEmailSelf-organizationServer (computing)Common Language InfrastructureExploit (computer security)Thresholding (image processing)Power (physics)GradientTemplate (C++)Line codeCross-site scriptingFile systemLecture/Conference
32:54
Motion captureCodeMultiplication signType theoryVulnerability (computing)WebsiteComputer animation
33:26
WebsiteComputer animation
Transcript: English(auto-generated)
00:03
My name's Mike, I'm the CTO over at Immuneo. I wanted to welcome everyone to Kansas City, I hope everyone's having a good time. It's the third day in the conference, so I'm gonna try to keep references to, we're
00:24
not in Kansas anymore, and the Wizard of Oz to a minimum, you've probably heard them all. RailsConf has always been a good place for us at Immuneo, it's actually, if you remember us here last year, we had a booth in the expo hall. We actually launched our company at RailsConf, so our first supported platform and our product
00:45
is Rails, and yeah, we love you guys, so thanks a lot for that. Speaking of launches, I wanna sort of divert at the start here and say, did anyone stay up late last night and watch the launch SpaceX guys?
01:00
Let's give them a round of applause, that was awesome. This actually isn't a talk on REST APIs, by the way, it's a talk on teamwork, collaboration, closeness. How many of you guys did any of these things today?
01:21
How many of you did all of these things today? All right, I think we'll find a seat, so I'm gonna get started here, just because we have a lot of content to go through. The last time I did this presentation, I sped through, I sped talking, I got done eight hours. I'm gonna try to get it done in like seven to six hours for you guys.
01:40
Sound good? I don't feel like there's like, half the group is like, yes, maybe you're seven hours, the other half is like, why? Is that coming over our speakers? So very quickly about me, the reason I'm doing this workshop, I'm an API fanatic. How many people here have used APIs? Does anyone know what they're talking about, is it better than my talk? Or poorly documented.
02:02
Or break. How many people like those APIs? Okay. No, it sucks, it makes my life suck, so. Can everyone hear me when I'm talking? Can I just talk over them, is that fine with everyone? A way that's future proof, a way that takes advantage of the best practices in modern technologies. Okay, work with me here, we'll try to make it through and not, I wonder if they
02:21
can hear me though. Interesting, okay. How many guys did this? All of you probably. How many of you guys maybe added some web banking in there? Maybe you arranged a date for the weekend? Maybe some of you right now with laptops are actually sort of like, managing your company's
02:44
network, or touching your production servers. All this is happening online through websites. You guys write websites, other people are out there writing these websites. This is all happening on the web. This is, you know, everyone knows, 10 years ago, 20 years ago, it's just getting more
03:04
and more stuff online. Government data, sensitive data, your date profile on Ashley Madison, everything's online these days. And the other people who are online are people like this. And of course, this is exactly what they look like. Or this one, you've probably seen a lot.
03:22
And how do we protect ourselves against people like these? Well, we go on the internet and we download padlock images and stick them on the screen. You guys have all seen these, right? You make your site more secure. Or maybe another one, green one in there, shield, and you know, stop.
03:44
So hopefully all of you guys are doing this. And all of these other websites that you're visiting and you're trusting to store your data are also doing these fancy techniques here. And that kind of brings up the question, who is actually protecting all my data on
04:01
the internet? Probably some of you guys are managing sites that are holding my data. Certainly there are other developers who are developing these sites. Because fundamentally, over the past 20 years, say, it's become easier and easier to make a website. We're all here this week because we love Rails.
04:23
That workshop that we were listening in on, they're learning how to make websites. It's really easy. Rails makes it easy. Other frameworks make it easy. But there's still that question of who's actually protecting our data. Who is protecting that data? Is it people in this room?
04:40
Probably it should be everyone. And are these people doing some of these things? Checking out our framework defaults, making sure things are up to date, maybe getting their code reviewed for security, pen tests, that sort of thing. Looking for new CVE vulnerabilities.
05:01
Hopefully you're doing maybe some of these things. Maybe you should be doing all of them. Or maybe you're lucky and you've got a pair of magic ruby slippers. Sorry, that's the last one, I promise. Because security's hard. All those things I listed are hard.
05:21
It takes a lot of time. It takes a lot of work. You guys generally are focusing on making your site work, making it do cool things, building features for your customers. Security, everyone wants to be secure, but it's a hard thing to do well. It's difficult. But it can also be really, really interesting.
05:41
And I hope some of you are here today to get into some of the interesting parts. So really I'm focusing today on three things, three types of vulnerable code that might be in your applications that you've written or that you're going to write. There's code that you write, your application itself, the view logic, that sort of thing,
06:03
the controllers, the actual app. This is code that you've written and you're responsible for. There's also code written by other people. You use the Rails framework. Rails runs on Ruby. You probably run a ton of third-party gems to add various functionality to your app, to your app.
06:22
Other people's code that you're now sort of responsible for their security posture. And then code not written at all. So maybe you should have written some additional functionality to protect you against attackers. But again, you don't always have time. So this code not written is also a gap in your apps.
06:46
It kind of sounds a little bit like the ghost of Christmas past, the ghost of Christmas yet to come, but whatever. So let's look at an attack type that probably everyone's familiar with, I hope, at least you've heard of it.
07:00
SQL injection. This is a very simple example up here. You've got an SQL query and you're building it by adding some strings together and putting in some user input there. And then a user comes along, one of those shadowy hacker guys with the mask,
07:22
and says, I'm going to set my username to this in red. It's red because it's from a hacker, of course. Single quote or one equals one. So if you're not familiar with SQL injection, you might look at that and say, okay, what does that do?
07:40
But what happens is when your query gets put together, it modifies the intent of your query. Instead of a where clause with one parameter, name equals username, it now has two conditions, name equals whatever or one equals one. And I don't know if you're experts on math, but one equals one is always true.
08:01
So that's always going to return true. So instead of giving you back one record that matches your username, it's now going to give back every record in your database. And this is the type of thing that introduces and allows these massive data breaches that you probably read about on the news, where there's millions of credentials floating around on the Internet.
08:23
Some of them might be yours, some of them might be mine. Now, SQL was first sort of discussed publicly in 1998. It's really well understood. This is not a new attack vector. It's not an advanced attack vector. So pretty much this is fixed in every app on the Internet.
08:44
Right? It is? Question? Obviously not. Last year, TalkTalk, a big UK ISP or mobile carrier, 157,000 of its customers had their details stolen.
09:00
They figured after the breach and all the handling of it that they lost around 100,000 customers and about 60 million pounds, probably about, what's that, $100 million US, because of this breach. SQL injection. Not advanced anything.
09:20
Just that SQL injection that was first talked about almost two decades ago. Okay, but they're an exception, right? Right. VTEC. Anyone with kids, this one's kind of scary. VTEC makes these little kid laptops for children. And the children log in, they've got their name, they can put in their birth date.
09:42
And they got breached, VTEC. And they lost details on 200,000 children along with almost 5 million of their parents with home addresses, passwords, emails, names, et cetera. SQL injection. Two decade old vulnerability.
10:01
And this one, a bit more fun. Wetherspoon's pub in the UK, they got hacked. Now this one wasn't awful. They only lost around 650,000 customer details. And it was only phone numbers, dates of birth, and email addresses.
10:20
So, no damage there. Oh, and beer vouchers. That's the one that really hurts me, because these now shadowy hackers are drinking free beer on Wetherspoon's. Maybe they deserve it. I don't know. So this age-old attack, almost two decades old, should be well solved. You're thinking, probably, well, I'm a Rails dev.
10:43
I don't write SQL statements like that. I use ActiveRecord. It takes care of a lot of this for me. Well, after the talk, go take a look at this website here. If you haven't seen it before, railssqli.org. It's written by, actually, Justin Collins, who's speaking right after me, so stick around to hear his talk.
11:05
You would be shocked, I think, at some of the things that in ActiveRecord look like they should be very safe. A function that takes a single parameter, like a column name or something like that, in the case of pluck. Instead, it actually, internally, really just builds up these strings.
11:24
So you can do, again, lots of arbitrary type attacks, like SQL injection. So it's still a thing after 20 years. This is code that you're writing. Now, what about code that other people are writing? So this is a vulnerability that was announced at the start of this year.
11:45
CV2016 means it's 2016. There were, I think, four Rails vulnerabilities announced all on the same day with a collection of things. This is credited to John Poulin from Invisium, a company that does Ruby on Rails consulting, security.
12:02
They're really good guys. He's also got a blog where he describes this in depth. I've linked it on the bottom there. And I'm basically just showing you the highlights of his blog post. But it was reported as a possible information leak vulnerability in Rails. And it really, it's an issue if you have something written like this in your app.
12:24
The render function, and you're rendering, well, anything where it's coming from, like user supplied input. So the idea here is I've got render params template so that I can have different templates for, in this case, my users. Maybe this is the dashboard template we're looking at the bottom.
12:44
So you type slash dashboard and you get the dashboard template. If you do slash details, you get the details template. So it saves you some time, right? So if you look at the render documentation, it's not super clear what that first parameter is.
13:01
Is it just the name of a template that then gets looked up along with all my other templates? Or is it a path to the template file within my app? Or as we'll learn, could it be an absolute path to my file system? And of course, I'm talking about it because it's this one.
13:22
So yeah, that same view, you add the percent encoded, but etsy password, which is the database on my Unix systems that stores all my user details. And dumps it right out. That's all the content in there. Okay, so maybe an exception.
13:42
What about something more Rails specific? What can you do with that sort of secret down there for session initialization? You can do a lot of stuff. You can basically forge any session data in Ruby because you can sign your own cookies.
14:02
So basically, through this vulnerability, we can read any file on the file system that your web server would normally have access to. They call it an information disclosure, arbitrary file disclosure, or sometimes directory traversal, where we're sort of using these dot dot slash or absolute paths to get into things.
14:20
And yeah, you can read any file on the system. SSL private keys? Probably something you don't want to lose. What else do we have here? Secret tokens, secrets.yaml. These things on the bottom, not everyone's aware. Sometimes you put sensitive data into your app through environment variables. So you don't need a file on your file system with data.
14:42
Well, if you can read these proc file systems, you can actually read those environment variables just like a file. So you're not really safe no matter how you do it. If you've got this vulnerability, you're in trouble. Yeah. Okay, so bad. It's really bad, this vulnerability. If you happen to have code like that in your app, and I just did a quick search on GitHub for render params, give it a try sometime.
15:10
There's something like 50,000 matches. It's not a rare occurrence, this stuff happens. But it gets worse. So there was another vulnerability in 2014, another CVE-0130.
15:26
And Jeff Jarmock, I think is his name, pronunciation, from Matasano, he wrote up an article and kind of dug into this. And it was a similar concept. Basically, there was a way that you could convince Rails to load an arbitrary file on the file system.
15:43
And he said, well, can I take this further, and instead of just reading a file, can I actually execute arbitrary code? And of course, you can. And it really comes down to a helpful default behavior in Rails, where you can...
16:01
Basically, if you load any file with render and it doesn't recognize the extension, it defaults to treating it as an ERB template. So in the example before, when we were, you know, etsy-password, what we didn't really see was it was actually rendering that as an ERB template, because it didn't know the extension. So for etsy-password, it's not a big deal, there's no ERB code in there.
16:25
But if we can put ERB code into a file, like something simple like that, and it's just using the backtick operators, which executes shell commands. If we can get that into a file on the computer, and then get Rails to read
16:40
from it, then we can execute any arbitrary shell commands on that server that we want to. Who am I tells us the current user, but you can imagine we could put far worse things there in red. And of course, again, it's red because it's from one of those shadowy hackers. So the basics is we write code into a file, and then we ask Rails to execute it for us.
17:04
So how do we do that? How do we get code into a file in Rails? Well, thankfully, that's built into Rails. Because every request gets logged to your log file, production.log.
17:21
And I don't know if you guys have looked in it, but by default it's showing all your query parameters, so great. My code, one, two, three, four, we could change that to something a bit more sneaky. Percent in code, there's our ERB data that we want to get in the file. Make a request, and of course, it dutifully gets written to production.log.
17:41
So now if we put this exploit together, the first half, the new vulnerability, plus this half, the old exploit from 2014, we get the same idea. We get a single request, we feed in arbitrary shell code, send it to a vulnerable server, and it executes.
18:02
Yikes. So, okay, that's a vulnerability. What does that let an attacker do? So this is something that's kind of a bit new over the past maybe year, year and a half. It used to be all this stuff. If you could get files from a file system, you were trying to steal data, personal information.
18:21
If you could execute arbitrary code, maybe you were trying to steal data as well, or use the server to launch further attacks elsewhere, or to further explore your infrastructure. But something new that started to come out is this idea of website ransomware. Now you've probably heard of ransomware, the normal kind. This is software that infects your computer, and in the background, it goes around, looks at all your files, and instead
18:48
of deleting them like maybe malware used to do in the old days, it encrypts the files with a special key. And it's a key that you don't have. So now when you go onto your computer and try to use it, you can't access any of your files.
19:04
And it pops up a helpful message that says, you know, pay us $100 in Bitcoin or something, and I'll decrypt your files for you. And it's really effective because the price is generally pretty low, and people want their files back, so they pay. So what started happening end of 2015 last year is the technique started to evolve to websites.
19:25
So primarily in WordPress-type scenarios where, you know, it's the Wild West in terms of security, but it's also affecting other apps as well. The ransomware, excuse me, gets in, executes arbitrary code, downloads a payload that
19:41
encrypts all the files on your website, maybe even the data in your database. And when you or your customers view your site, you get something kind of like this. And it says if you want your website back, pay us the ransom. And like before, generally people want to pay. This is actually affecting hospitals and other types of server malware.
20:02
You know, it's a big deal, so just be aware that this isn't just people coming in and stealing data from servers. It's not just your customers' data, it's also potentially your revenue, your livelihood, your website. And now the other type of attack I'm going to talk about is something called credential stuffing, or that's what some people call it.
20:27
And it's similar, basically the idea is some other site gets hacked. Maybe through some technique we just talked about, or some other breach, and the attacker steals a massive list of usernames and passwords.
20:42
Now chances are, and I think there was a study that said it's around 50% of user accounts, are using shared passwords. So the password on your site might be the same as the password in the dump that that hacker just downloaded.
21:01
And they want to know which ones match your site. So what they're going to do is they're going to take that big dump, maybe it's a million, maybe it's 100,000 username and passwords, and they're going to write a script that will go to your website and try to log in with those details. And when they find them, they know those accounts are active and vulnerable on your site.
21:25
And if they fail, it's just a failed login, they just move to the next one. Excuse me. So I always like talking about this case because it's a bit interesting in terms of blame. Whose fault is it? Some other website got hacked.
21:42
You might not be vulnerable at all to these SQL injections or arbitrary code execution. It was somebody else that got hacked. Their website got breached. Those are their user accounts that have been dumped. And it's kind of the fault of the users maybe, like maybe they shouldn't be reusing passwords.
22:01
It's kind of their fault. They didn't choose strong passwords. Maybe they're that 1, 2, 3, or 5, 6 up there. But fundamentally, they're your users, the ones who these attackers are breaking into. These are your user accounts. So it kind of falls to you guys to protect your users as you're developing sites.
22:21
How do you protect them? And this isn't just a small problem. It's not just common passwords like this. These are massive breaches with millions and millions of leaks. There was actually one just a few days ago. I really just pasted this for the headline here. This is a site that would actually help you find out if you were in one of these dumps.
22:42
And then they got hacked. And now there's a consolidated list of, what did they say, 866 million user credentials. So this site has helpfully consolidated them and organized them for whoever got them. So just be aware that this is not a problem that's being solved or going away.
23:01
This was, was it two, three days ago? There's now a new, almost 900 million usernames and passwords out there that might be coming to your site any day. And okay, maybe there's a bunch of passwords from this list that match users on your sites.
23:20
And, you know, is it your problem or is it the user's problem? And maybe you could justify saying, well, we don't really mind if our user accounts get breached a little bit. There's not maybe a lot of sensitive data there or, you know, those users aren't admins, so maybe it's not that big a deal.
23:40
So I wanted to talk through one use case, or one attacker use case, I should say, where attackers are using these types of account takeover attacks to directly monetize the result. And it's something called warranty fraud. And this happened to Fitbit a lot in 2015. The basic idea was they used these techniques, the hackers, they got a bunch of accounts.
24:03
And the first thing they did when they found an account that worked is they went in, they changed their email, they changed the phone number, and they changed the address to point at the attacker. And then they called up Fitbit and said, my Fitbit broke, can you send me a new one?
24:21
And Fitbit wants to keep their customers happy, so they send out the Fitbit before they receive the broken one. So now the hackers are getting all these Fitbits, they turn around, sell them for half price or cheap on eBay or something, and they've now turned your vulnerable accounts into cash for them, which means they're highly motivated to do this.
24:41
So there's always a way to monetize these things. So how do we protect ourselves against these attacks? Educating developers. That's probably why you're all here today. You're learning about security, learning more. There's great resources out there. The OWASP Top 10 is sort of a quick intro to a lot of this stuff.
25:03
It's the top 10 vulnerabilities that cause most of these breaches. And it kind of helps people stay up to date. They can see, they update the list every year, or most years. So new attack types will bubble up as they become more prevalent, and you can focus and learn a bit more about them.
25:21
There's static analysis. Actually the same guy, Justin Collins, writes Brakeman and Brakeman Pro. It will scan your Ruby app and tell you if you've got vulnerabilities. It detects the one I talked to right now, and it also detects the one from 2014. So use these tools to scan your code to try to stop these things before they get released.
25:42
And I mentioned earlier the manual code review, or maybe pen testing. Get other people to try to break your code. It's a good way to get a second opinion, to understand maybe things that you don't know about that someone else does. The big thing I don't like about this list is it's the same list I would be sending out 10 years ago if I gave this talk.
26:08
Everything's really changed here. There's no new defensive techniques that are helping people these days. So this is still good. You should still do all these things, and they help you produce a secure app.
26:22
But then once you deploy it, how do you protect it against stuff happening in real time, or against new threats that maybe you don't know about? There's a few tools that already exist for this kind of active defense. There's a thing called a web application firewall. You may have heard of it. It kind of became very popular when it became sort of a mandatory requirement for PCI compliance for handling credit cards.
26:47
But basically it's a box that sits in front of your app, and you can kind of see. Sorry, it's really small, but you go through every single URL in your app, and you tell it all the parameters that you expect to see. You tell it whether they're mandatory or not, how long they should be, what sort of characters you should expect.
27:06
And you can kind of get from this that it's hard to configure. And the big problem is it's really easy to bypass, because this is a box sitting in your network in front of your app. It doesn't really know what's going on. It's just applying these rules or signatures.
27:21
And there are actual books about how to bypass web application firewalls. So it doesn't give us a lot of additional security. There's also kind of a problem with how they're deployed, really. So you've got your apps down there on the servers. You've got the internet cloud, classic over there. You've got the yellow line, bad stuff being rejected. You've got your web application firewall protecting your app.
27:47
And that's all great if your deployment looks like this. But more and more these days, our deployments look a bit more like this. It's the app is the thing that you deploy. It's not the infrastructure around it so much anymore.
28:01
You write your app. You push it to Heroku or maybe Docker if you're rolling something your own. And you want security to go with the app. And that's where we kind of get into one of the defenses that I'm going to talk about today is this concept of RASP. I've never been a big fan of the acronym, but it stands for runtime application self-protection.
28:24
The idea that it's part of your app. It gives your application the ability to protect itself in real time. And it kind of shifts the story a little bit. It's inside the application now. So we kind of get a bit more visibility on what's going on.
28:43
So if we go back to our attack there, what was the actual exploit that happened in that CVE vulnerability? The vulnerability was that we could convince Rails to load an arbitrary file. But the actual exploit, the malicious intent, what they're doing is they're trying to read files that aren't normally read.
29:07
Or they're trying to execute shell commands that aren't normally executed. So can we hook into that and instead try to stop that, move that logic inside the app? And you can see these things happening directly. We're not sitting outside the box trying to guess what might happen when it hits the app.
29:28
Here's some examples what you can do. I mean, you shouldn't be reading anything from etsy password really. You should only be writing to varlog and temp. It shouldn't be writing some arbitrary places on your file system.
29:40
Your app should not be reading your SSH private keys. Shell code execution. Most apps don't actually need to execute system commands. Or if they do, it's usually in just a few spots. Like maybe you need to compile some CSS when your app first starts up. Or maybe you need to shell out to the command line to generate a PDF invoice or something like that.
30:01
But generally you're not executing shell commands. You're definitely not downloading Perl scripts from Russian IP addresses and executing them. You should not be doing that in your app, right? So can we detect these things happening and stop that? So instead of tracing all the individual and trying to chase the vulnerabilities as they're announced, stop the malicious behavior.
30:23
The same idea applies to those other attack types. SQL injection. We can see the whole SQL query. Can we stop that at the source? So instead of trying to guess at the bad input, look at the full query before it gets sent to the database. Stop that. The same for templates. If we're rendering the template, can we look for cross-site scripting then?
30:42
Authentication. Failed logins. Inside the app we get visibility of all that stuff. And as well, the application, it knows itself, right? It knows which lines of code are running these things. It knows which lines of code are running SQL statements.
31:00
And if you get an SQL statement that looks abnormal, it knows where that came from in your code so it can work with the development team a lot more closely and help them understand where these vulnerabilities are coming from. This is sort of the general idea of how a RASP can work. This is, not all of them work like that, but that's the idea, that you've got your app in blue.
31:23
And then you add the security logic, and it gets a chance to hook into all the various parts of your application. So it can protect against header-based stuff, it can protect against SQL queries, it can protect against authentication failures. And what that lets us do is, if we take our old example of the SQL injection, and we look at some possible inputs, the first one is a good query.
31:52
Most of the queries from that line of code will look like that. So we can learn that structure. Your where clause should have one condition.
32:00
And then when the bad input comes in, then all of a sudden that line of code is executing a query that has two conditions in the where clause, flag that up as an attack. And of course we know it's an attack because it's red and the other one's green. I actually had somebody tell me, why don't you just stop the red ones instead of all this logic, but that's the idea.
32:22
And same for things like the authentication. Instead of just blocking failed login attempts and allowing successful ones, we can start to look at the rate of failed logins. Most of your users, if they forget their password, if they're like me, maybe they might have to try four or five times before they get it right.
32:43
But they shouldn't be trying a hundred times, and if they cross these thresholds, you should take action to stop them. You can do something like automatically serve a CAPTCHA, or just block them, whatever you like.
33:02
So, back to these three types of vulnerabilities. Talk through a few examples. This provides tools for you to address some of these issues, because everybody's writing code, we're all using external code, and nobody has time to write all the code that possibly they should be writing.
33:23
If you can land a rocket on a barge in the middle of the Atlantic Ocean, surely we can make it easier to make websites more secure. Leaving with that, thank you very much.