The document discusses the top 10 attack techniques used by hackers to compromise web applications, as presented by Antonio Fontes at the Confoo 2011 conference. The techniques are: 1) Injecting code inside the system, 2) Attacking client systems, 3) Attacking authentication and session systems, 4) Exploiting direct object references, 5) Controlling a 3rd party browser, 6) Exploiting an insecure configuration, 7) Breaking weak cryptography. For each technique, the objective, strategy, and potential impacts are described, along with examples and checks developers can perform to prevent attacks.

1. OWASP Top 10Understanding the top ten attack techniques blackhats use to compromise a web application Antonio Fontes OWASP Switzerland March 9th 2011 Confoo 2011 - Montréal

2. Speaker info Antonio Fontes Owner L7 Sécurité (Geneva, Switzerland) 6+ years experience in information security Fields of expertise: Web applications defense Secure development Threat modeling, risk assessment & treatment OWASP: Chapter leader – Geneva Board member - Switzerland 2 Confoo 2011 - Montréal

3. I have 2 objectives: To show you the top ten intrusion techniques blackhats use to compromise systems or data connected through web applications. To give you actionable material to help you manage the risks associated with these 10 techniques, which you can use after you leave this room. Confoo 2011 - Montréal 3

4. Whyteaching the « attacks »? To connect : Some of you might immediately identify vulnerabilities in their products while watching this.  quick win To increase awareness It’s a good start. Confoo 2011 - Montréal 4

5. Webappsec landscape Confoo 2011 - Montréal 5

6. Webappsec landscape Confoo 2011 - Montréal 6

7. Whatis a web intrusion duringthis session? It may be: A breach of confidentiality: Confidential data is retrieved/stolen A breach of integrity Processes are modified Unauthorized transactions are performed A breach of availability The service is stopped, or its performance reduced Confoo 2011 - Montréal 7

8. Whatis a web intrusion duringthis session? A combination of: An undesired situation for the organization (damage, loss, etc.) Made possible by a vulnerability/weakness in your web apps/services Which was exploited by a human  whether intentionally or not Confoo 2011 - Montréal 8

9. About the screenshots… Real actual vulnerable apps are easy to find But…this is barely legal in Canada I'll use screenshots almost everyone understands: It doesn't necessarily mean Facebook is vulnerable to these attacks  Confoo 2011 - Montréal 9

10. Confoo 2011 - Montréal 10

11. 1. Injecting code inside the system Confoo 2011 - Montréal 11

12. 1. Injecting code inside the system Objective: execute hostile/arbitrary code within the infrastructure. Strategy: take control of an existing command channel and inject hostile code/instructions. Impact: usually, the worst! Complete breach of system integrity/confidentiality/availability Confoo 2011 - Montréal 12

13. Confoo 2011 - Montréal 13 "SELECT COUNT(*) as result FROM users WHERE email = 'admin@facebook.com';#' AND password = '1234'; "

14. "INSERT INTO users VALUES ('Antonio', '', '', '', '', '', ''); DROP table USERS; --', '-', '-', '-', hash('a'), 'male', '02/29/1950');" Confoo 2011 - Montréal 14

15. 1. Injecting code inside the system The problem occurs whenever: Command channels are established by the application (usually: always) i.e.: to the database, to the command-line, to the filesystem, to a 3rd party provider, etc. The attacker can inject code within these command channels Confoo 2011 - Montréal 15

16. 1. Injecting code inside the system Most famous example: the database channel "SELECT/INSERT/UPDATE/DELETE blablaFROM blablaWHERE condition = '" + usercontent_here+ "'" Payloads: WHERE condition = '' OR ''='' WHERE condition = ''; DROP table PAYMENTS;--' WHERE condition = '' UNION select TOP 1 1,1,1,username, password FROM users; --'' Confoo 2011 - Montréal 16 Always returns true Ugly. More useful.

17. 1. Injecting code inside the system Did you check this? Is your code using query encoding APIs in all command channels? Ex: mysql_real_escape_string for SQL calls Is your code using parameterized statements? query += " WHERE account = ? "; stmt = con.prepareStatement(query); stmt.setString(1, request["frm_account"]); rs = stmt.execute (); Confoo 2011 - Montréal 17 Good Aka bind variables Very good!

18. 1. Injecting code inside the system Myths: SQL Injections are gone.  Wrong they arent' SQL injections are for dummies  Wrong they arent' SQL injections are easy to prevent  as much as it is easy to forget just 1 injection point. Confoo 2011 - Montréal 18

19. 1. Injecting code inside the system Myths: Stored procedures are safe  Wrong! If using dynamic construction, the payload still gets injected. But by the DB server instead of the Application server… That's all. Injections are for SQL queries only  Wrong! LDAP, Xpath, Javascript, SQL, OS commands, third-party proprietary interfaces, etc. are ALL exposed. Confoo 2011 - Montréal 19

20. 2. Attacking client systems Confoo 2011 - Montréal 20

21. 2. Attacking client systems Objective: attacking client systems (leveraging the trust in the web app) OR triggering the attack on the web application by another user. Strategy: inject active content into the user's browser. Impact: this vector is usually used as base for another attack. The impact is highly variable (from window popups to credentials stealing and malware infection.) Confoo 2011 - Montréal 21

22. 2. Attacking client systems Yeah. This is the "XSS" attack. Confoo 2011 - Montréal 22 Reflected XSS attack: the attack is triggered by the request and the payload comes in the response.

23. 2. Attacking client systems Confoo 2011 - Montréal 23 Stored XSS attack: the attack is stored somewhere and the payload comes once the user requests it.

24. 2. Attacking client systems Confoo 2011 - Montréal 24 DOM XSS attack: the attack is reflected or stored, and manipulates the DOM in real-time.

25. 2. Attacking client systems The problem occurs whenever the application: 1. takes data from its users 2. returns this same data back to its users without properly encoding it typically: <%=Response.Write(user.Description)%> <?php echo(u->Name); ?> -> every way of writing user input directly into the response is exposed! Confoo 2011 - Montréal 25

26. 2. Attacking client systems Typical impacts: Hi everyone! I love cookies! ;) <script> //whatever you can imagine here </script> Confoo 2011 - Montréal 26 Cookie stealing Phishing Local exploit (malware infection) CSRF attacks (we'll see that later) Ad-driven clicks You name it!

27. 2. Attacking client systems Confoo 2011 - Montréal 27 #1: ( &, <, >, " )  &entity; ( ', / )  &#xHH; ESAPI: encodeForHTML() HTML Element Content (e.g., <div> some text to display </div> ) #2: All non-alphanumeric < 256  &#xHH ESAPI: encodeForHTMLAttribute() HTML Attribute Values (e.g., <input name='person' type='TEXT' value='defaultValue'> ) #3: All non-alphanumeric < 256  HH ESAPI: encodeForJavaScript() JavaScript Data (e.g., <script> some javascript </script> ) #4: All non-alphanumeric < 256  H ESAPI: encodeForCSS() HTML Style Property Values (e.g., .pdiv a:hover {color: red; text-decoration: underline} ) #5: All non-alphanumeric < 256  %HH ESAPI: encodeForURL() URI Attribute Values (e.g., <a href="javascript:toggle('lesson')" ) I'll talk about this tomorrow!

29. Are cookies protected from script stealing attacks? (httpOnly flag set)Don't reinvent the wheel, use encoding libraries: - OWASP ESAPI - Encoding libraries in your technology Some help: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API Confoo 2011 - Montréal 28

30. 2. Attacking client systems Myths: XSS attacks can be blacklisted.  Wrong!(javascript is an unpredictable language) See : http://ha.ckers.org/xss.html for examples Confoo 2011 - Montréal 29

31. 2. Attacking client systems Magic words: non-alphanumeric JS obfuscation / evasion Confoo 2011 - Montréal

32. 3. Attacking auth/session systems Confoo 2011 - Montréal 31

33. 3. Attacking auth/session systems Objective: bypassing the authentication layer or stealing a legitimate users' identity. Strategy: many. Impact: identity spoofing  Repudiation Confoo 2011 - Montréal 32

34. 3. Attacking auth/session systems The problem occurs whenever: Confoo 2011 - Montréal 33 Insecure credentials transmission Insecure credentials storage Weak credentials Unpredictable session tokens Stealable session tokens Replayable auth. sequence Insecure 1st password generation Insecure password recovery Insecure session termination Insecure simultaneous sessions Insecure endpoint authentication Insecure multi-staged authentication Users enumeration/ guessing Account bruteforcing Account denial of service Insecure strong authentication token Insecure browser caching Insecure trusts Replayable/predictable SSO token Authentication bypassing …

36. poor frameworks.Confoo 2011 - Montréal 34

38. Did you evaluate the risk on all these attacks?Confoo 2011 - Montréal 35 Insecure credentials transmission Insecure credentials storage Weak credentials Unpredictable session tokens Stealable session tokens Replayable auth. sequence Insecure 1st password generation Insecure password recovery Insecure session termination Insecure simultaneous sessions Insecure endpoint authentication Users enumeration/ guessing Account bruteforcing Account denial of service Insecure strong authentication token Insecure browser caching Insecure trusts Replayable/predictable SSO token Authentication bypassing … Also known as: "Ask the damn appsec guy to review the design!"

39. 4. Exploiting direct object references Confoo 2011 - Montréal 36

40. 4. Exploiting direct object references Objective: bypassing authorization procedures by requesting direct access to a particular resource (read or write access) Strategy: intercept and tamper the identifier Impact: Unauthorized modification Access to confidential data Confoo 2011 - Montréal 37

41. Confoo 2011 - Montréal 38 Message IDs, profile IDs, user identifiers, email IDs, file IDs, financial report identifier, payment ID, invoice ID, customer ID, e-health profile ID, card ID, event ID, etc…

42. Confoo 2011 - Montréal 39 All parts of the HTTP request are exposed: the URL, the Body (form responses fields), in the HTTP headers, etc.

43. 4. Exploiting direct object references The problem occurs whenever : The application exposes direct references (IDs) to the user interface AND does not implement authorization checks in each request. (sometimes called: presentation layer access control) Confoo 2011 - Montréal 40

44. 4. Exploiting direct object references In your checklist: Check at least one of these: Are direct references hidden from the users? i.e.: are you showing indexed lists? 0,1,2,3,4… Is access control enforced within the object read/write request? i.e.: "UPDATE object WHERE id = [objectID] AND owner = [userId]" Confoo 2011 - Montréal 41

45. 4. Exploiting direct object references Myths: If the IDs are not simple numeric sequences, it's not vulnerable  Wrong. Any real reference that can be guessed or computed is exposed. IDs should be sent within forms only  Wrong. Any part of the request can be tampered by an attacker: Querystring Form fields HTTP headers Etc. Confoo 2011 - Montréal 42

46. 4. Exploiting direct object references Myths: We implemented indexed lists, so we're not vulnerable.  It depends. Common mistake: using indexed lists on the main webapp and keeping direct references in other interfaces (APIs, web services, etc.) Confoo 2011 - Montréal 43

47. 5. Controlling a 3rd party browser Confoo 2011 - Montréal 44

48. Confoo 2011 - Montréal 45

49. Confoo 2011 - Montréal 46

51. Modification of sensitive informationService disruption (denial of service, etc.) (potentially: legal prosecution…) Confoo 2011 - Montréal 47

52. 5. Controlling a 3rd party browser The problem occurs whenever : The application exposes sensitive operations through predictable requests: - page URLs that can simply be reproduced - forms fields that can simply be copy/pasted on another page - smart fields that can be re-generated using advanced client-side code Confoo 2011 - Montréal 48

53. 5. Controlling a 3rd party browser In your checklist: Verify that all sensitive operations of your webapp are tied to unpredictable requests: If we can copy paste an URL -> vulnerable If we can copy paste a form -> vulnerable Use tokens, according to the risk: <input type=hidden value=<%=sessionid%> <input type=hidden value=<%=formid%> <input type=hidden value=<%=onetimeid%> "Please confirm the transaction by inserting the code appearing on your token." Confoo 2011 - Montréal 49

54. 5. Controlling a 3rd party browser Myths: FORMs are not exposed to the attack Wrong. <script>document.forms[0].submit();</script> Confoo 2011 - Montréal 50

55. 6. Exploiting an insecure configuration The problem occurs whenever : The service exposes an insecure configuration: - vulnerable services (systems) - unsecure configuration/administration settings Confoo 2011 - Montréal 51

56. 6. Exploiting an insecure configuration Objective: compromising defenses Strategy: exploit a configuration weakness or a vulnerable service Impact: variable (generally: quite bad) Authentication/authorization bypass Arbitrary code execution Service disruption (denial of service, etc.) Confoo 2011 - Montréal 52

57. 6. Exploiting an insecure configuration In your checklist: Verify that the application is deployed on an up-to-date system Verify the configuration enforces secure controls: Only necessary applications/services installed Strong passwords No public-facing administrative interfaces  OS/Services hardening Confoo 2011 - Montréal 53

58. 7. Breaking weak cryptography Confoo 2011 - Montréal 54

59. 7. Breaking weak cryptography The problem occurs whenever : Cryptography is used without understanding how it works... Confoo 2011 - Montréal 55 Hard-coded secrets Use of not-so-random randomizers Missing encryption of sensitive data Missing a cryptographic step Not using a secure encryption mode Not using a randomized initialization vector in chaining encryption modes Storing credentials with reversible encryption Using poor algorithms for secret-to-key derivation Unexpected loss of entropy Failure to follow specification Failure to use optimal asymmetric encryption padding Failure to store keys securely Failure to destroy keys securely Failure to revoke keys securely Failure to distribute keys securely Failure to generate keys securely Failure to use adequate encryption strength Use of unauthorized encryption strength Use of broken encryption algorithms Failure to prevent reversible one-way hashing Failure to prevent inference/statistical observation …

60. 7. Breaking weak cryptography Objective: decipher protected information Strategy: exploit a weakness in the implementation of the cryptosystem Impact: variable Authentication/authorization bypass Information disclosure Confoo 2011 - Montréal 56

61. 7. Breaking weak cryptography In your checklist: Is the implementation protected from these attacks/weaknesses? Confoo 2011 - Montréal 57 Hard-coded secrets Use of not-so-random randomizers Missing encryption of sensitive data Missing a cryptographic step Not using a secure encryption mode Not using a randomized initialization vector in chaining encryption modes Storing credentials with reversible encryption Using poor algorithms for secret-to-key derivation Unexpected loss of entropy Failure to follow specification Failure to use optimal asymmetric encryption padding Failure to store keys securely Failure to destroy keys securely Failure to revoke keys securely Failure to distribute keys securely Failure to generate keys securely Failure to use adequate encryption strength Use of unauthorized encryption strength Use of broken encryption algorithms Failure to prevent reversible one-way hashing Failure to prevent inference/statistical observation … Also known as: "Ask the damn crypto guy to review it!"

62. 8. Querying direct URLs Confoo 2011 - Montréal 58

63. 8. Querying direct URLs Confoo 2011 - Montréal 59 Is this confidential document URL secured? http://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-snc1/9718_175303097344_636682344_3601133_2199691_n.jpg

64. 8. Querying direct URLs The problem occurs whenever : The application builds its confidentiality model on sensitive listings rather than access controls. All URLs leading to a sensitive resource are exposed: - documents stored on the filesystem (reports, PDFs, pictures, etc.) - sensitive applications with "hidden" URLs (admin interface) Confoo 2011 - Montréal 60

65. 8. Querying direct URLs Objective: accessing confidential resources by requesting their direct address Strategy: intercept or guess the URLs Impact: Access to confidential data Access administrative panels/areas Confoo 2011 - Montréal 61

66. 8. Querying direct URLs In your checklist: Verify that all sensitive resources cannot be retrieved just by knowing their location: Documents Sensitive applications/modules i.e.: index.php?module=user_manager Confoo 2011 - Montréal 62

67. 9. Intercepting traffic Confoo 2011 - Montréal 63

68. 9. Intercepting traffic The problem occurs whenever : The application sends/accepts confidential information using unsecured communication channels. Confoo 2011 - Montréal 64

69. 9. Intercepting traffic Objective: accessing confidential information by intercepting legitimate traffic Strategy: intercept traffic (open wifi attack) Impact: information disclosure Passwords, credentials Sensitive URLs Documents, reports, private communications, etc. In advanced configurations -> traffic modification Confoo 2011 - Montréal 65

70. 9. Intercepting traffic In your checklist: Verify that sensitive information is exchanged securely: Use encrypted communication channels AT LEAST FOR CREDENTIALS!!! If SSL/TLS is unavailable: Use one-time or strong authentication Confoo 2011 - Montréal 66 I'll talk about this tomorrow!

71. 10. Exploiting redirects and forwards Confoo 2011 - Montréal 67

72. Confoo 2011 - Montréal 68 http://m.facebook.com/l.php?u=http://www.securityvibes.com/community/fr/blog/2011/03/08/piratage-que-sest-il-pass%C3%A9-%C3%A0-bercy&h=cb7bd&refid=0 ??? http://m.facebook.com/l.php?u=http://m.facebookmobile.com

73. 10. Exploiting redirects and forwards The problem occurs whenever : The application redirects browsers to an URL passed as parameter without verifying its integrity. Confoo 2011 - Montréal 69

74. 10. Exploiting redirects and forwards Objective: attract users by luring them into clicking a trusted website Strategy: forge a redirector link and phish the user Impact: phishing (variable impacts) Most frequently: passwords, credentials stealing Confoo 2011 - Montréal 70

75. 10. Exploiting redirects and forwards In your checklist: Verify that the redirector validates the target before instructing the browser to do so. Confoo 2011 - Montréal 71

76. Putting it all together We identified ten attack techniques Each of them is currently regularly used by blackhats they are actual risks. Is this referenced anywhere? Confoo 2011 - Montréal 72

77. OWASP Top 10 All 10 attack classes are explained It helps you identify the exposure of your code and mitigate against the attacks It helps you evaluating the risk It is updated yearly It is available online Confoo 2011 - Montréal 73

78. OWASP? Open Web Application Security Project Not-for-profit organization https://owasp.org Mission: Bring visibility on application security and risks to organizations Formalize and centralize the webappsec body of knowledge and make it open to everyone Confoo 2011 - Montréal 74

79. OWASP? More than 130 local chapters worldwide Canada: Edmonton, Montréal, Okanagan, Quebec, Ottawa, Toronto, Vancouver Confoo 2011 - Montréal 75

80. What'snext? Download the Top 10: http://www.owasp.org/index.php/Top_10_2010 Read it: For all: understand the attacks and the risks For developers: learn how to prevent them For testers: learn how to detect them For managers: use it as reference material Are your webapps protected from these 10 risks? Did someone teach this document to your teams? Confoo 2011 - Montréal 76

81. What'snext? There is a lot more to do: More attack techniques to identify Understand specific countermeasures for the development technologies you use Make sure your application is not vulnerable to these attacks Increase your skills on web application security Confoo 2011 - Montréal 77

82. What'snext? Good news: you're at Confoo!  Switch your code to strong authentication: Philippe Gamache (@securesymfony) Sylvain Maret (@smaret) Use APIs that will make your life easier: Philippe Gamache (@securesymfony) Don't forget about web services security: SebastienGioria (@spoint) Identify the major threats of your application earlier: Antonio Fontes (@starbuck3000) Confoo 2011 - Montréal 78

83. Please, ask! Confoo 2011 - Montréal 79

84. Merci!/Thankyou! Contact me: antonio.fontes@L7securite.ch Follow me: @starbuck3000 Downloadthis: on slideshare.net (starbuck3000) Confoo 2011 - Montréal 80