Unit 1 - The Web Application Security Problem - 2 PDF

Essentials of Web Application Security V3.
Module 1: The Web Application Security

Problem
© Copyright IBM Corporation 2014

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Objectives
After completing this module, you will be able to:
• Describe the threat that Web application security poses in the

world today: “The problem”
• Identify those organizations that are trying to help

Understanding the problem
Information security landscape
Desktop Transport Network Web applications
Antivirus Encryption Firewalls / Legit network-level user

protection (SSL, or IDS / IPS*
Secure
Sockets
Layer ) Port 80 & 443
Application Backend
Firewall
servers server
Databases
Web servers
*Intrusion detection system or intrusion prevention system

The myth: “Our site is safe”
• “We use network vulnerability assessments”
 This approach neglects the security of the software on the network or
Web server
• “We have firewalls in place”

 Port 80 & 443 are open for the right reasons
• “We encrypt our data with SSL”

 This only protects data between site and user, not the Web application
itself

The reality: unbalanced spending
Security Spending
% of attacks % of dollars
Web
10%
applications
75% 90%
Network
25% server
75% of all attacks on information security

are directed to the Web application layer
2/3 of all Web applications are vulnerable

Web application security: what can happen?
• Sensitive data leakage
 Customer, partner, or company data
• Identity theft
 Hacker impersonates a trusted user
• Defacement: content modification

 Hurts brand, misleads customers, and so on
• Application shutdown (site unavailable)

 Lack of access can cause major loses
• Remote execution
 Execute arbitrary code on the server

Cost of an application security breach
• Media attention / brand damage
 Sharp decline in stock prices
• Communication / monitoring service costs
• Legal fees (reported $3-4 million)
• FTC (U.S. Federal Trade Commission) penalties: fines can range up
to $15 million
• Audits
• New security spending
• Customer lawsuits
• Customer loss

The solution: application security maturity model
External security
Internal tactical
Cost
per
application
tested Strategic
operationalized
0% 25% 50% 75% 100%
Application coverage

The reality
• Two thirds of all Web applications have some type of

vulnerability
• Several organizations are trying to help

OWASP Top 10 — Web app security best practice
• The Open Web Application Security Project is an open source
community formed in 2001 that freely produces guidance on
application security risks.
• OWASP maintains the OWASP Top 10, a list that identifies the
most critical application security risks.
• Since 2004 a new list has been released every 3 years.
• The list is regarded as industry best practice in preventing web
app vulnerabilities, and is referenced by major security
organizations and security regulations, such as PCI DSS, FTC,
MITRE, and most web app-penetration testing providers.
• Official Web site: www.owasp.org

OWASP
• Open Web Application Security Project (OWASP)
 They are dedicated to finding and fighting the causes of insecure software
• Official Web site: www.owasp.org
• The OWASP Top Ten project

http://www.owasp.org/index.php/OWASP_Top_Ten_Project
 Purpose:
• A broad consensus about what the most critical Web application security flaws
are
• Raise awareness of Web application security issues

OWASP Top 10 (2004)

OWASP Top 10 (2007)

OWASP Top 10 (2010)

OWASP Top 10 (2013)

The OWASP Top 10 (2013) application attacks
Application threat Description
Injection Flaws Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a
command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing
data without proper authorization.
Broken Authentication and Application functions related to authentication and session management are often not implemented correctly, allowing
attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other
Session Management
users’ identities.
Cross-Site Scripting (XSS) XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or
escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites,
or redirect the user to malicious sites.
Insecure Direct Object Reference A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file,
directory, or database key. Without an access control check or other protection, attackers can manipulate these references
to access unauthorized data.
Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application
server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as
defaults are often insecure. Additionally, software should be kept up to date.
Sensitive Data Exposure Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials.
Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes.
Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when
exchanged with the browser.
Missing Function Level Access Most web applications verify function level access rights before making that functionality visible in the UI. However,
Control applications need to perform the same access control checks on the server when each function is accessed. If requests are
not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
Cross-site Request Forgery A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie
(CSRF) and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to
force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
Using Components with Known Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a
Vulnerabilities vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using
components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and
impacts.
Unvalidated Redirects and Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine
the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards
Forwards
to access unauthorized pages. IBM Corporation 2014
© Copyright
WASC
• Web Application Security Consortium (WASC)
 Their purpose is to develop, adopt, and advocate standards for Web application
security
• Official Web site: www.webappsec.org
• Web Security Threat Classification project

 Purpose:
• Clarify and organize the threats to the security of a Web site
• Develop and promote industry-standard terminology for these issues
• http://www.webappsec.org/projects/threat/v1/WASC-TC-v1_0.pdf

Threats against Web applications (WASC)
• Authentication
 Attacks that target a Web site's method of validating the identity of a user, service, or
application
• Authorization
 Attacks that target a Web site's method of determining if a user, service, or application has
the necessary permissions to perform a requested action
• Client-side attacks
 Attacks that abuse or exploit a Web site user's system
• Command execution
 Attacks designed to execute remote commands on the Web site
• Information disclosure
 Attacks designed to acquire system specific information about a Web site
• Logical Attacks
 Attacks that abuse or exploit a Web application's logic flow

Web Application Security Statistics Project
• In 2007 WASC conducted the WASC Web Application Security
Statistics Project:
 http://www.webappsec.org/projects/statistics/
• This initiative was a collaborative industry-wide effort to pool

together sanitized Web site vulnerability data to gain a better
understanding about the Web application vulnerability
landscape
• One of the main goals was to identify the prevalence and

probability of different vulnerability classes

The most prevalent vulnerabilities
45 41
40
35 31.47 32
30
25 23.27
20 % Vulns
15 % Sites
9 10.24
10 7.85 8
5
0
Cross-site Information SQL Predictable
scripting leakage injection resource
location
Data from: http://www.webappsec.org/projects/statistics/
Types of Security Test Assignments
• Network / Infrastructure Test

 Network Penetration Test
• Application Security Test

 Vulnerability Assessment - (e.g. Appscan)
 Application Penetration Test
 Partial / Component Security Test
 Pre-Production Security Test
 External / ASP Security Reviews / Tests
Used as part of purchasing process

Security Testing Techniques – Black Box vs White Box
There are distinct testing techniques that can be used for Security tests;
Black Box Testing
 No information provided about the target
White Box Testing
 Information about the target is provided to assist the test
 Including logon details and in some cases code
 Traditionally used if Functional & Unit test cycles
Grey Box Testing
 Mixture of Black & White Box
 Provides the most detailed analysis of the target

Application security testing techniques
• Dynamic Application Security • Static Application Security Testing
Testing (DAST) (SAST)
 Tests the functionality of an  Tests the internal structures or
application workings of an application
 Referred to as black box testing  Referred to as white box testing
Dynamic Analysis Static Analysis
Scan input Live web application Source code
Assessment Tampering with HTTP Taint analysis &

Techniques messages pattern matching
Results are presented as

Results are presented by
Results and output HTTP messages (exploit
line of code
requests)

DAST and SAST: Issue type coverage
DAST Only
SAST Only
• Null pointer dereference •Environment
• Insecure crypto functions configuration issues
• Threading issues Total Potential •Patch level issues
• Code quality issues •Runtime privileges
Security Issues
• Issues in dead code issues
• Issues in back-end application
•Authentication issues
code
• Complex injection •Protocol parser issues
issues •Session management
• Issues in non-web issues
app code •Issues in 3rd party web
components
•Cross-site request
DAST & SAST forgery
• SQL Injection •Malware analysis
• Cross Site Scripting
• HTTP Response Splitting
• OS Commanding
• LDAP Injection Manual Testing
• XPath Injection • Business logic
• Path Traversal issues
• Buffer Overflows
• And so on

Security Test – Methodology / Process
Host Discovery Conduct Test Report Findings
Phase 1 Phase 2 Phase 3

IDENTIFY SCOPE DETECT ATTACK COLLATE REPORT
Scan Ports Plan attack Analyse Findings Publish Report

Establish Target Browse App
Scan Application Exploit List Risks Review Report with
Meet Customer Map Application (AppScan) vulnerabilities Stake Holders
Risk Analysis (ASE Report
Agree Tests Foot printing Escalate attack / (DREAD)
Network
privileges
Console)
Enumeration
Environment Review Code Rank Risks Complete Action
Search for Verify Risks
Plan
Define Dates Define Vulnerabilities Develop
Draft Report Update Report with
Times
Identify Risks Action Plan
Schedule Retest
Define Roles
Close Assignment
Approve Test

Security Test Environment
Target Application
Non Intrusive Testing Remote server

Intrusive Testing
• Paros Proxy • Webserver
• NMap
• Tamper IE • Ftp server
• Nessus (Network Layer)
• Manual Tampering • Honeypot
• AppScan (Application Layer)
• Paros Scanning • Forced Browsing
• Netcat • Directory Traversal
• Nikto • Validate Findings
• AMap
• TFTP
• Fport
• Brute Force tools
• App Detective (Database layer)
• Custom Tools Security Test Lab
Various OS Options
• Windows
• Linux
• Mac OSX

Attack & Penetration - Tests
There are a variety of techniques that an attacker can use to exploit the
Web application. Some of the most common of these include;
Parameter Tampering Modifying parameters which form part of the URL or hidden HTML form tags
A Forced Parameter Tampering with debug and test flags within the passed code to change nature of application
Cookie Poisoning Modifying cookies in order to gain unauthorised access
Cross Site Scripting The injection of script into unsanitised input fields (can lead to “Phishing” attacks)
SQL Injection The act of passing SQL code into unsanitised input fields
Brute Force Attack Cycle through pre-defined list of logins
Buffer Overflow Sending too much data into a buffer (causes an overflow - may execute the ‘extra’ data)
Direct Access Browsing Browsing directly to directories on the server (bypassing any authentication)
Directory Traversal Traversing up the web servers directory structure in order to gain access to the web root
Form Manipulation Exploiting credentials that are passed in plain text within the HTTP POST request
…..to name but a few….

Typical Findings Identified
Many findings identified stem from the same root causes…
Inadequate / Poor Input Control

Iimproper input sanitisation on the server side that allows the exploit of SQL injection, Cross Side Scripting and
Phishing.
Information Disclosure
Returning unnecessary system and database information which can aid an attack
Non Standard Encryption

Encryption routines which are custom built and do not represent best practice
Improper Password Policy

Easily guessed passwords (nullify all other measures to secure applications / databases)
Poorly configured Ports and Services

Servers that have unnecessary ports and services open (providing information and potential attack points)
Insufficient Database Configuration

Database configurations that allow full control (allowing the execution of OS commands)
Insufficient Web Server Configuration

Web server configurations which allow full privileges (i.e. start and stop OS services - Telnet)

Exploiting Vulnerabilities
Lack of Input Control

Application Scan Findings
(AppScan)
Link Injection Cross-Site Scripting SQL Injection Points
Database Configuration
Phishing Attacks Issues
Password Policy Establish Command Add, modify and Increase Privilege

Issues Shell Delete Data
PCI Issues Compromise Box

Challenges Facing Security Testers
• Need to exploit vulnerabilities to

demonstrate dangers
• Tight schedules / little time between
tests
• Need to ensure coverage on all tests
Restrictive test windows (out of hours)
• Need to keep up with the latest
Vulnerabilities
• Can have restrictive test criteria
• Reporting needs to in clear non
technical language

Security Testing
“Real Life” Findings

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Reflective Cross-site scripting – MEDIUM (7.7/10)
• Cross-site Scripting (XSS) vulnerabilities
were identified in the [FILE] and [LANG]
parameters on the pub.cfm page
• XSS refers to that hacking technique
that leverages vulnerabilities in the code
of a web application to allow an attacker
to send malicious content from an end-
user and collect some type of data from
the victim.
• Our non-malicious example only opens
an alert box, but more malicious scripts
could easily be run.
• As these XSS vulnerabilities are within
the GET request and on URLs that do
not require a login, these were found to
facilitate Phishing attacks…
Recommend :
All input points should protect against invalid input, specifically the special
characters < > “ ‘ % ; ) ( & +
Phishing through Cross-Site Scripting – HIGH (8.3/10)
https://www.mydomain.com/pub.cfm?FILE=MF&LANG=E*/--></script><script>window.open('http://www.watchfire.com')</script>
• By exploiting the identified cross-site

scripting findings the team was able
to fabricate a Phishing attack which
could be used to extract confidential
information.
• A popup could be specifically crafted
to look like a genuine page,
containing the appropriate corporate
branding.
• The popup could be used to prompt
users into submitting their logon
details for the purpose of identity
theft. The link could be emailed to
unsuspecting victims.
Recommend :
All input points should protect against invalid input, specifically the special
characters < > “ ‘ % ; ) ( & +
Email Spam Relay – HIGH (8.5/10)
• Functionality within the cover letter

component, allows for HTML and
other potentially dangerous text to be
entered.
• No control for special characters
exists within the component allowing
the text to propagate to the database
• It is then possible to send the created
cover letter to an email address of
the users choosing.
• Using a Tamper tool, it is possible to
modify the list to send emails to large
multiples of addresses.
• In effect this allows for a SPAM relay.

Email Spam Relay… continued – HIGH (8.5/10)
• The attempted email runs in the email

client and the payload
alert(document.cookie) runs.
• This could easily be a more malicious
script, perhaps capturing key strokes.
• It is also possible to pass links
through to the email client which will
run even where the client does not
allow HTML
Recommend : The cover letter function should employ full input control
preventing or sanitizing the use of special characters.
Further the email selection should be limited to validated email accounts, thus
preventing the SPAM potential
Password Policy Control – MEDIUM (5.5/10)
Requirement Result Explanation
Username at least 8 chars Passed Password policy forces at least 8 characters
Username and Password can not Failed Possible to make these match by changing the
match Userid. Doing this forces a password change.
Enforce Password History Failed Changed password to same value several
times. Likely a business decision to allow this.
Maximum Password Age NR Not enough time to test
Account locked out after 3 Failed Account was locked out after 11 unsuccessful
unsuccessful login attempts attempts. Not best practice
Passwords must meet Complexity Requirements:
- at least 8 characters Passed Password enforced to 8 chars only
- english upper case (A-Z) Passed Password forced mixed characters & numerics
- english lower case (a-z) Passed Password forced mixed characters & numerics
- base 10 digits (0-9) Passed Password forced mixed characters & numerics
- non-alphanumeric (e.g. $,!) Passed Password forced mixed characters & numerics
Recommend : Reduce account lockout to 3 attempts

Introduce password history if possible
SQL Command Execution – HIGH (9.2/10)
• From the scan results the log.jsp page was identified as

having Cross-site scripting vulnerabilities (described later)
• This page, however also allows for the direct entry of SQL
against the Oracle database.
• It was possible to enumerate the whole database using this
page thus exposing this security risk.

• Using the log.jsp page, the following SQL was entered;

 select * from all_catalog
• This lists all the system and user tables in the Oracle
database.

• Using details from the previous query the following SQL
was entered;
 select * from user_users
• This lists all the user tables in the Oracle database.

• Using details from the previous query the following SQL

was entered;
 select * from CHECKOUT_CREDITCARD
• This lists the contents of the table, including credit card
details stored in plain text which is against PCI standards.

Credit Card Details Not Encrypted – HIGH (8.1/10)
• The recovery of credit card details shows data is stored in

plain text on the database.
• This is in conflict with the PCI Standard.
Recommend:
PCI Standards require that the Personal Account Number (PAN), at minimum be
rendered unreadable anywhere it is stored by using any of the following
approaches:
 Strong one-way hash functions (hashed indexes)
 Truncation
 Index tokens and pads (pads must be securely stored)

Manual Tested / Hidden Directories – HIGH (8.2/10)
• Hidden Directories would normally only be a very

low security risk
• Password file found in /test hidden directory
• /test directory accessible without login

Manual Tested – Password File Discovered – HIGH (8.3 /10)
• Password file ‘grid.aspx’ found in hidden /test directory

• Account details uncovered provided access to both test and
production environments
• Usernames, passwords and other sensitive data being
stored in plain text
• Best practice suggests passwords should be encrypted
using a 1 way hash such as MD5

Summary
In this module you learned:
• The threat that application security posses in the world today

 The myth: SSL, firewalls, and network assessments are enough
 The reality: 75% of all attacks are directed at the Web application layer
• To identify those organizations that are trying to help

 OWASP and the OWASP Top 10 Project
 WASC with the “Threat Classification Project” and the “Web Application
Security Statistics Project”

Unit 1 - The Web Application Security Problem - 2 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unit 1 - The Web Application Security Problem - 2 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Essentials of Web Application Security V3.

Module 1: The Web Application Security

© Copyright IBM Corporation 2014

After completing this module, you will be able to:

• Describe the threat that Web application security poses in the

• Identify those organizations that are trying to help

© Copyright IBM Corporation 2014

Desktop Transport Network Web applications

Antivirus Encryption Firewalls / Legit network-level user

*Intrusion detection system or intrusion prevention system

© Copyright IBM Corporation 2014

• “We have firewalls in place”

• “We encrypt our data with SSL”

© Copyright IBM Corporation 2014

75% of all attacks on information security

2/3 of all Web applications are vulnerable

© Copyright IBM Corporation 2014

• Defacement: content modification

• Application shutdown (site unavailable)

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

0% 25% 50% 75% 100%

© Copyright IBM Corporation 2014

• Two thirds of all Web applications have some type of

• Several organizations are trying to help

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

• Official Web site: www.owasp.org

• The OWASP Top Ten project

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

• Official Web site: www.webappsec.org

• Web Security Threat Classification project

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

• This initiative was a collaborative industry-wide effort to pool

• One of the main goals was to identify the prevalence and

© Copyright IBM Corporation 2014

• Network / Infrastructure Test

• Application Security Test

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

Scan input Live web application Source code

Assessment Tampering with HTTP Taint analysis &

Results are presented as

© Copyright IBM Corporation 2014

© Copyright IBM Corporation 2014

Host Discovery Conduct Test Report Findings

Phase 1 Phase 2 Phase 3

Scan Ports Plan attack Analyse Findings Publish Report

© Copyright IBM Corporation 2014

Non Intrusive Testing Remote server

© Copyright IBM Corporation 2014

Cookie Poisoning Modifying cookies in order to gain unauthorised access

Brute Force Attack Cycle through pre-defined list of logins

…..to name but a few….

© Copyright IBM Corporation 2014

Many findings identified stem from the same root causes…

Inadequate / Poor Input Control

Non Standard Encryption