706 Secure Programming ABAP PDF

Secure ABAP Programming
Peter McNulty SAP NetWeaver Solution Management May 2011
Disclaimer
This presentation outlines our general product direction and should not be relied on in making a purchase decision. This presentation is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this presentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. 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 assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent.
2011 SAP AG. All rights reserved. / Page 2
Learning Objectives
As a result of this workshop, you will be able to:

Learn common security vulnerabilities in ABAP applications Understand secure ABAP programming methodologies Realize the responsibilities of a developer
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP
Secure Programming & Secure User Interface
3. Common Vulnerabilities in ABAP Applications

Cross Site Scripting Backdoors Path Traversals Dangerous ABAP Commands
4. Developer Responsibilities
Security Why?
Why security is needed in every software application?

Appropriate security is that which protects the organization from undue operational risks in a cost-effective manner Cyber attacks are becoming more stealthy and sophisticated, creating a complex and dynamic risk environment for IT-based operations To address these concerns significant efforts are taken to reduce vulnerabilities, improve resistance to attack, protect integrity, business compliance, intellectual properties and trust relations with partners Open standards & networks create new business opportunities, but also new dangers
Security Law of Weakest Link
Law of Weakest Link

To SECURE an application, all of its components, functions, infrastructure and the related threats must be understood & implemented! To BREAK an application, only one flaw in any of its components, functions or the infrastructure may be enough!
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

At the heart of the PIL Product Security Standard: Security Requirements The PIL Security Standard defines a common set of security requirements for all SAP products, belonging to 3 areas:
Vulnerability Prevention TCO/TCD Reduction
Legal Compliance
5 of these requirements are corporate requirements

They are all typical, well-known vulnerabilities related to secure programming Deviations or non-compliance MUST be explicitly approved by the CEO SEC-102 SEC-111 SEC-133 SEC-136 SEC-139 SQL INJECTION vulnerabilities shall be avoided. BUFFER OVERFLOW vulnerabilities shall be prevented. CROSS-SITE SCRIPTING vulnerabilities shall be prevented. DIRECTORY TRAVERSAL vulnerabilities shall be prevented. SAP applications shall be free of BACKDOORS.
SAP
SAP Security Standard vs. Industry Standards
Requirements of the PIL Product Standard Security are strongly aligned with the requirements and problems identified by the IT security community, e.g.,
Common Weaknesses Enumeration (CWE) CWE provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems Open Web Application Security Project (OWASP Top10) The Open Web Application Security Project (OWASP) is a not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. The OWASP Top 10 is a risk focused list of the Top 10 Most Critical Web Application Security Risks. Common Vulnerabilities and Exposures (CVE) CVE is a dictionary of publicly known information security vulnerabilities and exposures , i.e., vulnerabilities in shipped software products

Common Weakness Enumeration 2010
Ra nk [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] Score 346 330 273 261 219 202 197 194 188 188 176 158 157 ID CWECWE -79 CWECWE -89 CWECWE -120 CWE-352 CWE-285 CWE-807 CWECWE -22 CWE-434 CWE-78 CWE-311 CWE-798 CWE-805 CWE-98 Name Failure to Preserve Web Page Structure ('Cross('Cross -site Scripting') Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection') Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') Cross-Site Request Forgery (CSRF) Improper Access Control (Authorization) Reliance on Untrusted Inputs in a Security Decision Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Unrestricted Upload of File with Dangerous Type Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection') Missing Encryption of Sensitive Data Use of Hard-coded Credentials Buffer Access with Incorrect Length Value Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion') [23] [24] [25] 142 141 138 CWE-601 CWE-327 [18] [19] [20] [21] [22] 153 147 146 145 145 CWE-131 Incorrect Calculation of Buffer Size CWE-306 Missing Authentication for Critical Function CWE-494 Download of Code Without Integrity Check CWE-732 CWE-770 Incorrect Permission Assignment for Critical Resource Allocation of Resources Without Limits or Throttling URL Redirection to Untrusted Site ('Open Redirect') Use of a Broken or Risky Cryptographic Algorithm [14] [15] [16] [17] 156 155 154 154 CWE-129 Improper Validation of Array Index CWE-754 CWE-209 Improper Check for Unusual or Exceptional Conditions Information Exposure Through an Error Message
CWE-190 Integer Overflow or Wraparound
Source http://cwe.mitre.org/top25/
CWE-362 Race Condition
SAP

Common Weakness Enumeration 2010
Ra nk [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] Score 346 330 273 261 219 202 197 194 188 188 176 158 157 ID SECSEC -133 SECSEC -102 SECSEC -111 SECSEC -207 SEC-39, SECSECSEC -40 e.g. SECSEC -70 SECSEC -136 SECSEC -27 SECSEC -108 SECSEC -97 SECSEC -76 SECSEC -111 Name Failure to Preserve Web Page Structure ('Cross('Cross -site Scripting') Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection') Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') Cross-Site Request Forgery (CSRF) Improper Access Control (Authorization) Reliance on Untrusted Inputs in a Security Decision Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Unrestricted Upload of File with Dangerous Type Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection') Missing Encryption of Sensitive Data Use of Hard-coded Credentials Buffer Access with Incorrect Length Value Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion') [24] [25] 141 138 SECSEC -143 [21] [22] [23] 145 145 142 SECSEC -199 SECSEC -47 [14] [15] [16] [17] [18] [19] [20] 156 155 154 154 153 147 146 SECSEC -69 SEC-123 SECSECSEC -112 SECSEC -111 SECSEC -39 e.g. SECSEC -155 SECSEC -111 Improper Validation of Array Index Improper Check for Unusual or Exceptional Conditions Information Exposure Through an Error Message Integer Overflow or Wraparound Incorrect Calculation of Buffer Size Missing Authentication for Critical Function Download of Code Without Integrity Check Incorrect Permission Assignment for Critical Resource Allocation of Resources Without Limits or Throttling URL Redirection to Untrusted Site ('Open Redirect') Use of a Broken or Risky Cryptographic Algorithm Race Condition
Source http://cwe.mitre.org/top25/
SAP
Information disclosure Error messages

Displaying too much information in error messages is security critical
Attacker provokes such errors to gather internal information about program structure Displaying erroneous SQL statement allows tailored attacks
Some real life examples:

Recommendation Create an individual error message for your web application (via transaction SICF) Remove all debug information Allow the adoption of error messages
SAP
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

Secure ABAP Secure Programming
Following security categories is mandatory for a secure program development.

Password Security Passwords as an authentication credential should be protected and never be visible e.g. by display in plain text, hardcoded in programs, recorded in logs, etc. Secure Data Storage (ABAP/DB) Functionality for storing sensitive data such as passwords or credit card numbers that are stored in encrypted form using crypto algorithms to be safe against data manipulations Security Logging Audits and logs are important for monitoring the security of your system and to track events in case of problems. SAP Virus Scan Interface Virus scanning should be performed every time potentially polluted data is imported via input channels into the SAP system. Secure Store and Forward Mechanism (SSF) SSF functions "wrap" data and digital documents in secure formats using digital signatures and encryption before they are saved on data carriers or transmitted over (potentially) insecure communication lines.
Secure ABAP Secure User Interface
Secure user interface development is possible only when the following security categories are fulfilled
Cross-Site Scripting (XSS) XSS attacks are set out to manipulate HTML pages by injection of malicious script code or by other indirect techniques, such as redirection to another server, logical attacks. SQL Injection SQL injection attacks arise from direct integration of user input into SQL statements without appropriate validation or filtering. Input Validation Make sure that the input is in expected form to prevent unexpected data from altering the intended execution of the program. Canonicalization Input variables content is transformed into its simplest and shortest representation for successful filter mechanisms to avoid polymorph attacks.
Secure ABAP Secure User Interface
Directory Traversal URL is manipulated such that the web server reveals the content of a file anywhere on the server, residing outside web server's root directory. These attacks take advantage of special-character sequences in URL input parameters, cookies, etc. Cookie Manipulation The cookie contains information used by web applications to persist and pass variables back and forth between the browser and the web application. The risk of tampering with data and even information disclosure is very high.
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

SEC-133 Cross-Site Scripting Introduction

Context
Web applications accept user input, which is used to create dynamic content in HTML pages
Weakness(es)
Insufficient input validation Missing output filtering or encoding, when writing user input back to HTML pages
Attack / entry point

An attacker supplies malicious data to inject client-side JavaScript into web pages viewed by other users and, as such, attacks other clients
Potential results
Stealing access credentials, DoS, Web page modifications, executing commands on the attacked users system
2 Types of XSS
Non-persistent / reflected (the most common type): The server receives input data and uses it to build a result HTML page for the same user, without properly sanitizing the input Persistent: Input data from a given user is persisted by the server, and is included later on in HTML pages returned to other users, again without proper data sanitization
SEC-133 Cross-Site Scripting Example (stored XSS)

The following is an example for all kinds of applications that accept, store and echo user input, a feature being part of thousands of web pages (think of SDN, news pages, bookstores, etc.)
Attacker
Post Forum Message: Subject: GET Money for FREE !!! Body: <script> attack code </script>
Web Server
Did you know this? ..... GET Money for FREE !!! <script> attack code </script> Re: Error message on startup ..... I found a solution! ..... Can anybody help? Get /forum.jsp?fid=122&mid=2241 ..... Error message on startup .....
1. Attacker sends malicious code as part of message 2. Server stores message 3. User requests message 4. Message is delivered by server
GET Money for FREE !!! <script> attack code </script>
Client
!!! attack code !!!
5. Browser executes script in message (= mixture of data and code)

SEC-133 Cross-Site Scripting Susceptibility of different ABAP technologies

ABAP code can also be vulnerable to Cross-Site Scripting
Plain HTML pages produced from ABAP and BSP (Business Server Pages) Pages with HTMLB taglib Pages produced with ITS BusinessHTML
BSP example
http://.../bsp/asdf/sample?name=Test
http://.../bsp/asdf/sample?name=<img src=+onerror=alert(document.cookie) ;>
<%@page language=abap %> <% DATA: name TYPE string. name = request-> get_form_field('name'). %> <html><body> <p>Hello <%= name %></p> </body></html> <html> <p>Hello <img src= onerror=alert(document.cookie);> </p><body></body></html>
<html> <body><p>Hello Test</p></body></html>

SEC-133 Cross-Site Scripting Overview ABAP output encoding technologies

Basic technology
SAP Output Encoding Framework for ABAP To be used for non-BSP extensions and whenever plain ABAP produces HTML Dedicated encoding methods must be called in the ABAP program code Internally also used by the following web frontend frameworks
Web frontend frameworks

Web Dynpro ABAP Does not require developers do develop HTML themselves Framework generates output HTML code

Automatic output encoding No manual actions are required in the program code
BSP extensions (HTMLB, XHTMLB and PHTMLB) Dedicated encoding parameter must be enforced/used explicitly in the HTML page ITS BusinessHTML (BHTML) Various encoding methods must be used in the HTML page
SEC-133 Cross-Site Scripting Recommendation for non-BSP extensions

Previous example fixed by using CL_HTTP_UTILITY for output between HTML tags
http://.../bsp/asdf/sample?name=<img src= onerror=alert(document.cookie);>
http://.../bsp/asdf/sample?name=Test
<% DATA: input TYPE string. input = request-> get_form_field('name'). CALL METHOD CL_HTTP_UTILITY=>ESCAPE_HTML EXPORTING unescaped = input IMPORTING escaped = input_enc. %> <html><body> <p>Hello <%= input_enc %></p> </body></html>
<html><body> <p>Hello Test</p> </body></html>
<html><body> <p>Hello <img src="" onerror="alert(document.cookie);& quot;></p> </body></html>
SAP
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

Common Vulnerabilities in ABAP Applications
Backdoors
Description The undocumented personal test hacks used by the developers for gaining unauthorized access. After a compromise the attacker will use the easier access to get around the compromised system for any security mechanisms. Business Risks Can potentially lead to a user gaining unauthorized access to privileged data within your SAP database. They allow malicious developers to secretly access extra-functionality by feeding certain triggers to the program. Very likely to violate regulatory compliance and Increase user privileges. Best Practices Avoid the usage of backdoors/hard coded usernames used for developer hacks inside any productive version of an application.
SEC-139 Backdoors Examples

Examples
Conditions on sy-uname IF sy-uname <> 'EVIL' If the username matches the hardcoded one, the program behavior changes, e.g., To grant additional privileges Hard-coded credentials are no-go! Dont make use of hard-code credentials! Undocumented OK codes CASE x_ok. WHEN 'MAGIC'. g_flg_adm = 'M' If the OK code is entered, programs enter in some special mode to, e.g., skip authorization checks Hidden input fields, e.g. Invisible (transparent) buttons on web pages
ABAP Vulnerabilities Command Injection (Backdoor)

ABAP Code with Backdoor vulnerability
DATA: itab TYPE STANDARD TABLE OF string. DATA: request TYPE REF TO if_http_request. DATA: prog TYPE string. DATA: mymsg TYPE string. DATA: mytext TYPE string. DATA: myline TYPE string. mytext = request->get_form_field( 'mytext' ). CONCATENATE `WRITE '` mytext `'.` INTO myline. APPEND 'PROGRAM mypool.' TO itab. APPEND `FORM myform.` TO itab. APPEND myline TO itab. APPEND `ENDFORM.` TO itab. GENERATE SUBROUTINE POOL itab NAME prog MESSAGE mymsg. IF sy-subrc = 0. PERFORM ('MYFORM') IN PROGRAM (prog) IF FOUND. ENDIF.
SEC-139 Backdoors Countermeasures

Prevent SAP Developers from inserting backdoors
Sound SDLC, i.e., a well-defined development process incl., e.g., Automatic scanning for suspicious statements (IF sy-uname EQ) Manual code review or similar techniques Developer trainings
Prevent external attackers from inserting backdoors

Effective protection is provided by checksums (CRC) / code signing (not available for ABAP) Delivered code is signed by software vendor Customer can detect modification (=potential backdoor) through signature / CRC checking Prevent display/change of code in ABAP workbench (display of special reports already blocked by ABAP kernel) Prevent injection flaws
Note: There are also backdoors not based on code but on privileges
Secret Accounts Hacked Accounts Modified Accounts
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

SEC-136 Directory traversal Introduction

Context
Software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory
Weakness
Insufficient user input normalization and validation, so that attacks can bypass security filters by using special-characters sequences
Attack / entry point

An attacker supplied malicious data (e.g., manipulates a file resource name or path) in such a way that the server executes, accesses, or reveals file contents anywhere on the server
Potential result
Unauthorized access (execution, modification, deletion, read) of server or application resources outside of the intended container or directory
Directory Traversal is a threat whenever file paths are processed. Typical scenarios:
Web applications URL parameter RFC-Modules input parameter Command line parameter
SEC-136 Directory traversal Countermeasures

General recommendations (language independent)
Avoid implementation of file access functionality based on user input, unless required If user input is required, Constrain file system access to a whitelist of allowed files and/or directories Define this list already in the application design document, and Detail also whether specific application parts should only access specific directories Before accessing the file system resource Normalize any pathname (normalization is the process to find the shortest possible representation of a pathname) Filter the input for malicious meta-characters Check that the resulting, normalized pathname points to the pre-defined whitelist
ABAP recommendations (details follow)

For the normalization and validation of URLs, use the class CL_HTTP_UTILITY For file system access, use logical file names
SEC-136 Directory traversal Attacks based on input to OPEN DATASET

Following code snippet takes a file name as input from a Web application parameter:
filename = request->get_parameter( file ). CONCATENATE /srv/sapprod/zapp1/ filename INTO file. OPEN DATASET file FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.
An attacker may provide any other relative pathname to access resources outside of the intended directory, e.g., the malicious user input
../../../etc/passwd
Is concatenated to
/srv/sapprod/zapp1/../../../etc/passwd
And resolves after normalization to the pathname

/etc/passwd
SEC-136 Directory traversal Recommendation for ABAP: Logical files

Logical files/paths are a concept that
Enables cross-platform applications (by abstracting from the syntax of the underlying OS) Offers several security features to prevent directory traversal
Typical scenarios
1. 2. 3.
An application defines a logical file name in code or customizing. This logical file name is later, at runtime, translated into the OS (and customer) specific physical file name. An application permits a physical file name to be entered in some UI. This physical file is checked against a logical file. An application permits a logical file to be entered in some UI. The set of permitted file names has been configured with aliases, which are again translated.
References
Note 1497003: Potential directory traversals in applications SAP Wiki: Knowledge Base SEC-136 Directory Traversal
SEC-136 Directory traversal Code snippets BEFORE and AFTER fixing

Scenario 2: An application permits a physical file name to be entered in some UI. This physical file is checked against a logical file. Before fixing
OPEN DATASET pa_file FOR INPUT IN TEXT MODE ENCODING DEFAULT. IF sy-subrc <> 0. ENDIF.
After fixing
CONSTANTS logical_filename = 'EXAMPLE_FIN1'. [] CALL FUNCTION 'FILE_VALIDATE_NAME' EXPORTING logical_filename = logical_filename CHANGING physical_filename = pa_file EXCEPTIONS OTHERS = 1. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. OPEN DATASET pa_file FOR INPUT IN TEXT MODE ENCODING DEFAULT. IF sy-subrc <> 0. ENDIF.
SEC-136 Directory traversal Attacks based on URLs

A regular URL for accessing a file resource from the Web server is as follows:
http://host/zapp1?file=bill-1234_2010-06-01.pdf
The file is located in the file system under

/srv/sapprod/zapp1/bill-1234_2010-06-01.pdf
An attacker may use following attack patterns to get access to other files on the server, outside of the applications root:
%2F = / http://host/zapp1?file=../../../etc/passwd %252F = %2F = / http://host/zapp1?file=..%2F..%2F..%2Fetc/passwd http://host/zapp1?file=..%252F..%252F..%252Fetc/passwd http://host/zapp1?file=..%252F..%252F..%252Fetc/passwd%00.html
Note: ABAP ICM/ICF is not susceptible to double-encoding attacks. This is just an example from the past, used to illustrate the difficulty of proper validation
SEC-136 Directory traversal ABAP Recommendation: URL validation 1/3

ABAP provides utility class CL_HTTP_UTILITY with following methods, which can be used in order to prevent Directory Traversal:
NORMALIZE_URL - Normalize URL Path IS_VALID_URL - Checks whether a transferred string is a valid URL CHECK_HTTP_WHITELIST - URL Comparison with a White List
Function NORMALIZE_URL can be used to transform relative URLs into absolute URLs according to the syntax rules of RFC1808
DATA: I_UNNORMALIZED TYPE STRING, E_NORMALIZED TYPE STRING.
CALL METHOD CL_HTTP_UTILITY=>NORMALIZE_URL EXPORTING UNNORMALIZED = I_UNNORMALIZED RECEIVING NORMALIZED = E_NORMALIZED.
SAP
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

Code Injection Dynamic ABAP code

ABAP allows to dynamically create and manipulate ABAP code
Create new ABAP program code in a table within an ABAP program Create report on the fly from ABAP code stored in table Execute report created on the fly Modify existing ABAP program code (e.g., to inject backdoors) Read report code into table Modify code Write back report code or execute report on the fly
Dynamic programming threats

Control over data and system
Dynamic programming features

GENERATE SUBROUTINE POOL itab NAME prog READ REPORT prog INTO itab INSERT REPORT prog FROM itab PERFORM (SUBR) IN PROGRAM (prog) EDITOR-CALL FOR REPORT prog (S_DEVELOP authorizations required) FOR itab (no S_DEVELOP authorization checks)
Not Limited: Execution of arbitrary code possible

SAP Page 20112010 SAP / AG. All37 rights reserved. / Page 37
Code Injection Dynamic ABAP Code

Details on dynamic programming threats
Worst case scenario: your program accepts whole code segments from external input Consequence: Arbitrary code can be submitted to be executed System compromised
What about Im just using this variable value in my dynamically created code.
Problem if you fail to carefully validate the variable value
val = '3' val = '3. DELETE FROM USR02'
FORM read_data USING val TYPE STRING. rep_append 'REPORT ZREAD_DYNAMIC.'. rep_append 'DATA: lv_val TYPE STRING.'. CONCATENATE 'lv_val = ' val '.' into l_statement. rep_append l_statement. INSERT REPORT lv_dynamic FROM reptab. SUBMIT (lv_dynamic) AND RETURN. ENDFORM.
REPORT ZREAD_DYNAMIC. DATA: lv_val TYPE STRING. lv_val = 3.

SAP Page 20112010 SAP / AG. All38 rights reserved. / Page 38
REPORT ZREAD_DYNAMIC. DATA: lv_val TYPE STRING. lv_val = 3. DELETE FROM USR02.
Code Injection Countermeasures

Complete mitigation
Refactor your program so that you do not have to dynamically generate code
Partial mitigation
Place authorization checks before the injected code Use rigorous whitelists that limit which constructs are allowed, i.e., In case of dynamic calls

Create a whitelist of permitted function modules, classes, reports, e.g., with help of utility class CL_ABAP_DYN_PRG
Filter all non-alphanumeric characters, e.g., via regular expressions In case of dynamically generated coding, create a whitelist of permitted ABAP commands, e.g., with help of utility class CL_ABAP_DYN_PRG
SAP
Agenda
1. Security
Why? Security @ SAP
2. Secure ABAP

Developer Responsibilities
A MUST for Secure Development:

Security should not be an afterthought Security is not optional Security is not a trade-off for Functionality/Performance Deploy only tested code Protect your credentials
Dont Blindly Assume Others Will Do it for You!
Application security is part of everybody's responsibility!
Get Ready for Secure ABAP Programming!
Understand Security Software Lifecycle Security SAP Security Solution Map Attention while Developing! Follow the Security Plan Adhere to Secure ABAP Programming Guideline Avoid Vulnerabilities listed in Security Advisories Evaluate the Application Security Test Tools ( ATC, Code Inspector ) Checklist for Secure Programming
Security Test Tools

ATC (ABAP Test Cockpit) Menu Path: Program -> Check -> ABAP Test Cockpit
Code Inspector Transaction Code: SCI Menu Path: Program -> Check -> Code Inspector
Secure Programming Checklist
This Checklist lists the most important issues that you should pay attention to in order to develop secure applications.
General No Backdoors Safe state in case of errors Password Security No plain text & hardcoded password Front-End Security/User Interface Input Validation No HTTP GET No SQL Injection, XSS, Path Traversal Access Security No revealing of data in error messages and URLs Hidden HTML Fields for Secrecy ABAP Programmers only Call Transaction with Authority Check, S_DEVELOP for ABAP command execution
In-accurate programming
SAP
Further Information
SAP Public Web:
General Info about Security SDN: https://www.sdn.sap.com/irj/sdn/security SAP Security Forum: https://www.sdn.sap.com/irj/sdn/forumID=208 SAP Security Guides: https://www.service.sap.com/securityguide SAP Security Notes: http://service.sap.com/securitynotes
Related SAP Education and Certification Opportunities

http://www.sap.com/education/
Contact Feedback
2010 SAP AG. All Rights Reserved

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, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated 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. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer 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 other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. in the United States and in other countries. 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.

706 Secure Programming ABAP PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

706 Secure Programming ABAP PDF

Uploaded by

Copyright:

Available Formats

Secure ABAP Programming

Peter McNulty SAP NetWeaver Solution Management May 2011

2011 SAP AG. All rights reserved. / Page 2

As a result of this workshop, you will be able to:

2011 SAP AG. All rights reserved. / Page 3

3. Common Vulnerabilities in ABAP Applications

Why security is needed in every software application?

2011 SAP AG. All rights reserved. / Page 5

Security Law of Weakest Link

Law of Weakest Link

2011 SAP AG. All rights reserved. / Page 6

3. Common Vulnerabilities in ABAP Applications

Vulnerability Prevention TCO/TCD Reduction

5 of these requirements are corporate requirements

2011 SAP AG. All rights reserved. / Page 8

SAP Security Standard vs. Industry Standards

2011 SAP AG. All rights reserved. / Page 9

SAP Security Standard vs. Industry Standards

CWE-190 Integer Overflow or Wraparound

CWE-362 Race Condition

SAP Security Standard vs. Industry Standards

Information disclosure Error messages

Some real life examples:

2011 SAP AG. All rights reserved. / Page 12

3. Common Vulnerabilities in ABAP Applications

Secure ABAP Secure Programming

Following security categories is mandatory for a secure program development.

Secure ABAP Secure User Interface

2011 SAP AG. All rights reserved. / Page 15

Secure ABAP Secure User Interface

2011 SAP AG. All rights reserved. / Page 16

3. Common Vulnerabilities in ABAP Applications

SEC-133 Cross-Site Scripting Introduction

Attack / entry point

SEC-133 Cross-Site Scripting Example (stored XSS)

GET Money for FREE !!! <script> attack code </script>

5. Browser executes script in message (= mixture of data and code)

SEC-133 Cross-Site Scripting Susceptibility of different ABAP technologies

http://.../bsp/asdf/sample?name=<img src=+onerror=alert(document.cookie) ;>

<html> <body><p>Hello Test</p></body></html>

SEC-133 Cross-Site Scripting Overview ABAP output encoding technologies

Web frontend frameworks

2011 SAP AG. All rights reserved. / Page 21

SEC-133 Cross-Site Scripting Recommendation for non-BSP extensions

<html><body> <p>Hello Test</p> </body></html>

<html><body> <p>Hello &lt;img src=&quot;&quot; onerror=&quot;alert(document.cookie);& quot;&gt;</p> </body></html>

2011 SAP AG. All rights reserved. / Page 22

3. Common Vulnerabilities in ABAP Applications

Common Vulnerabilities in ABAP Applications

2011 SAP AG. All rights reserved. / Page 24

SEC-139 Backdoors Examples

2011 SAP AG. All rights reserved. / Page 25

ABAP Vulnerabilities Command Injection (Backdoor)

SEC-139 Backdoors Countermeasures

Prevent external attackers from inserting backdoors

3. Common Vulnerabilities in ABAP Applications

SEC-136 Directory traversal Introduction

Attack / entry point

SEC-136 Directory traversal Countermeasures

ABAP recommendations (details follow)

SEC-136 Directory traversal Attacks based on input to OPEN DATASET

And resolves after normalization to the pathname

2011 SAP AG. All rights reserved. / Page 31

<html><body> <p>Hello <img src="" onerror="alert(document.cookie);& quot;></p> </body></html>