Learn how to protect your web applications in the cloud

1. Security in the Cloud:
Protecting Your Cloud Apps
Lars Ewe, CTO / VP of Engineering

2. Application Security Drivers
 75% of cyber attacks & internet security violations are
generated through internet applications.
Source: Gartner Group
 60% of the top 100 most popular Web sites have either
hosted or been involved in malicious activity in the first
half of 2008 Source: Websense Security Labs
 58% of total vulnerabilities are Web vulnerabilities.
Source: Symantec Threat Report – 2008
 73% of easily exploitable vulnerabilities affected Web
applications. Source: Symantec Threat Report – 2008
400+ New Vulnerabilities a Month and Growing
Security in the Cloud: Protecting Your Cloud Apps 2

3. Total Vulnerability Breakdown
Source: Cenzic Q3-Q4, 2008 Application Trends Report
Security in the Cloud: Protecting Your Cloud Apps 3

4. Findings from Cenzic ClickToSecure
Managed Services
Source: Cenzic Q3-Q4, 2008 Application Trends Report
Security in the Cloud: Protecting Your Cloud Apps 4

5. Corporate Security
Web App Database
Client Firewall IDS/IPS
Server Server Server
Intrusion Detection
And Prevention
Internet
Ports 443 & 80
still open
Desktop and
Content Network Security Application Security
Security 1990s 2000s
1980s
Security in the Cloud: Protecting Your Cloud Apps 5

6. 80 443
Cenzic, Inc. the Cloud: Protecting Your Cloud Apps
Security in 6

7. How Do Hackers Work?
 Hackers often use a combination of tools (proxies, fuzzers,
spiders, decoders, etc.) and manual testing and analysis
– Basic tools: Burp Suite, Paros, WebScarab, Tamper Data, …
 Fingerprint underlying infrastructure and implementation
technologies and try to explore known vulnerabilities
 Test infrastructure for weak configuration (e.g. directory
listings, WebDAV, default credentials, debug mode, etc.)
 Consult search engines and other sources to retrieve
information on the target (e.g. Google site: search)
 Analyze all requests / responses using an intercepting proxy
and a combination of different browsers and configuration
settings (e.g. JavaScript enabled/disabled, with/without
Flash, etc.)
Security in the Cloud: Protecting Your Cloud Apps 7

8. How Do Hackers Work? – contd.
 Attempt to map and analyze the application and identify
– HTTP headers, cookies, URL parameters, POST data, hidden form
fields, etc.
– Authentication & session management mechanics
(e.g. session tokens, login/logout pages, etc.)
– Client side controls & app logic
 Try to observe / analyze any encodings and obfuscations of
sensitive data (e.g. session tokens)
 Tamper with identified parameters in order to provoke
anomalies in app behavior (fuzzing)
 Provoke application exceptions that result in information
leakage
 Observe any naming conventions that might reveal hidden
content
Security in the Cloud: Protecting Your Cloud Apps 8

9. How Do Hackers Work? – contd.
 Search HTML source for any comments / disabled content
 Test for unsafe transmission of sensitive data (e.g. tokens)
 Test access controls & trust boundaries
 Analyze account registration and recovery, as well as
password change and “remember me” functionality
 Test multi-stage process flows / app logic flaws (e.g.
shopping cards)
 And so much more…
Security in the Cloud: Protecting Your Cloud Apps 9

10. Where Can I Learn More?
 OWASP (Open Web Application Security Project)
 Top Ten (we’ll look at five)
 Dev Guide
 Etc.
 WASC (Web Application Security Consortium)
 MITRE
 Common Vulnerabilities and Exposures (CVE)
 Common Weakness Enumeration (CWE)
 Etc.
 Many different blogs & other additional resources…
Security in the Cloud: Protecting Your Cloud Apps 10

11. OWASP Top Ten
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Security in the Cloud: Protecting Your Cloud Apps 11

12. Don’t Rely on
Client-Side Input Validation
 Don’t build your security model on the Web browser (client)
 Client-side security controls (e.g. input validation) can be
tampered with
 Easy to exploit – just trap the JS script with a MITM Proxy
and edit the script
 Attackers can bypass JS client-side logic altogether
 Attackers often don’t even use a browser for their attacks!
 Bottom line: The application must assume that each client
request is potentially malicious; client side input validation
provides convenience and better usability, but not security
Security in the Cloud: Protecting Your Cloud Apps 12

13. Check Application Input /
Test for Parameter Tampering
 All client input / request parameters must be validated /
checked, and filtered / scrubbed if needed
– For all kinds of HTTP “parameters”: Cookies, Form Fields,
URL Query Strings, HTTP Headers
– Beware of parameter (double) encoding
 All client requests could potentially be malicious!
 Examples of vulnerabilities that can result from
insufficient input / parameter validation:
– SQL Injection
– Cross-Site Scripting (XSS)
Security in the Cloud: Protecting Your Cloud Apps 13

14. OWASP Top Ten
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Security in the Cloud: Protecting Your Cloud Apps 14

15. Cross-Site Scripting (XSS)
 What is it?: The Web Application is used to store (stored
XSS), transport, and deliver malicious active content to an
unsuspecting user.
 Root Cause: Failure to proactively reject or scrub malicious
characters from input vectors and encode output.
 Impact: XSS allows cookie theft, credential theft, data
confidentiality, integrity, and availability risks. Browser
Hijacking and Unauthorized Access is possible using existing
exploits.
 Solution: A strong policy for handling untrusted content. Use
input filtering (white lists, blacklists, etc.) to ensure input data
conforms to the required character set, size, and syntax.
Beware of (multi-) encoded input data / canonicalization
errors. Implement strong output encoding (HTML, XML).
Security in the Cloud: Protecting Your Cloud Apps 15

16. Malicious Script
Security in the Cloud: Protecting 16
Your Cloud Apps

17. Security in the Cloud: Protecting 17
Your Cloud Apps

18. Security in the Cloud: Protecting 18
Your Cloud Apps

19. Security in the Cloud: Protecting 19
Your Cloud Apps

20. Security in the Cloud: Protecting 20
Your Cloud Apps

21. Security in the Cloud: Protecting 21
Your Cloud Apps

22. XSS in action!
Security in the Cloud: Protecting 22
Your Cloud Apps

23. Login Pop-up Script Example Code
<script>
window.open("","","status=1,width=250,height
=180").
document.write('<H1>Login Required</H1>
Your session expired.
<TABLE><TBODY><TR><TD>User:</TD><TD>
<INPUT></TD></TR><TR><TD>Password:</TD><TD>
<INPUT
type=password></TD></TR><TR><TD></TD><TD>
<INPUT type=submit value="Login"></TD></TR>
</TBODY></TABLE>');
</script>
Or something like document.cookie ….
Security in the Cloud: Protecting Your Cloud Apps 23

24. OWASP Top Ten
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws (Example: SQL Injection)
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Security in the Cloud: Protecting Your Cloud Apps 24

25. SQL Disclosure / Injection
What is it?: Database contents are compromised or
disclosed by the use of specially crafted input that manipulates
SQL Query Logic (often using tautologies).
Root Cause: Failure to properly scrub, reject, or escape
domain-specific SQL characters from an input vector or to use
parameterized SQL.
Impact: Data confidentiality, integrity, and availability with the
ability to read, modify, delete, or even drop database tables.
Solution: Use parameterized queries / prepared SQL
statements. Validate and scrub all user input.
Security in the Cloud: Protecting Your Cloud Apps 25

26. Security in the Cloud: Protecting 26
Your Cloud Apps

27. Security in the Cloud: Protecting 27
Your Cloud Apps

28. SQL Tautology
Security in the Cloud: Protecting 28
Your Cloud Apps

29. User data for other
users is being
disclosed!
Security in the Cloud: Protecting 29
Your Cloud Apps

30. Robert’); DROP TABLE Students;--
Security in the Cloud: Protecting Your Cloud Apps 30

31. OWASP Top Ten
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws (Example: SQL Injection)
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Security in the Cloud: Protecting Your Cloud Apps 31

32. CSRF (Cross-Site Request Forgery)
 What is it?: Basic Web Application session management
behavior is exploited to make legitimate user requests without
the user’s knowledge or consent.
 Root Cause: Basic session id management that is
vulnerable to exploitation (e.g. cookie-based).
 Impact: Attackers can make legitimate Web requests from
the victim’s browser without the victim’s knowledge or
consent, allowing legitimate transactions in the user’s name.
This can results in a broad variety of possible exploits.
 Solution: Supplement basic session management by using
non-predictable “nonce” or other unique one-time tokens in
addition to common session identifiers, as well as the
validation of HTTP Referrer headers.
Security in the Cloud: Protecting Your Cloud Apps 32

33. Security in the Cloud: Protecting 33
Your Cloud Apps

34. Be careful what you browse while you’re still
logged into a sensitive application!
Security in the Cloud: Protecting 34
Your Cloud Apps

35. Security in the Cloud: Protecting 35
Your Cloud Apps

36. CSRF Example Code
<body>
Welcome to hackerbank.com. It's been a pleasure doing business for you!
<iframe id="hidden_iframe" width=0 height=0 scrolling=no
src="Sell_Stock.htm"></iframe>
</body>
<body>
<form name="form" id="form" method="post"
action="http://localhost:8081/kelev/php/stock.php">
<input type="hidden" name="hUserId" value="7" />
<input type="hidden" name="symbol" value="GLO" />
<input type="hidden" name="values" value="30" />
<input type="hidden" name="numbersell" value="10" />
</form>
<script>document.form.submit();</script>
The browser sends session cookie along with the form data
Security in the Cloud: Protecting Your Cloud Apps 36

37. OWASP Top Ten
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws (Example: SQL Injection)
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Security in the Cloud: Protecting Your Cloud Apps 37

38. Information Leakage &
Improper Error Handling
 Information Leakage & Improper Error Handling can result
in:
– Configuration, data, and internal state disclosure
– Reveal internal workings of an application
 Implement a comprehensive, solid exception handling
architecture
– Default error handler which returns sanitized error
message for all error paths
 Don not disclose any stack trace, debug log, or path
information or failed SQL statements to users
Security in the Cloud: Protecting Your Cloud Apps 38

39. Security in the Cloud: Protecting Your Cloud Apps 39

40. OWASP Top Ten
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws (Example: SQL Injection)
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Security in the Cloud: Protecting Your Cloud Apps 40

41. Authentication & Session
Management Security
 Most common session / state mechanism: Unique session
tokens in the form of HTTP cookies
 Some applications use sessionless state mechanisms (like
ASP.NET's ViewState) to impl. state on the client
– Tip: If you use ViewSate, make sure you enable hash via
EnableViewStateMac="true"
– Caution: ViewSate hash prevents state tampering, but hackers can
still decode and view state information!
 Use strong authentication mechanism (e.g. two factor)
 Implement strong session termination / logout mechanism
 Avoid weak passwords & weak change / forgot password
mechanisms
 And always remember: The strongest authentication won't
help if session management vulnerabilities exist!
Security in the Cloud: Protecting Your Cloud Apps 41

42. Examples of Authentication &
Session Management Related Attacks
There are various authentication and session management
related attack vectors, as well as some more loosely related
ones, such as:
 Session Fixation & Hijacking
 Ineffective Session Termination
 Weak passwords, vulnerable “forgot password” functionality,
etc.
 Authentication Bypass (SQL Injection), Authorization Boundary
Vulnerabilities, Privilege Escalation
 HTTPS/SSL Bypass Vulnerabilities (access with HTTP)
 XSS / CSRF
 And others…
Security in the Cloud: Protecting Your Cloud Apps 42

43. How To Defend Yourself?
Given all these different attacks (and many more):
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access
Are there any Best Practices you can follow to
try to defend themselves?
Security in the Cloud: Protecting Your Cloud Apps 43

44. Web App Security Best Practices
 See owasp.org and OWASP dev guide
 Analyze and know your security boundaries and attack
surfaces
 Beware of reliance on client-side security measures
• Always implement strong server side input & parameter
validation (white & black listing) and output encoding
• Test against a robust set of evasion rules
• Remember: The client can never be trusted!
 Assume the worst case scenario for all 3rd party interactions
• 3rd parties can inherently not be trusted!
 Use strong tokens with strong randomness
 Implement strong logout functionality (with invalidation of
session tokens & deletion of session & state on server
Security in the Cloud: Protecting Your Cloud Apps 44

45. Web App Security Best Practices –
contd.
 Implement session expiration with same results as strong
logout (after e.g. 5 or 10 minutes)
 Ideally do not allow concurrent logins
 Terminate sessions when attacks are detected
 Beware of JavaScript Hijacking (prefix JavaScript with
while(1);)
 Implement anti-CSRF defenses
 Escape special characters before sending them to the
browser (e.g. < to &lt;)
 Leverage HTTPS for sensitive data, use HTTPOnly &
Secure cookie flags
 Use parameterized SQL for any DB queries
Security in the Cloud: Protecting Your Cloud Apps 45

46. Questions?
Lars Ewe, CTO & VP of Engineering
www.cenzic.com | 1-866-4-CENZIC (1-866-423-6942)