Application Security Part 1 of 2

Home , Secure coding

Table of Contents

Application Security ...... 2

Application Hardening ...... 3

Fuzzing...... 5

Secure Coding Practices ...... 6

Error and Exception Handling ...... 7

Input Validation Concerns and Protection ...... 9

Client-side vs. Server-side Processing -1 ...... 11

Client-side vs. Server-side Processing -2 ...... 13

Secure Coding Practice Examples ...... 14

Cross Site Scripting Prevention ...... 17

Cross Site Request Forgery (XSRF) ...... 20

Cross Site Scripting Prevention ...... 21

Cross Site Request Forgery (XSRF) ...... 22

Principles for Developing Baselines ...... 23

Baseline Management ...... 24

Notices ...... 27

Page 1 of 27 Application Security

Application Security

**005 So we're going to talk about Application Security, and we're going to dip our toe into a couple of different pools here.

Page 2 of 27 Application Hardening

Application Hardening

Several techniques that can be implemented to harden the applications in order to maximize security • Fuzzing • Secure Coding • Cross Site Scripting and Cross Site Request Forgery Prevention • Application Baselining • Application Patch Management

**006 Let's start off with application hardening. So you've got an application in place, and what you want to do is you want to maximize the security for it. How do you do that?

Well, the first thing that you do is you throw a lot of junk at the input fields. How does it respond to the junk? That's what fuzzing really is. We say, "Let's just keep on shoving variables at this thing. Let's keep on shoving just junk at this thing and see how it works."

All of that's automated. You can do automated fuzzing and it will work

Page 3 of 27 very well. Now there are other techniques from other tools that are out there, but that's a start to things.

You could inspect the actual code itself, if you own the code, and you can dig inside of it. If you're using the code from somebody else, ask them how they do code security.

And so secure coding means that we have two responsibilities. That we can program it so that it actually works. And that the programming that we do doesn't introduce us to potential flaws.

And so we're going to look at some of those flaws, like cross-site scripting, cross-site request forgery, baselining and patch management.

Page 4 of 27 Fuzzing

Fuzzing

A method of testing software applications by injecting automated malformed data inputs • Test the buttons and text inputs on application UI’s • Command-line options • Import and export capabilities Attack Types • Use of numbers • Use of characters • Metadata • Binary sequences

Ref: OWASP Fuzzing Definition, https://www.owasp.org/index.php/Fuzzing

**007 So when we're talking about fuzzing, what we're doing is is we're attacking the input fields and we're dumping data into there. We're testing all of the buttons. It's basically the giant "click test" is what it boils down to. And you can use any kind of attacks you want to sending randomized data into it.

Page 5 of 27 Secure Coding Practices

Secure Coding Practices

Input Validation Error Handling and Logging Output Encoding Data Protection Authentication and Password Communication Security Management System Configuration Session Management Database Security Access Control File Management Cryptographic Practices Memory Management

Source: The Open Web Application Security Project (OWASP), OWASP Secure Coding Practices Quick Reference Guide, http://www.owasp.org

**008 Now, big wide understanding here, talking about all the secure coding practices. This is what we're going to spend a little bit of time on. How do we do secure coding practices? What are some of them? What are some of the examples?

I can't teach you how to code right now, and I can't teach you how to do secure coding, but I can describe to you the components of secure coding so that you can go back to your organization and say, "Hey, how do we do input validation?" You know, "Do we do input validation in all our fields? How do we do authentication and password management? How do

Page 6 of 27 we do session management and access control for the applications that we're in charge of?" And you can ask those good questions.

Now you better be willing to understand the answer and sit there and hang in with the technical explanation of it.

Error and Exception Handling

Must occur when the normal flow of a program execution is altered • When an unexpected value is returned • If there is an error in the program • Unsuccessful terminations of invoked operations Handling errors and exceptions • When an error or exception occurs, the program can return to it’s previous execution point • Can also execute a routine known as the “exception handler”

**009 Let's start with Error and Exception Handling. How does your operational program flow? When it encounters an error, does it come back and clear the field and start over again?

Page 7 of 27 How does it handle those exceptions and errors when you actually put in the wrong data? What does it do? Does it report-- return to a previous point of execution? For them, it did. A little bit further back than the actual end-user wanted to deal with.

And is there an Exception Handler when it fails, not because the user didn't do the input fields, but it fails because of something else, how does it handle those exceptions? In a lot of cases, a lot of poorly written applications will cough up while I call is a giant screen dump, which tells you everything about the application, the operating system, the database that it's working on, the web server that it's working on. The name of the error, where the error was in memory. And it just does this big "blech." And that's great for us. I love that! I think that's a wonderful thing from an attacker's standpoint, from a penetration tester's standpoint.

But from a security standpoint, it's a bad idea.

Page 8 of 27 Input Validation Concerns and Protection

Input Validation Concerns and Protection

Concerns • Data entered by a user may not be what is expected • Many developers have unfortunately left bugs in their code • Privilege escalation can occur in some cases • Empty data fields may also be allowed, filling databases Protection • All data entered by a user should be validated per best practices • Watch out for similar vulnerabilities in your applications • Apply patches as soon as possible for affected systems

**010 Let's talk about Input Validation. First, how do we know that he users are giving us data that we expect? And when they give us data that we don't expect, how do handle that?

Some things happen when we get data that gets put in there, it gets thrown into another field or another location, and that that trips a bug or a flaw in their code.

When we have those empty data fields, were they allowed, or were they filled in by the database with junk, how does it handle that? I'm dealing with a learning management system right now that requires me to

Page 9 of 27 put in for every single user, it requires me to put in their city and state, but yet, it only gives me the possibility of 50 states. I have customers in Canada. What do I do about this?

So how does it handle those empty fields? Well, it kicks me back out, and forces me to key them in. When we talk about protection, all the data that the users enter should be validated in the best way possible, in the best practices that we can do. Input validation is the key to success!

We should look for all input validation on apps that we actually control, but we should also look for it on applications that we use.

Because remember, when we, as users, put data into those fields, it becomes available to that vendor and could it be available to those attackers that are out there?

Page 10 of 27 Client-side vs. Server-side Processing -1

Client-side vs. Server-side Processing -1

Client-side processing allows for faster communications with the server, cannot be trusted for proper input or validation. • Some proxy clients allow users to inspect and alter traffic between the browser and server enabling change during transmission. Sever-side checks are required for input validation to prevent input overflow or other errors. State Management • As the web is stateless, web applications may rely on an external form of state management. — Via cookies — On the server via lookup process

**011 Now we need to separate out here, and we need to step back and talk about Client Side Processing versus Server Side Processing. And the easiest thing to remember in client side versus server side. Client side data is not to be trusted by the server. Period.

Why do we do Client Side Processing? Well, because if we give the end-user a little couple of widgets, they can go ahead and process things and figure out calculations on their end, and then submit back to us, it makes our website snappier, so it feels better. That's fine!

Page 11 of 27 But don't rely on any of those pieces of data that the client was supposed to calculate correctly to use as input on the server side and to take all that data back without doing Input Validation, checking for input overflow and other kinds of errors.

What we're doing there is we're looking at Server Side Processing and saying, "We don't trust any client side input." We'll give them the tools to make it faster and snappier, but when it comes back to us, we will do all the processing we can.

One of the other problems that we run into from client to server when we're communicating over the web is the concept of "statelessness." Web applications have no "state." Even though we're using a TCP connection, that state is not real.

And what we say is, "Fine, you've authenticated with us, but what we're going to do is we're going to keep track of this state or this session by using a technique like a cookie, or a server-side lookup process to go ahead and make sure that we keep on seeing that your transaction moves to its final destination, which is, "Give us your credit card and get out!""

Page 12 of 27 Client-side vs. Server-side Processing -2

Client-side vs. Server-side Processing -2

JavaScript • Scripting language designed to be used with browsers to enable features including validation of forms before they are submitted to the server • Runs within the browser with the browser executing the code — Led to compatibility issues between vendors and browser versions AJAX – Asynchronous JavaScript and XML • Programming methodology to improve web application experience • Combination of technologies and their security issues — HTML — JavaScript — XML, XMLT, DOM — XMLHttpRequest object

**012 We can use techniques like Javascript and the scripting language-- remember that runs within the browser with the browser executing the code, so that means some processing is going on locally here. Feels good to the client. They feel like they're moving forward.

We could use something like AJAX, which is Asynchronous Javascript and XML working together. This gives us a combination of technologies of HTML, Javascript, XML, XMLT, Distributed Object Modeling, and HTTP Request Objects.

Page 13 of 27 Now we've got all these things on our side that AJAX works and it makes things feel really, really good! Again, because the client feels like they're getting somewhere. But for every one of these languages, HTML, Javascript, XML, they all have certain vulnerabilities in them, inherent in them, and so we could take advantage of that on the client side of things.

Maybe we could submit some of that data back to the server where it actually processes this and we can take advantage of those weaknesses.

Secure Coding Practice Examples

Database Security • Applications that use databases need secure communication • Errors introduced into databases can be read into the application • Malicious code could potentially be executed Memory Management • Buffer overflows could be introduced • Memory access by the application could be altered • Malicious code potentially executed by the program Data Protection • Dependencies like libraries could be altered • Files that the application reads in also need to be validated

**013 Let's take a look at some secure

Page 14 of 27 coding practice examples here. For database security, I'm sure we've all heard of SQL Injection at this point. What does that mean?

Well, databases, in general, what happens to them is that they want to produce data based on conditions that we set for them.

In any kind of database security, we're always focusing on integrity, and that's a good thing. Because we want accuracy of input and accuracy of output to the final destination. When we also look at memory management. Any of the calls that are made by the system programming, we want to make sure that that memory has a bounds or a buffer that is contained.

If that buffer isn't contained, we can generate what's called a buffer overflow, and at that moment in time in the buffer overflows, well, what happens at that point is some of our junk spills over into maybe a sensitive area.

Now, that wouldn't be so bad, because we could have buffer overflows all the time. And the applications usually cough up all that information and they restart at that point.

But if it's not data that we're putting in there, like our full name or something like that, and it happens to be instead of data, it's code, and we can get that to fall over into a bugger area where it executes that code inappropriately under, let's say,

Page 15 of 27 kernel permissions, instead of user permissions, then we-- then the adversary can take over the machine at that moment in time.

Buffer overflows are where we-- where adversaries and penetration testers focus most of their energy today. We create malicious code, so that we see that it executes on the server side that was passed from the client through a regular input field.

Now the other big problem that we run into in secure coding is, depending on the underlying platform, the DLLs and executables that are there, those libraries that are there may have weaknesses in them. So we can write the perfect application, but we wrote it upon a library dependency that was there. And that library dependency has a weakness or flaw in it. We see operating system updates all the time for all of the operating systems that are out there, because of failures to be able to protect those libraries or weaknesses in those libraries.

Now, those libraries, when they're attacked from the outside, they get down to the operating system and they don't just sit with the operating system as an attacker. When they get control, now they go back up into our application.

So remember, the files that the application reads need to be validated that are locally, that are used there, those configuration files need to all work just fine.

Page 16 of 27 But in those dependencies on the library, it could be that the machine was attacked for a different reason, and then they go after your data.

Cross Site Scripting Prevention

Cross Site Scripting occurs when input is not validated from the users and active content can potentially get executed. • Many different applications (JavaScript, ActiveX, etc.) make automated detection very difficult. Keep untrusted data separated from active web content. • Properly escape all untrusted data • White-list valid inputs

**014 Let's talk about Cross-site Scripting for a second. So Cross-site Scripting occurs when input is not validated from the user, and active content can potentially get executed. I convince your application to do my bidding.

Now, let's talk about the steps that are involved in this. The end user hasn't done anything yet. The evildoer comes to the site and says,

Page 17 of 27 "Here, take this information." In Web 2.0 world, we post that information all the time. Everybody's allowed to post things there. And this information has to be- happens to be some sort of script that should execute when viewed. We just posted it there. Now it hasn't executed yet.

The nice end-user comes along and they say, "Hey, let's read what the evildoer said," because they don't know that it's evil. It's catlover99 that said, "Take a look at this picture." And when they click on it to look at that picture, what does it do? It runs that script in our browser under our context and then takes control of our particular machine.

"Well, but wait a minute. That's a script, shouldn't they protect us from that?" We're in a Web 2.0 world, anybody can post anything that they want! What we would really like to do is keep that untrusted data separate from the web content itself, so it doesn't actually parsed.

As an example of how we can do this, this happens to me all the time when I go out and look for macros and VB scripts that I use for my machine, one of the things that I do is I go to a particular website that has executable code on it.

And what happens is, for all that executable code, the vendors of that site have said, "Hey, you know, we can't let it render this and actually execute this as code, so what we'll do

Page 18 of 27 is we'll put a whole bunch of comment lines in there, so that it stops that from occurring."

And then I have to go in and remove the comment lines to actually make the code work. That's not such a bad thing, because I can review the code myself, and it's not like it's executing in my browser. So what we can do is we can escape all that untrusted data if we want to.

Another way to deal with this, if it is actually data that's being submitted to a database, rather than just a big blob that's laid on our site, you might want to parameterize any of the data that's coming back, turn it into forced data at that point.

Page 19 of 27 Cross Site Request Forgery (XSRF)

Cross Site Request Forgery (XSRF)

Unauthorized commands sent from a trusted user to a website, without the user’s knowledge • Often requires that active cookies still be in the user’s system • Trusted user would have recently visited the site Preventing XSRF • Way to prevent, is for developers to include — Unique token in a hidden field — Unique token added to a URL

**015 Cross-site Request Forgery. Now in the first case, the evildoer went to the site, posted something to the site, and the end-user came to the site. In this second case, in Cross-site Request Forgery, the evildoer says, "Hey, come to that site right there. Here's a link to get to that site."

And the window pops up in front of me, and, "Oh, I think I'll go to that." Yeah, I've been to that site a whole bunch of different days." Well, it happens to be that the evildoer has given me an interface that is partially their interface, and he says, "Key in your username and password." And I key in the username and password,

Page 20 of 27 and it gets passed back to this site, but now they have my username and password.

So Cross-site Request Forgery starts from the end-user going-- the evil person and the end-user interacting directly before they get to the website there.

Cross Site Scripting Prevention

**014 Going back a second, and Cross-site Scripting, the evil user has gone to the website and then the end-user comes to the website.

Page 21 of 27 Cross Site Request Forgery (XSRF)

Cross Site Request Forgery (XSRF)

**015 Now the way that we prevent Cross-site Scripting from a developer's standpoint is to generate what we call "tokens." And tokens are a unique representation of the current state, or of the current site. So that when the end-user goes to key in their information, this site won't work, because the token will only match back to them directly. It's not quite authentication, but it helps us to abstract what's going on.

Page 22 of 27 Principles for Developing Baselines

Principles for Developing Baselines

It is a prudent business practice to set baselines. IT vendors and security organizations have identified acceptable security controls. Vendors, Information Security professionals, and auditors have agreed on specifications for security configurations. Consider controls/specifications at the level of security that is appropriate for the organization.

**016 Principles for Developing Baselines. Okay. What are our minimum settings on our machines? What are the minimum settings for our organization? For our applications? For our operating systems? What are those minimum settings?

Consider using those as your starting point, and then look at what other possibilities may be-- or problems may be unique to your organization, and you might have to go through and chip away at some of the settings that are there. Consider the controls that are specific to a level of security that is appropriate for your organization.

Page 23 of 27 If you're in the kind of business where it's low, then do the low settings, don't do the high settings.

Usually as we do the high settings, it's going to be more restrictive on the types of things that we can do.

Baseline Management

Consistent implementation of security configurations throughout the organization Different software packages, hardware platforms, and networks have different ways to best ensure secure configuration Test periodically to validate proper implementation Review regularly to ensure they are sufficient to address emerging threats and vulnerabilities

**017 Now the real trick here is is that once we set this baseline and we approve that for the organization, and it works functionally to achieve the mission of the organization, we have to make sure that it gets to each one of those machines. How are we going to deploy a set of settings to each

Page 24 of 27 one of our machines in our environment?

In a small enterprise where they have a common operating system, that is relatively easy at this point. We can do that for all three of the major platforms that are out there. We'll call it 'NIX-- Apple, I know, is a variant, but we'll still go ahead and set it aside-- and Windows. So those are the three major players that are in the market.

If we're doing it on the Windows side of things and we're creating baselines, we can deploy that with Active Directory.

If we're doing this on the Mac side of things, and it's less than 100 clients, the Apple built-in tools will actually help us to deploy accurate baselines.

If we're doing it on Linux way, there's probably about eight or nine different ways that we can deploy a secure environment there. There's not just one because of all the different variants of Linux that are out there.

When we get very large, there are some problems that we run into with certain tools, and those tools don't scale well. What's really nice is Google, who has the largest deployment of Apple products-- Apple machines in the world-- the largest single deployment-- they actually wrote their own tools, because Apple's didn't scale past like a thousand units. So they wrote their own tools, and they published them

Page 25 of 27 for the rest of us to use for free. Which was, oh, I thought that was pretty nice!

And in baselines management, what we're doing is is we're making sure that those settings stick and are consistently applied, except for when we have exceptions. Why don't you want this in place?

Well, the business reasons is, okay, that gives you an exception there will put in a compensating control for your change in the baseline, but we won't let that drift too much.

And what we may do is we may find that a cluster of people all need that adjustment to the baseline, we take that into consideration in our next rev.

Page 26 of 27 Notices

Notices

© 2015 Carnegie Mellon University This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected]. This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT). CERT ® is a registered mark owned by Carnegie Mellon University.

Page 27 of 27