/assets/images/CISO logo 2-color cropped.png Hardening Web Applications Webinar Transcript | True Digital Security

Your browser is out of date.

You are currently using Internet Explorer 7/8/9, which is not supported by our site. For the best experience, please use one of the latest browsers.

Request a Consultation

Hardening Web Applications Webinar Transcript Watch On-Demand Now

Lisa Remsa [00:00:07] Everyone, thank you for joining us today for today's TRUE Talk. My name is Lisa Remsa in the marketing manager here at True. It is my pleasure to introduce today's webinar, which is hardening your web application. It's going to be presented by true security consultant Christopher Wall. This presentation should run about 45 minutes with time for Q and A. Please feel free to use the control panel to submit questions during the presentation. If we run out of time and are unable to get to all questions asked, we will make sure to respond by email post. So thank you again for joining us today. And with that, I'm going to turn this over to Chris.

Kris Wall [00:00:45] All right. Thank you, Lisa. All right, guys. My name is Kris. I'll be presenting How to Harden your web app today. And let's go ahead and get started.

Kris Wall [00:00:56] All right.

Kris Wall [00:00:58] So just a little bit about me. So who is this guy? I do work for True Digital Security. I've been an I.T. guy for over a decade, went into web dev for about two years and started got involved in the local community. We created the Oklahoma City Ethical Hackers. I've helped run several conferences, including the BSidesOK. I joined in with True Digital Security and have become OSA CPE certified as well as I'm working on my OSWE.  For those that know those are very challenging tests and the penetration field, our penetration testing field and really great certs to have. So there's lots lots to learn. Lots of fancy letters that come behind my name. But it's all been it's all been a learning experience. So let's go ahead and get started.

Kris Wall [00:01:50] So today, usually I encourage those who that are listening into my to my talks to not take notes. I'll tell you when to take notes. I really want to engage everybody. I want this.... We're gonna take a philosophical approach.

Kris Wall [00:02:05] We're not going to get too deep into the into the weeds, into the nuts and bolts. And that's on purpose. I want you to see what the technical challenges that we're trying to overcome.

Kris Wall [00:02:17] But at the end. I'll switch it over to where we're taking notes. Plus, this is a recorded webinar. So you guys can be watch this webinar at any time. We'll make sure that everybody gets links. I'll answer any of your questions, but I really want everybody stay engaged. So once we get to the points for notes, I will let you know, hey, this is spot that we want to start listening in to our joining any of those notes.

Kris Wall [00:02:40] So is this the tools talk? This is not a tools talk. I'm not going to talk about tools. There are so many different tools, some different flavors of tools.

Kris Wall [00:02:49] There's only one tool or type of tool that I will talk about that you do need to be able to compress these things for your team to be able to to do the type of testing that we're gonna be talking about today to verify your web application secure. And that is a intercepting proxy burp suite is an intercepting proxy. You'll see several screenshots of that today as well as there's a couple others. There's ZAP, there's OWASP ZAP and several others out there, Fiddler, that are very useful tools. They're intercepting proxies. That's bits of information you're going to need to know. But outside of that, we're going to we're going to stay away from tools. This is not a tools talk. And that's important because we need to talk about, well, what what is this talk about?

Kris Wall [00:03:34] If we're not going to talk about tools, we're not going to get super in-depth into the nuts and bolts. What are we to talk about?

Kris Wall [00:03:38] What we're talking about, the philosophical approach, things that you can do to keep... to prevent roughly 99, 98 percent of all attacks on your web application from occurring there? It's impossible to hit every single every single vulnerability that could come along. But these are the main components, the main the fundamental principles that if you maintain on your web application, your customer application for your organization, that will help you stay secure. And as long as you keep up with these things, then then that's something that's going to be very beneficial. So we're also going to talk about as I go through here, I'm going to talk about how would we prevent and remediate these problems? How would I keep these problems from continuing on? We'll talk about some of the more common issues that a lot of organizations will experience and how how we've actually explained how to fix those. Now, I'm a pen tester. I work for traditional security. So my goal is to go to organizations and to explain to them. I after I take time and I tear apart the web application and then I take time to explain, hey, this is how we did it. These are the things that I saw. And I create a report and then that report you're able to look over and see all the different action items. So each item that I say is a problem there, whether it's not hippo compliant or whether there's there's some there's some piece of the application that's fundamentally broken. And I I create a report and that report is graded. I provide that to you guys. And it allows us to have a better understanding of what needs to be fixed. How urgent is it? What what do we need to do? And it's very important that we make sure that that I translate what we're going to talk about today into how into that report. So everybody understands what what are the high party items and how we can translate that into actionable items. Once again, disclaimer this is by no means every single type of attack. There's no way to cover all of them. But this is a great way to cover the main ones you guys should be focused on. You may have some very specific ones that Twitter your application may use.

Kris Wall [00:05:54] For example. You may be you may have a Java struts application and that there's very specific updates you should run. We're not gonna talk about this today. We're gonna talk about some of the main pieces that you should be thinking about. Once again, coming back at this from a more philosophical approach. So let's go to get started. All right. So scanners. So isn't our app secure because we use a scanner? Well, the fun answer is no. No. So web application scanners are great at finding common vulnerabilities.

Kris Wall [00:06:29] These are things that have already been found in the wild by somebody. So your web application scanners, whether they be Nexus, or Qualys or several other pieces..Arachni. So these tools, these scanners, are designed to find known problems and applications. And if you are creating a custom web application, the scanners, well yes, they're going to look for known or common problems. So, for example, some frameworks will will use the... You'll be able to create an entity, you know, will be .js file, but then your developers or your configuration management forgets to come by and remove the .json file of that entity.

Kris Wall [00:07:14] Well, that .json file is going to have information attached to it. So that entity may give up information. So a scanner by default will typically look for those things. It will automate the boring tasks, the tasks that we have to run on everything. So just because you scan it with a scanner doesn't mean it's going to find absolutely everything.

Kris Wall [00:07:36] You'll be able to find a lot of cross-site scripting. These are things that you can you can come out with an automated approach. But here's some of the things that it's ineffective at. So here is a real world with bits and pieces of information change.

Kris Wall [00:07:49] So we're not talking about exact exactly which test this came from. But this is a real world code example of... I was in the middle of a pen test, I found a page, and that it was a very strange little, little application. And when I was in there, I went to log in and it immediately denied my login without sending anything to the server. So my intercepting proxy didn't catch anything going out to the server. So how does the web app know that I have the wrong username or the wrong password? Well, so I took a look at the page source, which in this case was just a html javascript and I was able to see "Oh hey. So there is a function in here which will validate and validate the credentials placed in it. So it all happens inside the browser and it pushes forward. And then if you get that right, it sends you to the next spot. OK, cool." But there is no web application scanner that's going to be able to pick up on that very don't have the ability to look through functions of this type.

Kris Wall [00:08:57] They can they can do some dynamic processing. But really,  this is a huge glaring hole. You should never use this for securing your applications. This is something web scanner would be very ineffective at picking up on.

Kris Wall [00:09:14] Web application scanners. Unfortunately, so... So what are they good for? And that's what we're talking about, the the the boring stuff, the things that you have to check, where you have to come and you have to try and in place, whether it is a SQL injection site, the cookies inside the headers, maybe it's the doing command injection site, the user agent. So every application is at risk for these these issues to be there. Or a web developer may forget a backup file that's on the server. And we know all I can pull this .json file or this .html or .aspx file. Is there a backup file of is there a .zip? Is there .tar of that? And can I find that information? So this is the web site. web scanner will automate a lot of these borrowing tasks that you have to do. But just because you scan your web application with a web application scanner doesn't mean it's secure. So that's that's that's lesson number one to think about.

Kris Wall [00:10:12] So moving on. Let's talk about entropy. So what's that? Well, entropy is is the idea of of making something difficult to anticipate. It is the idea that something that is difficult to or impossible, hopefully impossible, to be able to anticipate whatever the next, the next stage is or what the next iteration would be. You see this quite often in cryptography. And so we're totally safe because we use cryptography. Right. Well, let's let's talk about that.

Kris Wall [00:10:49] So, rhetorical question. You're going to look at this and your problem and ask yourself, well, what is that? And I would I would ask you the same. Well, what is that? That is..Well, it looks like a nice cryptographic secure sequence. It's probably a hash. So what is this? Well, one easy way of finding out is just Googling it.

Kris Wall [00:11:09] Let's see. Can I find this hash? Can I find whatever the string of text is anywhere else? This will give me a quick idea of we've seen it before, whether it has high entropy. And in this case, there is. Well, three quarters of a million results. And lo and behold, this is the Indy 5. The hash of one. So it ends five hash of one. So if you're a web application and I've seen this before where web applications will just hash something and then pass that hash.  If it's a simple hash, especially the hash of one or the hash of password, all lowercase or something along those lines, that is a case where it's too easy to guess. It's been seen too many times. The entropy is  far too low because it's easy to guess what that is.

Kris Wall [00:11:56] Here's another one. So quickly, look at this one. It hopefully does it make any sense to you, but to show when we ask Google, hey, do you have any of this? Google says, well, I've got five results. And surprisingly, one of them was actually the answer. But that's just to show how how much more difficult it can be by simply changing that what you're hashing.

Kris Wall [00:12:19] All we did was add the plus one and that made the the entropy that made what the system was expecting or how easy it is or difficult it is to guess what we're going to do next. It was dramatically harder. And that's the important piece here. So this is, this is the equivalent of adding, for example, assault to a to a thing that you're hashing. It's very helpful. It adds makes it more difficult to guess. So, Bill, entropy is very easy to test for, easy to crack, anticipate and unfortunately, forge. So, for example, I've seen I've seen an application that users were running developers that created their own multi-factor authentication.

Kris Wall [00:13:01] And in this case, they were using they were using MD5 hashes of simple numbers. And that those simple numbers really created a lot of problems, because all you had to do was guess the right number of four digit number and you had 30 minutes to guess it and watch it come back on the same point. But you had 30 minutes to guess what that number was and supply the hash to it. Well, back here. That's easy to crack. It's easy to anticipate and very easy to forge, whatever the next number is. So that allowed us to change and try to guess where we are in line and be able to overcome that multi factor authentication, what high entropy should look like. Is this. So if you go to Gmail.com or to Google and you look at there are cookies, you'll see some really bizarre looking cookie values. And this is an example of high entropy, the sort of things that are very difficult to guess. And you will likely never see this combination of characters ever again. At least you will likely not see. And Googling these, though, looking to see, well, has this pop up anywhere else probably will also reveal very few results.

Kris Wall [00:14:10] So high entropy isn't just applied to cryptography. High entropy is also applied to the way the application acts. So, for example, we can salt our hashes, but we can our information before we hash it. But it also applies to how the web application behaves. So, for example, if you throw in a a cross-site request for dirty token and you throw that into the site and that tokens always changing is difficult to anticipate.

Kris Wall [00:14:38] Well, that really frustrates pen testers. That really frustrates evil-doers or malicious actors that are trying to break into your application and be able to force the application. If we can't guess and anticipate ahead of time what the application is going to do, that makes it much more difficult.

Kris Wall [00:14:56] You can also see this with a token rotation. That was where every time that we connect your application, regardless of the request, we always use a new token. And that token has to be provided by the server. If I am able to just send requests and the server never forces me to get additional information and if I'm unable or able to anticipate what the server is going to send to me, it's much more difficult for me to abuse the server, for me to abuse web application, be able to send requests that were poorly configured. And this is where high entropy really comes into play.

Kris Wall [00:15:33] You want to make sure that any pieces that are super important, like your session I.D., which is used on most app web applications, PHP and Java have their own built in session I.D. You want to make sure that you are using the built in version of that. You could run your own. But doing so, you risk creating a session token or a session I.D. that is not as secure as you would want it to be. It doesn't have enough entropy. It's too easy to guess. And that would be a very big problem.

Kris Wall [00:16:03] Moving on. Let's talk about DRY. What is DRY? Well, DRY is just a short acronym for don't repeat yourself. So this is super handy for your developer. Are you developing teams to keep in mind? So the DRY methodology, the don't repeat yourself methodology has to do with. Oftentimes you'll see, for example, SQL statements and you'll see the SQL query is all throughout a web application. You'll notice that several of the secret queries seem very similar, and having similar SQL queries all throughout your web application means you really could have just used the same query. You built one query and just called that query a couple times. So having prepared statements where you have these queries prepared allows you to anticipate these the input that would be coming in and have these queries ready to go. And that way you have a single query that if it needs updating and we need to update the sanitation of the query, if you need to parameters the query, you're able to go ahead and do that and prevents.

Kris Wall [00:17:11] This is our number one way to prevent SQL injection as well as command injection is to prepare these statements, have a single query that makes all these operations and call that query hand into the parameters, hand in the values as parameters. And I know we're going to a little bit into the weeds here, but this is something that's fundamental that the web developers need to understand that by doing this, you really decrease these risks. If anybody watches XKCD, hilarious webcomic, they've got a great one here. Why you should always sanitize your database. And is this is the number one way to accomplish that.

Kris Wall [00:17:54] And here's a real quick example of a SQL injection, where we can, I can pass in this this weird looking user name where we say a single quote or one equals one with more single quotes thrown in there. And what that means is, is that essentially if you have them a misformed or malformed secret query somewhere in your application and I find it, and I hand it the user name of, well, this means true. It deevaluates to true. It doesn't matter if I get the password right. It means nothing. I'm gonna be able to login as the admin. If I'm able to find one of these, where it was just one simple mistake in the query, allows me to get it to overcome that. So you want to keep this in mind.

Kris Wall [00:18:40] So here's an example of a just a randomly found statement inside of a application. And and to those those of you that haven't seen any any development before, this is just a simple, simple query. It says, "Hey, go get the name that was sent to you. So name equals name and then do a query and select everything from the top of the database.... I'm sorry, everything from my table where the name equals name." OK. So this this is a great spot for me to do SQL injection." And this is ... you can find this in applications, where a developer just forgot to sanitize that name. He didn't sanitize the information before it came in. So how can we fix this?

Kris Wall [00:19:25] Well, we can have a prepared statement where we can say, "hey, name equals [the sanitizing function], so my SQL I... Real Escape String... Now Real Escape String is a function that was made by developed or somewhere. The name will always change. It will always be whatever your developers create for you. But this is, this is where the the cleansing process is actually performed. So anytime we pass something into this, it's already been it's been cleansed. So we, we will create this once. We'll call this as a, as a function, we'll pass everything in and then we we have built in sanitation where we're able to to process that altogether. And we have one spot to make these changes back in the day. web developers would create styles on every single page. This was early 2000s and they would put all these styles. And that was when we actually switched to CSS. And CSS, what's cascading style sheets, was allowed us to create one simple document and apply that to all of our pages. And this is what we're trying to do. We're trying to create one single statement, get it just right for what our application needs are, and then only use that throughout the rest of the application and update it as needed.

Kris Wall [00:20:44] So another benefit of the DRY methodology is could reduce it makes it make sure it could be simple to modify, allows you to isolate the flow of the input, makes your code base more modular. You're able to find orphan code and you can do unit testing. So let's talk about unit testing. What is unit testing? This is something that allows you to test your applications ahead of time and to see what the application logic does, what the fuzzing malicious input. It allows you to be able to see this information ahead of time and. And with unit testing, this is where your developer so let's go back to that that prepared statement, that SQL query that we talked about earlier. So you would write that once and you would reuse that multiple places? Well, the unit testing is where you comeback by and your developers are going to say, hey, I'm going to test that piece of code. I'm going to throw a bunch of units that are parameters at it. I'm going to give it. So, for example, it may be a cart. And that cart says buy X items of Y. And so I may say by negative 1 items of Y, whatever that is, whatever its books, let's say I'm going to buy negative 1 books. Well in unit test and throw negative one. I can throw zero. I can throw zero point two five at it. You know these are numbers that the applications should not process, but this is an opportunity for your developers to catch this in the act. It also is a point for your your developers to catch malicious input. So for example, let's say I said I want to buy. What was it? One equals one or one ad with some single quote thrown in there. So triggering a SQL injection. If when you guys are creating your web applications, if your development team is testing for these, you have everything broken down into modular functions.

Kris Wall [00:22:46] You can test with malicious input as well. You can not only do tests with negative one or what have I tried to buy a million items, you know, is the application going to allow that? But what if I try to buy that SQL injection we just talked about where I send that malicious input. So we want to avoid that. And the drive methodology was what allows us to simplify the code. I only have one copy of each function and then be able to test that it also. So when me as a penetration tester, when I run into that, that means generally the application could be more secure. Additionally, when we do our code reviews, it makes the code easier to read, dramatically easier to read. And having it prepared that way is it's easier to find the problems. It's easier to to make corrections. Just running with the drive methodology is one of your best options. All right. Let's talk about frameworks, so. All frameworks are secure, right? Well, what is a framework?

Kris Wall [00:23:55] For example, the Struts vulnerability that we talked about earlier. So if you guys look at this, what is this? Well, that's the Struts vulnerability that that hit that hit Equifax last year. And and this vulnerability was built in to the framework that they were using. It was built into Struts and,  unfortunately, while they were doing everything correctly with their framework, the one thing they weren't doing was updating the framework. Struts had already identified that there was a problem and that it had been fixed months before. But with with them using this this framework, they felt there was any of that need to go in there and review the code or update. We should be good. This is a classic example of an unauthenticated command injection where we you don't need to know anything about their application other than, hey, I can do a command injection here. I can I know what application they're using. I know what framework they're using and I can pass things in. So frameworks have lots of issues with them that you should be aware of. Now, out of the box, they work pretty well. So, for example, here's Ruby on Rails. It really will save your developers a lot of time. Remember when we talked about entities earlier? So we have a user and his this user's ideas one here we look there up in the URL bar. So we have an entity here. So Ruby on Rails allows you developers to save a bunch of time by creating this and having this prepared for them. And so this is great. But what if one of your developers forget to lock down the framework? So Ruby on Rails. What if what if they send the same request and add the .json on it the end?

Kris Wall [00:25:52] Well, now we get all the properties of that of that entity. And this is built into Ruby on Rails. If one of your developers or configuration staff forgets to lock down this built in functionality, somebody that's on the on the site can simply make the request by just adding the dot, Jason. And this is meant to be helpful to the developers. But at the same time, it's one of the things that definitely has to be locked down if you're using frameworks. It's important to know that frameworks, they're pre-built houses. They're a bunch of Legos that have already been pre assembled or pieces of wood that are assembled into walls and doors, windows. It's important that you know that by using the framework, you're inheriting all the problems that may come with that pre-built piece.

Kris Wall [00:26:39] You you save a lot of time on the framework and some frameworks are really well supported. Whether it's the angular framework supported by Google or the react frameworks supported by  Facebook, these are frameworks that will save you developers a ton of time. And that's very beneficial. But it's important once you start using those to understand what the changes are, what the problems are with those frameworks and the support for the developers to stay on top of that. OK, all right. Well, what if, instead of frameworks, what have we got a little bit smaller and we use libraries? Well, common libraries can be trusted. Right? So let's let's take a look. JQuery is a common library. You could argue it's a framework or it's a library. Now we generally treat it more like a library.

Kris Wall [00:27:28] It's a set of pieces that we add into our code that developers will use to be able to write their code a bit faster. They're not it's not a prebuilt system of of pieces. But J query it has some known vulnerabilities. So here we see that there's there's no vulnerabilities that pop up over the years affecting any versions. As we see less than 3 or 3.0.0, if we look kind of here in the middle or any versions older than 1.6.3. And this is these are known problems to these framework. I'm sorry, to these libraries, very specific to these libraries. And it's important for your team to stay up the date. Well, what kind of libraries are out there? So. So there's gonna be things that your team is not going to want to write. For example, an xml parser. I don't want to write an xml parser. That sounds exceptionally boring. There's plenty of them out there. A pass you wrote one called Xerxes awhile back. And that's very beneficial to be able to use that that parser to be able to have that ahead of time. And and nobody really wants to write their own xml parser. Well, well, but is there any is there any problems with us? I'll pass it. Well, this xml parser was discovered back in November of 2018 to have a xml entity attack our external xml entity attack. And this allowed you to be able to add in a bit of information, XXE, a little bit of information here.

Kris Wall [00:29:05] If you see kind of there in the middle and I'm telling it, hey, your an xml parser, I'm going to give you a piece of xml, whether it's in a word document PDF; they all have an xml in them. And I'm going to give you this document. And inside that document, it's going to request something. And then here, if you look in bold, it says file etc password. And it says, go get that. And so if you are using this vulnerable xml parser, that's the vulnerable library. It won't know. Oh, hey, I shouldn't go get that file. And you can actually force the server to do a task for you. This is this is quite bad. So this is this is an excellent example why libraries can lead you astray.

Kris Wall [00:29:50] Also, libraries kind of get out of hand. Your developers are probably familiar with NPM, the node package manager. It's a huge repository of of libraries that you can add to your projects and add very beneficial to have. However, NPM does not come up without its own issues NPM. Recently there was a library that was fundamental. It was a dependent library or dependency for several other libraries that the developer got tired. He didn't really want to maintain the code base any longer. And this is a common thing. So he gave it up. He let the community take over, somebody volunteering. He said, that's fine. I'm going to give it give this to you.

Kris Wall [00:30:38] Now, several other libraries, including commercial libraries, were required, this particular dependency. And so any code changes you made to this would affect those as well. And he gave it up. Well, this library ended up getting beat, being used for malicious purposes. And then you have a backdoor that was built into this library that affected all other depending libraries that that called the set. And this is an excellent example of where where good intentions ended up with somebody handing this to the community and and somebody with malicious intent took over it.

Kris Wall [00:31:15] So NPM should be used carefully. And this is an example of a of a marketplace for for these libraries. It's important to also keep in mind, NPM is also filled with a lot of silliness, a lot of applications that have never been vetted. I did a quick NPM search for Batman and I kid you not one of the Batman libraries in here says, well, you can see it at the bottom. The NaNNaNNan. And they there are several libraries in here that are less than fully vetted.

Kris Wall [00:31:52] And it's important that you're able to spot these that your development team knows how to find trusted libraries, how to be able to work with those and actually be able to do the reviews. Has the library been vetted? Has the library been made? Hand and also there's fun little libraries. I know we did. I said we wouldn't talk about tools. There's fun little libraries that are built for malicious purposes. And while you can add these to your application to do additional testing, such as that unit testing we talked about earlier.

Kris Wall [00:32:24] It's also important that you make sure that your development team or even your vulnerability team make sure these never appear inside of your inside of your applications that you want to make sure that. Yeah. This is great. But I don't want this to be available to the wild. You don't want this ysoserial to show up. And while it's great for your testing, it's great for your debugging. It's great for your Q A environment. It's terrible for production. You should never have this in production. And if I were to find one of these by simple examination of your application. My little to find one of these. I've got penetration testing tools or malicious tools built into your application, and that's why you should be very careful about the libraries. You use libraries. The pre-built tools are not pre-built homes. They're not full blown walls. They're tools. They are things that are meant to make you move faster. For example, I have a client that needed to do some custom encryption and I explained, well, this is great. You guys can do your own encryption, but we should go with a library that is that is well supported. You don't want to roll your own encryption once a year. Once again, we're back to the low vs. high entropy where we're into that realm of. Do you really want to build your own security? You want to build your own padlock. You want to do your own security controls. Well, I encourage my clients to avoid that. And in this case, I recommended a a library called PYCA, Python Certificate Authority. And it was a fantastic library that is supported by the community that is actively being developed. There is a bug tracker. There are people that are actively auditing this application, or this library.

Kris Wall [00:34:15] And while it's maybe not a perfect library, it is far more likely to work than some library that's been left abandoned for years that I really hope that your development teams have to stay on top of which libraries have been abandoned. Should we continue using these libraries? Or should we roll our own? So OK. So should let's talk about rolling your own.

Kris Wall [00:34:38] Should your libraries, should your development team write their own libraries? And is it better to do that? Well, you take on all those risks. Remember how earlier we talked about multi factor authentication and the client that rolled their own?

Kris Wall [00:34:52] I mean, that was great. That was really great attempts. But they made some really fundamental mistakes. They allowed 30 minutes to guess any, I guess, the combination. There was only 10000 possible combinations.

Kris Wall [00:35:08] And and on top of that, it was only the MD5 of a single number. Whether that number was 1, whether a number was 500. So really all we had to do was take a number, convert it to MD5, send it in and try to do that ten thousand times. And statistically, it would take about half of that amount of time to actually guess it correctly.

Kris Wall [00:35:33] So that's all we had to do. And this client. Yeah, they did a great job, but they still made some fundamental flaws. So this is one of those cases where just because you've created a set of wheels doesn't mean there may not be better wheels out there.

Kris Wall [00:35:48] And especially in the realm of security, it makes more sense to borrow that which others have created and vetted that the community is actively using. For example, that Python C.A., a certificate authority library that is a fantastic library, is well vetted. This is one of the cases where the community has much better wheels than what your team has started to develop. Now, I'm not saying that your team couldn't develop something as good or better, but in many cases teams are strapped for time. And this is one of those cases where it would actually make to make the trip much smoother.

Kris Wall [00:36:27] All right. Let's talk about client-side security. So can we secure the client? Can I use. Can I keep the client from doing all kinds of crazy things? These JavaScript can you do? I'm a team. Stop the client for doing things. Here is it. Excellent analogy for client side security. And you know, it's just like that. In this case, the phone was tinfoil over it. You really only want you to build press 9 and 1. Well, it's obvious the vulnerabilities, the inherent flaws with this this implementation. And this is no different than client side security. So client side security is where, let's say, the user types in their password or types and you know, they're buying an item from a cart and they say, I want to buy 9 million of whatever this item is. And client side security, which runs in the browser, would say, hey, no, nine million is far too many. Yeah, we don't have 9 million. We all know you need to buy like one through one hundred. And that's all we're gonna allow. But here's the thing. So with a client side request, remember about those intercepting proxies we talked about earlier. So I can intercept that request. And I say, well, just because the browser forced me to pick a number between one and 500 hours are 1 to 100. I can come in here and I can change the request. I can intercept the request and change it to be whatever I want it to read instead of 100 as the max, I could set it back to nine million. I could set it at negative 1. I could set it at negative Pi. Who knows? And the application.

Kris Wall [00:38:07] Here's the thing. The applications need to be prepared to accept bizarre input. You always want to focus on server side security, client side security is good to have. It really smooths the experience for the clients as they're connected with their web browsers. But you still have to rely on server side security just because we put the tinfoil up and only nine and want are showing doesn't mean that somebody can't get in there, rip the tinfoil off and press whatever numbers they want. And then what is the system gonna do? 

Kris Wall [00:38:43] How is this system going to respond to this bizarre input that we didn't expect? And once again, just because you put javascript inside your page does not mean the clients have to respect that. The clients do not have to run it. A lot of times there's even plugins that will block those JavaScript pieces for running. So you'll find you're gonna find this all throughout applications. Do not rely on client side security. All right. Let's talk about information leakage. I'm secure because nobody knows how we operate. Nobody knows where our information is. Where are you know exactly how our operation works? Well, there's a lot of tools.

Kris Wall [00:39:24] And here's an example of some of these tools that help us as a pen tester or as a malicious actor. Help me get an idea for how your application works. And this is a simple one called JS parser. Once again, this is not a tools talk, but this is this is a example where I can come in and I can dig through all of your JavaScript files and and be able to look, oh, OK, I see you're calling to these endpoints. I see that you're accessing these pieces here. And I'm able to enumerate I'm able to figure out what's going on inside your application. Another big thing is another piece of information leakage is comments. Comments are a big problem. Your developers are developing team may, you know, add a common N that says, well, we need to fix this later or right now the password is password or or whatever. The combination of inadvertent leakages. You want your web applications to a comet free. That's well, you can have comments in there, but you need to be aware of what your comments are. Minimizing those comments really minimizes what I as the attacker am able to see, what I'm able to benefit from. If you're talking if one of your comments talks about the the framework that you're using behind the scenes and how you overcame it or what functions you have to pass. And yeah, I'm going to build a pickup on that and I'm going to build benefit from that. Additionally, there's error messages. So when we get error messages, this makes us so happy.

Kris Wall [00:40:55] Error messages are great, especially when they they dump these what we call the stack trace ...when you get all the debug information as we see here. You want to make sure your development team is not dumping this out. And for example, I can see I can see that their secret connections going in here, I can see that I generated a bad SQL command and I can start passing information to it until I get a proper SQL injection here. And this is very important that we we need to realize that error messages are treasure troves of information. Really? You want error messages to give as little information as possible. You want a generic error that says an error occurred and don't tell them what there was. This is very important in some rare cases you might say is an error processing your whether it's your password or username or password, I should say. But you want to give as little information as possible. If I can't discern what caused the error message, then it's much more difficult for me to be able to take advantage of that, especially of error messages. The return, what we call HTTP codes. If you return nothing but  200s and 200s mean, oh it's all good. If you return a 500, and I know I can trigger a 500, then it doesn't matter if you show me the error message or not.

Kris Wall [00:42:19] I can still sit there and trigger the five hundreds until I get a good two hundred and get that. OK. OK. Well now I've passed a good piece of information.

Kris Wall [00:42:28] Robots.txt This is how your web application, if it's exposed to the internet or to the public, how it talks to search engines like Google. And when search engines come by and come by crawling this robots, the text is meant to talk to them. "Hey, don't go in these folders. Don't go in the folder called folder...Don't look in file.html. Don't look in these. Just whatever you do, don't do it." And that is another example of information leakage.

Kris Wall [00:42:58] So this is... If you say don't go to the admin page. Well, now me as the attacker, I know you have an admin page. I did a capture the flag recently that was doing this, and there was an ad page ad as well as a code slash code page that were being that were inside of there. And what they were was one was they had been log in. The other one was an API. And I was able to send information to that API. I didn't know the API existed, had a really bizarre name, but I was able to to access that. And I only knew of it because of the robot's stuff text file. Really, it was good intentions that they tried to keep it hidden from Google. You don't want Google finding this information and sharing it, but that same good intentions met. Now I know exactly where it is. And I'm just going to disregard this robust text. Moral story is give away as little information as possible. You want to make sure that people can't benefit from too much information, something that there's so many more examples we could talk about here, but minimize the information's leaking out your application. Very important. All right. We're going to pick up speed here a little bit. So client protection. Do we need to protect the client? Do I need to worry about the user security up? Absolutely. So, for example, cross-site scripting, cross-site scripting is where I'm not attacking a web application. I'm attacking your user. And there's there's huge variety of ways of doing that. We're not getting into the weeds of how to to attack the user. But when the users on your page and they encounter process scripting command that I've injected. Well, they felt that your content was it was trusted. They went to your site. They they were they trusted your your site and that everything was gonna be secure. And if I've injected things that attack the client themselves, then it's gonna be it's gonna be very problematic. But it's very difficult to protect all the content. And anytime across that scripting or anything that tax the client comes through, you're going to ruin that trust. And the client is not going to trust you. And they're not trusting your you or your application. Well, then they're not going to use your application. That's going to be very problematic. So what are ways that we can combat this while there's a constant security policy? Very handy tool, not a really tool, a policy that browsers now respect that's come out recently. So you can add this to web application that a header is handed down to the app, to the users as are connected.

Kris Wall [00:45:41] And it says, hey, I'm gonna read through this real quick. By default, everything has to be from myself. My default source is self and my images can come from anywhere. My images source can come from anywhere. That's what star means. All my media sources have to come from media1 or media2.com. My scripts have to come from user scripts, that example, dot com. OK. So that's what's happening here. And we can say it allows us to overcome a lot of big issues with applications because applications are very difficult to manage and be able control all the all the HP security methods that you have to have built in.

Kris Wall [00:46:26] And you also want to make sure that if somebody injects cross-site scripting into your application, you want to be able to disable that. You want to say to the browser, no, no, no, don't honor that. Whatever that is that came through, don't honor it. If it didn't come from here, if it didn't come from where I said it could come from, then disable it. And the browsers, modern browsers will rule will follow that policy. That way, if there isn't a cross-site scripting that we can stop that. And if there is, do we want to report it? Do you want users browsers to report these violations back to you? And you can do this. This is actually very handy. You can actually even use constant security policies to just disable all script execution. And there you may have a security requirement that needs that application, that has that requirement the content and scripts are not running. So here's what that policy looks like again. And if you see here, halfway through, it says report-uri. This is where we're sending those reports. But the browsers that find violations will report it. They'll send a little message. They'll say, hey, report collector.example.com, I was told to get some injected information here. And this is a good way for you to learn. If there's content, there's cross-site scripting of your application. This allows you to know, hey, our application's not being attacked, but our users are. And this is a really great way for you to learn that information.

Kris Wall [00:47:59] Once again, constant security policy just just showing you one. One last example. It says, hey, according to this, our default policy says it has to come from example.com. So this js file, the file.js.. Good. File.css. Good. But this last one, I was told... The browser was told to go get malicious.com. This cross-site scripting .js files. Well, that's not coming from me is coming from somebody else. And the policy will tell the browser to ignore that. And this is a fantastic way to be able to stop that. You want to make sure that your browsers know who to trust. So content security policies are the way to go to be able to help protect your users. All right. So hidden web directories, it's important if you have let's say, remember the admin page I was talking about earlier? Well, nobody knows it's there. Let's say it's admin001. And that page, nobody knows how to get there, right? Well, I can do what's called a hidden directory scan. This is an example of using a particular tool.

Kris Wall [00:49:04] There's plenty of these go buster that will look for directories and we'll find these and be able to report those back to me. And in this case, if you look at the bottom, I'm scanning along and I'm getting 403s on some of those, which means forbidden that means I wasn't allowed to access. So I know it's there, but I'm just not allowed to see it. So this is very handy here. Here we are, zoomed a little bit more. We can... Oh, we have robots. We have robots.txt. If I try to go to some of these other ones, I get a redirect as well as such as PSP to and I can actually connect to that. These are commonly named files and directories that I can check for. I can check your applications to see if they're there. And depending on how your your web server responds, I will know ... I will be able to find out if there's hidden. So I'll probably find admin001 in here. But these hidden directories, there's an easy way to overcome this and what's what we call the wild card response. This is once again, this is go, buster. I'm asking, hey, go check for all these. And if you look, it's saying start at the bottom it says static status 200. Oh, hey, I found it. Install status 200. I found it. And really what it's saying here is that if you look up just above that, it says wild card response found.

Kris Wall [00:50:27] I asked it for a random address. Totally random. Should not be there. There's very little chance that it's actually going to be there and it randomize us every single time. If it responds and says, yeah, I'm here, well, then I know what cards are turned on. And at that point, as a pin tester or as a malicious actor, I'm going to give up. I know that if I ask your web application for everything, all the information and it always says, yeah, here you go. Yeah. Here you go. I'm not going to be able to discern what's good and what's bad information from that. That's going to be make my life so much more difficult. Now, to those of you that have web applications that are open to the Internet. Having a 200 message will will have ramifications on your SCA. This means that you're say yes to everything. Google is going to get mad at you. If Google ask for information. You say I have it and then you don't really have it. Google is going to treat it poorly. So in that case, you can respond with a 302. I'm sorry, a 301 redirection. This once again is a for youur development teams. This means, hey, I don't have it. You should go over here and this is good. It's not as secure as as always responding with a 200. You want to lie to clients. And I know that sounds terrible, but you need to lie a little bit, because when when a malicious actor comes in and they're going to start, they're going to ask for everything. And if you constantly say yes, you're going to frustrate that actor and it's gonna make their life so much more difficult. All right.

Kris Wall [00:52:01] So let's talk about authentication. Well, if a logged in, I can trust them. Right. Well, there's lots of examples of broken authentication, so the session fixation, which is using the same token before the law again, as well as after the log in. So I can pick up and I can identify and reuse the tokens. The token get passed in the URL, which means the firewall picked up on it or somebody intercepting in between picked up on the token. Then they can just steal it so easy. Another one is, let's say your password reset allows sequence connection and I'm able to just say or true, you know, I don't know the password, but how about I give you true and I'm just able to log in. You're going to have broken or older versions of authentication tokens like Jason webb token. Once again, we talked about SQL injection. I mean, the list goes on. So this is where there's no hard and fast rules. This is authentication as top party. It must be done correctly. And there's some things that your team can do to improve that, such as rotating your session I.D. frequently. Remember how we talked about if you rotate your sessions on every request, it makes it much more difficult. And the sessions have to be given to the client by the server, by the web application. And as long as you're constantly rotating those, I can't guess what those are. It's gone, or at least is a much more difficult for me to guess what those are.

Kris Wall [00:53:27] Once again, verification tokens will really stop this brute force attempts. And we referred to this earlier as cross-site request forgery tokens. Make sure your tokens are high entropy. If there's any technologies that are broken or old and out of date or have known vulnerabilities, get those out of there. And the main thing we commonly recommend... The main thing we always recommend is that there's multi factor authentication, that your authentication isn't bound by one single piece. Well, you may test for what do they know? Do they know the password? You can also test for what do they have? Do they have the authenticator that's needed? Or do they have access to their e-mail? So what vector authentication will really help you here? Fortunately, credential harvesting, that's another big issue. And we'll skip this credential harvesting, let's say there's a breach on linked in and all the passenger exposed. And then I can go pick those up and I can try and throw those at your application from the breach. And I might get a working one from LinkedIn that works on your application. I can't tell you how many times I've seen that actually work. So this is difficult. Like I said, this is one of those places it may make sense for you to check your databases for any of those credentials that are found inside of insider breach databases, because that is a fantastic source of passwords to be a log of applications. There is no room for error here.

Kris Wall [00:55:07] We can't mess this up. Unfortunately, every application is difficult and it's difficult to say give a hard and fast rule. Here's exactly how you do this. But once you keep those those pieces in mind, you can actually be in a much better position. Additionally, talk about authorization. So authentication is do you have a valid ease? You know, it did. Are you who you say your authorization? OK. So they've already logged in. They must be good, right? Well, authorization is where. Now, I've let you in, but I need to give you the right things. If you're all if you're you only have a secret clearance, I shouldn't be letting you see top secret information as an example. And so authorization is broken a lot of times. So if the session never expires is an example of broken authorization. If you authenticated them. But now the session is good forever and somebody steals that. That's a big problem. So now that they have an authorized token, that works forever. Additionally, you can have pages that never even check the tokens. Never in check is who they say they are.

Kris Wall [00:56:14] And these tokens are commonly... For those that wonder where are these tokens? There are almost always inside the inside the cookies that the application is connected to. Sometimes the cross-site request forgery tokens will be inside the application. But additionally, you're going to see both together when you see that. So you want those tokens and you want when you're checking these tokens. Well, if a person as token a they shouldn't be able to get to user B's content and vise versa, you should never be able to allow somebody who doesn't have access to somebody else's pieces for such as if I'm a standard user, I should be able to get the admin panel. Just because I'm authorized doesn't mean I should be able to go to slash admin. That page. We talked about earlier. I should have the correct authorization to actually be able to get there. Once again. Authorization is top priority. There's no room for error. How do we. How do we combat this? Well, once again, rotate the session items frequently use verification tokens. Sessions need to expire. This is very important. Sessions need to have an expiration that can't last forever. You also want to make sure that that your pages require constant authorization. You any sensitive page that is within your web application that is there.

Kris Wall [00:57:38] You want to make sure that they have the correct token that they are authorized to be there. Essentially, this is like we ought to do physical penetration. And on one of my latest engagements, I was able to get an I was able to tell get my way into the building. OK. So I passed the authentication check. And at this point, I was never challenged. Nobody stopped me. Nobody said, hey, let me see your badge. At one point, just to test the waters, I was walking around with a visitor badge and nobody asked me. Nobody said, hey, that's a visitor badge, right? What are you doing here? This is excellent, real world example, which applies back to your web applications. Check their badge. Check their token. Do this at every step as possible. And their badge should be constantly being updated by the web application. This is very important that the that the web application has total control over the badge that you don't want. You do not want the users to be able to dictate what their badges say or don't say or choose their own.

Kris Wall [00:58:37] OK. So remember, I said there'd be notes. So we covered a lot, right? So this is the point where we're actually going to. If you are taking notes, this is this is the part where you want to write these things. Yes. [00:58:48]Use the scanner. [0.2s] But just remember scanners find pre-determined or are already found vulnerabilities. They automate them. The the kind of the boring stuff. They automate the tasks that need to be done anyways. The unit tests that you need to have done ahead of time. But scanners, just because your application passes a scan doesn't mean that is secure.

Kris Wall [00:59:12] [00:59:12]Use high entropy. [0.4s] Once again, this is your crypto cryptography needs to be. Have high entropy as well as your application needs to behave in a way that's unexpected, such as using cross request forgery tokens.

Kris Wall [00:59:26] [00:59:26]DRY. Don't repeat yourself, [0.8s] reuse your code, make your code modular, have it in here as often as not as often as possible, a complete opposite. Have it in there as little as possible. That way you're. You have one spot to fix. Imagine if your car had instead of one water pump, it had 20. It would make so much more difficult to know which water pump hadn't had actually broken and which one was having an issue. So DRY says use that one water pump and everything it needs that needs to have it pumped. Use that right there and we'll will tailor it to push it through just fine.

Kris Wall [01:00:04] [01:00:04]Again, DRY. Unit testing. [1.5s] Test the functions that you're creating that your development team has created. This is important. It allows your development team to knock several these bugs, several of these malicious or these these vulnerability opportunities out ahead of time. Well, before I find them, it's important that if your team finds them during the development process and can fuzz them and fuzzing is a term where we just spray a whole bunch of random nonsense or there might even be malicious content in there. And we see how does the application respond if a response poorly. Then we know there's still things that need to be fixed. This is very valuable, should be done at the development process, not after the fact. Especially for those are use iterative, iterative development processes. This is you want to make sure that things there's unit testing, if it's for example, you're using agile before you move on to the next step and you start using that code.

Kris Wall [01:01:06] [01:01:06]When you use frameworks, [0.4s] you use them correctly. Make sure you read the manual. Make sure you understand how the framework functions.

Kris Wall [01:01:13] [01:01:13]Libraries. Use libraries carefully. [1.3s] So libraries, it's hard to use libraries incorrectly, but it's easy to use bad libraries if that makes sense. There's libraries that are old and need to be replaced, but there's also libraries that have been altered and become malicious and just that your libraries. Libraries are akin to a bunch of code that your developers could have written, but decided, hey, it's already been built. I'm going to use those libraries. Those pre-built functions and make use of those ahead of time. So just vet your libraries just like you would vet an employee, just like you would vet anything that's into your organization. Don't go nuts with their libraries.

Kris Wall [01:01:57] [01:01:57]Front and security... Can't trust it. [1.7s] Yes, it smooths the process for the end user. It makes it easier where they can't try to buy a million items.

Kris Wall [01:02:11] But with that, it's you're not going to be a force, the users, to abide by these rules, so front of security protects the [01:02:19]don't leak information [0.4s] like we talked about earlier with the robot.

Kris Wall [01:02:22] [01:02:22]Use a content security policy. [2.0s] This allows your clients to report when there's problems and for them to not honor client side attacks. So if you have the cross scripting, the browsers will ignore. And older browsers which don't have support for this will just ignore the content security policy.

Kris Wall [01:02:40] [01:02:40]Use wildcard responses. [0.6s] That way I can't figure out how your application works because you're just you constantly lie to me. Authentication and authorization are a priority. The thing is inspection, arrogance, you never, ever trust the users. And. And you need to build your application to expect bizarre interactions, bizarre pieces that may come through. And that that's that that's the key thing. Trust but verify. Everything that comes through, make sure that it is meaningful and contra that you actually wanna to work with. All right. And now for those that are that are here. We're gonna open up to questions.

Kris Wall [01:03:23] And. All right.

Kris Wall [01:03:28] OK. And so one of the questions was, hey, can we download a recording session of this webinar? Absolutely. We will make that available to you. I mean, have a little write up that goes with this. That include on our blog. But you guys are absolutely welcome to a preview or watch this webinar as many times as you like. Definitely. Let us know if there's any other pieces that we can go with.

Lisa Remsa [01:03:50] And just so everyone on the webinar knows the way to access that recorded version is the exact same one you used to register for the slide version. And you can also always find those links on traditional security, dot com boards, flash webinars.

Kris Wall [01:04:03] Thank you, Lisa. All right. Are there any other questions?

Kris Wall [01:04:09] We'll give it a moment. Somebody may be typing. I know we went just a little over time, but it's good. It's a good thing, right? Content packed webinar.

Lisa Remsa [01:04:19] Everyone hung in there with you. So, yeah. Yeah. All right. Well, all right. We had one more come in.

Kris Wall [01:04:29] What effect does the open source trend have? Open source is good and bad at the same time. It's mostly good, though open source means that the developer community has a chance to pore over ahead of time. There is no better disinfectant than sunlight, and having something exposed ahead of time allows the community to review it, find the problems and make use of that that software ahead of time and report what's wrong with it and fix it ahead of time. That's why several projects like Mozilla Firefox are such a great project because they're open source ie. I can go and review the source code from for Firefox and report back if I find any major flaws. In fact, if you are using Firefox, there was a major vulnerability found that has recently been patched. You should pass it. This is a big problem with Microsoft. Microsoft has almost always been non open source. They're a closed source. They don't show you what they're doing. And that's why a lot of Microsoft products tend to be riddled with security vulnerabilities because the crowd didn't get to look at it ahead of time.

Kris Wall [01:05:34] And so Microsoft, the onus is on Microsoft. Microsoft alone to fix those problems ahead of time. But it really saves a lot of a lot of work. Open source is very valuable. But also, remember that struts vulnerability we talked about earlier. That was an open source item. And being that it was open source, everybody knew how it worked. Everybody knew how well everybody was paying attention, knew what to take advantage of. And and the credit bureau failed to update their applications so the attackers knew exactly what to do. An open source made that easier, but all they had to have done the credit were all they had to do was simply update their applications with those. If their vulnerability management team had been on top of it or the developers and those hey, we need to update that.

Kris Wall [01:06:26] You're gonna get a lot of pushback from developers like no, we're not ready to update yet. I understand that. But sometimes the vulnerabilities are just too great and there's too much access to what the vulnerabilities are. And open source. Like I said, it's the spotlights. It's you. Once you see everything that's right with it, you can also see everything that's wrong with it. And we really encourage people to use open source, but it needs to be well vetted. Open source software. Any other questions? All right. Well, if there's no other questions, I think we're going to go ahead and end it right there. If any other questions come through, we'll make sure that we respond and send you guys an e-mail that way or all included on the blog post. But if there's no other questions, we're gonna go ahead and ended it there. Guys, I really appreciate you guys joining us.

Kris Wall [01:07:22] Lisa, do we have any other wrap up items?

Lisa Remsa [01:07:25] Nope, just keep an eye out for our next webinar. Coming up, we will have one scheduled in July, likely on incident response. So keep an eye out for that. Will make sure to keep everyone posted. And thank you for joining us today.

Kris Wall [01:07:36] All right. Thank you, guys.

Lisa Remsa [01:07:37] Have a good one.