6 - 1 Information Assurance Foundations - SANS ©2001 1 Web Security Security Essentials The SANS Institute Hello. With everything that is occurring on the Internet and all of the articles that have been written, web security is a very exciting area. Most attacks that are publicized are either directly or indirectly web-based attacks. Every company and person seems to have a web site, yet most web sites are not designed or built properly from a security standpoint. In the next hour, we are going to take a look at web security and cover some things you can do to check the security of the web sites you either maintain or use. This is a foundational course, developed for the SANS Security Essentials program. When you complete this course, there will be a quiz available from the SANS web page to help reinforce the material and ensure your mastery of it. Also, you should always get prior permission but I would recommend trying these steps out on your own web sites to see what vulnerabilities might exist. Remember, before you can fix a problem you must be aware of the problem. Hopefully after this module you will have some of the knowledge you need to start securing your web applications. 6 - 2 Web Security - SANS ©2001 2 Agenda • Web communication • Web security protocols • Active content • Cracking web applications • Web application defenses On the slide “Agenda” we list some of the key things that we are going to cover in this section. First, we are going to cover web communication and how it works. Topics that are often misunderstood, like input validation and cookies, will also be covered. Next, security protocols like SSL and SET will be discussed and key attributes and potential weaknesses of each will be covered. Active content that increases functionality but decreases security will also be addressed. CGI, Java, and ActiveX will all be explained, which will allow a reader to compare their alternatives when deciding on which one to use when putting together a web site. Then the exciting topic of cracking web applications will be covered. This is meant from an informative standpoint and the reader should be reminded that you should always get written permission before running any of these tests or tools against a website. Since the purpose of security is to protect your data, we will finish this section with how you can defend against web application attacks. Now without delay, lets get started at looking at web security. 6 - 3 Web Security - SANS ©2001 3 Everything You Always Wanted to Know About Web Communications… • Servers and Clients •HTTP and HTML The World Wide Web has become the de facto communications medium for the Internet. Millions of people use it every day to get information, communicate with coworkers, buy and sell goods, entertain themselves, and keep up-to-date with current events. However, most of these people have very little knowledge about how the web actually works. On this slide, we will give you a brief introduction to the web and tell you everything you always wanted to know about the web but were afraid to ask. All in less than three minutes. All computers on the web fall into one of two categories: clients or servers. Let’s start with servers. A server is a computer that contains some sort of information that an organization wants to distribute. The server runs a special piece of software, called a web server, that takes requests from other machines, figures out what the request is for, finds the answer to the request, and sends it back to the requesting machine. That’s basically all a server does. The client machine is the machine that is doing the requesting. The client runs a piece of software called a “Web browser”, or just browser for short. Browsers take input from users, convert that input into a language the server will understand, sends it off to the server over the network, and waits for the reply. When the server sends the reply, the browser will format it and display it for the user. Simple as that. OK, it’s not really all that simple. There may be a lot of processing that goes on behind the scenes. For example, the server may have to contact other computers to get the information the client needs, or the client may have to run some other programs in order to properly interpret the response from the browser, but here you have the basics: Client sends the request, server responds to the request. The way clients and servers communicate on the Web is through a protocol called HTTP – the HyperText Transfer Protocol. Like any other protocol, HTTP is just a set of standards, conventions, and notations the two systems must understand in order to communicate. The HyperText Markup Language, or HTML, is the actual language used to develop web pages. HTML uses a set of special notations, called tags, to tell the browser how to display a page, including things like where to center text, what fonts to use, where to place images on a page, and so on. If you want to see examples of HTML, most browsers allow you to view the HTML source code for any page it displays. 6 - 4 Web Security - SANS ©2001 4 Everything You Always Wanted to Know About Web Communications (2) • Stateless Communications • Retrieving Information – GET • Sending Information – POST Communication on the Web is called “stateless.” This is because each interaction between clients and servers is an independent transaction. For example, each time you click on a web page you are starting a completely new interaction between your browser and the server. If you click on 12 different links on a page, your browser will make 12 different connections to the server. There is no information about the state of any previous transactions carried over from one transaction to the next. That’s why it is called “stateless.” We will see in the next slide how servers and clients can be tricked into carrying state information between transactions. There are two types of transactions that browsers can request of servers. They are called GET and POST. A GET transaction asks the server to get some information and send it back to the browser. When you click on a simple link on a web page, you are typically issuing a GET transaction request. A POST transaction allows the browser to send some information to the server, usually information from a form the user fills out. POST transactions send the information from the browser to the server. The server will then act on the input and send any results back to the client. Generally, users don’t have control over whether clicking on a link on a web page will initiate a GET or POST transaction. That decision is already coded into the web page itself. 6 - 5 Web Security - SANS ©2001 5 HTML Security • Reading HTML Source Given the open nature of the HTTP protocol, it is easy to start seeing some of the negative security issues that surround its use. On this slide, we will examine some of these problems. The easiest way to learn HTML is to examine the HTML source code of any page you happen to visit. Most browsers have an option to let you view the HTML source of the current page you are viewing. From there you can see all the code, fields, tags, and other HTML elements that make up the page. You may also see some unexpected things. Many developers put information into source code that is never meant for public viewing, thinking that regular people will never see it. When you view the code, you may see things like variable names and data values that are used internally by the web site’s programs. You may see references to the names of the site’s developers or internal information about the organization that is running on the server. You may see references to directory names where files are stored on the web server. There may be references to user IDs or passwords for different services on the machines. If the server is using JavaScript, or some other scripting language, you may see code paths that refer to options that the user would not normally see. All this information can give an attacker a clue as to the underlying structure and organization of the server, in order to plan an attack. And it’s all there, free for the looking. 6 - 6 Web Security - SANS ©2001 6 HTML Security • Hidden Fields • Server Side Includes Many web pages, particularly those that use input forms, make use of a feature of HTML called Hidden Fields. Like their name implies, hidden fields reside on a web page form but they are hidden from view when the page is displayed. Hidden fields are typically used as a method for carrying information from one form to another without requiring the user to re-enter the information on each form. However, hidden fields can also contain values not entered by the user. For example, when a user enters a user ID on a web form, the server might look up the user’s Social Security Number and place that in a hidden field for later use. If you look at the HTML source for the page with the hidden field, you will see that information. Unfortunately, so will anyone else that may be sniffing the network when that page is transmitted. Another neat tool is the use of a technology called Server Side Includes. Server Side Includes are small pieces of code that are embedded in HTML documents. When a Web server begins to display a web page, it will go line by line through the code interpreting the HTML commands. When it comes upon a Server Side Include line, it stops and does whatever the include says. For example, it might insert text from a different file, like a copyright notice or policy statement. It might insert today’s date and time to be displayed on the page. Or, and this is the scary part, it might run a separate program and insert its output into the HTML document. This is scary because if the included program has a bug, or the attacker can manipulate the program to run some malicious code, the potential exists for the attacker to compromise the server and gain unauthorized access or obtain confidential information. Now, despite these shortcomings, and some others we will examine shortly, nobody is saying that we should do away with HTML. But security practitioners need to take extra care when developing, implementing, or reviewing HTML systems to reduce the likelihood that information in source code or the use of hidden fields and server side includes do not have a negative effect on the server or the organization. 6 - 7 Web Security - SANS ©2001 7 Input Validation • All programs are driven by their input – “garbage in, garbage out” • Normal input Æ normal results • Abnormal input Æ unknown results • No validation in standard HTML • Need to check all form input before processing Many web pages use forms or some other user input as a way of interacting with the user. The user may need to enter a term for searching or enter a user ID and password to gain entry to a particular site. Or, more commonly, the user will need to enter information into a form like a credit card number or merchandise numbers. The server will then send this information to some other program for processing. The processing program, like any other computer program, relies on this input to drive its functions. There is an age-old axiom in computers that says, “Garbage in, garbage out.” This means that if the user enters bad input into the program they will get bad output. Computer programs by and large don’t handle bad input very well. They do great with normal, expected input. As long as the user works with the program in the ways that the designer anticipated, everything goes along just fine. But when a user acts in a way that the designer did not anticipate, either accidentally or maliciously, the program will not act predictably. In fact, the results of this action are generally unknown. If you haven’t figured this out already, computer security people hate when things act in unknown, unpredictable ways. That’s because it makes it difficult, if not impossible, to protect the system. SYN floods, fragmentation attacks, and the Ping of Death are all examples of what happens when a system receives input it did not expect. Plain vanilla HTML also has no built-in methods for validating user input. There are no variable checks or data validation rules built into HTML to prevent bad input from happening. If you are using a scripting language to develop your pages, you can build validation routines into your forms, but if you want to stick with plain HTML, you are out of luck. That’s why you need to pay particular attention to any web pages, or any program for that matter, that requires user input. You need to ensure that all input is validated for correctness. What does “validated” mean? It means that you need to check that the input is correct for the type of information being requested. If you are looking for a Social Security number, make sure that there are no letters entered by the user. If you are requesting a piece of text that should be 10 characters long, make sure the user doesn’t enter 500 characters of text. Beyond simple type and length validation, you also need to check the input to see if it matches the type of information you are expecting. For example, if you normally only sell 2 or 3 of a particular item, is it normal for a user to order 999? Is the name on the customer’s credit card different from the name on the shipping address? Things like this can be a clue to possible unauthorized activity or fraud. 6 - 8 Web Security - SANS ©2001 8 Cookies • HTTP is “stateless” – no context information • Cookies provide “state” and context • Can only hold information given to the browser by the server • Can only be exchanged with originating server or domain • Beware of cross-site sharing (e.g. DoubleClick) • Can block cookies if desired One of the interesting things that we mentioned before about the HTTP protocol is that it is stateless. By “stateless” we mean that each transaction is an independent unit with no relation to any transactions that came before or after it. When you request a web page, your computer connects to the server, gets the page, then closes the connection. The next time you request a page, your computer makes a new connection to the server. Unfortunately, many web applications, like shopping or information retrieval systems, require that information be passed from one page to the other. How do you accomplish this in a stateless system? The answer is a protocol called “cookies.” A cookie is a small piece of information that a server will send to a browser. What does this information contain? Well, almost anything the server wants it to. It might be the product numbers and prices for things you want to order from a site. It might be your user ID or customer number on a particular site. It can be anything that the site needs you to store from page to page. Cookies are actually a pretty neat technology, and nicely solve a major problem in the original HTTP protocol. However, many people don’t like cookies. There are a couple of reasons for this. The first is that the user has no control over the information stored in cookies. Since the content of the cookie is controlled by the server, you have no way of knowing what’s in it. Also, if a site puts sensitive information in a cookie, like a Social Security number or a credit card number, unless they take steps to hide that information (for example, using encryption) that information will be available to everyone on the network as the cookie is transmitted back and forth between the browser and the server. 6 - 9 Web Security - SANS ©2001 9 Cookies (2) • HTTP is “stateless” – no context information • Cookies provide “state” and context • Can only hold information given to the browser by the server • Can only be exchanged with originating server or domain • Beware of cross-site sharing (e.g. DoubleClick) • Can block cookies if desired Some people object to cookies on privacy principles. They believe that cookies are somehow magically taking information from you or your computer and spreading that information around the Internet. Most of these fears are based on a lack of understanding of how cookies really work. First off, cookies can only contain information that you’ve already given to the web server or the company you are dealing with. There is no way the site can know your home address or credit card number unless you have already given it to them. So you’ve already given up some of your privacy before the cookies even entered into the picture. Secondly, cookies can only be sent to and from the server or domain that originally created the cookie. There is no way that a cookie from xyz.com can be shared with a server from abc.com. This last point, however, while technically true, has found a wrinkle lately. It is true that one company’s server can not share a cookie with another company’s server. But what if one company were able to distribute cookies on ALL servers? This is exactly what a company called DoubleClick has done. You’ve probably seen their advertisements on web pages you’ve visited. DoubleClick rents space on web pages for advertisements. So, for example, when you visit the web page for acme.com, you will see an ad that is actually generated by DoubleClick from the DoubleClick server. The cookies generated by that ad are shared between the browser and DoubleClick, not the browser and Acme. Then, when you go to widgets.com, you may see another DoubleClick advertisement. Again, you will share a cookie with DoubleClick, not Widgets.com. In this way, the DoubleClick service can begin to collect information on what sites you have visited over the Internet. Many privacy advocates are extremely worried about this practice. If you are really worried about cookies, you can take steps to protect yourself. In most browsers, you can set an option to prevent the downloading of cookies to your browser. There are also a number of shareware add-on utilities that let you selectively block cookies based on various criteria. 6 - 10 Web Security - SANS ©2001 10 What About Non-Persistent Cookies? • Non-persistent cookies = per-session cookies • Non-persistent cookies are not written to the browser file system – So they can’t be edited and are therefore safe from session ID attacks. Right? – Wrongo!!! • Several possible methods – 1) Raw read/write from/to the client-side memory – 2) Adapt Mozilla browser source to edit cookies – 3) Write a Javascript app that lets you view page and edit – 4) Write a proxy that allows for editing of entire session passed back and forth from browser (Achilles) There are two general types of cookies, persistent and non-persistent. Persistent cookies are usually written to your hard drive and even if you reboot your system, they are still there. They are meant for long term tracking. Non-persistent cookies are meant for a much shorter period of time and are usually used on a session per session basis. Non-persistent cookies are usually written to memory so if the computer is rebooted the information in the cookie is lost. Since non-persistent cookies are not written to the file system, some people think they cannot be edited. Don’t think you are secure if your web application uses non-persistent cookies. Sure, these cookies aren’t written to the browser machine’s file system, so they are more difficult to edit. However, there are several techniques for altering non-persistent cookies. Using a proxy to completely edit the session between browser and web server is the most promising of these techniques, and can support SSL. The following are four possible methods for accessing or modifying non-persistent cookies. 1) Raw read/write from/to the client-side memory 2) Adapt Mozilla browser source to edit cookies 3) Write a Javascript app that lets you view page and edit 4) Write a proxy that allows for editing of entire session passed back and forth from browser (Achilles) [...]... or Download 6 - 34 Website Retrieval Web Security - SANS ©2001 35 As indicated by the options screen, twelve threads are functional during the retrieval process The status for each type of thread is given on the status display at the bottom of the Threads view 6 - 35 Website Structures Web Security - SANS ©2001 36 The structures view shows all the pages, graphic images, and other web objects associated... for your web app, given enough time 6 - 22 Account Harvesting – Bad User ID Check out this error number HTML is identical to next slide Web Security - SANS ©2001 When the user types in an incorrect user ID, the web application shows error number 1 in the browser’s location line 6 - 23 23 Account Harvesting – Bad Password Check out this error number! HTML is identical to previous slide Web Security. .. window • Identifies broken links and embedded email addresses Web Security - SANS ©2001 33 BlackWidow is an offline web analysis tool that is valuable to attackers and auditors alike Because websites are becoming increasingly complex in structure, BlackWidow provides an efficient means to retrieve a full website or a portion within Once the website is captured offline, BlackWidow assists in the analysis... discuss several techniques for getting a web application to cough up data it shouldn’t give • Note that these techniques can be extended based on the particular implementation of a given web application – Determine the logic flow of the web application and try to reverse engineer how it works – Get into the head of the web developer (as scary as that may be!) Web Security - SANS ©2001 21 Now that we understand... developer/signer Web Security - SANS ©2001 18 ActiveX is Microsoft’s technology answer to active content In the ActiveX model, a web page has a number of objects called controls When a user accesses a web page, the controls are downloaded to the user’s computer and executed Like Java applets, ActiveX controls can be quite useful and entertaining Unlike Java, however, ActiveX has no built-in security model... numerous web- based applications involves the way that user sessions are tracked by the server • HTTP is close to being stateless - web servers cannot trace a client’s actions by using the protocol itself • To track users through a series of actions, the application must maintain state • “If you do state right, you have gone a long way to securing your web app If you do state wrong, you will lose!” Web Security. .. request for a web page, HTTP gets the page from the server and delivers it to your browser Not too exciting, huh? Well, early users of the Web didn’t think so either They wanted a way to interact with Web servers They wanted the servers to do something instead of blindly returning pages To make that happen, they invented the Common Gateway Interface, or CGI CGI is a method of extending the web server’s... some very important web applications We frequently test the manner in which web applications manage state and user sessions, and find significant vulnerabilities that allow us to impersonate other users in the application It’s very important that you design your web apps to do this right, or you’ll have big problems As we stated in the beginning, the problem stems from the fact that security is never... instructions embedded in HTML • Security Model – Execution in a controlled environment (the “sandbox”) – Local apps have more access than network apps – Byte Code Verifier, Class Loader & Security Manager enforce security Web Security - SANS ©2001 17 Java and JavaScript may sound similar, but in fact they are two different technologies Java is a programming environment whose programs are compiled and distributed... formal security model and the sandbox concept, Java programs and applets are not entirely secure, and, as with everything else, attackers have found a way around Java’s security features However, it is still light years ahead of anything that came before it in terms of active content security 6 - 17 ActiveX • Downloadable components to provide functionality • Can perform any action as user • Security . securing your web applications. 6 - 2 Web Security - SANS ©2001 2 Agenda • Web communication • Web security protocols • Active content • Cracking web applications. have a web site, yet most web sites are not designed or built properly from a security standpoint. In the next hour, we are going to take a look at web security