Web Security, v2

Plain Text Passwords

Steve Kinney

Steve Kinney

Temporal
Web Security, v2

Check out a free preview of the full Web Security, v2 course

The "Plain Text Passwords" Lesson is part of the full, Web Security, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses the importance of using libraries instead of writing your own code for tasks like parsing request bodies and handling security. He demonstrates how to use the Cookie Parser library to handle cookies in the app and points out the security issue of storing user information in plain text.

Preview
Close
Get $100 Off
Get $100 Off!

Transcript from the "Plain Text Passwords" Lesson

[00:00:00]
>> Steve Kinney: All right, so we're gonna run npm start to look at our list of all of our fun examples today. The first one we gonna look at is this one called cookie jar, and we'll open it up. And for starters, it is a relatively simple app that we are going to exploit.

[00:00:21]
So this is an Express app running on Node.js. We'll use a SQLite database that's kind of like the standard kit for us, because like, yes, the principles apply regardless. And we will try for the most part we use one or two libraries, but for the most part, we'll keep things to the stuff that is generally applicable to whatever, whether using like Next or Sveltkit or Rails or some Java monstrosity that has existed long before you work there, like whatever.

[00:00:51]
We'll kind of play around that as well. I just kind of made this little abstraction here, honestly, so that we could keep a lot of the boilerplate code that wasn't important out of the way. You can go ahead and take a look at if you want. It's just, configuring the ability to parse request bodies, so on and so forth, and some various settings as well.

[00:01:13]
Cool and sue. Let's go back over to where I was in a cookie jar, we've got this index.js, which is our server at this point. Out of the box, Express does not come with any support for cookies, so we'll talk about how to pull that in. For future ones, I just had it already set up, so I overrided it with being I don't really want cookies right now, and then we'll add them in ourselves.

[00:01:40]
That way, we can tweak them and see them a little bit, and we can see some of the changes that we're gonna do. So this will be done for us kinda going forward, but just so it doesn't look like magic to you, let's try this out real quick.

[00:01:51]
So there is this well named library called cookie parser. It does what you think it does. It takes that request header that is It's got the cookie that we saw before, and it has a string with all those semicolons. And you know what it does? It grabs that header off the request object, and then it separates out all of the different keys and values by the semicolons so that you're not doing string manipulation by hand.

[00:02:17]
Which kind of hits one of the core tenets of what we're gonna talk about today, which is, don't write your own database, don't roll your crypto, and honestly, like, in terms of when it comes down to a sanitizer or anything like that, grab a library, right? Look at it, because there are some that are known deprecated, right, especially when we see, Csurf, right?

[00:02:39]
There is an express module that was built into Express that has been deprecated cuz it was actually riddled with security holes. So do your research, but maybe don't roll it yourself so you're implementing your own new security holes. There's something about having eyes across the industry on something.

[00:02:57]
Cool, and so we'll get that in place, and we're just gonna pop in that middle where we'll say app.use and we'll bring in this cookie parser and so if there were no cookies at all, we got that cookies are disabled. This app should and does restart whenever we change the server.

[00:03:15]
So we don't have to kill the server every time as well. Again, these are the things I didn't wanna do over and over again. So now if we refresh it, we actually get the real page, which is this login screen. Now, this is intentionally at first not a particularly secure app, but if we look in our database file, we've got just some users that are already loaded into the database, right?

[00:03:37]
And so, we've got our good friend bobbytables. We will look at XKCD a cartoon later if you have not seen it, cuz it's worth it. And you're actually legally required, if you do any like course on web security, to reference that cartoon, which I'll show you, but you're legally required to references.

[00:03:55]
Otherwise you actually can't like brand the courses web security. So, great. And so we got bobbytables here with some of my favorite CSS colors as their insecure passwords. So let's go ahead and we'll try that out. And we'll say we got bobbytables, papaya whip. Now you can argue, if he was live coding, why didn't he pick passwords he could spell?

[00:04:20]
That's a great question, I'm glad you asked it. And so we've got this little application that seems like a precarious button. Before we hit that button, let's go ahead and look at some of those other tools I saw you. That's called like, building intrigue, by the way. All right, so we've got this application.

[00:04:41]
And we don't wanna throttle. We wanna go to this application here and can see that I've logged in and I am bobbytables, right? But this is already bad. Does anyone know what crucial mistake I have already made here? We've stored who we are in plain text. And anyone go ahead and decide, you know what?

[00:05:03]
I am going to be someone else. And now when the browser goes, it sends that request. We look for that username directly, it turns out now if they get something wrong, they're not in the database and this app does not have great error handling it. But this is already like, again, yes, an obvious mistake, but also the theme of, you can obfuscate this, you can encrypt it, you can do all sorts of stuff.

[00:05:25]
But if someone still has various levels of sophistication for getting it, you end up in the same, some version of the course of our day will likely end us in the same situation that we are in the very beginning, just with added layers of sophistication as we go along, right?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now