2 securing soa web applications and services with rational ...€¦ · and services with rational...

IBM Rational Software

© 2008 IBM Corporation

Securing SOA Web Applications and Services with Rational

Chatchawun JongudomsombutRational IT Specialist


© 2008 IBM Corporation2

“Approximately 100 million Americans have been informed that they have suffered a security breach so this problem has reachedepidemic proportions.”Jon Oltsik – Enterprise Strategy Group

“Up to 21,000 loan clients may have had data exposed”Marcella Bombardieri, Globe Staff/August 24, 2006

“Personal information stolen from 2.2 million active-duty members of the military, the government said…”New York Times/June 7, 2006

“Hacker may have stolen personal identifiable information for 26,000 employees..”ComputerWorld, June 22, 2006

The Alarming Truth



Web Application Security – Situation Today

HIGH AND INCREASING DEPENDENCE ON WEB SERVICES

– Work and business

– Communications and transactions

– Leisure and community

WEB APPLICATIONS ARE NEW TARGET FOR HACKERS

– SOA, portals, web services

– Some recent examples

• ASUSTEK

• MONSTER.COM

• China gaming “Panda” trojan

• USA Financial Analyst blog



We Use Network Vulnerability ScannersNeglect the security of the

software on the network/web server

We Use Network Vulnerability ScannersNeglect the security of the

software on the network/web server

The Myth: “Our Site Is Safe”

We Have Firewalls in Place

Port 80 & 443 are open for the right reasons

We Have Firewalls in Place

Port 80 & 443 are open for the right reasons

We Audit It Once a Quarter with Pen Testers

Applications are constantly changing

We Audit It Once a Quarter with Pen Testers

Applications are constantly changing

We Use SSL EncryptionOnly protects data between site and user not the web

application itself

We Use SSL EncryptionOnly protects data between site and user not the web

application itself



Network Server

WebApplications

The Reality:Security and Spending Are Unbalanced

% of Attacks % of Dollars

75%

10%

25%

90%

Sources: Gartner, Watchfire

Security Spending

of All Attacks on Information SecurityAre Directed to the Web Application Layer

75%75%of All Web Applications Are Vulnerable2/32/3

•Buffer Overflow•Cookie Poisoning•Hidden Fields•Cross Site Scripting•Stealth Commanding•Parameter Tampering•Forceful Browsing•SQL Injection•Etc…



The manipulation of web applications

Web Attacks



Desktop Transport Network Web Applications

AntivirusProtection

Encryption(SSL)

Firewalls /IDS / IPS

Firewall

Web ServersDatabases

BackendServer

ApplicationServers

Info Security LandscapeInfo Security Landscape

Understanding the Problem

Legit Network-level user

Port 80 & 443



Perimeter IDS IPS

IntrusionDetectionSystem

IntrusionPrevention

System

Network Defenses for Web Applications

App Firewall

ApplicationFirewall

Firewall

System Incident Event Management (SIEM)



Web Application Hacks are a Business Issue

Misdirect customers to bogus site

Read/write access to customer databasesUnauthorized Site/Data Access

Forceful Browsing/SQL Injection

Alter distributions and transfer accountsFraud, Data TheftParameter Tampering

Access to non-public personal information, fraud, etc.

Access O/S and Application

Stealth Commanding

Larceny, theft, customer mistrustIdentity TheftCross Site scripting

Unauthorized access, privacy liability, site compromised

Admin AccessDebug options

Illegal transactionsSite AlterationHidden fields

Larceny, theftSession HijackingCookie poisoning

Site Unavailable; Customers GoneDenial of Service (DoS)

Buffer overflow

Potential Business ImpactNegative ImpactApplication Threat



OWASP and the OWASP Top 10 list

Open Web Application Security Project – an open organization dedicated to fight insecure software

“The OWASP Top Ten document represents a broad consensus about what the most critical web application security flaws are”

We will use the Top 10 list to cover some of the most common security issues in web applications



Hackers can impersonate legitimate users, and control their accounts.

Identity Theft, Sensitive Information Leakage, …

Cross Site scripting

Hacker can forcefully browse and access a page past the login page

Hacker can access unauthorized resources

Failure to Restrict URL Access

Unencrypted credentials “sniffed” and used by hacker to impersonate user

Sensitive info sent unencrypted over insecure channel

Insecure Communications

Confidential information (SSN, Credit Cards) can be decrypted by malicious users

Weak encryption techniques may lead to broken encryption

Insecure Cryptographic Storage

Hacker can “force” session token on victim; session tokens can be stolen after logout

Session tokens not guarded or invalidated properly

Broken Authentication & Session Management

Malicious system reconnaissance may assist in developing further attacks

Attackers can gain detailed system information

Information Leakage and Improper Error Handling

Blind requests to bank account transfer money to hacker

Attacker can invoke “blind” actions on web applications, impersonating as a trusted user

Cross-Site Request Forgery

Web application returns contents of sensitive file (instead of harmless one)

Attacker can access sensitive files and resources

Insecure Direct Object Reference

Site modified to transfer all interactions to the hacker.

Execute shell commands on server, up to full control

Malicious File Execution

Hackers can access backend database information, alter it or steal it.

Attacker can manipulate queries to the DB / LDAP / Other system

Injection Flaws

Example ImpactNegative ImpactApplication Threat

The OWASP Top 10 list



Application Security Defects #1 & #2 Vulnerabilities



1. Cross-Site Scripting (XSS)

What is it?– Malicious script echoed back into HTML returned from a

trusted site, and runs under trusted context

What are the implications?– Session Tokens stolen (browser security circumvented)

– Complete page content compromised

– Future pages in browser compromised



XSS Example I

HTML code:



XSS Example II

HTML code:



Cross Site Scripting – The Exploit Process

Evil.org

User bank.com

1) Link to bank.comsent to user viaE-mail or HTTP

2) User sends script embedded as data

3) Script/data returned, executed by browser

4) Script sends user’scookie and session information without the user’s consent or knowledge

5) Evil.org uses stolensession information to

impersonate user



Exploiting XSS

A malicious user would create a banner image or a sends out an email with HTML text

Hidden by active scripting this HTML sends JavaScript code to the search box on the target application.



Exploiting XSS (cont.)Embedded JavaScript from e-mail message



Exploiting XSS

If I can get you to run my JavaScript, I can…– Steal your cookies for the domain you’re browsing

– Track every action you do in that browser from now on

– Redirect you to a Phishing site

– Completely modify the content of any page you see on this domain

– Exploit browser vulnerabilities to take over machine

– …

XSS is the Top Security Risk today (most exploited)



2 - Injection Flaws

What is it?– User-supplied data is sent to an interpreter as part of a

command, query or data.

What are the implications?– SQL Injection – Access/modify data in DB

– SSI Injection – Execute commands on server and access sensitive data

– LDAP Injection – Bypass authentication

– …



SQL Injection

User input inserted into SQL Command:– Get product details by id:

Select * from products where id=‘$REQUEST[“id”]’;

– Hack: send param id with value ‘ or ‘1’=‘1

– Resulting executed SQL:Select * from products where id=‘’ or ‘1’=‘1’

– All products returned



SQL Injection Example I



SQL Injection Example II



SQL Injection Example - Exploit



SQL Injection Example - Outcome



3 - Malicious File Execution

What is it?– Application tricked into executing commands or creating

files on server

What are the implications?– Command execution on server – complete takeover

– Site Defacement, including XSS option



Malicious File Execution – Example I



Malicious File Execution – Example cont.



4 - Insecure Direct Object Reference

What is it?– Part or all of a resource (file, table, etc.) name controlled

by user input.

What are the implications?– Access to sensitive resources

– Information Leakage, aids future hacks



Insecure Direct Object Reference - Example



Insecure Direct Object Reference – Example Cont.



6 - Information Leakage and Improper Error Handling

What is it?– Unneeded information made available via errors or other

means.

What are the implications?– Sensitive data exposed

– Web App internals and logic exposed (source code, SQL syntax, exception call stacks, etc.)

– Information aids in further hacks



Information Leakage - Example



Improper Error Handling - Example



Information Leakage – Different User/Pass Error



10 - Failure to Restrict URL Access

What is it?– Resources that should only be available to authorized

users can be accessed by forcefully browsing them

What are the implications?– Sensitive information leaked/modified

– Admin privileges made available to hacker



Failure to Restrict URL Access - Admin User login

/admin/admin.aspx



Simple user logs in, forcefully browses to admin page



Failure to Restrict URL Access: Privilege Escalation TypesAccess given to completely restricted resources– Accessing files that shouldn’t be served (*.bak, “Copy

Of”, *.inc, *.cs, ws_ftp.log, etc.)

Vertical Privilege Escalation– Unknown user accessing pages past login page

– Simple user accessing admin pages

Horizontal Privilege Escalation– User accessing other user’s pages

– Example: Bank account user accessing another’s



Root Cause:– Developers are not trained to write or test for secure code– Firewalls and IPS’s don’t block application attacks.

• Port 80 & 443 are wide open for attack.– Network scanners won’t find application vulnerabilities.

• Nessus, ISS, Qualys, Nmap, etc.– Network security (firewall, IDS, etc) do nothing once an organization

web-enables an application.

Current State:– Organizations test tactically at a late & costly stage in the SDLC, if at all

(<10% market penetration)– A communication gap exists between security and development as

such vulnerabilities are not fixed– Testing coverage is incomplete

Goal:– To build better and more secure applications/websites

Why Application Security Problems Exist



Building Security & Compliance into the SDLC

Build

Developers

SDLC

Developers

Developers

Coding QA Security Production

Enable Security to effectively drive remediation into development

Provides Developers and Testers with expertise on detection and

remediation ability

Ensure vulnerabilities are addressed before applications are put into production



A Different Approach

InterfaceInterface Consultants Online

ProcessProcess Project Based Ongoing

Manual Automated



Governance addresses Web Application SecurityExample: PCI – BEST PRACTICE BECOMES STANDARD BECOMES LAW (BY 06-2008)

Visa’s PABP, Payment Application Best Practices – a list of auditable statements regarding the secure development, deployment, and documentation of cardholder data processing software – is being converted to a new PCI security standard - PASS, Payment Application Security Standard.

Requirement 11.2 : Run internal and external vulnerability scans

– At least quarterly

– After any significant change in network

Requirement 11.3 : Perform penetration testing at least once a year

– 11.3.1 Network-layer penetration tests

– 11.3.2 Application-layer penetration tests

Requirement 6 : Develop and maintain secure systems and applications

– Requirement 6.6 :Ensure that all web-facing applications are protected against known attacks by having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security

VISAMASTER

AMEX



Rational Software Quality Solution

Developer Test Functional Test

Automated Manual

Rational RequisitePro Rational ClearQuest Rational ClearQuest

Defects

Project Dashboards Detailed Test Results Quality Reports

Performance Test

SOFTWARE QUALITY SOLUTIONS

Test and Change Management

Test Automation

Quality Metrics

DEV

ELO

PMEN

T

OPE

RA

TOIN

S

BUSINESS

Rational ClearQuest

Requirements Test Change

Rational PurifyPlus

Rational Test RealTime

Rational Functional Tester Plus

Rational Functional Tester

Rational Robot

Rational Manual Tester

Rational Performance Tester

Security and Compliance Test

AppScan

Policy Tester



Web Application Environment

Database Operating System

Web Server

Web Application Web Services

Database Scanners Host Scanners

NetworkScanners

Web Application Scanners



How does AppScan work?

Approaches an application as a black-box

Traverses a web application and builds the site model

Determines the attack vectors based on the selected Test policy

Tests by sending modified HTTP requests to the application and examining the HTTP response according to validate rules

HTTP Request

Web Application

HTTP Response



AppScan Goes Beyond Pointing out Problems



Identify Vulnerabilities



Actionable Fix Recommendations



Report



DashboardsDashboards ReportsReports

CSO / CIO Divisions Applications Project Manager Developers

Entire Organization

Equity Investments

Berkshire Life

Group Portal

Individual Markets

Application 1

Application 2

EFORMS

OWASP Top 10

GLBA Security Issues

App Security

Cross-Site Scripting

Section 1.1

SQL Injection

Visibility for Different Levels Within the Enterprise



AppScan Reporting Console - Dashboard



AppScan / IBM Rational CQTM Integration



AppScan with QA Defect Logger for ClearQuest



AppScan Enterprise / IBM Rational ClearQuest Integration



At a First Glance – a good candidate if…

1. Their website is used to communicate with customers.

2. Their website is used to send and receive sensitive customer data.

3. Their website is subject to having hundreds, thousands (or even millions) of users access it.

4. Their business falls into one of the following verticals - Retail, Government, Financial Services, Insurance, Technology

5. The customer is subject to any type of federal or state legislative regulations – PCI/HIPAA/SOX/GLBA



Conclusion: Application QA for Security

The Application Must Defend Itself– You cannot depend on firewall or infrastructure security to do so

Bridging the GAP between Software development and Information Security

Never before was QA Testing for Security integrated and strategic, until now

We need to move security QA testing back to earlier in the SDLC– at production or pre-production stage is late and expensive to fix

– Developers need to learn to write code defensively and securely

2 securing soa web applications and services with rational ...€¦ · and services with rational...

Documents