Hey everybody, welcome back to another episode of the Ruby Rogues Podcast. This week on our panel we have Valentino Stoll. I know. Charles Maxwood from Top End Devs. We have a special guest this week. It is Greg Molnar. Greg, we've had you on before, but how are things in the middle of the Atlantic? Hi guys, yeah, all is good. We are still alive in the middle of the ocean. The island's still upright, so things are good. Yes, yes, yes. Shitty weather sometimes, but yeah, it's wintertime.
I heard a clip not that long ago. It's an older clip, but it was a U.S. congressman that he was interviewing a general or an admiral or something. Basically he was talking about Guam and he said, well, are you worried that the island is going to capsize? And the general with the straight face, right, because they have to have some decorum in there and they don't want to tick off the congressman. He looks at him and he goes, no, no, we don't anticipate that. Amen.
So your island didn't capsize? No, no, no. And the Maldives is supposed to be gone for a few years now and it's still there. All right, well, we brought you on to talk about security in Rails 8. I don't even know where to start. Did a whole lot change, or is it mostly the same as 7.0?
Well, yeah, there are a bunch of things which are 7.2, but I think the invitation was triggered by my talk word which was titled the state of security in rails 8 but some of the things i mentioned were actually rails 7.2 but i think it was still worth mentioning those because a lot of people don't even know about those new like many years old back then. It was released at the conference, so it was a bit of a pre-plan.
so so yeah so where do we start then well i can just list out the things which i was talking about if you guys are okay we can go through all of those and you can ask questions uh sounds good to me so one of the first things i mentioned during the talk was uh every new rails app this is a 7.2 feature every newly generated Default dependable GitLab CI file which means if you are using GitHub. If you are using GitHub, then on your CI automatically run.
which is a vulnerable dependency checks. So if any of the gems you are using has a vulnerability published, then you are getting alert. Sounds good. Well, I was just going to say some people, I think most people know what a Pentabot is, but effectively you get pull requests if you have vulnerable versions. yeah or even for outdated ones that's why i don't like dependable actually i prefer bundle out it but it's basically very similar thing but bundle out it only alerts you about
Whereas Dependable, I think you can configure it. Dependable also alerts you about outdated ones where usually my way of, when I work on a Rails app, my way of handling upgrades is it's like on a regular basis, like every three months. spike update all the dependencies but security dependencies are different security issues are different obviously you want to upgrade them immediately but the rest i don't really out if it's just a non security issue I will have ready
That makes sense. I do the same thing because a lot of times your upgrades, if it's a major or even sometimes a minor version, it changes the API, right? It's not just...
Oh, hey, you're going to upgrade this and you're going to get security goodies, right? Now, you may have to pull a major or minor upgrade version because... because there is a security issue and they didn't fix it in the version you're using, in which case, yeah, you have to go through the upgrade rigmarole and update your code as well as... the gem. But yeah, I'm with you. I tend to tackle those things when I feel the need, right? So sometimes legitimately it's like, hey, there's a new feature.
But if it's the older version... how do I put this? I've been having conversations with people about AI in programming, and it's like, hey, look, it makes you more effective in all of these different ways. And a lot of people are asking, is that going to replace programmers? And I'm like, have you ever worked on a project that ran out of things for you to work on?
And the answer is, you might have had a side project that you decided was done, right? And so with this, it's the same thing. It's like, okay, until it's a real high priority, there's just no reason to do it. Yeah, it's funny. I've been trying to push people to just like bundle, update, patch.
on like every deploy. Cause like the chances of something going wrong in a patch release is like so low that like you've gained so much more by like all of those security enhancements and like fixes in a patch level version and it's almost worth just like doing it if the test pass right like yeah So what does Bundle Update Patch do? Because I've used, like, the pessimized gem. that locks in your version, right? And lets you upgrade.
Yeah, so bundle update tool, it has a way to give it different flags. So it's a canonical version, all the Ruby gems typically are. So as long as the gems your independency is using are canonical, meaning that... a patch level, a minor and a major version to it, then you can just say, okay, give me only the latest, you know.
patch updates uh and like i feel like as at least for like everything that reels would touch like the gem maintainers of those are very careful about what to release in a patch version issues because like they don't want to deal with all the issues that come from that right like if somebody being like oh hey like i have like this new like obscure thing like they would rather just like okay let's make it minimal and then you know in a minor major version
it's to be expected, right? We've outlined these things, it's gone through the process. But a patch version, like, it's like, hey, we fixed this thing as serious, like, you should really integrate this. Right, so if I have in my gem file just Sidekick, and I didn't specify a version, and there's a major version update, I can do bundle update with the patch flag, and it'll just... to the highest
and it won't do a major version update. It won't even do the minor, right? So it'll keep it. If it's like 3.2, it'll do that, and then just bump it to the latest one.
To be honest, doing that with Rails may be a little trickier because it does like... Yeah, Rails is funny. It has so many patches that get released, so if you fall behind... But that's why you're like, if you're deploying a lot anyway... right like then like getting rails to update itself incrementally as it gets updated at a patch level is not going to be so bad uh and a lot of times you know if you have a good test
you know, let's hope everybody does. But like, if you don't, like, obviously, maybe you don't want to build this into your deploy process. But like, if you have a good, like, test infrastructure, like... doing a patch update like it's gonna be almost nothing and you'll catch most of the issues What about applications? What if they deprecate things in a... I know actually they shouldn't, but sometimes they do, and then your logs are littered with all...
Right. I mean, personally, I would rather have it be secured than like. you know, worry about all the verbosity of the outputs, right? Like, I feel like, you know, yeah, littered logs is not great to deal with, but like, it's honestly better than the alternative of having like a security hole. And then like getting like, you know, pager duty in the middle of the night, like, hey, somebody took advantage.
starting incident response right like yeah but that's why you should use bundle audit or dependable with the security updates because then even though it's a patch release you are notified that this is an input Right. Yeah, so I'm curious what your thoughts are there. Is that the best approach still today, is using the audit?
feature uh like what does your workflow like look like for that's what i use it's running on ci and it's running also in And then it's just you on the divide immediately and also see a lot of people when they forget is they set it up to run on the match request or pull request githose they use but they don't run it daily on on the master or main branch which is if you don't deploy every day if you don't match requests every day then you might not be notified
So it's a good idea to, actually the way I set it up, if I had the chance to set it up anywhere, run it twice a day on the master branch and run it on every pouring. because then you are notified anyways also like weekends so if it's on a weekend something on a Saturday you are not getting notified if you only write on poor requests right and it'll fail the bill
if it doesn't pass the honor, right? Yeah, and if it fails on master, but you are not expecting a build, then you will get an email notification or whatever. Makes sense. I'm just waiting for the day to have like, you know, Rails autopilot. Just automatic. But like, if you have like a bunch of hobby projects that you just like, oh, like I'm not going to spend any time on this for six months. Like, just like automatically merge any updates as it comes.
resolve itself like i would love that and then just come back and then you know if when i'm ready to work on it again at least it's up to date and i can like resolve any issues that there are right but you know every single time i go back to a hobby project i'm like shit, I can't spend any time on this because I've got to spend the time updating it. And then I lose that, like, you know... You should... I think it depends on what does it, you can sell it to Automatic. I think you can, yeah.
for patch level and maybe you can do it for minor, maybe you can do it for every level, I don't know, but you can do it for sure. And then yeah, it upgrades everything, things might break because... Right. You might not carry it with a test, but... Right. I don't know, I don't- Maybe it's just me that this is why I also don't trust- I trust humans more for some reason. If there is some human oversight, I trust that process like an order of magnitude more than if it's just something holy.
Yeah, I think it's getting better. Yeah, I've been liking the review process, so like automate, but review. So like, you know, where they'll just like set out a plan and then like, okay, I executed all the plan and then notify you, okay, review this. I did these things, right? Right. And then if you do like decide not to review it, like, okay, well that's... the same as like working with a coworker that did the same thing. Right. And you didn't review it and they did it anyway. Right. Yeah.
but also from a human i expect more than from so with ai my my issue is that i write a piece of code right i ask him can you refactor speeds back a bunch of changes which I need to review And if I ask a junior developer, can you work on this feature? They work on it, they submit a pull request, and if they are uncertain about some things which they did, they will highlight. Here is my pull request, but I'm not really sure about this part. Can you review that more thoroughly?
but AI doesn't do that it's confidently says this is the solution and they were like okay it's like 50 lines of changes You bring up a great point. Maybe what we're missing is a junior AI.
right like that hasn't programmed in i am not confident i don't know what i'm doing and uh then it can you know be maybe a little more cautious uh i think you're on to something Or wait what it gives, because it can be confident about some parts which are like basic or it knows it well, but if you are a little bit uncertain about something, highlight that so I can reuse. Yeah, the issue that I run into, though, is that a lot of times when I get back...
i'm not confident that a it would flag the right things or b that a lot of times i get code back that it's like it's like Yeah, like the general structure as far as like, I have to loop over these things or I have to make this kind of a request or, you know, call into this API is generally correct. And then the rest of it, it's...
It may as well have written pseudocode, right? And it's like you guessed at the method name instead of looking it up, which a human would do. They'd go look it up. How do I, whatever. Anyway, we're off on a tangent. I want to get back to security. So the petabot is in there by default. You can use bundle audit if you want instead and put that into your CI. What else do we get?
Another change which is really similar is Brakeman. It's also got a default CI file, so Brakeman is a static code analyzer for security issues. It basically highlights code spots where you might do something which is insecure. I think that's also a great addition. It gives you false positives. You can ignore those, but it at least makes you aware of certain things and saves you from silly mistakes. It's so easy to make a silly mistake.
don't realize you use an insecure, an API insecure way because. it just saves you from those I think that's also great. The thing I like about Breakman is that, yeah, it gives you false positives, but... Like all of the commonly understood bad things you can do or the traps that you more easily fall into, it's got all of that in there. And so, yeah, I might give you a false positive and say this is insecure and you look at it and you go, no, I'm not doing what you think I'm doing.
But it catches the really easy dumb stuff. Yeah. Yeah, definitely. And the next one, which is a new feature in this, is the rate limiting, the built-in rate. I'm sure you guys heard about that one. I'm really excited about this. I don't know how many times I've built rate limiting. I've got an app that I want to build. to replace a process we went through last year.
stuff but letting people register for our caucus night in utah we get we have like 900 000 party members that are eligible to attend our caucus meetings and we got last year by somebody who doesn't like the party. And so I'm wondering if something like this will help. It could help, but it might not help. For a DDoS attack, I think you would need something like Cloudflare. That's what I'm serious about.
so for for what this one is good for the thing this one is good for rate limiting is save you from credentials you know when there is a leaked password database and then a malicious actors will try to use all of those login details on your site. Oh, I gotcha.
And in my talk, I highlighted a few examples from, it's actually now two years ago, from 20... three it was the year before like 23andme the dna analysis side they had an issue with this also general motors had a big issue they had a bunch partial credit card details leaked and Roku the streaming platform also had like half a million of their users access details were leaked because of a credentials stuff So I think this is a very good addition to this to prevent all of these issues.
It's a very old jam, but a lot of people don't know about that. And this is why I really like these changes in Rails, because once it's in Rails core, a lot of people are becoming aware of these issues. and it might not be the best for that team or that person, but at least now they are aware, oh, I need and then they find a solution which works for them. So is this in Rails 7.2 or is this in Rails 8 only? It's in Rails 7.2. It got some improvements which only landed in Rails 8.
And it's really simple, you add a single line to your controller you just set the two parameters, which is how many requests you want to allow, and you set the within, which is like the time frame, let's say you want to allow 10 requests within 3 minutes from the same user. that's it and then you have rate limiting you can also configure which actions you want it to be called it on it's like a before filter in the controller you can set if you want to exclude
only certain actions. You can also configure a custom response because by default it raises a 429 header and then you can change that and just or whatever you want to do and also another important thing to mention initially when the first implementation used redis but then it's been rewritten and now this storage the backend is any real can work. So you can use the solid cache or whatever you want and you don't need to have Redis as a dependency.
I love all the moves away from Redis. The storage patterns across the board are just really great to see it become more cohesive. I really like this byline too, where you can give it a proc and say like, hey, you know, rate limited by IP or whatever you want to filter. Yeah, if you would want to have something like Cloudflare, you could achieve that. a cookie and then you will race limit by that cookie and then you can handle more propeller.
otherwise if you do it by the ip adidos is usually they use a whole range of ideas it's one client so if you set a cookie on that client then you can identify it's the same client Yeah, I'm liking where this is going, for sure. I think Cloudflare is probably the best answer for what I'm looking for. But I like this to manage your credentials. Yeah, my only problem with cloud- cool it's a matter But I think now they are swallowing a big part of the internet.
maybe one day they will say okay now we are greedy an extortion amount on everybody let's hope they never do this but it happened before and they might say yeah now we want all the money and now you rely nowhere else to go all the small competitors are gone and they need to pay us a lot but let's hope they are not going to do that Cool, and so the next thing I mentioned in the talk was the new authentication generation.
Yeah. Well, we had another one before. It's called Authentication Zero, which is in Rails. It was done by... I forgot the name of the guy, he's a Brazilian guy. I probably can't even pronounce his name properly. Lazaro Nixon, I think, or something like that. I'm sure my pronunciation is not correct, so sorry for... Yeah, but it was an awesome project. yes it's still it's still a great project and it does more what the built-in
a generator, but the thing is, even though that generator was there, other people don't know about it. Now that Rails has a built-in one, a lot of people are aware, oh, we can have an authentication generator, and they might say, the built-in Rails one is not for me, but they... other one or other alternatives so this is why i love getting these features into rails and on the built-in one in rails doesn't have registration
it doesn't have a few few features which you would expect from an authentication flow because i think the reason for that is the core team believes that they are custom for usually like sign up it might it's very So they expect you to implement that one on your but this authentication 0 for instance it generates all of the
If you are into a fully-fledged, you just want your own code, the code to sit in the repository, but you don't want to write a line of code, I think that's a better option. If you want to have something custom and use just a real... stuff, then go with the built-in Rails one. Yeah, I'm working on a generator of my own that will generate the views.
generator but yeah I mean just it's it's basically I would like to build the tool build things that run on top of the built-in rails generator because I think it does a really good job. I'm curious here. I love your insight, Greg. I know it does passwords as the default for the gen. How do you feel about, you know?
passwords with users like i know there's a lot of talk around this like doing a password list pass keys for the future for a bit like you know where where do you see like the industry like coming together or is it still kind of like a little bit Or the OAuths. That's the other one. Somebody else is managing your credentials. Like Apple or whatever it is. You have a token from them and you authenticate them on the token.
Yeah, well, in both of those cases, I think I might not be the mainstream with my opinion. So for pass keys, I love pass keys. I use a YubiKey for two-factor authentication. I think it's amazing for that. For that you can have multiple options. For instance, I have a YubiKey, but I have two laptops. Sometimes I don't have my YubiKey.
And I have two UbiKey's, but I keep one as a backup at home. So that's not in a laptop. That's just if mine breaks, I can use that one. So I have multiple authentication. I can use my phone in the app on my phone, or I can use the UI key, which is much easier. But for whole authentication, I think there are a bunch of things which are not so easily resolved. Like what are you doing with logging in on your iPhone and on your...
with the same passkey because you can't really transfer it between devices. You can if you are on iOS and Mac with everything. It's amazing. It's fine. It's convenient. Everything is in the whole ecosystem. But what if you have an Android? it's not so easy to transfer your credentials between different services. That's my main problem with passkeys. It will be probably solved eventually in the future, then I will be all for passkeys, but since then...
Easy. Yeah, one thing that I'm wondering along the lines of what Valentina... is that it seems like when folks' credentials get compromised, it is the password, right? It's, hey, here's a username and a password that'll get you into the web. So do you favor more passwordless options? I mean, that's what the passkey is, but you've also got like...
hey, here's an email and we're going to send you a one-time password or any of that, is that any more secure or is that just an illusion? In my opinion, no at all. Because if I get access to your email account, I have the keys to all of your accounts. But usually so, it's not that clear because also if all of the sites you signed up for support a password reset by email, then I can also take away yourself, right? So I think the solution for all of this is multifunction.
Because even with Peskis, what if my laptop gets stolen and stolen in a state when it's open? And then they have access to all of my... usually this is why it should be something you know and something you have access to because my one password shuts it down after five minutes or whatever so if someone gets access to my lockpot they can't get access to my passwords they can access to my ubic
the laptop but they don't have the password so I still have two things which they can only get one of them same with the email once someone has accepted the email your account but this is true if it's only password so just passwords on your own good enough so the other piece of this for me is How do I put this? I'm super cheap. And so like Riverside, for example, right? I could set up.
account for every single one of the hosts to be able to start the podcast but realistically that's a lot more expensive than setting up you know a couple of generic hosts But then, you know, how do you set up third-party authentication for shared account? or two-factor authentication for shared accounts. That's been the Rob, right? And so I tend to not turn it on and then essentially just trust the people that I've shared the password out to. You can do that!
I'm working on something with a team where we have the same problem and the way we solved it. You know, if you set up two-factor authentication with an authenticator app, you just need a seed and it generates a token base. we have that saved and whenever we want to share that 2FA with someone, he gets deceived and he can have the same setup on their phone. And then you have the same authenticated setup of multiple devices for multiple paper, so they can still have the second factor.
That makes sense. That's really cool. That's been the piece that I've been missing is, yeah, it's like, okay, how do I share the second factor of two factors? Or you can go down the other way, which I don't recommend, but it's quite popular. You use something like 1Password, where you can share... That's essentially what I've been doing.
My problem with that, then it's not two factors because you have the password and the second factor at the same place. So if anybody gets access to that one, they have everything they need to log in. I like to separate the factors. Well, that's the whole... Anyway, I may have preempted other questions from Valentino, so I'll let him keep writing that. On the topic of outsourcing your authentication, I don't think that's a good idea. Actually, the Q&A, somebody asked me about this.
And Okta is a very popular service for outsourcing and authentication. Okta and Auth0, but Auth0 is owned by Okta. Yeah, so they had breaches in the past, and they just had a breach after my conference talk again. Not a breach, but a security incident, but they had a proper breach a few months before the conference. And I think, yeah.
I kind of like the approach, like, single sign-on took in that it's like, at least there's a rollover approach, right? Like, okay, if you've been identified of a breach, like, you can invalidate everything. If you use a password manager and you have unique passwords everywhere, if you are in a bridge, it doesn't really matter.
That's true. And my problem with Okta is their attitude. I think even though they are a security company, they are more money and profit oriented than security oriented. That's what I see from their behavior.
opinion but that's what i i see and i think they they care more about And you can see that from the sacred issues they had in the past because some of them is I don't want us to be rude or just because everybody makes mistakes, but some of it you wouldn't Yeah, I will say, so when I started building Top End Dev... I had two problems. But a couple of the problems came into if they were down.
was one. Right, because nobody could authenticate. The other issue that I ran into was it was way more complicated than just allowing people to have or building my own. These days, I just roll my own. I use the right...
put what I want on top of it. And so it was just overkill. And then the last issue was... I mean, literally any time I had any kind of problem, like, yeah, it wasn't just the complications and it wasn't just that I was down when they were down, but there were some other issues within just the way. I had things set up and it was easy to fall into those problems and it affected every And sometimes if there is an issue, you can't resolve it because it's out of your hands.
But they do a lot of things for you, too. So, you know, they do some level of authorization. They'll handle the third party like Google. Facebook, you know, whatever, whoever you want to let people log in with GitHub, like they do all of that. And so you don't have to go and jump through. There are reasons why people go for it. They're probably a little bit better at security than you are.
as you're pointing out, Greg. Yeah, you may not know the issues that they actually have because you're outsourcing it and trusting them instead of being in your own system where you can audit and verify it. Exactly. Anyway, I see people use it. They seem to like it. But I think it's for those bigger apps where you're really looking for that enterprise-level set of features for the things that I was doing. It just didn't make sense.
Yeah, I also think it doesn't make sense for most organizations, but probably it does for some. But even then, I wouldn't go with Okta for sure. I haven't heard of Auth0, which is probably a good thing. Probably they didn't have any branches. Yeah, but Okta acquired Auth0 like three or four years ago. It's more like... But for me, and I think this is what you're saying too, is do your due diligence if you're going to pick one.
and make sure that you know why you're going that way as opposed to... And one more thing I wanted to mention about the Rails authentication generator is the reason I really like this one because Rails has a bunch of helpers which people don't know about like HasSecure all of this new secure token generation
Oh, those are so nice. So I'm going to back up for a second because I love these. So I use them for all kinds of things, right? People think, oh, I have a secure token generator that's, you know, so I'm going to put it in. My cookie is some kind of... I'm going to use it for this other auth and that other auth. But you can generate keys for anything. And so I've been using it. I'm trying to get to the point where I'm running my own premium podcast.
like, hey, look, if you donate to the show, you'll get ad-free stuff, right? And so you can generate tokens for that. You can generate tokens. Anyway, I don't mean to derail, but this is a really, really handy feature. If you need something that's not guessable, then this makes it really useful. and verify it is just built in it's just super easy Yeah, and I think that's why it's good because you generate your authentication system and then you read through the code and you learn...
Oh, this helper has never heard of this. I think this is also why it's good to have this. It just raises awareness of certain Rails helpers and features which people wouldn't know about otherwise probably. And then the next thing I mentioned in the talk is it's not really a technical change, but it's an important change is Rails has a new maintenance policy.
which is uh i need to read this because i can't say tell it from the top of my head so every minor releases will receive security fixes for two years after the first release in its series which means in practicality if 1.1.0 is released January 1st in 2023 it will receive security fixes until January 1st, 2025. After that it will So I think the maintenance period became shorter, which means that everybody should take upgrades seriously and don't stay...
because it's not going to get security updates. They make exceptions sometimes, but you shouldn't rely on that. In my opinion, you should make sure your apps are up to date. Yeah, I think a lot of things have changed on that front too, though, because I've worked on a handful of apps for clients where... And those upgrades were often rather painful for one. And the other thing is that... It was kind of a giant thing and you had to take it off. you know, the maintenance cycle on things. Anyway.
Lately, with everything past about Rails 6, Rails 7 for sure, like the upgrades have not been near... And so, you know, you're mentioning the maintenance cycle and, hey, this encourages people to upgrade. Maybe you have a different window to get security patches and stuff like that. But the other side of it is that I have a whole bunch of Rails 7.2 apps. upgrading to Rails 8, and I've kind of...
a couple of patch versions to come out, right? So that whatever issues everybody else is finding, good on you folks. And I really appreciate the work you're doing. And, you know, and then I can go pick them up. But yeah, from what I... 7.0 to 7.1 to 7.2 to 8. They really haven't been that bad. And so, you know, it's okay. I'll spend a few days on this or a week on this. If it's a really big...
It's much better. I did Trails 2 to 3 upgrades as well. 2.3 to 3. That was a big pain. 3 to 4 was a little bit easier. 4 to 5, a little bit easier. From 5 on... much easier except when you go real estate you need to ask yourself the question what am I gonna do with the front Are you gonna keep Vepa care or are you killing it? Because then it might be a bigger change.
By the way, prop shaft. My first Rails upgrade. Yeah, prop shaft. Prop shaft and all the stuff that's there, the way that Rails 8 and Rails 7 too. handles the front end stuff. It is... I don't miss Sprockets. I don't miss Webpacker. When I moved off of Webpacker, I want...
because it was so much easier. I mean, the issue with Webpacker a lot of people had was just setting it up and knowing how to do it. But I found myself having... prop shaft i've just kind of set it and forget it it's been really cool and the build step is always like yeah something fails at the build And it was just slowing things down. I also didn't like that. It's funny, you don't realize how stable Rails and Ruby goes.
uh because i mean i'm going back like to you know upgrades like you know i was thinking of my first rails upgrade i did like a rails one that was on Ruby 187, which was like a nightmare Ruby to upgrade. Because there were just so many drastic changes, right? And so I don't think people realize what the early stages of a framework or a language are, right? Cause like the stability that we get now, like.
mind-boggling right like you know yes there'll be some deprecation warnings or things like that or like you know the big changes like are really not that big in like the grand scheme of things right like if you look at like some of the other libraries out there you like
you know the whole like back end could get swapped out and you'll be like well what do i do with all this stuff i know like yeah yeah you know uh it's like incredibly stable now so it's it's just why Yeah, and for the record, when Greg was talking about upgrading from Rails... That was when they merged another framework called MERB Interest. And so there were just major, major changes. I mean, a lot of stuff got a lot better, but the upgrade...
Active record was pretty much that's a shout out to uh to macandra who like maintains the rails art lts uh if you're like honestly if you're out there stuck on a rails upgrade and it's just like not worth it for to your business like just pay the service rails lts and long-term support and just like they make sure that like yeah they give you security patches Yeah, we used that for a couple clients a long time ago, and it just works incredible out of the box. It's turnkey.
Yeah. We have to get them on and ask them how that all goes. They've been around so long now. I'm sure it's tricky sometimes. I'm sure it's very tricky to solve issues. I wouldn't want to be in their shoes. Yeah, but at the same time, I mean, it's got to be really, because I just went to their page, and they have LTS versions for Rails 2. And so I'm going, boy, what are you having to say?
you know and then how deep into the weeds do you have to get yeah but from a security perspective i think it's still risky to be on that old version because nobody really So there are no security patches or security issues made public. There might be some non-public ones which people might abuse.
you just don't know about them so I think it's because like the latest version of rails a lot of companies who are using rails gets bad are upstreamed from the reservoir to a penetration test they find an issue it turns out oh it's actually an issue inside of rails so we upstream this Yeah, that's true. But those old versions I think are not a good idea to use even though you get some support.
Yeah. And then the next thing I mentioned in the talk is a pretty small change is that CVV and CVC was added to the parameter filter. But the reason I wanted to mention that in the talk is because a lot of people don't know about the- is a very handy tool to filter out anything sensitive from your logs. Like you know, when a request comes in with a password in it, you don't want that to show up in your log.
social security numbers you don't want them to show up in your logs before you encrypt them and this feature is just amazing for anything sensitive which you don't want to be in the logs you can just add it to your initial These are the things which I also think Rails excels at, because a bunch of other frameworks don't really have an easy solution for this problem, but Rails is just out of the box and for years, it's amazing. Yeah, I did have this bite me in the rear end once.
But, yeah, I agree. The way it bit me in the rear end was I had a stripe webhook key that for some reason wasn't being set. and it still showed it as filtered and so i didn't know it was empty until i actually like forced it But yeah, this is definitely a best practice. And if you get into like HIPAA. What's the financial one? PCI or any of these? They will crucify.
And the logs are usually an area of vulnerability that's overlooked. Yep. And Rails does it by default for all the common sense stuff. Yep. And then the second half of my talk was, these are the new features, which wasn't that many, to be honest. But still, there are small progresses, and that's all. The second half I wanted to highlight to people why I think somebody should choose Rails if they need an application.
And my main reason for that is there is a tool for everything you would need in the Rails and Ruby ecosystem, like parameter filtering, which we just mentioned, built into the framework. Authentication, you have device and a bunch of other things. It's super easy to implement all of these features. Cross-site scripting stuff. Oh yeah, cross-site scripting. You don't even need to think about it. Actually, cross-site scripting you need, but cross-site request forgery.
just built it to the framework for I don't even know which version, like Rails 2.0. Yeah, it's been in there forever. Yeah, so we have a lot of things which you just get ready for free. and other things which are not yet If you're talking about compliance, one of the requirements to be SOC2 or ISO compliant is that your developer... shouldn't access anything in production without you knowing about it so if you have a rogue employee it's not like they
still whatever they want, usually they can, but at least you have an audit log, so you can pinpoint who malicious actor and there are there is a gem from 37 signals called audi console 1984 which is if you install that anybody who goes to the rails console so they need to say who they are and why are they accessing the data.
production data an audit trial one important thing to know about this, though, is it's advised to store this data in a read-only database, sorry, a write-only database, so nobody can update the data. rights but you can't update otherwise if somebody wants to be really tricky Ruby is very dynamic, so they can find a way. I found a bunch of ways, but now it's much more secure than the initial release was. You can find a bunch of ways to trick the system and override.
If you store it in a database which is only, you block update commands on the database connection, then it's pretty secure and safe. When did they change that to write only? That's really awesome. Ah, they didn't change it, you need to change that on the database. Yeah, you can't build that into the gem because you do it on the database level. If you build it into the gem...
You might still find a way to override it in Ruby, because it's a super dynamic language. You can do things which you wouldn't even think about. That's how I found a bunch of things to bypass it. But yeah, that's a really good tool for compliance reasons. Also static code analysis, there is brake mender. Vulnerable dependencies, we just mentioned. Bundle Audate, Dependabot, and probably there are others as well. CSP, Content Security Policies built into Rails.
So you have a tool for every security required Encryption. Active record encryption. It's really easy to do now. You don't even need to think about anything cryptography. It's just you set your keys and you are good to go and everything is encrypted in the database. The only thing that's missing is secret scanning. Secret scanning? You mean the repository? Something like Truffle Hog.
As an example. Yeah. Well, but you should do that on the repository and there are services or there are tools for that for sure even in Ruby. I don't line it from the top of my head. How do you feel about storing encrypted Rails secrets in a repo? As long as your master key... with quantum computing we might get into trouble in a few years but until then we are fine and safe and then we'll figure out how to have to solve it i'm sure not us but someone who's good with cryptography
But I think that's perfectly fine, you just need to make sure your master key is safe and secure. Right. And it also simplifies the whole process. You can use environment variables, but then how do you handle that during the deployment flow? How are you gonna pull those from secret storage? A lot of that I've just been doing what Kamal does, so it just sticks it up.
Yeah, Kamala has good integration with 1Password and other secret storages like Bitbucket. Yeah, I haven't used any of that because I'm the only one that applies. If it's a team, it gets a bit more complicated, but still, it's not hard to solve. Do you have a security checklist that you run through for Rails apps that you make sure all these things are...
Not really, to be honest. When I do a penetration test, I have a checklist which I go through, but it doesn't really depend on a Rails app. I have some Rails specific things, which I know it's a Rails app. this and that but a lot of it is only in my head to be honest I mean, to that point, you know... Rails is pretty secure out of the box. It's not exactly difficult to break that, but it's not easy.
I feel like with the Rails new, it's going to be pretty hard to do something insecure until you start. adding new things yeah most of the vulnerabilities i see are now it's it used to be xss and it's still i would say that's kind of the second but the top one nowadays is authorized because it's super easy to make a mistake to forget to authorize some endpoints and then it can be I think if you are talking about a basic level of security, make sure you're authenticated.
make sure your authorization is secure, and then make sure that there are no accesses, and that's pretty much it. The rest, like SQL injections, really hard to have a SQL injection issue in Rails now. 80% of the APIs in active record are safe and secure. And for authorization, what I always recommend is use a whitelist. because it's always better to have someone complain about not
to, then realizing, oh shit, somebody has access to something they shouldn't. Right. Because then you need to report that to your... Well, one thing I'm curious, I know we're short on time, but I'm curious to get your thoughts on one common pattern that Rails has embraced has been this restful resource. like targeted by ids and like part of the problem with that is this like guessable because they're like sequentially ordered id
Do you feel like Rails is overdue for a new pattern there? Or is it not worth the effort to try? It doesn't matter, even if it's guessable or not guessable. I found authorization issues with the UI. because they are not secure. They can be guessed, they can be brute-forced, and they can be leaked. That's the most common thing, that you have UIDs and you think, oh, it's safe, we don't need authorization, but somewhere in your API, you leak. the UIDs and then people can just find them and
Security through obscurity, huh? Exactly. You should have authorization. That's why I actually think numeric IDs are better because then it forces you to think. If you're like, oh, it's hard to guess, we don't need authorization. Yeah, down the line, you will see for sure you have issues. Well, the other thing is, is that typically you're going to see your authorization at the controller level.
And so if you've got good tests around either end-to-end or controller tests, you should be able to pick up... Person has whatever it is that credential. or something, right? You should be able to test that and say, okay, I, with reasonable confidence, running my tests every day or, you know, whatever, twice a day or, yeah. or every time I check in, right, I can say with reasonable confidence people don't have access.
Yeah, but you can still make mistakes. You can. And then you forget to add authorization to that. I found an issue recently. They were doing authorization, the same endpoint could fetch one record or a list of records. So they were expecting either an ID or an array of IDs. And they did the authorization on the... So what you could do, you could set the ID to something which the user has outright. and you can set the IDs in the same request to something they don't have.
And then because it thought, oh, it's only requesting one item, but actually it returned all of the items because it also sent the second parameter, the authorization check was successful, but you could still... It's an easy to make mistake, to be honest. Yeah, I guess what I'm saying is for kind of your baseline stuff. if you're testing it, you know, but yeah, you're right. If, if your strategy isn't well thought out and your test only tests that your strategy were.
This is why I think gems like Pundit is really useful, because with Pundit you can turn on a feature which will erase you don't call the authorize, I think it's called authorize the method in a contract action. So it forces you to have authorization in every endpoint. And if you don't, then you might make a mistake and it will warn you. And also you can do a whitelist approach easily with that one. So nothing can be accessed by anybody and you explicitly grant access to certain records.
for certain conditions. Alright, cool. Well, is there anything else you want to make sure that people know before we do our picks? I think that's it basically. Reels is still a great choice for security, in my opinion. But still, you need to be aware all the time. because it's easy to make a mistake, nobody to blame for that, we all make mistakes. All right, well, let's go ahead and do some picks. Valentino, you got some picks for us?
Oh, yeah. So I was at the last New York City Ruby AI meetup and happy hour and demo night, which has now been consolidated into a nice artificial Ruby event. So I gave a talk on a project I'm working on called RubyTuner to try and fine-tune an LLM specifically for Ruby code generation. I have this whole framework built that wraps Python basically to start with the idea of over time moving it away from Python as the new Ruby features start to become available.
And so I showed showcase kind of like the whole process end to end of fine tuning a very specific contrived example of turning a URL into Markdown and then getting So it was a lot of fun. There's a new event in March I recommend people signing up for at artificialruby.ai. And check out Ruby, too. And then just like something really fun. And because I always share something very specifically AI.
Peter Cooper has been diving deep, and he runs the Ruby Weekly. He shared this really fun and kind of hilarious... I... prompting strategy for Basically creating a group of specific... authors of software so he has like paul graham and uh linus torvold and david hannimer hansen and like of made personas for each of these characters and then got them into a prompt to like argue over a very specific implementation strategy at a very detailed level.
And he shared the prompt that he used for it. And it's kind of fun to play with this. And it brings in kind of like a combination of mixture of agent or mixture of experts. as well as like plan and execute, like combination of those two. It's just like really fun to see, uh, that kind of stuff evolve and like see a panel of judges, judge things, uh, in a simulated way. Uh, I recommend. It's just fun. That sounds...
I'm going to go ahead and throw in some picks. So first of all, I do a board game pick or a card game pick. This week I'm going to be picking a card game. It's called The Gang. It is essentially... It's Texas Hold'em Poker, cooperative Texas Hold'em Poker. So what you're trying to do is you are trying to... Sorry, I'm trying to... So you're all playing Texas Hold'em, so you have two cards, you flip over the river, all that stuff, right? That you normally do, right? So...
And then what you do is, once you have your cards, there are tokens out. There's one for each player, right? So if you have five players, there's a five-star token of four. And so what you're trying to do is there's no bluffing in this game because what you're trying to do is you're trying to get the tokens to the right people. So the five star token is with the person that wins. And the four-star token is with the person.
third fourth fifth uh we played it with three players so we you know it was just you know three tokens um so anyway so you grab the token that you think you deserve And then somebody may say, no, I think I have that right. And so usually it's the top one that gets passed around a lot in the bottom. So it's like, you know, I look at my car. pocket cards, I think is the term, right? I have a two and a three. I know that I'm, you know, I'm probably not.
But as you flip over the river, maybe you flip over a two and a three. So now I have two pair. Now I have a good hand. And so, you know, then I may be more aggressively grabbing the top or next to top. You know, and so, and you can't talk about what you have, but, you know, so if somebody has, you know, three of a kind in Kings, right, they may more aggressively take that five-star token back.
but I can take it back from them and they can take it back from me. And so then I may be looking at it and going, well, I have two pair, but they're kind of crappy pairs. So maybe they do. And then as you flip over cards, every time you flip over cards, you put more tokens out. And so you can see where people are changing.
And so a lot of times, right, you'll flip over a 10 and somebody who was kind of not sure where they were all of a sudden is really aggressively saying, I should get the top one. And it means that. my hand went from having nothing to having a pair or something like that. And so you're kind of trying to read the table and figure out what it is. And the way you win is you get three.
Or not three in a row, but you get three correct before you get three incorrect. And that's pretty much it. And then there's a deck of cards, and we only played with a handful of these. But there's a bunch of cards that put restrictions. So maybe it takes away a round of tokens where you would get more. So anyway, it was a lot of fun. The Gang, Board Game Geek, has it as a weight of 1.64. So it's pretty approachable for most gamers.
I think my kids, I don't know if I'd play with my kids just because I'd have to explain poker to them. And mostly it's that I would have to, like, you have to explain the statistics and why this hand beats that. how to figure out, right? So anyway, that's where it gets complicated. And then recognizing I have a straight or I have a flush or I have, you know, whatever. So anyway, fun, fun, fun, fun stuff. We played it after it was readily.
By the way, go birds. Anyway, so that's my pick there. And then the other pick I have is I'm pretty aggressively pulling together Ruby Geniuses. I have meetups. starting on the 25th of February. We're going to be getting into all kinds of stuff. There's going to be a book club at the end of March, and we're reading the O'Reilly book. prompt engineering for AI. You know, so just diving into a whole bunch of stuff. Basically, it's meetups.
I'm going to set up a Discord channel for each of them, right, so we can collaborate with that. You get discounts on summits that I'm putting together, right? They're not doing RubyConf this year, so I plan to put on a summit about when they would do that. have people show up and speak at that. You know, so just stuff like that. I'm trying to think because ultimately... I guess the other thing is if you sign up by the end of the week, which means...
I guess people didn't go live. So anyway, um, I was also offering, um, if you had questions, you could text or send me a voice message and I would get back to you and you would get that. But anyway, so yeah, so it's the book club. It's the meetup. the collaboration with other people, just the ability to kind of get feedback on what you're doing or get help when you need it. These are the things that really came through for me when I was a newer programmer.
What I found is that even as a senior developer, I'm craving that kind of interaction anyway. And so, you know, getting a bunch of people in and, okay, what? And then finally, I'm also lining up some of the meetups are going to be with people that are on the show. Right. So, you know, I've asked some of our past guests to do them and we're going to start doing some of those.
The first handful, I just wanted stuff on the calendar that people were asking me for that I could teach. And that way I didn't have to worry about whether or not I could fill those meetups with other. Yeah, we're going to have a lot more of that because there are... Anyway, you can go get it at rubygeniuses.com. And, yeah. Greg, what are your... I have two picks. One is a gem called Pandit, which we just mentioned, because I think it's really good to handle outright.
good help and it helps you to solve a bunch of issues easily. So that's one of the picks. And the other pick is a bit of a self plug, which is I'm working on a course for almost a year about security for Rails developers. And now I'm close to getting it ready. already on pre-sale. Once I record the video, it's basically written well. Hope it's gonna be useful for people to learn more about the caveats of security things in Rails.
Cool. Where do people find it? Just go to my website. There is a link somewhere on it. I should put a banner on it, but you can find it on my website. There is a link. bank.model.io All right, cool. We'll put a link in the show notes too, and that way people can go and keep an eye out for it. Great, thank you. Yeah, thanks for coming. Thanks for having me. It was fun again. Yeah. All right, well, we'll go ahead and stop here, wrap it up. Until next time, folks. Max out.