Application Security Part 1 of 2 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 5 **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 6 **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 7 **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 8 **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 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” 9 **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 10 **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