Addressing Web Application Security Vulnerabilities.pdf

AGS201
Addressing Web
Application Security
Vulnerabilities

SAP AG 2006, SAP TechEd ’06 / AGS201 / 2
Contributing Speaker
Patrick Hildenbrand,
SAP AG, Walldorf

Learning Objectives
As a result of this workshop, you will be able to:
Understand the nature and the intention of different groups of hackers
Name some important security risks in development
Understand how to avoid security issues while programming in SAP
environments

Security Development – That’s YOU
Beat the Hacker – Solutions
Security, Why?
Who is the enemy – Hacker Types
The Final

The Challenge of Security
In order to secure an application, all of its components, functions,
infrastructure and the related threats must be understood
In order to break an application, only one flaw in any of its
components/functions or the infrastructure may be enough
The problem:
Each new technology brings with it new vulnerabilities
Firewalls, Intrusion Detection Systems and Encryption don't make a
secure IT system

The OWASP Top Ten
Source: http://www.owasp.org/documentation/topten.html
The OWASP (Open Web Application Security Project) top ten
web applications vulnerabilities are typically targeted by
hackers
1. Unvalidated Input
2. Broken Access Control
3. Broken Authentication and Session Management
4. Cross Site Scripting (XSS) Flaws
5. Buffer Overflows
6. Injection Flaws
7. Improper File Handling
8. Insecure Storage
9. Denial of Service
10. Insecure Configuration Management

Know Your Enemy: How Hackers "Work"
Hackers
highly-skilled, but
few in numbers,
break mostly into
"challenging"
systems,
publish/trade
weaknesses
Hackers look for new
security weaknesses
Script Kiddies
low-skilled, but numerous, use
other peoples` tools to break
into systems
goal is to “OWN" as many
machines as possible
Script Kiddies look for systems
vulnerable to known exploits
Social Engineers
very good technical as
well as social skills
attacks are primarily
directed against
humans ('wetware')
Social Engineers look for
clues on which they can
base their attacks.
(Disgruntled) Employees
use insider knowledge to gain
system access
motivated by curiosity or anger
Disgruntled employees will try to
damage the IT infrastructure
Employees usually look for HR
information (e.g. salary) or want to
enrich themselves

Know Your Enemy: How Hackers "Work"
Hackers
highly-skilled, but
few in numbers,
break mostly into
"challenging"
systems,
publish/trade
weaknesses
Hackers look for new
security weaknesses
Script Kiddies
low-skilled, but numerous, use
other peoples` tools to break
into systems
goal is to “OWN" as many
machines as possible
Script Kiddies look for systems
vulnerable to known exploits
Social Engineers
very good technical as
well as social skills
attacks are primarily
directed against
humans ('wetware')
Social Engineers look for
clues on which they can
base their attacks.
(Disgruntled) Employees
use insider knowledge to gain
system access
motivated by curiosity or anger
Disgruntled employees will try to
damage the IT infrastructure
Employees usually look for HR
information (e.g. salary) or want to
enrich themselves
The new threat:
Organized Crime
The new threat:
Organized Crime
Organized Crime

Know Your Enemy: Stages of an Attack
Reconnaissance – find a target
Get all data on the Web or somewhere
else you can get
Data analysis – where are the weak points
Analyze source and behavior of the target
Attack – hack it
Use the knowledge you have gathered to
break into the target
Clean up – Remove your traces
Clean up all debris you have created
while breaking in to the system

There is NO Central Security

Collected Statements About Security
Of course my application is secure. I’m using HTTPS!
We use an application server for development,
it covers all security topics for me
I don’t need to worry about security during
development, because all gaps will be detected
and corrected during the test period
Security is not my job, there’s a
security group in our company
Note: All these statements are wrong!
The caller of my function will never send
me any malformed data

Responsibility for Security Cannot be Delegated!
Don’t blindly assume others will do it
for you
Don't only rely blindly on others in terms of
security
If you rely on someone else’s software, then
clarify whether or not your security demands
are fulfilled
Only if they commit to solving the issue you
can delegate responsibility
Application security is part of everybody's
responsibility in design and development !

Include Security in the Design

Requirements for Productive Use
1. Companies must be able to comply with regulatory
requirements, especially concerning data protection/privacy
and audit
Must be possible to audit changes in user and authorization
management, and security-related events
Must be able to track changes to business data
2. Principle of fewest possible rights must be possible
Must be part of application design
Deliver description (roles and authorization proposals, for
example)
Administration efficiency important
For users as well as for the application/program
On the file system, for the OS permissions and within the server

Retrospective Security Does Not Work

Common Sense Requirements
1. Encryption of all communications connections should be
possible
2. No transmission or storage of passwords in plain text
- all passwords and user IDs must be changeable
3. No back doors in applications
- especially not for management, support or other purposes
4. Avoid broadly generic functions
- if security can not be guaranteed
5. No unintended disclosure of internal information
Error messages, logs, URLs, cookies, …

Input Validation

Validate your Input
Unvalidated input is the number one problem for applications
according to the OWASP top ten. Therefore do a
… positive check on server of all user input
To protect against
buffer overflows
SQL injection
other attacks targeting the server
BUT Validation of user input is not a sufficient precaution against
cross-site scripting (XSS)
Different parts of the information may be combined
Input may be used ‘out of context’ (Log-files)

Beat the Hacker – Solutions – XSS
Security, Why?
The Final

Cross-Site Scripting (XSS) – A Description
Cross site scripting (XSS) is a type of computer security exploit
where information from one context, where it is not trusted, can be
inserted into another context, where it is.
From the trusted context, an attack can be launched
Threat:
an attacker manages to place HTML content into a web page, email, file
or other media which someone else will open at a later time, possibly in
a different security context
Risk:
Tampering with Data
– execution of ActiveX commands
Information Disclosure
– Stolen or modified Cookies
– Stolen or modified data (redirected forms)

Cross-Site Scripting (XSS) – What To Do
Examples:
an online application viewed in a corporate intranet
a message posted to an online forum
an administrator opening a log file with a browser
Best practices:
Use WebDynpro, because of its closed rendering model, it is possible to ensure
HTML encoding through the complete rendering engine by the WebDynpro
runtime itself
Use BSP/HTMLB similar to WebDynpro with some few exceptions (see developer
guide for additional details, needs forceEncode=“Enabled”)
escape HTML/Javascript control characters < > & " ' ( ) using methods in class
StringUtils
! Caveat:
attack methods vary depending on context
Note:
XSS attacks the client, not the server, thus input validation may not help

Cross-Site Scripting (XSS) example code
Part of the companies intranet application:
public void doContent(...) {
...
String s;
if ((s = getUsernameByID("userid")) != null) {
response.write("<br>Applicant:<u>" + s + "</u>");
}
...
}
Supposed output:
<br>Applicant:<u>Mr. Brian Smith</u>

Cross-Site Scripting (XSS) secure code
Security enhanced function:
public void doContent(...) {
...
String s;
if ((s = getUsernameByID("userid")) != null) {
s = StringUtils.escapeToHTML(s, 50);
response.write("<br>Applicant:<u>" + s + "</u>");
}
...
}

Cross Site Scripting – Attack Scenario 1
Output BETWEEN tags
StringsUtils.escapeToHTML()
<head>
<title>[CASE1]</title>
</head>
<table>
<tr>
<td>Username</td>
<td>[CASE1]</td>
</tr>
</table>

Output INSIDE tags, but output is not a URL
StringUtils.escapeToAttributeValue()
<form name="[CASE2]">
<input type="text" name="user" value="[CASE2]">
<input type="text" name="user" value='[CASE2]'>
</form>
<a name="[CASE2]"><img height="50" width="[CASE2]"></a>
! Caveat:
Be sure to enclose values in double or single quotes! Omitting those
will make an attack easier

Output is a URL
StringUtils.escapeToURL()
<a href='[CASE3]' style="[CASE3]">
<img src="[CASE3]" lowsrc="[CASE3]">
</a>
! Caveat:
Be sure to enclose values in double or single quotes! Omitting those
will make an attack easier

Output is inside a SCRIPT context
StringUtils.escapeToJS()
<script>
var a = '[CASE4]';
alert("[CASE4]");
var a = [CASE4];
[CASE4];
</script>

Beat the Hacker – Solutions – SQL
Security, Why?
The Final

SQL injection – A Description
Threat:
An attacker manages to place SQL commands into an input string that is
used as a parameter in a database query.
Risk:
Tampering with Data
– data can be created/changed/deleted without authorization
Information Disclosure
– data can be read without authorization
Denial of Service
– data can be deleted without authorization
Elevation of Privilege
– depending on the database, system commands can be executed
Best practices:
Validate input and remove/escape illegal characters '

SQL Injection – some suggestions
Generic protection is available if the OpenSQL framework is being
used, as this uses prepared statements with the command having
to be static. However, you still have to be careful for all dynamic
parts of the queries, to make sure, that they do contain permitted
values only
An example:
SELECT (select_clause)
FROM (from_clause)
WHERE (where_clause)
GROUP BY (groupby_clause) HAVING (having_clause)
ORDER BY (orderby_clause).
Being able to enter arbitrary values for ‘from_clause’ may
enable a hacker to ‘select’ the database to operate on. …
The same applies to all other commands as well

Beat the Hacker – Solutions – Viruses
Security, Why?
The Final

Virus Protection for SAP Systems
Partner products access
the VSI API directly with
the scan engine or
indirectly using a
separate VSA
Built in scanning for
– GUI_UPLOAD in the SAP
ABAP Stack
– HTTP_UPLOAD (BSP)
– FileUpload of WebDynpro
for Java
Programmatic execution of
virus scans with dedicated
classes and methods of
the VSI
ABAP Code
SAP Virus Scan API (ABAP)
Java Code
SAP Virus Scan API (Java)
Scan Service
J2EE Engine
Virus Scan Server
SAP Internal VSI API
SAP VSI Library
SAP NW-VSI
Virus SCAN Adapter
Scan Engine Internal API (optional)
SCAN Engine
Partner Part
SAP Part Interface
Remote Function Call (RFC)
(RFC,
optional)

Using the Virus Scan Interface
try {
myInstance = vsiService.getInstance();
if (myInstance != null) {
/* perform virus scan */
if (! myInstance.scanBytes(<your data>)) {
/* there was an infection,
* what needs to be done comes here */
}
} else {
/* The returned instance was null, this means, the virus scan profile is
not active
* => do here nothing to allow the scan to be switched
off */
}
} catch (VirusInfectionException vse) {
Infection[] myInfections = vse.getInfections();
String errorText = vse.getLocalizedMessage();
/* print out only the locale error text */
if (myInfections.length == 1) {
/* the scan engine has found the infection */
// ...
} else {
/* not expected error */
// ...
}
}

Application Examples for the Usage
For which application components is the virus scanning available?
For all applications based on SAP NetWeaver’04
– All upload functions for file-uploads will be affected
Sample application scenarios:
– HR: upload of applications documents from applicants
– KM and KMC: upload of documents for storage

Related SAP Notes About the VSI
The following notes are available for more information
786179: Data security products – Application in the Anti-Virus Area
797108: Virus scan interface (VSI): Changes and releases
782963: Availability of Virus Scan Server for NW-VSI
807989: Problem analysis: Virus check during the file upload
639486: Anti viruses protection within SAP applications (BC-SEC-VIR)
803637: Virus check added to gui_upload
666568: Using the EICAR anti-virus test file

Consider Security
100% security is not achievable
But you can do a lot:
Law of the weakest link
Security should not be an afterthought
Reduce the complexity of the whole application
Security is a “horizontal” aspect of software development
Protect your credentials
Deploy only tested code (do at least some kind of unit testing)

Beat the Hacker – Solutions
Check out SAP NetWeaver Developer’s Guide:
Best-practice cookbook on how to avoid
typical vulnerabilities
http://www.sdn.sap.com/irj/sdn/developersguide
Fundamentals
Making Applications Enterprise Ready
Security Secure Programming JAVA / ABAP
Conduct security testing and perform
assessments:
By external security specialists
By internal QM
Establish Security Response Measures

Rules for Everybody in Planning and Development
Define a security level or quality for the
application depending on:
Environment (back end versus Internet)
Application profile (banking, defense)
Regulatory requirements
CEO’s don’t like security surprises
Don’t blindly assume others will do it for you
“An application that has not been specified cannot
be incorrect; it can only be surprising”

Further Information
Public Web
SAP Developer Network: www.sdn.sap.com
+ SAP NetWeaver Platform Security
NetWeaver Developer‘s Guide: http://www.sdn.sap.com/irj/sdn/developersguide
http://www.sap.com/education/
JA300 SAP WebAS Java Development
SAP Service Marketplace:
http://service.sap.com/security
http://service.sap.com/securityguide
SAP Security Newsletter
Send email to security@sap.com with subject = subscribe
Related Workshops/Lectures at SAP TechEd ’06
AGS202, Authentication with SAML
AGS212, Single Sign-On in Heterogeneous Landscapes
AGS213, SPNego Login Module for Windows Integrated Authentication to SAP
NetWeaver for J2EE (Lecture, 1 hour)
AGS250, J2EE Authentication (Hands-On, 2 hours)
CD255, Developing Secure Web Services (Hands-On, 2 hours)
CD262, Using Authorizations in Java Application Development (Hands-On, 2 hours)
AGS214, The Top Five Security Threads and Countermeasures (Lecture, 1 hour)

THANK YOU FOR YOUR
ATTENTION !
QUESTIONS – SUGGESTIONS – DISCUSSION

Please complete your session evaluation.
Be courteous — deposit your trash,
and do not take the handouts for the following session.
Feedback
Thank You !

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information
contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP,
Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other
countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned
are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications
may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose
without the express prior written permission of SAP AG.
This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended
strategies, developments, and functionalities of the SAP®
product and is not intended to be binding upon SAP to any particular course of business, product
strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice.
SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics,
links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited
to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use
of these materials. This limitation shall not apply in cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use
of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party
Web pages.
Copyright 2006 SAP AG. All Rights Reserved

Addressing Web Application Security Vulnerabilities.pdf

More Related Content

Similar to Addressing Web Application Security Vulnerabilities.pdf

Recently uploaded

Addressing Web Application Security Vulnerabilities.pdf