Download - Security in the cloud protecting your cloud apps

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


Total Vulnerability Breakdown

Source: Cenzic Q3-Q4, 2008 Application Trends Report


Findings from Cenzic ClickToSecure Managed Services

Source: Cenzic Q3-Q4, 2008 Application Trends Report


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?


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.


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.


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?



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


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


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)


OWASP Top Ten












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


Your Cloud Apps

17


Your Cloud Apps

18


Your Cloud Apps

19


Your Cloud Apps

20


Your Cloud Apps

21


Your Cloud Apps

22

XSS in action!


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 ….


OWASP Top Ten


A2 – Injection Flaws (Example: SQL Injection)










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.


Your Cloud Apps

26


Your Cloud Apps

27


Your Cloud Apps

28

SQL Tautology


Your Cloud Apps

29

User data for other users is being disclosed!

30

Robert’); DROP TABLE Students;--



OWASP Top Ten












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.


Your Cloud Apps

33


Your Cloud Apps

34

Be careful what you browse while you’re still logged into a sensitive application!


Your Cloud Apps

35


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


OWASP Top Ten











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


OWASP Top Ten











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!


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



How To Defend Yourself?











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


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.


www.cenzic.com | 1-866-4-CENZIC (1-866-423-6942)

Questions?

Lars Ewe, CTO & VP of Engineering

Download - Security in the cloud protecting your cloud apps

Top Related