Web Application Security21/03/2012

Softjourn Inc.

Web Application Security

Anatoliy Okhotnikov

Softjourn Inc.

Web Application Security

3/21/12

Agenda● Why this is important? What to do?

● Security threats & Mitigations

● Designing Secure Web Applications

● Building Secure Web Applications

● Securing Your Network, Web Server and Database

● Assessing Your Security

Why this is important?Web applications allow visitors

access to the most critical resources of a web site, the web server and the database server

Deface a web site Loss of trust with customers

and/or visitors Damaged brand reputation Lost sales revenue Your site labeled as a malicious Loss of search engine rankings

Why this is important? (more) Insert spam links directing visitors to another site Insert malicious code that installs itself onto a

visitor’s computer Insert malicious code that steals session IDs

(cookies) Steal visitor information and browsing habits Steal account information Steal information stored in the database Access restricted content And much more...

What to do?

reduces the likelihood of a successful attack and mitigates the extent of damage if an attack occurs. It resides on a secure host

(server) in a secure network and is developed using secure design and development

guidelines.

Build a hack-resilient application

Why this is important?

Security threats SQL injection OS Command injection Classic buffer overflow Cross-site scripting (XSS) Missing authentication

and/or authorization Direct site attacks more...

Security threats (more) Use of Hard-coded Credentials Missing Encryption of Sensitive Data Unrestricted Upload of File with Dangerous Type Reliance on Untrusted Inputs in a Security

Decision Execution with Unnecessary Privileges Cross-Site Request Forgery (CSRF) Improper Limitation of a Pathname to a

Restricted Directory ('Path Traversal') Download of Code Without Integrity Check even more...

Security threats (even more) Incorrect Authorization Inclusion of Functionality from Untrusted Control Sphere Incorrect Permission Assignment for Critical Resource Use of Potentially Dangerous Function Use of a Broken or Risky Cryptographic Algorithm Incorrect Calculation of Buffer Size Improper Restriction of Excessive Authentication

Attempts URL Redirection to Untrusted Site ('Open Redirect') Uncontrolled Format String Integer Overflow or Wraparound Use of a One-Way Hash without a Salt

Mitigations

Mitigations Establish and maintain control over all of

your inputs and outputs Lock down your environment Assume that external components can be

subverted, and your code can be read by anyone

Use industry-accepted security features instead of inventing your own

more...

Mitigations (more) Use libraries and frameworks that make it

easier to avoid introducing weaknesses Integrate security into the entire software

development lifecycle Use a broad mix of methods to

comprehensively find and prevent weaknesses

Allow locked-down clients to interact with your software

Designing Secure Web Applications

Designing Secure Web Applications Design input validation strategies Partition Web sites into open and restricted areas Implement effective account management practices Develop effective authentication and authorization

strategies Protect sensitive data Protect user sessions Prevent parameter manipulation Handle exceptions securely Secure an application’s configuration management

features List audit and logging considerations

Designing: input validation strategies

Designing: input validation strategies

Assume ALL input is malicious Centralize your approach Do not rely on client-side validation Be careful with canonicalization issues Constrain, reject and sanitize your

input Use common input handling practices

Designing: authentication

Designing: authentication

Separate public and restricted areas Use account lockout policies for end-user

accounts Support password expiration periods Be able to disable accounts Do not store passwords in user stores Require strong password Do not send password over the wire in

plaintext Protect authentication cookies

Designing: authorization

Use multiple gatekeepers Restrict user access to

system level resources Consider authorization

granularity

Designing: configuration management

Secure your administration interfaces

Secure your configuration stores

Separate administration privileges

Use least privileged process and service accounts

Designing: sensitive data

Secrets Sensitive per user data

Designing: session management

Use SSL to protect session authentication cookies

Encrypt the contents of the authentication cookies

Limit session lifetime Protect session state

from unauthorized access

Designing: cryptography

Do not develop your own cryptography

Keep unencrypted data close to the algorithm

Use the correct algorithm and correct key size

Secure your encryption keys

Designing: parameter manipulation

Encrypt sensitive cookie state

Make sure that users do not bypass your checks

Validate all values sent from the client

Do not trust HTTP header information

Designing: exception management

Do not leak information to the client

Log detailed error messages

Catch exceptions

Designing: auditing and logging

Audit and log access across application tiers

Consider identity flow

Log key events Secure log files Back up and

analyze log files regularly

Building Secure Web Applications

Building Secure Web Applications

Role-based Security, URL authorization

Code Access Security Be aware of unauthorized access,

privilege elevation, code injection, information disclosure, tampering

Log events Data Access Obfuscation

Secure Web App: class design

Restrict Class & Member Visibility

Seal Non-Base Classes

Restrict Which Users Can Call Your Code

Expose Fields Using Properties

Secure Web App: exceptions

Use Structured Exception Handling

Do Not Log Sensitive Data Do Not Reveal Sensitive

System or Application Information

Consider Exception Filter Issues

Consider an Exception Management Framework

Secure Web App: file I/O

Avoid Untrusted Input for File Names Do Not Trust Environment Variables Validate Input File Names Constrain File I/O Within Your

Applications' Context

Secure Web App: serialization

Do Not Serialize Sensitive Data Validate Serialized Data Streams Partial Trust Considerations

Secure Web App: threading

Do Not Cache the Results of Security Checks

Consider Impersonation Tokens Synchronize Static Class Constructors Synchronize Dispose Methods

Secure Web App: cryptography

Use Platform-provided Cryptographic Services

Key Generation Key Storage Key Exchange Key Maintenance

Secure Web App: architecture & design

Input validation Authentication Authorization Configuration Management Sensitive Data Session Management Cryptography Parameter Manipulation Exception Management Auditing & Logging

Securing Your Network, Web Server and Database

Securing your network Securing your web server Securing your database

Securing Your Network

Securing Your Network: routers Patch & Update Ingress & Egress Filtering / Screen Traffic Prevent TTL Expired Messages with Values of 1

or 0 Do Not Receive or Forward Directed Broadcast

Traffic Disable Unused Interfaces Apply Strong Password Policies Use Static Routing Audit Web Facing Administration Interfaces Auditing and Logging / Intrusion Detection

Securing Your Network: firewalls

Patch & Update Filters

Packet filters Circuit-level filters Application filters Stateful inspection Custom application filters

Logging & Auditing Perimeter Networks

Securing Your Network: switches

Patches & Updates Virtual Local Area Networks (VLANs) Insecure Defaults Services Encryption

Securing Your Web Server

Be aware of profiling, denial of service, unauthorized access, arbitrary code execution, elevation of privileges, viruses, worms and trojan horses

Patches & Updates. Services. Protocols. Accounts. Files & Directories. Shares. Ports. Auditing & Logging. Sites & Virtual Directories. Script Mappings. API Filters. Server Certificates. Permissions. Error Messages. Sample & test files.

Securing Your Database Be aware of SQL injection, network eavesdropping,

unauthorized server access, password cracking Patches & Upgrades. Disable unused server services Restrict server to TCP/IP, harden TCP/IP stack Secure DB accounts, delete or disable unused accounts,

enforce strong password policy, restrict remote logons, disable anonymous

Verify permissions on files & directories, secure or remove tools, utilities and SDKs

Restrict access to DB port Log all failed logon attempts, actions, enable SQL logging Run server using a least privileged account Do not grant permission to the public role Remove sample DBs, secure stored procedures

Assessing Your Security

Get organized. Establish the process

Standardize how you verify web application security (ASVS)

Assemble tools suite (OWASP Live CD Project)

Code review. CodeCrawler, Orizon, O2

Testing/Penetration. WebScarab

Assessment: Injection

Assessment: Injection Verify that all use of interpreters clearly

separates untrusted data from the command query.

Check the code. Code analysis tools can help. Penetration testing with exploits.

Automated dynamic scanning which exercises the application.

Assessment: Cross-Site Scripting (XSS)

Assessment: Cross-Site Scripting (XSS)

Ensure that all user supplied input sent back to the browser is verified to be safe and properly escaped before it is included in the output page.

Both static and dynamic tools can find some XSS problems automatically, but complete coverage requires a combination of manual code review and manual penetration testing.

Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.

Assessment: Broken Authentication and Session Management

Assessment: Broken Authentication and Session Management

Are credentials always protected when stored using hashing or encryption?

Can credentials be guessed or overwritten through weak account management functions?

Are session IDs exposed in the URL? Are session IDs vulnerable to session fixation

attacks? Do sessions IDs timeout and can users log out? Are session IDs rotated after successful login? Are passwords, session IDs, and other credentials

sent over TLS connections?

Assessment: Insecure Direct Object References

Assessment: Insecure Direct Object References

Verify that all object references have appropriate defenses. Code review/testing.

For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.

If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.

Assessment: Cross-Site Request Forgery (CSRF)

Assessment: Cross-Site Request Forgery (CSRF)

Verify if each link and form contains an unpredictable token for each user.

Check multistep transactions, as they are not inherently immune.

Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesn't count since this information is also included in forged requests.

OWASP's CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.

Assessment: Security Misconfiguration

Assessment: Security Misconfiguration

Do you have a process for keeping all your software up to date? This includes the OS, Web/App Server, DBMS, applications and all code libraries.

Is everything unnecessary disabled, removed or not installed (eg ports, services, pages, accounts, privileges)?

Are default account passwords changed or disabled? Is your error handling set up to prevent stack traces

and other overly informative error messages from leaking?

Are the security settings in your development frameworks and libraries understood and configured properly?

Assessment: Insecure Cryptographic Storage

Assessment: Insecure Cryptographic Storage

Which data is sensitive enough to require encryption?

Is it encrypted everywhere it is stored long term, particularly in backups of this data?

Can the authorized users only access decrypted copies of the data?

Is a strong standard encryption algorithm used?

Is a strong key generated, protected from unauthorized access and key change is planned for?

Assessment: Failure to Restrict URL Access

Assessment: Failure to Restrict URL Access

Verify every page. Consider is the page supposed to be public or private. Is authentication required to access a private page? Is a private page supposed to be accessible to ANY

authenticated user? If not, is an authorization check made to ensure the user has permission to access that page?

Verify external security mechanisms are properly configured for every page? If code level protection is used, verify that it is in place for every required page.

Penetration testing can also verify whether proper protection is in place.

Assessment: Insufficient Transport Layer Protection

Assessment: Insufficient Transport Layer Protection

Is SSL used to protect all authentication related traffic?

Is SSL used for all resources on all private pages and services?

Are strong algorithms only supported? Have all session cookies their 'secure' flag

set? Is the server certificate legitimate and

properly configured for that server?

Assessment: Unvalidated Redirects and Forwards

Assessment: Unvalidated Redirects and Forwards

Review the code for all uses of redirect or forward. For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.

Spider the site to see if it generates any redirects (300-307). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such URL. If so, change the URL target and observe whether the site redirects to the new target.

If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and those that do.

Assessment: Additional Risks to Consider

Assessment: Additional Risks to Consider

Clickjacking (UI redress attack) Concurrency flaws Denial of service Header injection Information leakage and Improper error

handling Insufficient anti-automation Insufficient logging and accountability Lack of intrusion detection and response Malicious file execution

Copyright © 2000-2011 Softjourn, Inc. All rights reserved

Links• http://en.wikipedia.org/wiki/Web_application_s

ecurity• http://cwe.mitre.org/top25/• http://msdn.microsoft.com/en-

us/library/ff649874.aspx• http://www.applicure.com/solutions/web-

application-security• http://www.clusif.asso.fr/fr/production/ouvrage

s/pdf/CLUSIF-2010-Web-application-security.pdf

• http://www.webappsec.org/• http://code.google.com/p/owasptop10/

Copyright © 2000-2011 Softjourn, Inc. All rights reserved

Questions & discussion“Anatoliy Okhotnikov”

<aokhotnikov@softjourn.com>