Security in the Cloud: Protecting Your Cloud Apps
Lars Ewe, CTO / VP of Engineering
Security in the Cloud: Protecting Your Cloud Apps 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 3
Total Vulnerability Breakdown
Source: Cenzic Q3-Q4, 2008 Application Trends Report
Security in the Cloud: Protecting Your Cloud Apps 4
Findings from Cenzic ClickToSecure Managed Services
Source: Cenzic Q3-Q4, 2008 Application Trends Report
Security in the Cloud: Protecting Your Cloud Apps 5
Corporate Security
Internet
Client FirewallWeb
Server
App
Server
Database
ServerIDS/IPS
Application Security
2000sNetwork Security
1990s
Desktop and
Content
Security
1980s
Ports 443 & 80
still open
Intrusion Detection
And Prevention
Security in the Cloud: Protecting Your Cloud Apps 6Cenzic, Inc. 6
80 443
7
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.)
How Do Hackers Work?
Security in the Cloud: Protecting Your Cloud Apps
8
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
How Do Hackers Work? – contd.
Security in the Cloud: Protecting Your Cloud Apps
9
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…
How Do Hackers Work? – contd.
Security in the Cloud: Protecting Your Cloud Apps
10
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…
Where Can I Learn More?
Security in the Cloud: Protecting Your Cloud Apps
Security in the Cloud: Protecting Your Cloud Apps 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 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 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 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 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
16
Malicious Script
Security in the Cloud: Protecting
Your Cloud Apps
17
Security in the Cloud: Protecting
Your Cloud Apps
18
Security in the Cloud: Protecting
Your Cloud Apps
19
Security in the Cloud: Protecting
Your Cloud Apps
20
Security in the Cloud: Protecting
Your Cloud Apps
21
Security in the Cloud: Protecting
Your Cloud Apps
22
XSS in action!
Security in the Cloud: Protecting 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 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 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
26
Security in the Cloud: Protecting
Your Cloud Apps
27
Security in the Cloud: Protecting
Your Cloud Apps
28
SQL Tautology
Security in the Cloud: Protecting
Your Cloud Apps
29
User data for other users is being disclosed!
30
Robert’); DROP TABLE Students;--
Security in the Cloud: Protecting Your Cloud Apps
Security in the Cloud: Protecting Your Cloud Apps 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 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
33
Security in the Cloud: Protecting
Your Cloud Apps
34
Be careful what you browse while you’re still logged into a sensitive application!
Security in the Cloud: Protecting
Your Cloud Apps
35
Security in the Cloud: Protecting 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 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
38
Information Leakage & Improper Error Handling
Security in the Cloud: Protecting Your Cloud Apps
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 39
Security in the Cloud: Protecting Your Cloud Apps 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
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
42
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…
Examples of Authentication &
Session Management Related Attacks
Security in the Cloud: Protecting Your Cloud Apps
Security in the Cloud: Protecting Your Cloud Apps 43
How To Defend Yourself?
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?
Given all these different attacks (and many more):
44
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
Web App Security Best Practices
Security in the Cloud: Protecting Your Cloud Apps
4545
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 <)
Leverage HTTPS for sensitive data, use HTTPOnly & Secure cookie flags
Use parameterized SQL for any DB queries
Web App Security Best Practices –contd.
Security in the Cloud: Protecting Your Cloud Apps
www.cenzic.com | 1-866-4-CENZIC (1-866-423-6942)
Questions?
Lars Ewe, CTO & VP of Engineering