Time
10 hours 28 minutes
Difficulty
Advanced
CEU/CPE
15

Video Description

This lesson focuses on application security, specifically: - Security by design: anything that is built - Security by default: software has doors closed and can only be opened by users, nothing is installed and nothing is enabled - Security by deployment: Deploy an application in a secure manner and lockdown deployment process and minimize user interaction. Participants also learn about general application issues: - Error and exception handling - Privilege escalation - Improper storage - Input validation - Race conditions - Resource exhaustion The lesson also teaches about issues specifically related to web applications: - Cross site scripting - Cross site request forgery - Click jacking - State/session management - SQL injection - Cookies

Video Transcription

00:04
Okay, Uh, as we move on and talk more specifically about the applications on our network uh, Cem, principal security considerations. And we've talked about the's a TTE leased to a degree
00:17
security by design, by default and by deployment.
00:22
Security by design
00:24
security is integrated into the design of the product, just like we talked about with I p Version six i p Version six was designed with I p SEC Integrated. It was designed to be a secure network layer protocol.
00:42
Security by design is huge, and we talk about it doesn't have to just be for software.
00:47
Certainly it's here for application, but it could be from hardware systems. It can be the physical security of your building. Design your facility using secure materials, mesh stairways, parking garages, designed toe have openings rather than just being a big, dark, tomb like
01:06
structures to park cars.
01:07
Security by design, anything we build we should build with security in mind.
01:15
Now, security by default means our software products should have all the doors closed. And if you want to open those doors, open him up. And here's how, Like I said earlier, Microsoft isn't necessarily known for that philosophy. they've focused more on open all the doors in the house. And if you want to close him, you can.
01:33
Their focus has been ease of use, more so than security.
01:37
And remember, there's always a cost benefit that leads to our decisions. Microsoft has done fairly well, and I know that they may not be where they once were. But, you know, I wouldn't mind having a good amount of stock in the company. So
01:55
there's always a reason that we choose the path that we choose. Microsoft has chosen to make their living on. This is in no way a judgment on Microsoft. They've just found that ease of use met their goals. Bells, other companies, other operating systems are designed to be secured by default.
02:14
Nothing's installed. Nothing's enabled. If you want to turn it on and if you want enable it, you can do so.
02:19
And one of the things that's interesting is you'll see that Microsoft is offering products now Mawr, in line with that school of thought with 2008 and with 12 2001 of the things that Microsoft has really introduced has been the idea of modularity
02:35
and by modularity because this really gives me greater security by default. The ideas, Nothing's installed. As a matter of fact, if you've been in II s seven, it's a real shock coming from earlier versions of II s six and I at five and so on. Because when I ask people, what is I I s from Microsoft.
02:53
Many people say, Oh, it's a Web server.
02:57
I s seven is not a Web server. It is a big, empty box with nothing in it. And if you want it to be a Web server, you install the Web server module. If you want it to be an FTP server, you install that module. You want it to allow authentication, you install that module.
03:15
Uh, you want to run D and s on a server, you install the module.
03:20
So the idea is Microsoft's goal now is much more in line with security. By default, nothing's installed. If you want to install it, you can add it in. And that really is certainly much better from a security standpoint.
03:34
Now, security by deployment simply means that we're gonna deploy it in a secure manner. Um, we're going to lock down the deployment process as much as possible. We're gonna try to minimize user interaction because users make a lot of mistakes if you put too much on their plate.
03:52
So, uh, you know, the three foundational elements
03:54
designs securely, default to security and deploy security. And that's how we implement applications in a secure manner.
04:03
Now there are lots of issues that can come up with applications, and one of the things that we've done is we've evolved throughout the years with our operating systems and our applications. We've evolved as to how we handle these issues that can come on
04:19
error and exception handling. There's been some sort of access that goes against her violates system policy. So what does an application due in that event? While the application may terminate, the application may lock up, may have a system reboot.
04:36
Uh, and it's frustrating as some of those things are. You may just get an air message on your screen,
04:42
but these air all ways of responding to some sort of security breach our security violation in such a way that no further error can happen. So that has to be built into the design of an application.
04:55
We can't count on applications being well written. We can't count on applications playing nicely together. You know, if you've been around computers for a while, If you go back to the windows 31 days, when does 95 98 days? You know, if you think your system locks up today, go back and get on a Windows 95
05:14
system
05:15
where they didn't really have a good memory manager in a good way of allocating and enforcing, uh, memory stacks to the different applications. Even though, you know, that was that was the intent. And that was the that was the process that was designed to do. It didn't necessarily do so well, so you'd always have these
05:32
event errors. You'd have illegal operation errors, you'd have the system locked
05:36
up. You have individual programs locked up. But the bottom line is each of those are ways that the system responds to a violation. Let me terminate in such a way that no further breach could be compromised.
05:51
Other things that we've got to think about with their applications, applications need to be resistant to privilege escalation. You know, I think about this, particularly with operating systems, but there are other applications that have rights and permissions associated with certain roles.
06:10
Attacks like buffer overflows, buffer overflows is where, um,
06:15
and applications, trying to access more memory than is allotted to it. And sometimes these buffer overflows can cause a system not just to lock up, but to inter estate, where a user could potentially be ableto escalate their privileges. So we want to be very cognizant of the harm that can come
06:35
with things like buffer overflows.
06:39
Ah, and of the threat of privilege escalation,
06:42
improper storage, you know, with improper storage. The thing that I think about is I think about covert channels, covert channels and a covert channel is any means of communicating across a path that wasn't anticipated
06:59
for communication?
07:00
For instance, the Loki attack l okay, I the Loki attack. Uh, this is where processes would communicate by storing information behind the ICMP header of a packet.
07:13
That's not what the ICMP headers. For so many times, that packet may not have been thoroughly or that portion of pack. It may not have been thoroughly inspected,
07:21
So by taking advantage of that idea in storing data in a place that doesn't normally get inspected, we may be able to covertly communicate
07:32
so improper storage. I'm storing things where they shouldn't be stored.
07:36
Input validation I've already talked about, but this is an essential piece of data base security,
07:44
garbage in, garbage out. So what's the best way and make sure garbage doesn't come in? And I do that by examining input from users, I force it to adhere to certain standards like data tight field link. I scan it for potentially malicious code and look for data control languages.
08:03
But I validate what goes in before passing it along to my back and serve
08:09
race conditions. Um,
08:11
there are lots of different types of race condition, as in, it's a race to the finish line.
08:18
Race conditions are all about causing timed functions. Toe happen out of order
08:24
were to mess with the timing of events. For instance, we talk about accessing the system. The way that usually works is if I'm gonna access the system, I log in
08:35
and it's part of log in. I provide my user name.
08:39
That user name is identification. I am making a claim
08:43
now. We should never start stop with just allowing the user to make a claim they should always have to support that claim. That's where authentication comes in. So I claim to be Kelly Hander Han. I prove on Kelly Hander hand by providing a smart card or a token or password,
09:00
and then and only then should I get authorized.
09:05
Should I get rights and permissions associate with Kelly Hander head? Well, a race condition might be an attack on the system architecture that slows down authentication.
09:18
It speeds up authorization so that I can cause those things happen out of sequence. You may be able to get authorized based on how you've identified without having to provide authentication. Now that's a high end attack that really is breaking the system's design in the system's architecture. But for a high enough value system, it's worth the attack.
09:37
Another type of race conditions specifically erase condition is called a talk
09:45
how talk towel attack.
09:48
And that stands for a time of check
09:52
time of use,
09:54
time of check time abuse. So let's say I go to a grocery store and, uh, I ask the cashier, I say, Listen, I've got 5 $20 bills in my pocket. Would you mind giving me $100 bill for these five twenties.
10:07
All right, night countem. 2040 60 80 100. And I put that money on the counter and the cashier goes to open up their cash register takes out $100 bill. But while they're busy doing that, I grabbed one of the twenties and I took it back in my pocket.
10:24
There's a variance in between when the cash cash here comes back around To put that in her drawer from when she checked and verified that the money was there. That's what a time of check time of use attack is all about. It's all about like, for instance, with configuration file. Let's say a process verifies that what they need
10:45
is in the configuration file in the configuration file
10:48
is valid.
10:50
Well,
10:50
I should immediately use that config file after verifying, I shouldn't verify that it's good and come back half an hour later and say, Oh, I'm gonna use that now
11:01
again if I can attack the system architecture that creates a variance between when something is verified as being legitimate and when it's used. I have this space in between to manipulate a system should be designed to not have a pause between authentication and authorization.
11:20
If you want to be authorized, you authenticated. And immediately you get your authorization not 10 minutes later, an hour later or whatever.
11:28
So timing attacks often referred to his race conditions and then the top metallic. A particular type of race conditions,
11:37
resource exhaustion. One of the, uh, most common attacks denial of service or also extended beyond that, A distributed denial of service all about exhausting resource is king floods, pings of death, sin floods. You know all these different types of attacks.
11:56
I want to overwhelm the system. I want to keep that system so
12:00
busy with my bogus requests, it can't respond to anything else. So that would be resource is exhaustion
12:07
from an attack standpoint.
12:09
Now there's, ah whole page of other types of attacks. Cross site scripting is often abbreviated. X S s cross site request Forgery is often abbreviated. C S R f. You might even hear it. Call the sea surf attack.
12:26
These were becoming very common and they are to a degree comparable
12:31
cross site scripting.
12:33
Cross site scripting takes advantage of poorly with written websites and there are a 1,000,000 poorly written websites out there out on the web.
12:46
So what a cross site scripting attack does is, um, uh it's a way of manipulating an existing website so that I input malicious code into the source of your Web page so that someone visits your site. That code wraps around and runs in their browser.
13:03
Ah, lot of phishing attacks use this. So I'm gonna send out an email to a ton of people. Click here on this link in, download today's joke of the day or whatever that might be. So when you click on that link that takes you to the infected website,
13:16
whatever the payload is of that malicious attack, that Java script that's been injected or whatever it might be,
13:24
it wraps around and runs in your browser. So that's obviously something very negative Now. Cross site request for Cherie, this, is, is something that would work in a very particular environment. What it takes advantage of is you having an open session to a secure site
13:43
at the time I perform in an attack.
13:46
Okay, so, for instance, let's say you log on to your bank. Let's say maybe you log on to Capital one so you've logged in. You provided your credentials, your brain into cookie on your system that essentially contains your session I D and information that says I'm legit here.
14:03
Well, it's an attacker. I want that cookie. And I want to be able to make requests using that cookie. So I appear to be legitimate.
14:11
So maybe you and I are talking in a chat room and I present myself as a tech support employees.
14:20
And while you've got that banking session open,
14:24
if you connect if you and I, uh, are able to connect, maybe I can get you to click on a link,
14:31
for instance that would transmit that cookie to me or allow me to intercept that cookie. I I hope this is making sense. Basically, the thing is, is when you have a secure connection to a banking server, you need toe handle that secure connection, and then you need to log off. I don't know if any of you have ever had it happen where
14:50
you log on to your bank, get distracted than 10 minutes later, you get a message that pops up and says, Hey,
14:54
your account has been terminated or disconnected to system in activity. That's to prevent sea surf attacks. If you leave that banking session open, you've got a cookie there with all your session I D and all your important information. And if I get you to go to this website
15:13
and you and I have a secure can, open up a connection. If I get you to click on the link,
15:20
I can access that cookie and then transmit requests on your behalf. Now. Certainly there are mitigating strategies in place. The best mitigating strategy is if you log on to your main, do what you need to do on your bank and get off.
15:33
So that's a cross site request. Forgery. Taking advantage of an established, secure connection.
15:41
Click jacking. You know, if I had 1/4 for every ad I saw that said, Click on the bull's eye to blah, blah, blah. And, of course, the bull's eye moves around but never really moves around so fast that it's a real challenge. What they're trying to get you to do is go to a Web page and click on a link. Essentially,
16:00
you know you would never do that if you went to a website that said click here for something surprising toe happen.
16:07
None of us would fall for that. Oh, but look, it's a dancing bear. It must be safe.
16:11
So you know what? The very least I'll pop up and add when you click there but more sinister, you know, just simply by clicking on a link, you can start a download. You can initiate a script to run. There's always a reason they want you to click there. Be very careful
16:30
now. State in session management As I mentioned before, um, when you open up a secure session, when you open up a secure connection, there's usually a cookie that contains very sensitive information that in Abel's that state to be current in that session to stay open.
16:48
These cookies are very desirable for an attacker.
16:51
So with your secure connections, know that that's a vulnerability. So you don't want to be doing a whole lot else when you do have a secure connection
17:00
code injection databases,
17:03
code injection code injection, code injection, input, validation is the source. It doesn't have to be sequel injection, although, of course, that's appropriate to sequel databases, any type of code injection, something we're concerned about, and we always look to input validation
17:18
cookies. I've already mentioned them in relation to session hijacking. That's out. Such and hijacking happens, I get ahold of your session cookie, but also, uh, these air static devices placed on your system to track history and browsing.
17:34
You know, not only do you have first party cookies from somebody like Amazon,
17:38
you know, if you're like I am, uh, I've got a four year old at home and he's finally sleeping through the night. But when he was younger, we always had problems with him waking up in the middle of the night. And so once I'm awake at night, I'm away. There's nothing to do. There's nothing to do except go on my computer and do online shopping. By golly.
17:59
And so, uh, one of the things is I'm one of those people that's on Amazon's thank you list and probably will be forever. So for a long time you get up in the middle of the night and all of a sudden these unnecessary plastic objects you didn't know you needed suddenly look very appealing.
18:17
Well, it didn't take long before my house had a new policy. And the policy was. You fill up your cart all you want, but you don't click on purchase until 9 a.m.
18:29
And the idea they're clearer Heads prevail. But one of those handy features about Amazon is that cart still full when you come up with 9 a.m. Right? You, The Amazon doesn't at all. Once you forget, you know to forget that you needed a calendar of pugs or whatever it was that seemed like a good idea at midnight.
18:48
So it's a cookie that Amazon places on your system to track your purchases.
18:53
That's a first party cookie, and generally we don't look at that as being a big privacy concern. We expect Amazon to know what we purchased. But the other thing is many of these companies sell rights, toe other companies to put cookies on your system. Which is exactly why, when I do buy a pub calendar for 20,015
19:12
all of a sudden on my Facebook page
19:15
or in my mail, I start to get very targeted advertising advertisements geared towards previous purchases. So third party cookies or another company say I want to know what you're buying it Amazon, and we generally do consider those to be privacy invasion, but a lot of sites won't let you go unless you do accept
19:36
cookies.
19:37
Your browser's will allow you to turn off all cookies. But like I said, you're not getting any website if you don't accept cookies, but they'll also let you turn off just third party cookies as well.

Up Next

CompTIA CASP

In our online CompTIA CASP training, you will learn how to integrate advanced authentication, how to manage risk in the enterprise, how to conduct vulnerability assessments and how to analyze network security concepts and components.

Instructed By

Instructor Profile Image
Kelly Handerhan
Senior Instructor