Web Application Security September 28th, 2004 Mark Lachniet, Analysts International Introductions Mark Lachniet, Technical Director of Analyst Internationals Security Services Group Technical lead developing for services, methodology, quality control, technical presales Certified Information Systems Auditor (CISA) from ISACA Certified Information Systems Security Professional (CISSP) Linux LPIC-1, Novell Master CNE, Microsoft MCSE, Checkpoint CCSE, TruSecure ICSA, etc. Former I.T. director of Holt Public Schools Frequent speaker for local organizations Conceptual Overview of Web Apps Web applications are generally developed in Tiers User / Client Web Server Business Logic Database In many cases, the database is the same one that holds other critical organizational data! Logical / Physical Overview Let us pretend that we are looking at a real web site at your location The purpose of the web site is to allow self service access to Human Resources information: Pay stubs, deductions, direct deposit bank name Demographic information Emergency Contact information Education Dependants (names, ages) The application was written by a combination of internal and external programmers The application was written in Microsoft.NET, and communicates with the actual Human Resources system Logical / Physical Overview In order for this all to work, the HR system needs to trust the self service web application to access data Thus, the program logic of the self service application may be critically important, responsible for ensuring that: Users are properly authenticated Users are authorized to use the system Adequate logging of activity takes place The Internet-facing components do not have known security flaws In short, a part of the security of the human resources database now lies in an Internet-facing web application, possibly bypassing the more established and mature database security What could possibly go wrong? Implications What Can Go Wrong??? Frankly, a lot.. Secure programming practices have not really been taught in higher education Productivity pressures have made security a secondary priority A lot of insecure web sites have been implemented In fact, a recent study found that no less than 92% of web pages surveyed over a 4-year period had serious security flawsAre you confident that your web site is within the fortunate 8%? If you dont have an explicit set of controls for application development, security and ongoing testing, you shouldnt be! Types of Flaws in Web Applications Lets look at the statistics from the previously quoted article: 1.Cross-site scripting (80 per cent) 2.SQL injection (62 per cent) 3.Parameter tampering (60 per cent) 4.Cookie poisoning (37 per cent) 5.Database server (33 per cent) 6.Web server (23 per cent) 7.Buffer overflow (19 per cent) My personal experience indicates that these numbers are about right Any one of these flaws could lead to a disclosure of critical or protected data Lets look at a few examples Cross-Site Scripting Occurs when input from a user is not sanitized before being re-displayed on a web site For example, an Internet guest book may allow you to enter a message, along with the time and date that you visited a web site It may be possible to craft this message in such a way that users Internet browsers interpret the message as HTML code, instead of plain text If this happens, person A can make it appear to person Bs computer that a web site (presumably a trusted one) is the source of a tricky attack This commonly used to do things like steal authentication information, or redirect to a phishing web site to harvest passwords, credit card numbers or bank account numbers Real Life Example of CSS While working for a customer, analyzing a well known SSL VPN appliance, I discovered a CSS bug I then created a proof of concept to demonstrate this bug I created a (virtually) identical copy of the VPN servers login page, and put this on a server that I had control of I then created a special CSS web address (URL) that, when entered, would redirect the user transparently to this external web site The fake web site said session has timed out, please log in again message, and had a place to log in again When the user entered their username and password on the fake login, this information was written to disk on my hacker computer, and the user was redirected back to the *real* VPN servers incorrect password page The end user would simply think that their session had timed out, and that they had mis-typed their password SQL Injection The next most common flaw, SQL injection, is worse In this case, a hacker would find a part of the application code that did not perform proper input sanitization By passing special characters in form fields (e.g. a place to type in a query or address) it is then possible to embed additional commands for the HR database Since the application server is trusted by the back end database, it assumes that the request is legitimate and performs the query The normal results, as well as the database commands entered by the hacker are displayed in the browser This attack can be used to completely bypass application and database security In our working example, an identity thief hacker could then print out the names, SSN#s and addresses of all employees and use this to steal their ID Real Life Example of SQL Injection While analyzing a production Internet web site during a WASA (Web Application Security Analysis) I discovered a SQL injection flaw in the application code With this knowledge, I configured a program called data thief to assist me in demonstrating the vulnerability Using data thief, I was able to copy the entire back-end database, with all of the data, including usernames and passwords, across the Internet to my computer Using this database of logins and passwords, I was able to log in, and access the application as an administrator At that point, I also had the ability to run software on the database server, which was on the internal, protected network If I were a bad guy, I could have used this access to compromise additional systems on the Internal network Real Life SQL Injection Example Other Web Application Risks There are a number of other risks that need to be looked at: Ability to bypass authentication systems Ability to steal user sessions Flaws in the underlying operating system / web server Flaws in the chain of trust (relying on an additional system for some security component such as a SSO (Single Sign On) system) Flaws that allow a hacker to deny service to the system (e.g. by using all of the licensed connections, flooding the server, or causing a software crash) Reliance on client-side security (especially client-side scripting) And so on. Input Validation The key to fixing the vast majority of web application flaws is proper input validation All client-side input should be filtered at the server side (never trust anything coming from the client, as it can be modified) Only those characters which are explicitly expected should be allowed Dangerous characters such as ; , should be stripped or rendered in a non-interpretable format Use database stored procedures to limit the type of data that can be inserted into a database query (data typing) Use of Encryption Any web site that is important enough to have a user ID and password should use encryption In the web world, this is a SSL connection (https) Indicated by the presence of a locked icon in your browser toolbar, or similar This will prevent the casual interception of data by a hacker, including usernames and passwords To be done well, requires a valid SSL certificate from a company such as Verisign at a cost of approximately $400+ for your web server Once a user has authenticated, the remainder of the session should be over the encrypted channel Any encryption is better than no encryption even basic 40bit SSL is too bothersome for most to break Authentication Issues User authentication is critical for web servers, since you are potentially serving a global audience Strong password systems (NT auth) are better than weak (e.g. default HTTP Basic) Account lockout should be used to minimize the risk of brute force attacks Strong passwords should be used (e.g. long, complex passwords that are not in the dictionary) For truly important applications, use two-factor authentication such as biometrics (fingerprint readers) or SecurID tokens Consider using mandatory client certificates (requires pushing down a certificate to the client) in addition to a username and password I Forgot My Password The I forgot my password feature should be implemented securely Even if the question is answered correctly, the current password should never be displayed Questions that are too easy (e.g. your favorite restaurant) could be determined by stealing a credit card bill or looking at a personal web page (look at the nice pictures of my favorite dog!)ing a complex URL with a set new password web page is better This invitation to reset should be time limited (e.g. 30 minutes or similar) because it may linger in someones inbox Data Caching Issues Many web sites (e.g. portals) are accessed from public locations such as libraries and coffee shops This activity may leave remnants of sensitive data on the workstation caches To minimize this risk, the web site should: Use cache-control directives Ensure that URLs (left in browser history, in index.dat in IE) do not have a user ID or password embedded in it Use a graphical PIN type login (this requires clicking, and cannot be captured by a keylogger) There should be a remote access policy that requires a certain level of security (A/V) and conduct (practices) for users Cookie Management Cookies are small pieces of information that are stored on the local workstation Come in two varieties persistent and non-persistent (stored to disk, or just in RAM) They typically contain a user ID, or perhaps a web site preference (e.g. show me the U.S. version of CNN.com) They are tied to a domain such as cnn.com and cannot be accessed or modified by servers in other domains Are often used for session tracking, for example holding a temporary session ID Cookies can be viewed and intercepted in transit (using a protocol analyzer) and programmed into a hackers computer If they are used for security purposes, can be a problem Best practices suggest linking a cookie to a source IP address, but this is not perfect (imagine a shared firewall) Logging and Auditing Most web applications have very poor logging capabilities by default Logging is required in order to create an audit trail Logging may also be required by some regulations as well, depending on usage Logging is essential for forensic purposes (catching and prosecuting a hacker or terminating a bad employee) Logs should be reviewed on a periodic basis, and documentation maintained about the fulfillment of these duties (e.g. a written log that duties have been done) Ideally, an automated tool will be used to sift through the logs and identify exceptions Log data must be gathered from multiple levels, including network, OS, web server, application and database Common Sources Network Data NetIQ (Web Trends) Firewall Suite Converts large amounts of firewall data into handy charts and graphs Tracks both packet and web browsing data Microsoft Windows Logging Microsoft products use their own logging system There are a number of disparate places for logs: Windows Event Log (MMC plugin) Internet Information Systems Logs (www, FTP, SMTP) DHCP server logs Microsoft Exchange DNS logs, etc. etc. Because of this, it is difficult to set up centralized logging for Windows machines out of the box (note: UNIX has the same problem) Fortunately, a number of products have been created to help us with this task Windows Event Log Example The Event ID is a critical component that you can search for Supplemental information can also be useful Windows Event Log Example Cont. The previous was a perfect example of something you might want to know about Not even this level of information is available by default it must be manually configured on most systems (Windows 2003 may be an exception) !! The default level of logging is useless!! No system should be green lighted unless there is some kind of formal system hardening methodology that includes adequate logging of the operating system Also, note that the event log only tracks some events, and does not include web servers, etc. Configure Event Viewer Settings Within the event viewer, you need to set: The size of the event log What happens when the event log reaches maximum size (overwrite, rollover, nothing) How many days to store the logs for before rolling over There is also the option to hard stop the server if it cannot log this may be needed for high-security systems. See:?url=/technet/columns/security/askus/aus1101.asp Windows Event Logging For a list of Windows event IDs check out: There are a variety of things that you can audit for: Login / logout Account management (create, delete, modify) Directory service access Object access (files, printers) Use of privileges (backup) Yet, there are many things you cant monitor with event log: Internet Information Server Microsoft Exchange, etc. Web Server Logging The web server (IIS, Apache, etc.) also logs a lot of data that is useful for tracking abuse Often the only way to track a session to a source IP address Ensure that maximal logging is configured Back up logs regularly (to another machine, to tape, etc.) Use log analysis tools where possible (e.g. Web Trends log analyzer) to identify unusual activity Use time synch on all devices to facilitate log analysis between multiple systems such as web servers and firewalls Application Layer Logging Applications should be explicitly written to include logging routines it is usually the only place it can be done Things to log (from OWASP): Login and logout of users Critical transactions (eg. fund transfer across accounts) Failed login attempts Account lockouts Violation of policies Including User ID, timestamp, source IP address, action taken, error codes, etc. Database Layer Logging Databases can also maintain a log of activity This may introduce a system overhead, but it might be better on the database than on the application server Carefully target logging to critical events (database permission functions) and data (SSN#, financial data, etc.) Consider logging to an external source, in case the server is hacked and the records are removed There are often rollback or transaction logs that are kept as part of disaster recovery systems Prevention Strategies Only purchase products that have had some kind of security analysis (work this into the RFP process) Good luck finding any (never trust a vendor!!) Use secure coding standards for internally developed applications (and send your people to training!!!) Use Intrusion Prevention Systems, either host based (e.g. Entercept) or applicance based (e.g. Symantec Gateway) to catch abuse* Perform web application security assessments against the application you can hire companies to do this, or you can learn to do it yourself Use defense in depth to put as many barriers to hacking as possible (e.g. separate web servers from DB servers through a firewall, use strong authentication such as SecurID, etc.) Security Best Practices A lot of information is available for programmers, auditors and I.T. staff on web application security issues The most referenced one is the Open Web Application Security Project atOWASP has specific guidelines for what programmers should and shouldnt do, as well as detailed information on what the issues are and how they can be detected For more information on how to go about assessing an application using accepted methods, check out Open Source Security Testing Methodology Manual atA number of product-specific web sites for major vendors also exist. A good one for both theory and practice is the Microsoft Building Secure ASP.NET Applications 600pg PDF at:=en&FamilyID=055FF772-97FE-41B8-A58C-BF9C6593F25E Linksasp (windows settings)(using Kiwi in a Cisco and Microsoft environment)(Syslog in a Microsoft environment)(best practices in web application development) (Enhanced SQL Security auditing)(syslog products for Windows)(Syslog NG products)(web site / listserve dedicated to log analysis)overview.pdf (overview of Syslog in general) More Links(turning on logging of DHCP)chnet/columns/security/askus/aus1101.asp (enabling auditing on Windows)(list of security events to audit for)(commercial product to analyze Windows and UNIX logs)(MonitorWare)(Effective logging and the use of the Kiwi syslog utility) Discussion This presentation to be available at:Mark Lachniet CISSP, CISA, MCSE, MCNE, CCSE, LPIC-1 Technical Director, Security Group Analysts International (517) (voice) (517) (fax) mailto: