The Laravel Podcast

Matt Stauffer:
Welcome back to The Laravel Podcast, season four. Today, we are talking security, super important, with Rizqi Djamaluddin, a UX designer, but also a longtime Laravel community member who knows a ton about security. Stay tuned.

Matt Stauffer:
All right. Welcome back to The Laravel Podcast, season four, where every single episode is about a specific topic. And today we're talking about security, which to be honest, I feel like I don't know as well as I want. This is one of the ones where I really lean on the framework and our existing tooling to teach us about this. And I want to know more about what's going on. So I am super excited about this one, because more than ever, I'm going to be learning today. Today, my guest is Rizqi Djamaluddin.

Matt Stauffer:
He lives in Indonesia right now, so it is 8:30, his time in the evening, it's 8:30 my time in the morning. We are making this happen. And I'm really excited to have him here and learn from him. So Rizqi, if you meet somebody in the grocery store, if that's the thing you do these days, how do you tell people about what you actually do?

Rizqi Djamaluddin:
Hey, Matt, yeah. Honestly, when I run into people and they ask me what I do, I just go ahead and tell them, I work with computers and I help you work with computers better.

Matt Stauffer:
I love that. Could you tell us a little bit more? Because I think that you uniquely have a very specific role. A lot of us are ... not just ... but we're just application programmers or website developers. Tell us a little bit more about what you actually do.

Rizqi Djamaluddin:
So I have both feet in both worlds. I'm a bit of a designer and a bit of a developer. I do a lot of backend. I do a lot of front end. I do a lot of security. I do a lot of privacy. And most importantly, I'm a tech advocate, and I try to talk to people and explain to them how they need to be more technology conscious, more privacy conscious, and how they should think differently about their organizations.

Matt Stauffer:
Yeah, that's very cool. And I asked you this before the call, but I was asking what sort of organizations you do tend to work with more. And I don't know if you wouldn't mind just sharing real quick about what type of groups you normally work with.

Rizqi Djamaluddin:
I work mostly with schools, healthcare, policy makers, all the big lumbering organizations who are still feeling out of 21st century, especially here in the developing world.

Matt Stauffer:
Yeah. The time spent assisting those groups have a really significant impact on the broadest population, right? You have a lot of opportunity to be impactful on a lot of people by helping those groups be tech-literate. So that's really cool.

Rizqi Djamaluddin:
Absolutely, that's why we do it, because a lot of people don't know that Indonesia is the world, I think third or fourth most populous country, or right behind the US.

Matt Stauffer:
Really? Wow.

Rizqi Djamaluddin:
So I think that puts us fourth or fifth. Somewhere around there. And so we have a lot of people who need catching up. You probably don't hear about Indonesia a lot because we tend to be quite quiet people. We don't really stand up very much, at least compared to our compatriots, like say, in India and China.

Rizqi Djamaluddin:
And so this is part of it. I'm trying to help everybody catch up. But I do travel around quite a bit, a lot. A lot of developing countries, but also to Europe, to the US and just helping people understand a bit more about technology.

Matt Stauffer:
Okay. That's really cool. I told you this at the beginning, but I wish I had you on last season, because I feel like I want an entire episode just about you and your backstory, but hopefully little bits will come out through this. So the first thing at the beginning of every single episode this season is to talk about what it would look like to explain your concept to a five-year-old. So your concept, security is pretty big. I'm guessing you've thought about this at least a little bit, but I think I would ask if you were talking about security in software, and you can decide to focus primarily on Laravel or whatever, but I know that you have some broader ideas about this. So let's just talk about whatever makes sense to your brain. If you wanted to explain the security concept to a five-year-old, how would you go about it?

Rizqi Djamaluddin:
Oh, five-year-old, okay. So little Timmy, he has his favorite yellow security blanket, right? So he has to sleep with that. If he doesn't sleep with that, he'll be all night knocking on daddy's door. He needs to keep that safe from the evil dust bunnies and the mean big brothers who are out for blood. He stashes it in his toy box, hides it down the bottom.

Rizqi Djamaluddin:
The problem is, he needs a way to make sure he can get to the blanket, but other people can't. And when you're dealing with those mean big brothers, man, or those dust bunnies, they are wicked beasts. And so they will try whatever they can do to get that blanket, and they might break stuff, They might try to steal it, They might try to pretend to be your parents and say, "The blanket needs to be washed," but you really don't want to wash it.

Rizqi Djamaluddin:
So security is all about, how do you make sure only you have access to that little security blanket, which is very valuable to you, and not everybody else? And surprisingly, you can make a whole job out of that, apparently.

Matt Stauffer:
Yeah, turns out.

Rizqi Djamaluddin:
Turns out.

Matt Stauffer:
I wish I had a soundboard because I would've done an applause soundboard. That was fantastic. I love it, because you didn't just tell us about the fact that you want to keep it safe. You also have to think about, you need access to the thing when everybody else doesn't need it, because if it's just safe, right? That's one thing. You just barricaded or whatever. But it's the idea that you need access. Other people don't need access. People may be pretending. Oh my goodness. That was good. All right, so let's dial down a little bit now into the concept of security, in the context of building web applications using Laravel. Can you tell me a little bit about what kind of concerns, what higher level or specific, or whatever, as you think about, just an average Laravel programmer, who uses Laravel day to day, either the benefits they're getting from Laravel, or the things they need to be thinking about that they're not getting from Laravel? Like where does your brain go about the big understandings and groupings of what security really looks like as a web application developer?

Rizqi Djamaluddin:
Right. So when you're looking at web applications, there's always these big, handful of concerns, which we hear day to day in the news. And I'll get to that in a moment, but I also want to hint at a little bit of foreshadowing here that we will also be talking about how you should be designing your app in a way that should be useful, because stuff is only as strong as it is well designed. So in terms of raw security, as you need to be thinking while you're coding, the most common cases we hear about nowadays, you'll hear about cross-site scripting, you'll hear about SQL injection, and you'll hear a lot about file uploads. Those are the three most common problems, by far, which affect Laravel applications.

Matt Stauffer:
Yeah, that's good. I mean, a lot of us have probably, at various points seen, verify CSRF tokens or whatever. Even if you don't exactly know what you're being protected from, you know some of those things are in there. I don't know if there's anything that specifically says XSS in the code base, but a lot of those things we're being given the benefit. That's one of the things I love about working with open source is, we're being given the benefit of decades of security research, figuring out what the best practices are, and embedded them into our thing. But again, like I said at the beginning, I feel like sometimes that can lull us into a sense of complacency, right? Like, "Oh, well, I'm totally good."

Matt Stauffer:
So I thought one of the cool things we could maybe start with is, could you share with us a little bit about what are the things... We'll maybe start from the angle of, what are we already protected from? And one of the reasons I think that's beneficial is that at Titan, we'll often inherit somebody else's code base, where instead of using what came in from Laravel from scratch, they will build something on their own and the thing that they built on their own doesn't get these benefits that we all get for free if we just use Laravel. So maybe, could we start a little bit from the perspective of, what are the things that are already integrated in a framework like Laravel that it's giving us protection from, both so we know what's going on, but also so that we don't accidentally subvert the natural protections we have? And maybe, then we can go from there to talk a little about what you're talking about, which is, how to design our applications in a way that helps us continue that security coverage.

Rizqi Djamaluddin:
Absolutely, Matt. And this is, I think, the big overarching theme here, which people need to understand, is that Laravel affords us so many conveniences that, often, we're most vulnerable when we are trying to circumvent it for some particular reason and that's when the security fails.

Matt Stauffer:
Amen. Yeah, exactly.

Rizqi Djamaluddin:
So maybe if we start with, for example, SQL injection. Most of the time, if we're working with a web app, which talks to a database, we'll just be using Eloquent. And Eloquent is fantastic. You basically can't really mess up with Eloquent because it pre-prepares every statement that goes through it and you can basically just take user input. You'll do your normal validation on top, and then you can push it into Eloquent and make your normal requests. That's normally perfectly fine. And this is also why security is often quite tricky because a lot of newcomers who come into it don't understand which feels right and which feels wrong.

Rizqi Djamaluddin:
And to a lot of PHP developers, seeing a bb query and then a dollar GET is a very alarming thing to see. But Laravel provides that-

Matt Stauffer:
Okay, that is smell.

Rizqi Djamaluddin:
Yeah, a lot of programmers seeing that'll just back away slowly before the incoming explosion. But for Laravel you need to be careful whenever you are passing in anything with a database raw, or you're doing unprepared statements. Those are where they slip in. And this especially happens because people are making more and more complex apps. And early on, they're fine because they're using normal database queries. And as they get more and more complex, you have all these complex monster queries running around and you're using DB::raw to push stuff in, and that's when it happens.

Matt Stauffer:
That's great, yeah. If you have graduated from the point of writing, simple Eloquent to writing something so that you don't know how to do it without raw, but you have not been educated that raw is not protecting you anymore, you could make that step without realizing, all of a sudden, "I'm unprotected." That's a really, really great point. And can you give us a real quick example? Because I think a lot of listeners maybe actually haven't even heard of what SQL injection is. Can you give a real quick example of what a context for SQL injection might look like?

Rizqi Djamaluddin:
Right. So SQL injection at its core works because SQL runs off a simple string. It's a simple instruction set for SQL. Normally, whenever we're talking with Laravel, we'll be able to say that if you're updating a certain value, we'll just be able to pass it into an identifier and that is automatically filtered by Laravel. When you're doing DB::raw, however, you are assembling that string manually, you are actually using string functions to put it together. And when you're doing that, you're losing that automatic security. So for example, whenever you do a standard query in Laravel, it'll automatically escape. And that means characters, which are not safe in the query are automatically sanitized. But when you do a DB::raw, you're telling Laravel, let me hold the controls, turn on sports mode, let me do what I want to do. And that's where it gets tricky.

Matt Stauffer:
That's lovely. Yeah. And that's a great point, and one of the things you mentioned earlier is that if you're seeing dollar underscore get so for anybody, who's again, not an old school PHP programmer what he means is user provided input, right? A form that they submitted or a query parameter. If you are passing that directly into your string, that you're building on sports mode without the protections that Laravel provides, somebody could theoretically pass in a string to your email field that is semi-colon drop Bobby tables, drop table or whatever. So basically they could pass in destructive SQL and if you're not escaping it, they can all of a sudden take control of, or completely delete your entire database or something like that. All right. So you talked about SQL injection. That's a good one. So the big warning with SQL injection is the moment-

Rizqi Djamaluddin:
DB:raw.

Matt Stauffer:
... you use DB::raw you now have to know what you're doing to escape things.

Rizqi Djamaluddin:
I can also give you-

Matt Stauffer:
That's a good easy one.

Rizqi Djamaluddin:
I can also give you a hint on how to quickly check if you have that problem. And this is something hackers do all the time. If you can put input through how, for example, if you're to have a page where you're displaying people's profile based on their email or based on the user ID, if it tried to put certain characters within that user ID, the most common being, quotes or back ticks, and there's a whole bunch you can look up like SQL testing strings, you can put them in and you can see if your application responds predictably. It probably doesn't exist if user close quote, semicolon, probably doesn't exist in your app and if that happens, then it should probably show a 404.

Rizqi Djamaluddin:
But if your app behaves weirdly, then that means you have a vulnerability and you should patch it. This is also why I tell people the best way to deal with security injection floss is to have automated testing because that's easy to do. You can have an automated test. What happens if this input comes in and based off of that alone, you can just have that test and whenever you're coding in the future, run a test again, I'm still safe from the test again, I'm still safe.

Matt Stauffer:
That's awesome. When I was first building Karani, which is the first software as a service I've ever built and actually charge money for it. I didn't know any of this stuff and it was on CodeIgniter. Laravel didn't exist. And I ended up paying a group $3,500 to do like a automated penetration test. And that was not in my budget at that point. And so I'm super curious, maybe down the road, or maybe at the end, when I ask for resources, if you can help us think through what are some good ways to set up those automated tests ourselves, or if there are more affordable automated suites that we can think about. You mentioned one option would be just Google, common SQL error. Maybe we'll put some links in the show notes or something like that, but it'd be very cool if we can kind of give some resources for how to set up those sorts of tests generically on every website you have without paying $3,500 on every single website you build. So that's awesome.

Matt Stauffer:
All right. So moving on from SQL injection, what do you think is the next thing we should be thinking about in terms of that we're normally protected from in Laravel?

Rizqi Djamaluddin:
Probably by far, and this is the more catastrophic one because when people make mistakes for SQL injection, then usually the database gets leaked. That's the worst possible scenario. But if you screw up and let people upload arbitrary files to your server, which they can execute, they gain the keys to the kingdom. If people do a SQL injection, they don't get your app keys most of the time because that's an environment, but if bad file uploads happen and everybody has a file upload on their system, suddenly if people are able to upload malicious files, all hell breaks loose. It's very difficult to defend against those, but there are tricks around it.

Matt Stauffer:
Okay. So before we even talk about the tricks, can you talk about what's... Because I bet with file uploads, there's some that are catastrophically bad, some that are medium bad, and some where it's totally protected. So if I was building a file upload and I wanted somebody to be able to upload things and we haven't decided whether or not that thing's going to be publicly accessible yet, we haven't yet set up any validation. Can you talk through like, what is more problematic? What's more catastrophic in terms of file uploads and what's maybe like medium bad and what's like, "Hey, this is totally locked down."? And then you can give us all those tricks.

Rizqi Djamaluddin:
Sure.

Matt Stauffer:
Or if that maybe if that's part of it.

Rizqi Djamaluddin:
Sure. So the worst case scenario in a file upload is someone uploads an executable file, because we've all seen that when we're early on being a developer, right? They would always tell you, pull up notepad and type open angle bracket, HTML, close bracket HTML, and then save and then go to your file, right click, rename, and then change the TXT to HTML. And the problem is that applies everywhere. A lot of misconfigured servers will just execute any file, which it thinks is a script file. And so if you managed to upload a script file, I remember even legitimate files like images and audios and all sorts of formats often have a bit of part of their file, which may contain the comments or arbitrary information. And that's where the payloads sneak in. And those are the worst case scenarios.

Rizqi Djamaluddin:
The middle case scenarios are... One of the most easy ways to try to break an application is yes, what happens if I send them a one gigabyte image, and that-

Matt Stauffer:
Wow. Yeah.

Rizqi Djamaluddin:
... upload file, what happens if they send them a really problematic file or just something that's full of errors. And that can take down servers, that can bump up your AWS budget, that can take down people's accounts, that might cause corruption and might cause all sorts of fun toys.

Rizqi Djamaluddin:
And on the minimum side, there's not really much that can happen, but you've seen situations where people would find, for example, in a forum where people could only upload JPEGs. It turns out this one guy has uploaded a GIF and then all the users are like, "What's happening? This guy has hacked the server. He's a hacker." And this erodes your confidence in your application and your-

Matt Stauffer:
Oh. Got it. Okay.

Rizqi Djamaluddin:
Those are things-

Matt Stauffer:
There's one other one that I just happened to run into recently where somebody had allowed users to upload only certain types of things non-executable but HTML was one of them. So it was semi executable. And so every single user could upload HTML files into like a publicly accessible directory. And so now people could build websites pretending to be under his website because it was his website.com/storage/whatever/whatever you want on HTML. And so people were uploading stuff into there and pretending to be him. So, yeah. And I guess that falls in the executable, right? But I tend to think of executable like you uploaded a PHP file and somebody can do anything on your server. HTML is a little bit less scary, but they still were able to do it to do some really nasty stuff. So, yeah, that's a great list. So-

Rizqi Djamaluddin:
And remember, because the same source origin policy, just an HTML file uploaded on your server has basically all the rights of, like I said, it goes straight into XSS, doesn't it?

Matt Stauffer:
Yeah, yeah. Which we haven't covered yet. But when we get to XSS look back on this moment and that's going to be a dangerous thing. If somebody can serve arbitrary HTML from your domain, you're not in good shape for that. Okay. But you were about, before I asked you to give us those worst, best, whatever. Could you share a little bit about what your... You gave us, I think you were going to give some tricks about how to think about avoiding some of those problems.

Rizqi Djamaluddin:
Well, man, I'll tell you the best trick in the book, which is put it on AWS or some other platform, because-

Matt Stauffer:
Oh yeah. I didn't think about that.

Rizqi Djamaluddin:
It's actually a lot easier than people think. Especially a lot of younger developers think, "Oh, I need to go out... I need to go register." And you've heard all those nightmare stories about people get to figuring AWS, but it's actually quite simple and straightforward to set stuff up and you can even have it so users can upload files without ever touching your server. So they can upload signed uploads straight to AWS. And because they're on AWS, they're not on your server and they are just in a static place and they're easy to work with. That's the best in my opnion.

Matt Stauffer:
See? I told you I was going to learn a lot because I use AWS sometimes and S3 is super easy to set up, but I hadn't even thought about the fact that you instantly lose all of those security concerns when it's on AWS, not on your server. That's really cool. Okay, so-

Rizqi Djamaluddin:
Although you still need to be careful about a few things because sometimes this leaves security and enters trust, right? Like the example you had earlier about an HTML big in your uploads is although it might not be security problem on its own because they're on your website that erodes trust. And so even if it's on S3 you still need to be a little bit careful, be sure you validate, just because of the S3, you should still make sure about, especially those file sizes and the file types.

Matt Stauffer:
Oh yeah.

Rizqi Djamaluddin:
But yes, it's removed so many attack vectors.

Matt Stauffer:
Okay. I'm going to ask a very, very specific question only because I'm curious and sorry if this disrupts you a little bit, but I remember reading that people were embedding executable code inside of JPEGs and PDFs and some other things. Do we have any native kind of way around that? Is Laravel validation covering for us? Is there something we can do to make sure that's not going to bite us?

Rizqi Djamaluddin:
Laravel validation I believe uses PHPs. There is a mechanism for MIME type checking. I'm not a hundred percent sure, but the key problem here is even if there are built in protections, which I'm sure there are some, it's very common as time goes on, and this becomes a disclaimer where... Don't take my word for gospel. These attacks evolve daily and weekly and it's a-

Matt Stauffer:
Totally.

Rizqi Djamaluddin:
... game of cat and mouse. Even in perfectly formulated files. It's perfectly possible to have an evil payload because it's possible to have comments and metadata, which are otherwise not known.

Matt Stauffer:
Yeah. So one of the notes there might be, no matter how much you think you're protected with the file uploads, lock it down as much as you possibly can. Right? Like if you don't have to allow somebody to arbitrarily view that JPEG or whatever, then just don't put it public in the first place, right?

Rizqi Djamaluddin:
Absolutely.

Matt Stauffer:
Okay. So upload S3. Have you ever used MinIo by the way? M-I-N-I-O.

Rizqi Djamaluddin:
Yeah. Yeah, yeah. It's basically a drop-in S3 that you can manage on your own. I've heard about that.

Matt Stauffer:
Yeah. So if anyone's not familiar at Titan we made this tool called Takeout that allows you to really quickly spin up little Docker based services locally. And one of the things I realized is that one of the things that keeps me from using S3 by default is because S3 by default is not as easy as uploading my local storage folder by default. S3 is super easy once you're actually already setting up your production environments, but S3 in day one is maybe not quite as easy as just, just let it go where it goes on day one.

Matt Stauffer:
But I was realizing that if I were to start moving towards like an S3 upload by default policy, MinIO might be that thing that allows me to get there, like have a local MinIO instance running managed on Docker or managed by Takeout all the time. And then the moment I spin up a new app, I just connect it to my MinIO. And when I'm ready to go to production, then... When I'm pushing something up to forge or whatever else, I'm much more comfortable with the idea of spinning up an S3 bucket and stuff like that.

Matt Stauffer:
And if I've got a local MinIO thing, maybe that would make it more comfortable. So I really appreciate you saying this because I'm now going to go Takeout, enable MinIO and I'm going to try that being my default for a while.

Rizqi Djamaluddin:
Absolutely that sounds like a good drop in replacement while you're developing.

Matt Stauffer:
Awesome. Do you have any... Thank you. Do you have any other pieces of this whole file uploads you want to talk about or do you feel like S3 is the magic ticket and we should move on to the next one?

Rizqi Djamaluddin:
I have one other thing to add on. Well, two things. First of all, this is basically a life pro tip. Don't listen to what people tell you when they tell you this chmod file directory is on the internet, because every other tutorial will tell you, "It's fine. Just triple seven it for a while and nobody will ever notice." If any new programmers are listening to this and you're trying to learn about, I'm having permission issues, it's telling me I can access a file. Take your time. Chmod is quite a tricky beast because it's not like the most intuitive thing, but you should take your time to understand what it means and why you need to have certain levels of access. And don't just willy-nilly upload it.

Matt Stauffer:
That's a good point.

Rizqi Djamaluddin:
The second thing I want to say is one of the most common mistakes and we've seen these from very common breaches recently is people will just take a file with the existing file name and upload it to the same file name. And so often file names contain important information. Sometimes it will be metadata left behind inside the file name. Some people will just increment the file names to be one 1.JPEG, 2.JPEG, 3.PEG. But those are dangerous because you can do what's called a numeration attack, which is when you just go one by one by one and pull up every file and thus violate everybody's privacy.

Rizqi Djamaluddin:
If any developers are looking for a way to limit access to a file, you want to look at either signing them, if they're on an S3, or if you are hosting them locally, look at a XXL, as acceleration SL. And that's basically a way of putting your web server in front of a file and limiting who has access to that particular file. A lot of developers rely entirely on obfuscation or unpredictable file names. And that's not really good enough.

Matt Stauffer:
It's better than auto incrementing, right? But it's only a little bit better.

Rizqi Djamaluddin:
Definitely.

Matt Stauffer:
Yeah. One of the things I've often done, which is not XSL, I don't think is if I don't worry too much about the performance of these images or whatever, I will actually store them in a way that they're not publicly served and I'll build a PHP script in front of them that basically just says, is this user authenticated? It does our normal ACL check, right? Is this user authenticated? Does this user have access to this image? If so, then it literally just returns the images as a stream. And then I set my cache headers so they can actually get it. But sounds like XSL might be more at the Nginx level. Can you tell us a little bit more about that? Okay.

Rizqi Djamaluddin:
So that's on an engine X level and all it basically boils down to is emitting a header and basically the request will hit your server first and you can basically emit headers that tell Nginx, "Okay this person has passed the check. Now emit this file."

Matt Stauffer:
Wow.

Rizqi Djamaluddin:
It requires a server configuration.

Matt Stauffer:
Okay. But it's basically like... If anybody's familiar with the idea that a lot of requests will send like an options request before they actually send the real request. So you're going to tell Nginx for any files in this directory, you need to ping slash API slash me beforehand and make sure that it gets back a header that says, "Whatever X is all cool and authenticated or whatever. And only if that user gets that response as yes, or true or valid or whatever, then serve this." And otherwise Nginx will give them like unauthenticated.

Rizqi Djamaluddin:
Absolutely. All you need to do is in the response header from Laravel, you're going to need to pass them XXL redirect. It's also called XN file. They're kind of related and basically pass a path to like /storage/apps/ wherever you're storing it.

Matt Stauffer:
Wow.

Rizqi Djamaluddin:
And will send your PHP. You can emit the file.

Matt Stauffer:
That's freaking amazing. I had absolutely no idea. Okay, cool. We'll put some links up to that in the show notes, if I hopefully fingers crossed remember. Thank you. All right. You said there was two, was there was another one you wanted to share about files or was that the second one already?

Rizqi Djamaluddin:
Yeah, that was the second one. The first one is about the permission issue.

Matt Stauffer:
Oh, perfect. Yeah. And I would say that with permissions, I really appreciate you bringing that up. I don't think I have ever in modern Laravel, maybe in some of the old days when we hadn't figured it all out, I don't think I've ever had to chmod any files or folders in Laravel. Like if my local setup is good and if I'm using a decent deploy system... And if anybody doesn't know, the chmod is the thing that if you've ever listed a list of files in your directory, and it says our RWX RX RX or whatever it's talking about, who can read and write these files. And chmod changes that system, makes it so that everybody can read and write these files or only these people can or whatever. And I don't think I've ever had to have to do that. I mean, do you ever use it on a day-to-day in applications you're building?

Rizqi Djamaluddin:
It's quite rare. I find it from my experience most people run into this when they're setting up their local environments and to be clear, the modern developer experience of pulling down Docker and setting up everything through Valet, all these nice new tools is actually kind of new. A lot of people start up with just bare bones, MacOS, or even on windows, whatever that they can use. And that's when you run into those issues. And because they do them on their local, they'll see the same error on production and say, "Oh, that worked last time. I should do it again." And that's what happens.

Matt Stauffer:
It's a chmod again. Okay. That's a great point. And that's another reason to consider using not just what are the built in systems in Laravel, and if you use them, you get Laravel's protections, but even what are the modern development environments locally? Because if you have something like Valet or Homestead or whatever else, they're going to get your local environment set up so that the file permissions are correct, not too open, not too closed. And so you don't have to ever be in the... And I use Valet every single day and I never see chmod anything. I use Forge for setting up my servers and I never have to chmod anything. So that's a great point.

Rizqi Djamaluddin:
Absolutely.

Matt Stauffer:
Avoid chmod unless you really know what you're doing.

Rizqi Djamaluddin:
Yep.

Matt Stauffer:
I love that. All right. So we've talked about file uploads. We talked about databases like SQL insertion. What are the other kind of biggies that we're already productive from?

Rizqi Djamaluddin:
So the third one, and this is the one which is also one of the most common attack vectors is XSS, Cross-Site Scripting. And Cross-Site Scripting at its heart is about when we allow users to emit information in our HTML and it runs as the end user, because like for example, if you let people just dump whatever HTML they want out on their user profiles on Facebook, that whoever views that page will run scripts as if that was Facebook sending it to them. And this is very common because early on, when you're doing Laravel and are using Blade, you are protected from this by default. By default and this isn't just Laravel, but basically any modern framework will assume that when you're emitting something, you do not want to allow any sort of HTML or any sort of Trojan horses living in there.

Rizqi Djamaluddin:
Just as an example of how this attack would behave. Imagine you have a great new idea for a big social network and you're thinking, "I'm going to let people customize all of their profile pages and they can embed whatever they want and they can add whatever they want." And then a user comes up to you and says, "Hey, I want to have paragraphs and headings." And you're like, "Okay, I'm going to allow the strong tags so they can bold bits that they want." And then like, "Okay can I have links? And can I have this, can I have that?" And then suddenly one day you realize the bold tag, the strong tag allows a whole bunch of attributes, which can contain code in them. And that code executes as if you, the website owner were telling the user's computer to run it. And that can just talk to any server, that can dump out some data. It can leak basically everything the user has access to.

Matt Stauffer:
Yeah. With cross-site scripting, so I always get Cross-Site Scripting and a couple of other ones mixed up, but Cross-Site... Yeah. So CSRF and... So a lot of them have to do with not just the ability to inject code, inject JavaScript, but also to decide whether you're acting as the origin or not. Right? So I'm going to be really honest with you. I've learned XSS, CSRF and CORS a million times and I have in my head a little bit, but even right now, when you said this, I was like, "That's not what XSS is. XSS is Cross-Site Scripting." Right? And so that must be the one where somebody from another server posts stuff over to my server, but that's not that. And so why is this one called Cross-Site Scripting when it's really just injection into my page? Do you know?

Rizqi Djamaluddin:
Yeah. So it's called Cross-Site Scripting just because they are injecting their stuff into your site.

Matt Stauffer:
Okay. Got it.

Rizqi Djamaluddin:
As I understand it, that's where the confusion came from originally. There was a lot of... The web security community is also quite up in arms about how confusing some of these terminologies can be as you'd probably expect. The other ones Cross-Site Request Forgery, the keyword there is forgery and that's when you lure somebody to their website and then you forge a request to another website as if they did.

Matt Stauffer:
Okay. So that was where... Let's say they're logged into my website. They go over to the bad person's website and then they hit submit on something and it submits back to my website, but it's submit stuffs that they never would have wanted to submit, right? Or something.

Rizqi Djamaluddin:
Yes.

Matt Stauffer:
Okay, cool. So that's CSRF. XSS, which is the one you're talking about right now. Sorry to derail us.

Rizqi Djamaluddin:
No problem.

Matt Stauffer:
That's the one where we're allowing the users to actually echo their own arbitrary scripts on our pages.

Rizqi Djamaluddin:
Yes.

Matt Stauffer:
Okay.

Rizqi Djamaluddin:
Yes.

Matt Stauffer:
So please continue about XSS and best practices there and everything.

Rizqi Djamaluddin:
Cross-Site Scripting. Let's get back to Cross- Site Scripting. By default in Laravel you're protected from that because all tutorials and all articles will tell you to use the double curly syntax and what a double curly syntax will do is if a user try to say, my name is, open angle bracket, strong closed angle bracket, Rizqi, then it'll just show the actual angle brackets at the output when user sees it again. And that is a foiled XSS attack. That means your server was able to identify that, "Hey, that's just a username. You're not supposed to parse that." And that's when it's been foiled.

Rizqi Djamaluddin:
Now it becomes a bit of a tricky problem because Laravel does allow a format to emit an escape data. And that is using the exclamation marks. And you should only use that when the data is coming from a trusted source. So for example, if the data is coming back because you have say them bad script or something, which you yourself ripped down in the app, basically, if it comes from the database, don't do that. And for our listeners who are using say Vue, for example, then Vue also has a similar setup. If you're using the double curlies in Vue that is sanitized for you, don't need to worry about Cross-Site Scripting. But if you're using the V-HTML attribute, the directive, then you are vulnerable. You should only use that if you can, a hundred percent trust data coming back.

Matt Stauffer:
Yeah. And if you do find yourself in a scenario where you have to allow the users, for example, to pass an HTML or something like that, you either need to work with entirely trusted users. Like it's an internal tool and then still, then it's a little bit scary. Or you have to all of a sudden now deal with attribute parsing and bringing in a library that sanitizes your HTML and all that. Yeah.

Rizqi Djamaluddin:
That one in particular comes up a lot because a lot of people ask me like, "So you're telling me not to emit HTML. What if I want to let people emit some HTML?" Because the most common example now is this Markdown. People will say, "Let me admit some HTML, some basic HTML and so people can use Markdown in comments." For example. But the problem is little known fact, Markdown actually allows HTML. Markdown was always designed to be a free text format. It allows you to just write HTML and it'll just give you HTML back. It does not check that for you. And so if you are ever in a position where you need to sanitize your HTML, never do it alone. I personally prefer the HTML Purifier package for that. They have a lot of really good checks and they can figure out this achievement is allowed on this tag, but not on this tag for example... But never do it yourself. Always, always, always pick up a package.

Matt Stauffer:
Yep. Totally agreed. And HTML Purifier... I'm glad you mentioned that name. We use it on at least one project and it's really wonderful to work with. And it's the same as all security stuff, right? You don't know all the things that could break. So I want that... Don't do it by yourself is like definitely my mantra on anything security. So I appreciate you saying that. All right.

Rizqi Djamaluddin:
If I can add a horror story while-

Matt Stauffer:
Please.

Rizqi Djamaluddin:
... while we're on this part. One of the most common things, I've seen this happen three times now in a year, and this is why I think I have to tell you about it because I don't want any more people to make this mistake. One of the most common issues is nowadays when people make websites and with Vue for example, they will want to make it support internationalization. So they'll take a package like Vue IED then, and that will let them have string tables. So different parts of the app will be translated and shown in different ways to different users of different locales. The problem is some languages or some regions or some people will prefer formats in different orders, for example. So they might prefer to have the name of the year at the front. Some of them will have different time formats. Some of them just have all sorts of weird formats.

Rizqi Djamaluddin:
And so often people will wind up having to use HTML in their translation strings, and they're in the file full of strings. And they're like, "Oh, it has HTML in it. If I just do double curlies, it just spits out the HTML as like a readable text and that's not okay." So yeah, it should be fine. It has V-HTML in it. Right? And that's where they get ya! So be double careful if you're dealing with anything like that.

Matt Stauffer:
That's great. That's a really helpful thing because it's something I wouldn't have predicted. And so it's just kind of keeps you in that same, like if you're using DB::raw be very, very careful. If you're using curly brace with the exclamation points or V dash HTML or whatever else, be very, very careful because you don't even know what could potentially get injected there. That's awesome. I mean, scary but helpful to hear. Okay. So that's, XSS, Cross-Site Scripting. So what are our other concerns?

Rizqi Djamaluddin:
So the cousin to Cross-Site Scripting, the one that you alluded to earlier is Cross-Site Request Forgery, and the keyword there is forgery. This is basically another person tricking you into sending a command. So I play an MMO-RPG, Final Fantasy XIV, and very early on in its lifetime there was a bug where there's a market board where you can buy items. You can buy armor and vitamins for your character. And whenever you bought an item, your client would tell the server, "Hey, I so-and-so name would like to buy so-and-so item five pieces." Someone figured out the server doesn't check who sent that, all they know is-

Matt Stauffer:
Oh my goodness.

Rizqi Djamaluddin:
... the person who says... Rizqi is buying five potions. So somebody else can come along and say, "Yo server, Rizqi is buying 10 more potions." Or, "Rizqi is buying 50 portions from this guy." And that's basically how it works. CSRF is when a user is trapped by any other website, classically by faking it an HTTP request to a trusted server. But there's actually a lot of different variations to it. It's just all about tricking people.

Matt Stauffer:
And the most common example I know of is let's say that I was building this hacking site and I sent an email to somebody or a Twitter link to somebody that says, "Hey, go check out my favorite site." And on that site, it has maybe an Axios request that sends that post over to the server that says, I logged in user and since I'm logged into the marketplace it gets whatever my information, when I ping it there. Want to buy 500 things from me, the hacker who's doing the thing and all of a sudden, as a hacker, I make money. And you said there's a lot of other contexts, but is that like a good kind of understanding of at least one of the common-

Rizqi Djamaluddin:
Yeah.

Matt Stauffer:
... of vectors for it? Okay.

Rizqi Djamaluddin:
So of the most common ones is just because... One of the easiest ones to understand is some people will put, for example, log out as the get request. And your routes and you'll have a routeget/logout and it'll do the actual log out of the user. Now, the thing is, you know GET requests are not only sent when people talked with an API, they're also sent when people say, get a image on the internet. So if somebody makes an image tag and they set the SRC to source to that URL with the log out, because the lockout was a GET URL-

Matt Stauffer:
Oh wow.

Rizqi Djamaluddin:
They will log you out from just by looking at that image. In the past, a lot of the text worked that way. Just by making somebody look at a webpage, you are sending GET requests with... And because of how GET works, especially with stuff like cookies back in the day, you're a fully authenticated. Any GET route could be hit that way.

Matt Stauffer:
Yeah. So that's one of the reasons why... And I didn't even realize that, but that's one of the reasons why GET requests aren't supposed to have any impacts, right? GET is only supposed to be reading. Your server should never be different as a result of a GET request and that's one of the... That design pattern lines up with, and therefore stuff can be sent along with get requests that you probably don't realize is being sent along with it.

Rizqi Djamaluddin:
Yep.

Matt Stauffer:
Okay. Thank you. That's very helpful. So what do we do to protect ourselves? What do we get for free? What work do we need to do? How should we be thinking about protecting ourselves from CSRF?

Rizqi Djamaluddin:
So Laravel provides the token for CSRF. I think it's just in the default middleware. And so, as long as on the front end, if you are making any more requests to the server, once again, you should pass along that token to make sure that the server understands that the user is trustworthy. That's all really there is to it. These is actually one of the attack types which are slowly becoming far less common. And I should probably say at this point, if you have an API where you're not using standard cookies, for example, to authenticate sessions with the server, if you're using an authentication token, like a JWT or something like that, then you can use the JWT as the hidden token, because when people make that fake requests, they have no way of grabbing your JWT so they have no way of pretending to be you.

Rizqi Djamaluddin:
The reason why the standard CSRF attack works so well is because whenever you hit one of those GET requests, your cookies are sent along with it. And those cookies are what are keeping your session intact. And so if you are using cookies, please use the token. And if you are not, then go ahead and use whatever token you are using to authenticate.

Matt Stauffer:
Okay. But there's also, for me, like I was... So I tend to think, and I want to make... I'm going to say this to you and make sure that I'm getting it right. I tend to think that the cook... Sorry. What you just said, handles APIs, but let's say I had just an end point that is like update user information endpoint and for some reason, somebody maliciously wanted to change my password, right? And so if I didn't have CSRF protection... So first of all, the big problem you said is if that was a GET, it would obviously be a big problem, but let's say it's a post and I didn't have CSRF protection on and somehow they were actually able to trigger a post. That post would work, whether or not things are being sent along with it, because there's no way for that server to know that the request came from the same server, right?

Rizqi Djamaluddin:
Absolutely.

Matt Stauffer:
All it checks is, am I authenticated? And so that's where I think of CSRF protection as being the most helpful and that's why that token is useful is because the originating form has that CSRF token embedded into it, right?

Rizqi Djamaluddin:
Yeah.

Matt Stauffer:
And there's no way for them to know what that CSRF... Okay, cool. So you mentioned that there's a middleware, that's verifies CSRF token middleware. And there's a note that it only runs on POST and DELETE and PATCH. It doesn't run on GET, so that's yet another reason why your shouldn't have anything making side effects from a GET request.

Rizqi Djamaluddin:
Absolutely. And a tip I give to a lot of newer developers as well. If you're confused about all the PUT and PATCH and DELETE, which I've met a lot of developers were like, "Should a soft delete be DELETE or should be like a POST." If you're confused, by default, a good rule of thumb is if you are not making any changes, if it's purely transactional reading, use a GET. If you're making any changes use a POST. And that along with good practices will keep you safe.

Matt Stauffer:
I love that. Yeah. And it's cool to get into put PATCH, DELETE, and those kind of things, but a lot of simple APIs just use POST for them. And of course, an API developer might say, "No, don't do that, blah, blah, blah." And it's good to learn those things, but I do think that's a great point from a security perspective and from just like the way the framework is expecting you to work perspective. GET if it doesn't make a change, POST if it makes a change. I love that. That's a really great, simple rule to start with even if you don't know all the other differentiations. Okay. That's CSRF. What else do you have?

Rizqi Djamaluddin:
Going down the list. Okay, let's get one of the things everybody hates out of the way, CORS. CORS is the-

Matt Stauffer:
Yes. Everybody hates it.

Rizqi Djamaluddin:
... bane of every developer and the root of millions of Stack Overflow posts when people are trying to figure out why they are failing. CORS exist because we want to be able to develop APIs on different domains, different sites from our front ends. By default, when JavaScript makes requests, it tries to make sure that it can only make those requests to websites on the same domain. And this is to prevent request for groups that we talked about just now. And so what CORS does is it says, it's okay for only this one website to make requests to me, even though we're not on the same domain. It all comes down to what's called the same origin policy where a website can only get requests from front ends on the same domain and CORS lets you get around that.

Rizqi Djamaluddin:
But what I'll say is the simplest way to handle CORS is the latest version of Laravel has a config file for CORS. And all you need to do is if you are developing an API where the front end is going to be in a different domain or sub domain, in the CORS settings for that API put the domain of that front end, that's all there is to it. Do not do Allow-Origin star, for example, unless you intentionally want it to be open to the world.

Matt Stauffer:
Right. So if you're developing a publicly accessible API, you may have to Allow-Origins for the API, but you're still going to want to try to make sure that nothing else, other than that publicly accessible portion gets that, right?

Rizqi Djamaluddin:
Yes. This is basically another mechanism to protect people from making a request to servers they should not be able to make it from.

Matt Stauffer:
Okay. Yeah. And we tend to not want anybody to access our sites other than when we public open up APIs. And often there's a note there that like a lot of people tend to eventually plan to open up their API. That doesn't mean you have to open it up today, right?

Rizqi Djamaluddin:
Pretty much.

Matt Stauffer:
You can build the whole API without allowing anybody else to use it until you're ready for that day.

Rizqi Djamaluddin:
Absolutely.

Matt Stauffer:
Good point. All right. You got any other big ones because I think those were the big ones I wanted to make sure you cover. I would love to keep going down your list, but I also know that you talked a little bit about design and wanting to think about it. So I would say from here forward, I just want to think about like, what's next on your brain? What do you want us to be thinking about?

Rizqi Djamaluddin:
So let's slide a little bit away from pure code and a little bit more on the application designer's code. One of the things which a lot of people forget about is the weak point of your application is always the authentication. Now there is a fantastic Laravel podcast episodes specifically about authentication and authorization, the auth stuff. But I would like to really put a lot of emphasis here on rate limiting, logging, and allowing two factor authentication when possible, because no matter how good your security is, if you have a door, which people can try to knock on and say, "I'm Bob, I'm Dave, I'm John." And they say every name possible eventually they will get through. And so rate limiting to lock up people after enough attempts, allowing two facture and the fact that people are logging in or failed to log in all of that are critical pieces to being able to hold up a good security system.

Matt Stauffer:
All right. So rate limiting, we get at least the ability to add rate limiting by default on Laravel but I don't think it's turned on, on anything other than the API routes by default, right?

Rizqi Djamaluddin:
Yeah. I think it's only for API routes because APS are very easy to just harvest information from.

Matt Stauffer:
Yeah. So we do want to do rate limiting on authentication things, which I think is pretty easy. I think there's even a throttle middleware where you can just say on the authentication login page, maybe the password reset page or some... Well, I guess it would only be the login page you want to rate limit that. So that's a pretty simple one to add.

Matt Stauffer:
You mentioned logging, could you talk a little bit about... Because I've always like when I first built Karani again, I logged every problem, everything that could be a smell, but eventually I just got overwhelmed by reading all of them and then I stopped reading all the logs. And at that point I said, "Well, it maybe logging them, but what does that do me?" So how do you think about logging as something that can have enough information to be useful, but also that we can actually attend to?

Rizqi Djamaluddin:
So this is a great shift over to thinking about security, not as technology, but as policy, right? The reason we need logs is if stuff goes wrong. And I don't like to say if in that case, I prefer to say, when stuff goes wrong because inevitably something will happen. Right?

Matt Stauffer:
Yeah.

Rizqi Djamaluddin:
A lot of companies have extremely good security, but they don't have a plan to do what happens when they get broken into. And when somebody has the misfortune of getting their application or service or website broken into, they need to be able to quickly one, detect that it happened, two, identify who has been impacted and three, contact those people and four, tell them what to do. Logging, accomplishes that second part and helps do the third and fourth part.

Matt Stauffer:
I love that. That's a really great... Logging is not a... It's not something that you're proactively monitoring necessarily. Although you could do that with something that watches, you set rules in your logs. It's more about having the information available to you when you need it rather than something went wrong and now you're like, "Well, we don't know what happened. Wish we had logged all that." Right?

Rizqi Djamaluddin:
It's actually kind of scary when you think about it, how many websites get hacked, but they just don't know. Or they get having known months ahead because their data is on the market.

Matt Stauffer:
Yeah. Sheesh. Okay. So that's the logging part. And what was your third... You had a third component of this that I just got so stuck in logging. Do you remember what it was?

Rizqi Djamaluddin:
2FA.

Matt Stauffer:
2FA. Okay. So I know that 2FA is being added to a lot of the jet stream and stuff like that, but have you been doing 2FA with a particular package or anything like that? You really like in the past?

Rizqi Djamaluddin:
I actually tend... Okay. So when we're talking 2FA just to be clear, we're talking about making sure that people can authenticate using a device or something else they have access to other than just their username and password. And that colloquially, when people say 2FA they're usually talking about an authenticator app or something like that, which is dedicated for doing that. And there are really good packages and there's an open protocol for how to do to 2FA. So it's actually-

Matt Stauffer:
How cool!

Rizqi Djamaluddin:
... surprisingly easy to do 2FA. A lot of people are scared about it because it seems scary, you'll read all these documents about we should just do all off in this, all these back and forth. But in fact, it's really just a factor of following a spec and then people be able to pull up any app on their phone that supports that spec and use it. But personally, I also have no coms where people are doing to 2FA through text messages, through Slack messages, through any other avenue they'd want to with the warning that if you allow people to authenticate using another mechanism, you are also opening a new potential security hole. So you need to be very careful about-

Matt Stauffer:
That's why a lot of people say don't do SMS 2FA because now all of a sudden, all the ways that SMS is potentially vulnerable to social hacking or whatever now become your security concern as well. Right?

Rizqi Djamaluddin:
Absolutely. You can have multiple layers to slow people down, but just don't rely on one at a time.

Matt Stauffer:
Yeah. Okay. All right. So those are your three for design. Are there any other kind of aspects of that particular piece that you want to talk about?

Rizqi Djamaluddin:
Well, I think it's impossible to talk about authentication without talking about authorization. So if you just want to get that one out of the way, I would-

Matt Stauffer:
Yeah. Let's do it.

Rizqi Djamaluddin:
... repeat the same advice I gave earlier, which is test it. Authorization is extremely easy to test because if you have any sort of end-to-end testing, which Laravel provides for free, then all you need to do is make some dummy users attempt to request and just assert the response status code. It's super easy. You have some baked in tests, you can run at any time to make sure you're still protected. And the other denim I would add there is most people when you think off, they just think any sort of ACL or any sort of controlling through either maybe a role-based or maybe they'd use any other mechanism to identify who is who and who has access to what, but when you're doing that, be sure to be very aware, do all those people in that group need all that access? It's very easy to say, just give admins access to everything.

Rizqi Djamaluddin:
But when it comes to security and privacy, it's important to remember that people are liable for what they know. If people don't know something, they are not liable for it. And so it's in everybody's interest for you to limit and to lock down that access to only those who actually need it.

Matt Stauffer:
Yeah. I love that point. And that's especially helpful when you think there's going to be one admin super account and you either say, "Well, everybody at the company who I'm building this app for is now going to use that one admin account, or we want more admins in..." Well, they need to do this one thing that's in the admin role. So they must do all the things. And if you've ever learned about the privacy liabilities that a company has, one of the first questions they ask is how much private data can how many people get access to? And the more people that are on that list, the more liable you are. And also the more you have to care about like, "Well, how well is their computers set up protected or whatever." Right? So like you say, "Oh, we can limit our liability, not even just privacy, but our legal liability by limiting who has access to potentially damaging information." That's actually a really wise decision just for the sake of the client, let alone for the customers. That's a great point.

Rizqi Djamaluddin:
That's quite funny often because whenever one of my colleagues or coworkers mentioned, "Hey, do you want to have access to this guy's account?" Or "Do you need database credentials?" And I'm like, "No, I would prefer not to have it. I am legally safe if I don't have it. Add me when you need me and remove me when I no longer need it." That's a really important point.

Matt Stauffer:
I love that. As a consultancy, when people offer us production database dumps, we're like, "Please, no."

Rizqi Djamaluddin:
They just offer it straight up?

Matt Stauffer:
Yeah. Well, because a lot of them, they don't have migrations and seeds any everything like that.

Rizqi Djamaluddin:
Oh, absolutely. Yeah.

Matt Stauffer:
And so they say, "Oh, well, this will be the best way for you to get it." And of course, usually they'll offer it and then somebody in their security team will say, "No, you can't give that to them." So usually it never actually gets to the point where we could have gotten it. But I never want to shame them or anything like that, but what I'll often say is this is a perfect opportunity for us to set up migrations and seeds for you so that everyone can have functioning local version of this thing without you having to worry about exporting your production database. But yeah, usually it's not that we actually get access to it. It's more like a well-intentioned individual offers it to us and then somebody on their team says, "No, no, they can't have that."

Rizqi Djamaluddin:
If I can talk about that for just a moment. See, half the problems here is that people don't have a instinct for security. Humans have been around for quite a while now and we've developed and built in automatic instincts for, "Man, something smells a bit off in this room. Maybe I should go somewhere else." Or, "I feel a little bit uncomfortable here. Maybe there's something about to happen." We have really good instincts, but we don't have that for security. That is not built in because it's only been around for a few decades. And so developing a good security culture, like not accepting that information when it's offered to you or not accepting credentials when you don't need it. Developers in particular are extremely high risk because we have keys to the kingdom. If you have a GitLab account and somebody breaks into your account, they can just commit code, deploys to production and everything's lost. That culture has to be built up.

Matt Stauffer:
That's a great point. Yeah. There's just something that just came out that a North Korean state actor, several were targeting security researchers at Google and a couple other places using things where they, I think they were saying, "Hey, can we pair program on this thing? I'm a young programmer." And they would send them over a visual studio project to work on that had an embedded DLL that was malware and would all of a sudden run malware in the machines. And they were specifically targeting security researchers because they knew that they had access to more things than everybody else did. So obviously they're a little bit more the case than those of us as normal programmers, but I think that's a really, really great point, like I don't... And not even just in terms of being hacked, but in terms of accidental mistakes.

Matt Stauffer:
If I plug my local into the remote, just to do a little bit of tests, then I'm now liable for accidentally running a command that I didn't want to run on production and all of a sudden sending an email to 50,000 live users. And I can't ever do that if I never had the live production credentials in the first place.

Rizqi Djamaluddin:
And the culture really contributes to that, doesn't it? One of the things if I could change anything about a development culture in our community is how we glorify cowboy coding sometimes. "It's fine. Push it for production. I'm just going to log into artisan on production. I'm just going to blast out these emails to everybody." Where one little typo error will actually screw everything up.

Matt Stauffer:
Yeah. That's a great point. And it's interesting because I trust my team a lot, but by default they don't get access to things. And there have been times where I think people have felt a little bit weird. Like, "Well, wait a minute, don't you trust us enough to give us maintain access on all GitLab repos." And I was like, "Well, when it's time sure. But I don't want to have to all of a sudden realize that I..." It doesn't even have to be malicious. It could be a mistake or whatever. It's so much easier for me to give out permission for things when somebody needs it. And when they ask for it, I'll give it to them. Right? But it's just this default, everything is locked down. The same thing is true for our 1Password account. By default, you don't get access to anything unless I realize that you need it and then I give it to you. So that there's just less accidental possibility for that liability.

Rizqi Djamaluddin:
You brought up another really good point there, which is use a password manager. How many teams I've had to tell them to grab a password manager. You think developers would use them, but they don't. One of the things people need to do when they're thinking about security is recalibrate your risk factors. Because much like in the real world, we are exposed to certain types of vulnerabilities, more than others, but in real life, password reuse and misconfiguration are some of the most common avenues of attack. And so you can have the world's most secure infrastructure. If one of your developers is reusing their password for SSH, because he didn't disable that for some reason and they use that for their Facebook account and when it was hacked a few years ago, then it's basically lost.

Matt Stauffer:
Yeah. You've got a problem again. Yeah. That's a great point. Yeah. And in terms of SSH and databases, one of the things that is nice is that if you're using Forge for everything, you are going to get brand new generated passwords and everything like that for all of them. It is relatively easy for us to invalidate one person's SSH keys across any servers they had access to if their laptop gets compromised or something like that. But even then let's say you have a server that has 15 websites on it because people do that a lot or a hundred websites, by default the Forge user and its password will have access to all of them. And thankfully recently, and for Forge users, I want you to notice this. You can now set up that a different user will be set up for every single new site that you set up.

Matt Stauffer:
And so it's a little bit more work because you have to SSH in or whatever as different users every time, but it is allowing you to start walking down the road of different users per site so that if you don't all of a sudden get 150 websites compromised if somebody got access to your Forge user, now they only got access to one website or whatever.

Rizqi Djamaluddin:
And it's absolutely important that we develop that culture of taking it slow. One of my favorite experiences is if you ever go to Japan or... A lot of countries do this, but Japan is known for it. You will find that their train drivers habitually touch every control on their dials and on their displays. And they will look outside... It's basically a much more involved version of check your mirrors before backing up. And there needs to be developer equivalents, like when you're accessing something, you need to habitually form that habit of am I on the right user? Am I on the right place? Am I my underwrite server? All of us have had that time where like we're about to do something. We're like, "Wait a second. That's not staging, that's production." You got to build in those habits.

Matt Stauffer:
Yeah. And I love that because you want to build the habits to always check and if you don't have access to production, that habit doesn't have to be tested in that moment.

Rizqi Djamaluddin:
It's fun.

Matt Stauffer:
So yeah, no, that's a great point. I love the habits because I think one of the habits is if you just tell yourself every single time before I'm doing XYZ, I will do ABC those habits aren't just helpful for security. Like for example, one of the things that I kind of beat into the heads of every single new Laravel programmer when they joined Titan is when you make a pull request, the first thing you do before you assign somebody to it is you read down the changed files list and you notice those dumper dies you left in there or there's those typos. So every single time you do a pull request, read your pull request first. And that little change has changed my experience reviewing other people's pull requests crazy because all of a sudden their brain is now in a different mode and they're able to see that thing that they didn't expect to be there and they fix it.

Matt Stauffer:
And so you can build these practices, but you're talking about more about security practices. One of them being, "Hey, every single time you're about to do something, check where you're doing it or check what users you're on." I love that. Are there any other practices that you think we could globally adopt in that same way or is it more just kind of contextual?

Rizqi Djamaluddin:
A lot of practices when you're just developing habits is all about making sure, am I doing what I intend to do? And if I'm doing something, what may be affected by it? But that being said, when it comes to habits and practices, I'm kind of known somewhat in the community as the checklist guy, because-

Matt Stauffer:
I love it.

Rizqi Djamaluddin:
Matt, if you know, I have a 27 point checklist, which I went into before this recording, of every bit of making sure the iPad is here, turn the curtains down-

Matt Stauffer:
Oh, I love it.

Rizqi Djamaluddin:
... set the conditioning to minimum fan speed, all the little bits and every single line of those you know came from an incident in the past where you forgot to do something.

Matt Stauffer:
Yep. Add it to the list.

Rizqi Djamaluddin:
And so one thing I really like to tell people is humans have always worked because we write down what we learned last time. And so if you only develop the habits based on what you feel you need to be doing, you're not going to develop them fast enough. But instead, every time somebody does one of those pull requests were to leave something wrong in, don't just fix it and then accept it and then move on, write that down so next time you're doing it, you check it again. And that is how you flesh it out. And that's how you build the habit.

Matt Stauffer:
I love that. I am also a checklist guy and we have a few checklists folks at Titan, and one of the things I've been spending a lot of this past six months doing is trying to recognize that we have 15 to 20 developers at Titan. I don't want their time to be spent redoing anything. I don't want their time to be spent making decisions that have already been made, but I also don't want the folks who are reviewing pull requests time to be spent making sure things are standardized, that could've just been a checklist in the first place and it could have been automated in the first place. And so I love this. I'm even building Bash scripts to automate the starting of new projects so we don't have to always remember to set up PHP CodeSniffer or whatever. And so this is great. I love the idea of security checklist and deploy checklist and that kind of stuff.

Matt Stauffer:
And obviously everybody's not going to do it that way. They're not all instantly going to become the checklist person, right? But the idea of just building in the practice of, "Here are the things I must do every time I do X, Y, and Z." And just building those as standard things that people do as programmers. I think that's a really great idea.

Rizqi Djamaluddin:
And I think it loops into what you said just now about protecting people from what they need to do, because when you have a checklist, not only does it save time, it also makes them feel, "I've done the steps I need to do. I don't need to sit there thinking, is there anything else I need to do?" You've done the steps. If anything slips through, it's still your fault, but you can say it wasn't on the checklist let's learn from it. Let's fix it next time.

Matt Stauffer:
Yeah. And it saves you... You mentioned that. I love that. It saves you the mental overhead and the more things that are known your brain now doesn't have to focus on them every time. Do the thing on the checklist and now your brain space is left for the creative things that are unique about, which is what's great about frameworks in the first place, right? We shouldn't all have to spend the first six months of every project writing authentication. Now we can just say, "Oh, I'm going to use Laravel." Cool. Now we're going to spend the first six months writing stuff that is unique to this particular project. Similarly with checklists, I don't have to spend X amount of brain power seeing, "Did I remember to secure that? Did I remember whatever?" No, just follow the checklist and then move on. I love that.

Rizqi Djamaluddin:
And pro tip, you can extend that even further through... What I like to do is I make artisan commands which health check everything on the server. So if stuff is going wrong, I can run it and get a really quick diagnosis of the server and if everything is going well.

Matt Stauffer:
Oh, I love that.

Rizqi Djamaluddin:
And this falls right into security, because what you can do is you can have, for example, a health check command, which also spits out last time admins logged in. Because when security flaws happen again, the most critical time are those first few minutes after it happened, can you detect it before the attacker can cover their tracks? Or can get the database dumps out of you? And so if you're like, "Hang on a second, something's off. I'm going to run the health check." You'll run the health check and see, "Wait a second. Richard is not supposed to be awake. It's 3:00 AM." And you call him, he's like, "No, I was sleeping." You know immediately. Those minutes are precious.

Matt Stauffer:
That's really cool. Are there any checklists or artisan commands or anything like that, that are out there publicly that people could look to as like an example of the type of things that you would do for that?

Rizqi Djamaluddin:
I'm not a hundred percent sure. I've seen some checklists, which just go over like general health, for example. Well, the thing with checklist, right, is you can have really a MIME checklist. You're going to have like, "Am I running out of disk space?" That's a common problem. "Am I running out of memory" "Which GET version is this running?" "Oh, no, it didn't pull the latest version." Just all the basic stuff out.

Matt Stauffer:
Yeah. I love that.

Rizqi Djamaluddin:
But going back to the thing we talked about just now about how you can build it as you go build it as you go, build it as you go. So as you develop your application, every time something wrong happens, build it into that health check to see if it's happening again.

Matt Stauffer:
Yeah. I love that. Yeah. Spotsy has a couple packages, one that's called, I think, Server Monitor and one that's similar and they have a couple of health checks built into them. And so we've just got an instance of that running for all of our sites that just says, "Okay, are there any errors in this place? Is the HTTPS certificate resolving correctly?" All that kind of stuff, but it also allows you to write your own. And so sometimes checklists are good, but sometimes you can also get external tooling that checks that kind of stuff. And we are also building a tool right now called Checkmate together with some folks that just lists out all of our Laravel applications in our GitHub and says, "Hey, are any of them out of date with their Laravel.?" And so then it gives you a prompting that to kind of...

Matt Stauffer:
So just the more we can simplify it, automate this, Checkmate's not going to fix it for me, but it is going to give me a list of action items. So now I don't always have to be worrying, "Oh, are a couple of our apps are not up to date?" Now I just go to checkmate and I say, "Oh, I got update those three or whatever." So yeah. I love that there's different angles for it and the best ones come from your experience. Right?

Rizqi Djamaluddin:
Absolutely. Do you want to do a little detour right not about Dev UX? Because that's something I'm really passionate about.

Matt Stauffer:
Do it. Let's do it. Yes, absolutely.

Rizqi Djamaluddin:
People don't vouch their dependencies. People decide, "I want to have this little thing. I'm going to pull it in." And when you really think about it, I've had someone... The most fun interactions in my work in Indonesia is I'll talk to like a business person and they'll be like, "Okay, how much is this application going to cost me? I'm like, "Well, the framework's free. This is free. That's free. This has a very generous $10 a month subscription." They're like, "Wow, you guys are kind of nuts. You just give out your code for free." Like in any other industry that's not going to work. You're not going to have people giving up patents, but that's just how we work. We're cool like that. But at the same time, it means underneath each web application or any application, there's a giant tree of dependencies, which you have never seen in your life. And it's possible one of them down that chain will have a vulnerability halfway up.

Rizqi Djamaluddin:
And this is where I think developer UX is essential. For the consumer side, for us, people who use packages, who use these open source magic kits, we need to make sure that we develop that culture of learning about how do you lock them down. Because for example, even really high-level things like Elasticsearch or Mongo or Redis have no authentication by default. They just run because ostensibly it's because they are expecting to run in, for example, in Kubernetes or in some environment where that is locked down by people who are experienced, but Joe developer, who just graduated high school and just tinkering around doesn't know that. And if you are a developer on Elasticsearch or any of those services, make sure you provide that. You provide a simple checklist for, "Hey, thank you for using our tool. Here's how you secure it."

Matt Stauffer:
I love that.

Rizqi Djamaluddin:
For a while I think Elasticsearch, even paywall that stuff behind one of their subscription services. Redis doesn't even have any sort of authentication that expects you to do it on the network side, which makes sense for a real application. But a lot of people don't know that. People are living on shared hosting and still... People don't know how to do that kind of stuff.

Matt Stauffer:
I love that. Yeah. The security defaults and the clear instruction for the least knowledgeable people about how to make sure that they're not biting themselves in the butt by... Not biting, anyway, they're not making a bad decision by setting your thing up with the defaults. I think that's a really great point. And again, that's one of the reasons why I really appreciate tools like Forge and stuff like that is because I'm not a professional DevOps person, right? I know enough. I've been working in Linux servers for a long time, but I can't tell you that I know all the aspects of how Redis communicates over the network and what its authentication scheme is like or anything like that. So I'm glad for people who automate those things, but I also love your idea that people who are building anything targeting developers, let's take the responsibility of helping those developers do the thing in the way that doesn't really put them in a bad situation later. And we throw our hands up and say, "Oh, well, it's not my responsibility."

Matt Stauffer:
Well, people are going to use your tool so take some responsibility for them. I love that.

Rizqi Djamaluddin:
I've met so many situations where a documentation, for example, will tell you, "Oh, grab an API key." And you're like, "What scopes do I need? Just everything?" And like, "Well, look on Stack Overflow. They say use everything? So, aah." That kind of habit.

Matt Stauffer:
And all of a sudden... Yeah. And that's a thing I love about API scopes is when we implement them, it allows people to really kind of limit the potential damaging impact. I feel like maybe that's something that people don't know a lot today about limiting the API scopes or limiting the database user's access to things or limiting your Ubuntu user on your server. Just like we were saying before, right? Like if I don't have production credentials in my table plus I can't accidentally wipe the production database. If a database user doesn't have the ability to do anything other than read databases, then that database user being compromised doesn't hurt you as much.

Rizqi Djamaluddin:
Absolutely. Limiting your avenues of attack, your attack surface and what you are liable for. I like to ask that to newer developers we're talking about security, "Tell me what ways your application can be accessed. How do you log in?" I'll be like, "Well, usually just username and password." But in reality, there's often this... the attack surface is massive. Like you'll have the password resets. So you have Magic sign-in links. You have all-auth, you have JWTs, you have all these different ways to access and you don't really think about it. And so again, reducing that surface, making sure that you're only enabling what you need both internally and externally, like the ones you mentioned and also what people can use to attack you is essential. Just locking all that down. We're not used to that as programmers. We're used to having all the options available to us.

Matt Stauffer:
Yep. Because it's a pain to have to lock things down because now you have to remember what you used to log into or whatever. So yeah, there's definitely a value to be had in locking it down by default and then incrementally releasing access only when it's needed, rather than having everything open by default.

Rizqi Djamaluddin:
Absolutely.

Matt Stauffer:
Okay. So we went down a little bit of a rabbit trail here. I know that you've got notes. So I'm going to ask you what's next for you? What next do you want us to talk about?

Rizqi Djamaluddin:
If I can piggyback off your platform, Matt and say something which is really important I think to a lot of developers and foreshadowing, this might be a sneak peek into an upcoming talk I might do at some point.

Matt Stauffer:
Oh, cool.

Rizqi Djamaluddin:
Be very aware that security is only as good as it is usable. No matter how good your metal, steel, titanium house door is, if there is a dog or door underneath it and the dog can be trained to open door handles, it doesn't matter. A lot of what I see when the security issues happen is... So, for example, website will get hacked and people will get alerted, say from the media saying, "Hey, if you used so-and-so e-commerce, your account is compromised." And the company is obviously busy scrambling around. They don't have a checklist. They don't know what to do. They don't know the power structure. They don't know who's making the phone calls, who's locking down the servers.

Rizqi Djamaluddin:
I have seen literal offices of people running around in literal circles because they don't know who has access to the servers, who's on today, who's on monitoring, who has the email password, everything breaks loose and obviously the attacker is making everything worse. And the users are left to fend for themselves. And so if you have a website which manages people's personal information in any way, even as simple as like a file upload or something, like if you have people's personal information and you're important to somebody, then make sure you have the tools so users who are in a hurry to make quick changes to their account can do so. They should have a button to delete their account quickly. They should have a button to check recent logins. They should have a button to see where they logged in from and they should be able to log out from other sessions, which are ongoing for example.

Rizqi Djamaluddin:
Because when we talk about security, we talk about these big hacks, but there's also a lot of small hacks day today. Somebody's password gets leaked or somebody's password posted next to their monitor gets stolen by a disgruntled ex. And these precision attacks happen daily all the time and users will panic. And you need to spend time thinking about the usability of your software. If that password reset button, if that delete account button, if the change email button, page, whatever is too hard to use, it doesn't exist. So spend time thinking about how will your users be able to react if they are compromised, for example. Can people extract their data?

Matt Stauffer:
I love that.

Rizqi Djamaluddin:
How do they change their password? How they lock it down?

Matt Stauffer:
It's almost another checklist, right? Because you've talked about how do we respond when our servers are hacked, but then you're also trying to think about what things are you allowing the user to do? Like imagine yourself in their scenario, what would you want to do and how hard is it to do those things?

Rizqi Djamaluddin:
Yeah. Like, how do I get rid of my credit card? How do I check if they made a purchase off my credit card? Which credit card was it? People have multiple credit cards. All that chaos is happening. And as a UX designer I find that more often than not the biggest security failures are actually UX failures.

Matt Stauffer:
Yeah. Huh. That's a really good point. Okay. So we have talked a lot. We talked a lot about application design and we talked about dev UX. We've talked about specific technical things that are difficult for people. I know just based on the length we've been on, we probably need to start wrapping it up, but I bet you have a couple of other things you really want to make sure that we get to before we're done. So what are the other couple things we haven't got a chance to talk about that you really want to make sure we cover?

Rizqi Djamaluddin:
Top one, and this is more of a personal note for me is be careful with the words, "I didn't think we needed security there." And be careful of those Band-Aids you do? Because those are some of the most common things people run into because they'll be coding something. They'll be like, "Oh, it's a hack thing. It's just a couple of days. I'm just going to throw up a play project."

Matt Stauffer:
Just throw it together.

Rizqi Djamaluddin:
But the problem is people's data doesn't care if you're a hack project or if it's a real one. And if you have users and they have information... I've seen image hosting websites where they're usually like, it's just people's photos. What could possibly go wrong? And then somebody who like has their dead grandparents last photos in there suddenly lose access and they're panicking. It's important to think that we as developers are in control of a lot of people's lives and a lot of people's happiness and a lot of people's privacy. And so again, that culture, that habit of treating everything seriously, of taking every request, making sure that your website has a link to say, "If you find a bug on my site, please email me here."

Rizqi Djamaluddin:
There's a really good story lately from a, I think it was a phone case company who had a massive vulnerability but the developer tried to contact them and they just never got a response. They contacted the customer support. They were like, "What are you doing? Don't do this to us." Like, "I'm just trying to tell you what's wrong." And just having a plan for all that and taking everything seriously, taking security seriously is a massive thing.

Matt Stauffer:
And it's a culture thing just like you said. Like, even if you don't have that find a bug link, there's probably a contact link somewhere. But if everyone's just terrified of it, then it doesn't matter that they got in touch with you in the first place.

Rizqi Djamaluddin:
What do you do? And when you're browsing like... I really like it when you're browsing GitHub and you look like through issue threads and stuff, and you see people complaining, how do I fix this problem with CORS? And someone underneath it is like, "Oh, easy, just add this one command." Or, "Just comment out this line in your vendors." It's always stuff like that, man. It's always the small things which come back to bite you later on.

Matt Stauffer:
Yeah. All right. Any other things high on your list you want to make sure we cover before we wrap today?

Rizqi Djamaluddin:
I think that's it. This conversation can go on for hours. Obviously it's a massive landscape.

Matt Stauffer:
Yeah, exactly.

Rizqi Djamaluddin:
But I don't want to overwhelm people and I think it's important that just developing the culture and knowing the common attack vectors are very important. As I know, you're going to go into like what resources we want to go into here?

Matt Stauffer:
Yeah. Let's just go there.

Rizqi Djamaluddin:
I highly recommend, and this is more important than anything is to stay up to date with recent attacks, recent occurrences. And that includes knowing the version history and new releases of your frameworks and stuff like that. So if you're relying on particular frameworks or particular technologies stay on top of those. For general purpose stuff, I also really recommend looking at global cybersecurity reports. So a really easy one to get your hands on is the Verizon cybersecurity report. They have one for 2020. And it breaks down to the types of attacks happening worldwide. So you can calibrate your risk factors and it will talk about how misconfiguration is more common, an issue than for example, password reuse and just stay tuned, stay up to date. OWASP is the obvious classic resource, but MDN and Mozilla have their own little interpretation, which might be a bit more applicable. Just stay in those communities, keep your ear down to the ground and listen up.

Matt Stauffer:
I love it. So if someone... Oh, hold on. Last thing. Second last thing. Before we get to asking for people to follow you or anything like that, personal thing. So I told you at the beginning, I feel like you have been in the Laravel community for the longest time and I just haven't known you at all and I felt... There was a couple of things I wanted to ask you. One was just about your history, but the other one as I just said, I just got to be honest with you, I know nothing about Indonesia and nothing at all. I know so little about Indonesia that I don't even know what I don't know. You know what I mean? I don't even know what question to ask there. And one of the things you had mentioned was it's the, I think the fifth largest, most populous country and we just don't know this. So for someone who...

Matt Stauffer:
As an American, I have general concepts of India and Pakistan, and I have general concepts of a lot of areas around you and I have so little knowledge of Indonesian culture at all. If there was something where you would say, if anybody knew one thing about Indonesian culture, I wish that they would know about this or as we think about visitors to Indonesia, the first thing we want them to do is to see, or to try or to experience this. What would that be for you?

Rizqi Djamaluddin:
So Indonesia as a people we are not very outspoken. Of course there's outliers in every community. But Indonesians are one of those very strong family base, like you would expect in Asia, honestly, where you can come to a family, you can have a chat, you can sit down with them, you can listen to their life stories, just like mine. And they'll probably be a lot more interesting, to be honest. And if anybody's going to come to Indonesia I just highly recommend just going out like... Here's the problem, we are in the tropics. If there's one thing I can borrow from you guys in the West, and the upper latitudes, it's please give us some of that cold weather, the fact that we can't go out, people ask why we don't have pedestrians here and it's because it's 38 degrees out there sometimes.

Matt Stauffer:
It's so hot.

Rizqi Djamaluddin:
It doesn't make sense. But when tourists come here and they visit Bali, because Bali is always the most common tourist spot, at the same time, just go out to a random village and say hi, and people will be more-

Matt Stauffer:
I know.

Rizqi Djamaluddin:
... than happy to just spend some time, chat and relax. It's some of that older Asian experience I think which is just slowly being lost as larger countries like India and China are rapidly developing. Indonesia is a little bit underneath there. Like we're just catching up. And so a lot of people are very eager to make new friends, meet new people, learn about the world.

Matt Stauffer:
That's cool.

Rizqi Djamaluddin:
Sometimes we get a bit of a reputation of being a little bit behind and obviously as a once colonized country, that's kind of inevitable, but sometimes we just need to get to know more people. As you said, we have a big population, but none of them have ever met anybody. And we are very open to visitors once all this is blown over for obvious reasons.

Matt Stauffer:
Right. When people can actually travel again.

Rizqi Djamaluddin:
When people can actually travel. I hope hospitality in Indonesia will be something people really enjoy.

Matt Stauffer:
Oh, I love that. And you taught me how to pronounce it. I already... Jakarta?

Rizqi Djamaluddin:
Jakarta.

Matt Stauffer:
Is that right?

Rizqi Djamaluddin:
Yep.

Matt Stauffer:
Yeah. Jakarta.

Rizqi Djamaluddin:
Jakarta.

Matt Stauffer:
So is that the largest city, the capital? I mean, because when I think of Indonesia, those are the two things I think of, it's Jakarta and Bali. Is that the main kind of tourist area, main place where flights come into and everything?

Rizqi Djamaluddin:
Jakarta... Okay. If you want to play a guessing game. Well, okay, fine. I'll make it quick. My company is based in Finland. I work for Javilla, a recruitment company based in Finland. And I'm just going to say my district in Jakarta is more populous than the entire country of Finland. Jakarta has-

Matt Stauffer:
What?

Rizqi Djamaluddin:
... I want to say roughly 40 million people in the metro area. We're one of the world's largest right up there with places like Tokyo and stuff like that. And yes, Jakarta is the nexus, but I would consider Jakarta more of the LA of Indonesia. It's a business district, not as much a cultural district, economic district, financial district. But yes, hop on down. This is the nexus basically where people just drop in, hop another plane, go somewhere, go-

Matt Stauffer:
I was just going to say, you're going to fly into there and then you're going to get your flight out to where you want to go if you wanted more of a cultural experience.

Rizqi Djamaluddin:
Pretty much. But Jakarta is one of those cities where you'll find a skyscraper right next to a traditional, I wouldn't want to say village, but just basic housing of like middle... what you would expect from like a developing Southeast Asian country. So there are places to explore in-

Matt Stauffer:
That's cool.

Rizqi Djamaluddin:
... Jakarta. If you like exploring, just want to have a wander and also just hit me up. Indonesia is a very open place.

Matt Stauffer:
I love it. I'm hoping to get back to Laravel Australia. So I'm just trying to think about like what excuses am I going to have at sometime in the near future to be eight hours... eight time zones away anyway. So the idea to just be able to drop into a major hub and just kind of like hit my friend and wander for a day, that sounds pretty nice. So maybe I'll get to see you once this is all over.

Rizqi Djamaluddin:
Top tip about that, Indonesia has one of the world's most open visa policies.

Matt Stauffer:
Really?

Rizqi Djamaluddin:
Well again, when all this has blown over. Basically if you have a passport, you can basically get here. It's almost guaranteed.

Matt Stauffer:
Awesome. That's wonderful.

Rizqi Djamaluddin:
Just show up, rock up, say you know Rizqi and it's walking.

Matt Stauffer:
Oh, everybody knows him. Yeah, there's 40 million people here, but we all know him anyway.

Rizqi Djamaluddin:
Yeah. We're a tight family.

Matt Stauffer:
Okay. Yeah. Right. Okay. So the one other thing is I feel like, and I could be wrong in this, but I feel like you have been in the Laravel community since the earliest days. And I mentioned this to you before, but you know what? There's a lot of people who I know from the early days who I've had some reason to actually meet face to face, to conference or something like that. And I feel like I've known you from the earliest days, but only from a distance. Am I right that you have been using Laravel for a long time? What's your origin story with Laravel?

Rizqi Djamaluddin:
Yeah, I've been around for a very long time, but I think I really cut my teeth on the community through IRC back then. And that's-

Matt Stauffer:
Yeah. And I was in IRC too. So that must have been-

Rizqi Djamaluddin:
Yeah. That must've been then. Back in the good old days of when we'd have all the people on the IRCs. It's different man nowadays, but it's-

Matt Stauffer:
Yeah, it's a big community now.

Rizqi Djamaluddin:
... quite nice because the community back then was quite a bit smaller. Even till today I go to Laracon EU almost every time I can because Shawn is a good friend and we can just meet up with the community there that's... The Laravel community is more open and more of a society than just a programming forum, which a lot of people think it is.

Matt Stauffer:
Yeah. For sure. Have we met at Laracon EU and I'm forgetting? Because I do that all the time and if so, I feel like an awful human being.

Rizqi Djamaluddin:
I don't think so, because I think I just keep missing-

Matt Stauffer:
Okay, good.

Rizqi Djamaluddin:
I've been looking for you sometimes in Laracon EUs because I have a bad habit of preparing my talks the night before. I just-

Matt Stauffer:
Yeah, totally. No, me too. Yeah.

Rizqi Djamaluddin:
Yeah. People think-

Matt Stauffer:
The night... Go ahead.

Rizqi Djamaluddin:
Now, people think we're prepared. I don't... The night before it's a little panic day as we're getting everything cramped in.

Matt Stauffer:
Yeah. I mean, no matter how much preparation I do, I'm still so anxious the night before I'm working on anyway. So yeah, I've missed the last couple of EUs unfortunately, because they always overlap with my son's birthday.

Rizqi Djamaluddin:
I see.

Matt Stauffer:
And I've just promised my kids that I'm never missing your birthday for a work thing. And so every year I'm like, "Shawn, when's it going to be?"

Rizqi Djamaluddin:
Take them to Amsterdam.

Matt Stauffer:
Listen, I am sorry... Yeah, exactly. I'm thinking about it. Honestly, it's kind of tempting now he's a little bit older. But, yeah. So that's why I keep missing them, but I love Laracon EU, wonderful community, wonderful group of people and hopefully I'll get back there one day. All right. So... Oh, go on.

Rizqi Djamaluddin:
In that case, I really hope I'll be able to visit the Laracon US and we can be there as well. The flights, man. The flights.

Matt Stauffer:
Yeah, that would be awesome. I know. Yeah. I still can't believe people come up from Australia and other places that are so far away. Okay. So if people think you are wonderful, which I'm sure they do and want to follow you or to give back to what you're doing or anything like that, what would that look like for them?

Rizqi Djamaluddin:
I can always be contacted by anybody on Twitter Rizqi_DJM because Twitter for arbitrary reasons doesn't allow my full name, which is Rizqi Djamaluddin because it's too long. So that's Romeo, India, Zulu, Quebec, India, underscore Delta Juliet, Mike. And I know that's hard, so I hope it will be accessible in the show notes or somewhere-

Matt Stauffer:
It'll be in the show notes too.

Rizqi Djamaluddin:
I hope.

Matt Stauffer:
Yeah. Yeah. It'll be-

Rizqi Djamaluddin:
And I don't tweet very often because I am not that type of person as in, I like being a little bit off the grid, shall we say, but I am always open the DMs and if people want to consult or ask or just discuss, I am more than happy to chat. And if you want to take it somewhere else too, I'm more than happy. I'm also on Laravel Slack and various other communities. So if you find me there under my name Rizqi, just to hit me up.

Matt Stauffer:
Awesome. You are amazingly open to help for somebody with the amount of knowledge that you have. So I really, really appreciate-

Rizqi Djamaluddin:
Thank you,

Matt Stauffer:
... you being willing to jump on. With somebody you don't really know very well I mean, I like you a lot. I'm glad we're friends now, but... And just share all the stuff. So thank you so much for all the contributions you've made. And I would assume that if you were to do more talks in the future, they would be listed there. So that might be a good place if people even just want to follow you, maybe not a lot of tweets, but when there's going to be some more content that you're creating, it will be listed there.

Rizqi Djamaluddin:
Absolutely.

Matt Stauffer:
So that's definitely a good idea.

Rizqi Djamaluddin:
There are stuff coming down the pipe pipeline, don't worry.

Matt Stauffer:
There we go. So follow Rizqi purely for that reason. Well, I had a ton of fun. You mentioned this and of course everybody knows this, but I could talk to you for three more hours about this and I'm learning so freaking much. So I look forward to digging a lot of these things, all y'all, if you liked all this stuff, everything's going to be in the show notes. And as always, if we miss anything in the show notes, let us know and we'll fix it up. And, yeah. Thank you again.

Rizqi Djamaluddin:
Thank you. Thank you very much.

Matt Stauffer:
All right. See y'all next time.