SECCD

Code Security

.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 11
Course Duration: 2 Day(s)
e-book Duration: 2 Hours 50 Minutes
Material Number: 50147760
SAP Copyrights and Trademarks

© 2019 SAP SE or an SAP affiliate company. 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 SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.

© Copyright. All rights reserved. iii

Typographic Conventions

American English is the standard used in this handbook.

The following typographic conventions are also used.

This information is displayed in the instructor’s presentation

Demonstration

Procedure

Warning or Caution

Hint

Related or Additional Information

Facilitated Discussion

User interface control Example text

Window title Example text

© Copyright. All rights reserved. iv

Contents

vi Course Overview

1 Unit 1: Introduction

2 Lesson: Explaining Application Security and Vulnerabilities

8 Unit 2: Secure Programming

9 Lesson: Describing ABAP Best Practices and Handling of SY-SUBRC

12 Lesson: Understanding Injection Vulnerabilities

75 Unit 3: Security Testing Tools

76 Lesson: Describing Security Testing Tools

79 Lesson: Explaining ATC and CVA

© Copyright. All rights reserved. v

Course Overview

TARGET AUDIENCE
This course is intended for the following audiences:

Developer

Development Consultant

Technology Consultant

© Copyright. All rights reserved. vi

 UNIT 1 Introduction

Lesson 1
Explaining Application Security and Vulnerabilities 2

UNIT OBJECTIVES

Explain application security and vulnerabilities

© Copyright. All rights reserved. 1

 Unit 1
Lesson 1
Explaining Application Security and
Vulnerabilities

LESSON OBJECTIVES
After completing this lesson, you will be able to:

Explain application security and vulnerabilities

Overview of Application Security and Vulnerabilities

Figure 1: The Current Software Security Vulnerability Situation

Companies these days are facing a lot of challenges as technologies are evolving at a very fast
pace, and sometimes it is very hard to keep up as each new technology might bring with it
new vulnerabilities.

Figure 2: Security Failures Create Big Problems

© Copyright. All rights reserved. 2

 Lesson: Explaining Application Security and Vulnerabilities

The data breach information is taken from the following resource:

http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

Figure 3: Application Security is Getting to the Forefront of Digital Transformation Effectiveness

The number of cyber-attacks and loss in revenue have increased tremendously over the
years.

Figure 4: The Approach Today: Expensive and Reactive

Security should be planned earlier in the application development cycle and not just as an
afterthought.

Figure 5: Costs of Fixing Critical Security Defects: It Pays to Discover Issues Prior to Release

Finding security issues at design time instead of in production is easier and less expensive!

© Copyright. All rights reserved. 3

Unit 1: Introduction

Figure 6: The Challenge of Security

To safeguard their business applications, companies have to understand in detail the various
vulnerabilities and the latest countermeasures in order to know how to implement them
effectively.

Each new technology brings with it the risk of new vulnerabilities.

Firewalls, intrusion detection systems, signatures, and encryption alone cannot make an
application secure.

Figure 7: The Right Approach: Systematic and Proactive

SAP provide a lot of tools to assist developers or project team members in the different
phases of the software development life cycle.

Figure 8: Security Questions Concerning Custom-Developed ABAP Applications

Ensuring security and compliance of custom developed code is key.

You must consider security right from the very start of your software development.
The project team needs to understand the security requirements and have good knowledge
about the different security vulnerabilities and how to countermeasure.
Threat modeling needs to be considered for your application:

What are the attack entry points?

© Copyright. All rights reserved. 4

 Lesson: Explaining Application Security and Vulnerabilities

How would an attacker misuse the application?

Figure 9: Does Security Vulnerability Exist in SAP? How Do You Address Application Security?

SAP has a patch strategy and process for solving security issues in shipped software.
When a vulnerability is identified, SAP endeavors to make available corrections quickly and
provides these to customers via security notes on the SAP Support Portal. SAP actively
encourages all customers to apply these notes and offers additional services included in
SAP's support offerings as well as a dedicated team of specialists at SAP Consulting for
customers with specific security requirements.
SAP provides security fixes for all product releases still in standard and
extended maintenance.

Figure 10: SAP Security Patch Day and Security Notes

The security maintenance of installed SAP software is the key to protect against new types of
attacks or newly identified potential weaknesses.
SAP has launched a regular SAP Security Patch Day, scheduled for the second Tuesday of
every month, which has been synchronized with the Security Patch Day of other major
software vendors. On these SAP Patch Days, SAP publishes software corrections as SAP
Security Notes, focused solely on security to protect against potential weaknesses or attacks.
SAP categorizes SAP Security Notes as Patch Day Security Notes and Support Package
Security Notes, with the sole purpose of making you focus on important fixes on patch days
and the rest to be implemented automatically during SP upgrades.
For more information about SAP Patch Day and SAP Security Notes, see https://
support.sap.com/en/my-support/knowledge-base/security-notes-news.html#section .

LESSON SUMMARY
You should now be able to:

Explain application security and vulnerabilities

© Copyright. All rights reserved. 5

 Unit 1

Learning Assessment

1. Why is code security important?

Choose the correct answers.

X A It affects the security of the system

X B It is more expensive to fix afterwards

X C More security attacks are happening in the application layer

X D It is important for migrating to SAP S/4HANA

2. Which of the following are correct about SAP Security Patch Day?
Choose the correct answers.

X A Critical security notes are released on Security Patch Day.

X B It is every second Tuesday of the month.

X C Security notes contain only security fixes for SAP NetWeaver.

X D All of the above

© Copyright. All rights reserved. 6

 Unit 1

Learning Assessment - Answers

1. Why is code security important?

Choose the correct answers.

X A It affects the security of the system

X B It is more expensive to fix afterwards

X C More security attacks are happening in the application layer

X D It is important for migrating to SAP S/4HANA

You are correct! Code security affects the security of the system, it is more expensive to
fix afterwards, and more security attacks are happening in the application layer. Refer to
the lesson ‘Overview of Application Security’ for more details.

2. Which of the following are correct about SAP Security Patch Day?
Choose the correct answers.

X A Critical security notes are released on Security Patch Day.

X B It is every second Tuesday of the month.

X C Security notes contain only security fixes for SAP NetWeaver.

X D All of the above

You are correct! Critical security notes are released on Security Patch Day and it is every
second Tuesday of the month. Refer to the lesson ‘Overview of Application Security’ for
more details.

© Copyright. All rights reserved. 7

 UNIT 2 Secure Programming

Lesson 1
Describing ABAP Best Practices and Handling of SY-SUBRC 9

Lesson 2
Understanding Injection Vulnerabilities 12

UNIT OBJECTIVES

Describe ABAP best practices and handling of SY-SUBRC

Understand injection vulnerabilities

Explain web-based vulnerabilities

Understand inaccurate programming vulnerabilities

Describe tools to detect security vulnerabilities and sanitization techniques

© Copyright. All rights reserved. 8

 Unit 2
Lesson 1
Describing ABAP Best Practices and Handling
of SY-SUBRC

LESSON OBJECTIVES
After completing this lesson, you will be able to:

Describe ABAP best practices and handling of SY-SUBRC

ABAP Best Practices and Handling of SY-SUBRC

Figure 11: Best Practices in ABAP Programming

The standard SAP software is known for its extensibility and flexibility. Customers can adapt
optimally to meet their specific business requirements. With this customer-specific
development comes the risk of inefficient or even error-prone applications when the
development is not done properly. In order to safeguard your business applications against
any of these risks, it is very important for customers to follow some best practices or
guidelines during their software development cycle.
Some of the above best practices can be found in a guide from the DSAG Special Interest
Group SAP Development.
For more information, see Best Practices Guidelines for Development - Practical Tips on the
ABAP Development .

Figure 12: Application Security in ABAP

© Copyright. All rights reserved. 9

Unit 2: Secure Programming

Application security is an important topic but a lot of times it is neglected during the
development cycle or comes just as an afterthought. SAP systems running on ABAP are
protected by roles and authorizations. This may be true for the SAP standard, but might not
be the case for custom code. Authorization checks are executed only if they are explicitly
programmed in ABAP code, so if the custom code does not check the necessary
authorizations correctly then this might open up some security loopholes.
Security issues might occur in the following cases:

Authorization check is not implemented in the code

Wrong authorization object is used

Proprietary authorization logic which is not compliant to SAP standard is used

Return value of the authorization check is not handled properly

Injection vulnerabilities are covered in more detail in the next section.

Figure 13: Authorization Checks in ABAP

When doing custom code development, developers need to program their own authorization
checks to protect the critical points in their ABAP programs.
Besides coding the AUTHORITY-CHECK statement, developers can also implement scenario-
based authorization checks if there is a need. This provides delivered software with
alternative authorization checks for authorization objects in different use cases. Adding
scenarios enables developers to enhance their application without completely disrupting the
current processes, giving developers time to plan for a redesign. To implement this kind of
authorization check, use the method AUTH_CHECK_SPEC of the class CL_SACF. In the
method call, define the scenario names and the authorization objects and values to check.
For more information about scenario-based authorization checks, see https://help.sap.com/
viewer/c6e6d078ab99452db94ed7b3b7bbcccf/7.5.9/en-US/
a9a721a34a4b4e2fa5c12947022c7d76.html .
In ABAP, the system field SY-SUBRC returns the success or failure of a statement. In some
cases, not handling this return code can lead to severe instability and unexpected results.
This situation is obvious in the case of the statement AUTHORITY-CHECK, where
disregarding the return code means performing no authority check at all.
In other statements, the return or export parameters can be undefined if SY-SUBRC is not
equal to zero, which can lead to application errors when the return code is ignored.
Some ABAP statements can endanger stability, data integrity, and overall program security
when used carelessly. The Code Inspector tool from SAP will report during the code check if
any of the statements are critical. For example: one of the checks is to see whether the SY-
SUBRC is handled after the AUTHORITY-CHECK statement. The code check should be done

© Copyright. All rights reserved. 10

 Lesson: Describing ABAP Best Practices and Handling of SY-SUBRC

during development in order to detect any of these critical cases early in the development
cycle.

Figure 14: Handling of the System Return Code SY-SUBRC

For example, If application errors occur when a function module is processed, the function
module raises a corresponding exception. The exception cancels the processing of the
function module and returns the system to the calling program. If the exception is caught in
the EXCEPTIONS block of the call, the specified return code is entered in the SY-SUBRC
system field of the calling program. By checking this field after the call, you can determine if
and, where applicable, which exception was raised so you can react accordingly. If no
exception is raised by the function module, the SY-SUBRC of the calling program is set to
zero.
An exception is a situation that arises while a program is being executed during which there is
no point in continuing the normal program flow.
Exception situations can be recognized either by the program or by the runtime environment.
When an exception situation is recognized, either the ABAP program or the runtime
environment raises an exception. Exceptions in the ABAP runtime environment are generally
caused by error situations that cannot be predicted by the static program check.

LESSON SUMMARY
You should now be able to:

Describe ABAP best practices and handling of SY-SUBRC

© Copyright. All rights reserved. 11

 Unit 2
Lesson 2
Understanding Injection Vulnerabilities

LESSON OBJECTIVES
After completing this lesson, you will be able to:

Understand injection vulnerabilities

Explain web-based vulnerabilities

Understand inaccurate programming vulnerabilities

Describe tools to detect security vulnerabilities and sanitization techniques

SQL Injection

Figure 15: Vulnerabilities

In order to identify the risks and address the security problems in your applications, you will
need to understand the different types of vulnerabilities. We will explain each category here
and discuss the countermeasures.

Figure 16: Injection Vulnerabilities - Introduction

Almost all software applications accept user input in some way or other. For example:

Passwords

Search requests

Forms

File names

Messages (SOAP, IDOC, JMS, and so on)

© Copyright. All rights reserved. 12

 Lesson: Understanding Injection Vulnerabilities

Configuration settings (customizing)

Command line parameters

Uploaded documents (Excel, …)

And so on

Programmers often make assumptions on the format of the input received from the outside.
Applications should be resilient to unexpected input, for example, it shouldn't crash if it
receives a string instead of a numeric value.
Security concerns arise when user input is mixed with active parts of a program.

Active parts are executable parts, such as SQL queries, or calls of OS commands.

If the user input is used without protection, it can subvert the logic of the program.

Applications, through various means (such as web services, REST, RFC, and HTTP) can
expose their functionality to users. In order to interact properly, users are meant to provide
information (such as username, password, address, or file name) to applications.
Attackers may try to inject commands (such as OS or SQL commands) in order to take
control over the system running the applications.
Injection attacks occur whenever user input sanitization is not sufficient in the application. For
example, in order to prevent execution of malicious SQL commands injected by an attacker,
an application might discard any SQL reserved command in user's input. (For example,
SELECT would be discarded.)
Injection attacks are considered to be a major security threat. Lack of sanitization of the user
input can lead to the execution of commands on the OS of the application, or the SQL
commands. When an application is vulnerable to such an attack, the consequences for the
hosting system can be disastrous (for example, drop of an entire DB, theft of credit card
information, installation of backdoors, and so on).
Except JMS, all of the example inputs are relevant for ABAP. Passwords are taken care of by
the central authentication API, and are not dealt with by the developers themselves.
Abbreviations:

SOAP
Simple Object Access Protocol, used for web service invocations
JMS
Java Messaging Service

© Copyright. All rights reserved. 13

Unit 2: Secure Programming

Figure 17: Injection Vulnerabilities - Overview of the Different Types

Injection vulnerabilities can be found in various places in ABAP. Here are the most common
types of injection vulnerabilities:

Directory traversal

SQL injection

Command injection

Code injection

Call injection

Figure 18: SQL Injection - Introduction

An SQL injection attack is an insertion or injection of an SQL query via the input data from the
client to the application. A successful SQL injection exploit can read sensitive data from the
database, modify database data (insert/update/delete), execute administration operations
on the database (such as shutting down the DBMS), recover the content of a given file
present on the DBMS file system, and in some cases issue commands to the operating
system. SQL injection attack is a type of injection attack in which SQL commands are injected
into data-plane input in order to affect the execution of predefined SQL commands.

© Copyright. All rights reserved. 14

 Lesson: Understanding Injection Vulnerabilities

SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause
repudiation issues such as voiding transactions or changing balances, allow the complete
disclosure of all data on the system, destroy the data or make it otherwise unavailable, and
become administrators of the database server. The severity of SQL injection attacks is limited
by the attacker's skill and imagination, and to a lesser extent, defense countermeasures, such
as low-privilege connections to the database server and so on. In general, consider SQL
injection a high-impact severity.
In most cases, SQL injection is dealing with the manipulation of an SQL statement, not with
the insertion of new statements.

Figure 19: SQL Injection - General Example

This slide shows an example of SQL manipulation (changing an existing query) and SQL code
injection (introducing new statements).
It is useful to explain the concept, even if the example as such is not possible in ABAP.
However, if you use the "WHERE (variable)" clause and do not care about the variable, then
the first issue is possible.
The first example illustrates SQL manipulation by changing just the WHERE clause and adding
a statement that returns true for any case. The second one illustrates an SQL command
injection that drops the user table.

Figure 20: SQL Injection - Susceptibility of Different ABAP Technologies

© Copyright. All rights reserved. 15

Unit 2: Secure Programming

The susceptibility of different ABAP SQL technologies to SQL injection is as follows:

Static Open SQL

Transformed internally to prepared statements

SQL statement and user data are clearly separated; no SQL code injection is possible

Dynamic Open SQL

The use of dynamic programming has increased over the years. Dynamic Open SQL
interprets string or character variables as parts of an SQL statement, for example, the usage
of variables or parameters within the SELECT statement. This can be done by carefully
constructing its components such as FROM, INTO, and WHERE clauses.
In Dynamic Open SQL:

No encoding function is available

User data cannot be separated from SQL commands; SQL manipulation is potentially
possible if user data is used in dynamic SQL statements

Native SQL
Native SQL allows you to use database-specific SQL statements in an ABAP program. Native
SQL for ABAP is always static and therefore not vulnerable..

Beware of EXEC SQL in dynamically created ABAP code

Use only when you ARE a member of the database operation team

ADBC
ADBC is the ABAP analog of JDBC in Java. It is used for dynamic native SQL in ABAP with
database-dependent SQL statements (ABAP class CL_SQL_STATEMENT).

Incorrect usage of SELECT.. from (variable) or class cl_sql_statement regularly leads to

Security Notes on the HotNews level

Potentially vulnerable against SQL manipulation and SQL code injection

Figure 21: SQL Injection - Countermeasures (1/2)

If possible, try to avoid using dynamic SQL statements. Of course there are valid cases for
dynamic SQL (for example, based on control tables).
Don't throw all good things away. Take care of external input. Database manipulation, when it
must be done by SE16, is not our enemy.
If it is not possible to avoid dynamic SQL statements:

Reduce the number of dynamic elements (for example, only the WHERE clause).

© Copyright. All rights reserved. 16

 Lesson: Understanding Injection Vulnerabilities

Filter and validate user input while retrieving user information for your SQL statement.

Filter according to specification and data type. For example, email addresses should
comply with the respective RFC and must only contain special characters "@", "_", ".", and
"-".

Where possible, use the utility class CL_ABAP_DYN_PRG to support the following types of
checks:
- Whitelist check
- Validity check for DB table names, DB column names, and variable names
- Integer check

Where not possible, use regular expressions. Regular expressions are used to check for
non-permitted characters. For example, the following regular expression finds any
character not contained in the whitelist of letters and numbers:
FIND REGEX '[^A-Za-z0-9]' IN userinput MATCH COUNT mcnt

Use escaping (e. g. CL_ABAP_DYN_PRG=>QUOTE)

Note:
Developers not familiar with regular expressions can look at the report
DEMO_REGEX_TOY for a quick demo.

Keep the business data in mind. It does not make sense to limit a last name field to ASCII-only
when you go to Germany.
On older releases (< 6.20) you need to use the function modules RS_ESCAPE_QUOTES,
RS_CHECK_VARIABLE, and RS_CHECK_WHITELIST_TAB, which were replaced by
CL_ABAP_DYN_PRG.

Figure 22: SQL Injection - Countermeasures (2/2)

The keyword CLIENT SPECIFIED allows you to read DB content that belongs to a client other
than the actual SAP client (German: Mandant). If this keyword is used and the WHERE clause
of the SQL statement is vulnerable to SQL injection, an attacker could read data belonging to
other clients (by adding a WHERE condition to the DB column CLNT).

© Copyright. All rights reserved. 17

Unit 2: Secure Programming

Some functionality, however, requires the use of CLIENT SPECIFIED. One prominent example
is "client copy" where data is copied from one client to another on purpose.
If you build dynamic WHERE clauses, ensure that you do it as in the first example. Even
though the difference between the first and the third code snippets is small, the first one is
NOT vulnerable. Here, the variable names are present in the dynamic WHERE clause (and not
the variable values, as in the third code snippet).

Figure 23: Introductory Example: SQL Injection

Figure 24: Example: Data Flow

To look for vulnerability in a program, we need to look for the following:

Different user input sources

- Parameters
- Dynpro fields
- Insecure database tables
- ABAP lists
- Set/Get parameters
- Non-trusted sources

Different vulnerable statements

Data flow

© Copyright. All rights reserved. 18

 Lesson: Understanding Injection Vulnerabilities

Code Injection and Call Injection

Figure 25: Code Injection - Introduction

Code injection refers to situations where the attacker can insert malicious input to inject
unintended coding.
For example:

Malicious code injected into a generated code (dynamic ABAP code).

As a result, an attacker can virtually do anything that is possible with ABAP, for example:

Access the entire database

Make operating system calls

Make kernel calls

Figure 26: Code Injection - Dynamic ABAP Code (1/2)

An attacker can inject and call code that does not yet exist in the system by exploiting
dynamic ABAP code.
ABAP code can be created and manipulated dynamically. For example:

Create new ABAP program code in a table within an ABAP program

- Create a report on the fly from ABAP code stored in a table
- Execute a report created on the fly

© Copyright. All rights reserved. 19

Unit 2: Secure Programming

Modify existing ABAP program code (for example, to inject backdoors)

- Read report code into a table
- Modify code
- Write back report code or execute a report on the fly

EDITOR-CALL FOR REPORT is safe (it is almost identical to call the development environment
except the missing transaction start authorization check).
EDITOR-CALL FOR itab followed by INSERT REPORT or GENERATE SUBROUTINE is very
critical in most cases.
Wrong usage of INSERT REPORT or GENERATE SUBROUTINE regularly leads to Security
Notes on the HotNews level.

Figure 27: Code Injection - Dynamic ABAP Code (2/2)

In this example, the attacker injects ABAP code in order to delete table content.
As the ABAP code executes the report right after its generation, the statement DELETE FROM
USR02 is executed on the system.
Dynamic programming threats:

Worst case scenario: Your program accepts whole code segments from external input

Consequence: Arbitrary code can be submitted to be executed, which leads to the system
being compromised

What about "I'm just using this variable value in my dynamically created code"?

Problem if you fail to carefully validate the variable value

Figure 28: Code Injection - Countermeasures

The first recommendation is NOT to use dynamically generated code based on user inputs.

© Copyright. All rights reserved. 20

 Lesson: Understanding Injection Vulnerabilities

If the use of dynamically generated ABAP code is required, ABAP developers should place
authorization checks before the execution of any ABAP statement containing dynamically
generated ABAP code.
For persisted generated code, developers should place authorization checks within the
following:

Generated code, so that only authorized users can execute it

The code generator, so that only authorized users can generate code

Persisted generated code refers to generated code that is stored in the database (such as a
report), and which can be called at later times by users other than the one generating the
code. Persisted code is different from non-persisted code which is created, for example, via
GENERATE SUBROUTINE POOL and executed immediately afterwards.
Another recommended countermeasure is to define whitelists using class
CL_ABAP_DYN_PRG to limit which constructs are allowed.

Figure 29: Call Injection - Introduction

Through dynamic ABAP calls, attackers in call injection scenario can provide malicious input
to specify the piece of code they want to call. This can be a transaction, function module, or
method, etc.

Figure 30: Call Injection - Dynamic ABAP Calls

CALL TRANSACTION ta
The statement CALL TRANSACTION calls the transaction whose transaction code is
contained in the data object ta.

© Copyright. All rights reserved. 21

Unit 2: Secure Programming

Authorizations of the caller are NOT checked! (Unless SE97 is maintained, but this is not
well unknown and not state-of-the-art any more. Authorization checks are also influenced
by system profile parameters.)

LEAVE TO TRANSACTION ta
The statement LEAVE TO TRANSACTION calls the transaction whose transaction code is
contained in the character-type data object ta or the current transaction. ta must contain
the transaction code in upper case.
Authorizations of the caller are checked; as such, LEAVE TO TRANSACTION is always safe,
even in the case of dynamic programs.
For more details about the syntax, refer to https://help.sap.com/doc/
abapdocu_751_index_htm/7.51/en-US/index.htm

Generic programming threats:

If relevant input is user-controlled -> control over program

If relevant input is not validated -> unintended use of functions

There is further risk for remotely accessible functions. For example: Generic table or file
readers accessible as RFC modules
- Limited to functions provided by already existing code
- Cannot execute what is not already there

Figure 31: Risks of Dynamic Remote Function Calls: What is the Risk?

© Copyright. All rights reserved. 22

 Lesson: Understanding Injection Vulnerabilities

Figure 32: Risks of Dynamic Remote Function Calls

In this example, the parameter FUNC can be used externally to control which dynamic RFC to
be called.

Figure 33: Risks of Dynamic Remote Function Calls: What are the Sanitization Methods?

A whitelist is a list of accepted inputs or content, and a blacklist is a list of inputs or content to
be refused.

Figure 34: Risks of Dynamic Remote Function Calls: How to Use CL_ABAP_DYN_PRG for Whitelists?

If a passed value is not in the value set, the exception CX_ABAP_NOT_IN_WHITELIST is

thrown. The methods mass_check_whitelist_[str|tab] can be used to check sets of values.

© Copyright. All rights reserved. 23

Unit 2: Secure Programming

Figure 35: Risks of Dynamic Remote Function Calls: How to Use CL_ABAP_DYN_PRG for Whitelists Without
Expressions?

If a passed value is not in the value set, the exception CX_ABAP_NOT_IN_WHITELIST is

thrown. The methods mass_check_whitelist_[str|tab] can be used to check sets of values.

Figure 36: Risks of Dynamic Remote Function Calls: What Other Input Validation Does CL_ABAP_DYN_PRG
Provide?

Operating System Command Injection

Figure 37: Operating System Command Injection - Introduction

Executing operating system (OS) statements from ABAP programs should be the exception,
not the rule. ABAP developers should avoid invoking OS commands directly on the hosting OS
at all. Any need for OS commands or programs should be considered carefully. There might
be existing libraries that already encapsulate the required OS command which can be used to
prevent OS command injection vulnerabilities. This type of vulnerability does not depend on
the programming language but on the OS on which an application server or presentation
server runs.
Some examples of OS commands that could be invoked for malicious purposes include the
following:

© Copyright. All rights reserved. 24

 Lesson: Understanding Injection Vulnerabilities

dir (to list the content of a directory)

copy

taskkill (to force the end of a process)

ping

Obviously, the attack depends on the OS specifics, for example, to pipe or redirect input and
output with regard to the callable OS commands.
The attacker can try to interfere and add additional arguments to his input text, in order to
modify or invoke new system commands that could be very risky for the security of the OS on
which the application server is run.
Some examples of compound command symbols on the Windows platform include the
following:

cmd1 & cmd2

Executes command cmd1 then command cmd2. Additional ampersand symbols can be
added.

cmd1 && cmd2

Executes command cmd1, then executes command cmd2 only if cmd1 completed
successfully.

cmd1 || cmd2
Executes command cmd1, then executes command cmd2 only if cmd1 did not complete
successfully.

()
Use parentheses to indicate the nesting of complex multi-command sequences. Also used
in IF ... ELSE commands.

Some examples of command redirection symbols on the Windows platform include the
following:

>file
Redirects the command output to the file specified. You can also use a standard device
name such as LPT1, CON, PRN, or CONOUT$ as the file name. Any preexisting contents of
the file are lost.

>>file
Redirects the command output to the file specified. If the file already exists, all command
output is appended to the end of the file.

<file
Redirects the command input from the file specified. You can also use a standard device
name such as CON or CONIN$.

2>file
Redirects the command error output to the file specified. You can also use a standard
device name such as LPT1, CON, PRN or CONOUT$ as the file name. Any preexisting
contents of the file are lost.

2>&1

© Copyright. All rights reserved. 25

Unit 2: Secure Programming

Redirects the command error output to the same location as the command output. This
makes any command output redirection also apply to the command error output.

cmd1 | cmd2
Pipes the command output of cmd1 to the command input of cmd2. Multiple pipe
characters are allowed, creating a chain of commands, each sending output to the next
command in the chain.

For more information about the syntax, see https://docs.microsoft.com/en-us/windows-

server/administration/windows-commands/windows-commands .

Figure 38: System Command Injection: Executing Operating System Commands From ABAP

Of all these alternatives, the only recommended method for executing OS statements from
ABAP on the OS of the current application server or another server is to use the SXPG
framework. This framework is based on a list of permitted OS statements (which you define
your own) that can be called using function modules (SXPG_... ) in the function group SXPG.

SXPG Framework
The SXPG framework has the following features:

Can be used to call OS commands on the application server

Provides platform-dependent physical OS statements

Comes with a number of default OS commands

Is based on a SAP-delivered executable called through the RFC gateway

Allows customers to define check modules for each OS command, for example, to realize a
character whitelist

Comes with an authorization check

CALL 'SYSTEM' ID 'COMMAND' FIELD <command>

CALL 'SYSTEM' is simply a usage of the ABAP statement CALL cfunc. This statement should
only be used internally in system programs to call system functions from the c-kernel.
SYSTEM is one of those system functions; it passes system commands to the OS and returns
the results. CALL 'SYSTEM' is vulnerable against system command injection and there is a
profile parameter rdisp/call_system that can switch it off. A runtime error occurs if you use
CALL 'SYSTEM' and it is switched off.

OPEN DATASET …. FILTER command

Not recommended with the usage of filters

Specifying a filter causes the application server to start an external program to pre-
process (reading) or post-process (writing) the data

© Copyright. All rights reserved. 26

 Lesson: Understanding Injection Vulnerabilities

A typical use case is to compress/decompress files before writing/reading

Available on Windows and Unix

Figure 39: System Command Injection - SXPG Framework

System administrators with appropriate authorizations can define a list of permitted OS

statements using SM49or SM69. Each of the OS statements is assigned to a logical command
name in ABAP. Static parameters can be assigned to any OS statement and additional
parameters can be specified further when the statement is called.
In the figure, there is an example of LIST_DB2DUMP for Windows which calls cmd/c dir and
the result is a listing of the work directory.
What if there's an additional parameter ".." ?
When an operating system statement is called using a logical command name, implicit
authorization checks are performed. The check module will also be called if it is set up.
For more information, see SAP Note 686765: Security check when you execute external
commands .

Figure 40: System Command Injection - SXPG Function Module Example

Besides using SM49or SM69to call the OS statements, ABAP developers can also make use of
the SXPG function modules in their ABAP programs. These function modules can also be
called remotely.

© Copyright. All rights reserved. 27

Unit 2: Secure Programming

SXPG_CALL_SYSTEM for execution on the current application server

SXPG_COMMAND_EXECUTE for execution on other servers; the result can be caught but
is not mandatory

SXPG_COMMAND_EXECUTE_LONG, like SXPG_COMMAND_EXECUTE but with a longer

list of parameters

Besides calling the OS command from the user input, attackers can attempt to execute
additional OS commands by manipulating the parameters in the call. Of course, the attacker
needs to know additional information about the OS running the ABAP stack. This type of
information can be acquired easily, for example, through information disclosed in error
messages or similar.
In this example, the attacker uses the '|' character to chain an additional OS command. Once
the 'dir' command is executed on the folder specified by the user, any OS command
separated by '|' will be executed on the host operating system.

Figure 41: Operating System Command Injection - Countermeasures

It is highly recommended NOT to use any OS command invocations in ABAP code.

If you really need to do it, use existing ABAP functions which already do the job, or use
SPXPG_ functions. Check SM49or SM69for the list of available functions in your system.
If an OS command needs to be defined in SM49or SM69, make sure to define the OS
command statically without user input.
Additionally, it is recommended that you sanitize the user input first. Always try to perform a
rigorous whitelist check.

Escape or filter all characters that do not pass a strict whitelist

Use class CL_ABAP_DYN_PRG

Use regular expressions, for example, to filter all non-alphanumeric characters, as in the
following example:
FIND REGEX '[^A-Za-z]' IN userinput MATCH COUNT mcnt.

Do not use a blacklist approach; you will likely fail to cover all encodings and characters

In cases where special characters are needed, wrap each argument in double quotes and
check that double quotes themselves cannot be entered in the user input

© Copyright. All rights reserved. 28

 Lesson: Understanding Injection Vulnerabilities

Directory Traversal

Figure 42: Directory Traversal - Introduction

In a directory traversal (or path traversal) attack, malicious users try to access restricted files
or folders on the OS of the application. Directory traversal may compromise confidentiality,
integrity, and availability (CIA) whenever file paths are processed.

Figure 43: Directory Traversal Vulnerability: What is the Risk?

Files can be manipulated during directory traversal attacks (for example, create, append,
write, read, delete).
Some examples of directory traversal attacks include:

Sensitive data can be READ

DELETE can be made possible

OPEN of pagefile can lead to denial of service

Directory traversal is more relevant for the backend (application server) as access to any
front end files (presentation server) via CL_GUI_FRONTEND_SERVICES (or corresponding
function modules) is protected against directory traversal attacks. A simple check of
CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD with a file name containing the character
sequence ".." results in the exception FILE_OPEN_ERROR.

© Copyright. All rights reserved. 29

Unit 2: Secure Programming

Figure 44: Directory Traversal Vulnerability: What are the Sanitization Methods?

Do not allow the user to define a file name but let the administrator decide. Use the function
module FILE_GET_NAME to retrieve the definition from the administrator.
If it is required to request the file name from the user, validate the file name using the function
module FILE_VALIDATE_NAME.
Even if you used FILE_GET_NAME with user input you have to use FILE_VALIDATE_NAME
afterwards. Or use the combination of both: FILE_GET_NAME_AND_VALIDATE.
Do not just try to search for '..' in the file name. Depending on the encoding, the OS, and other
factors, this may not be sufficient.
For more information, refer to https://blogs.sap.com/2013/08/05/protecting-abap-code-
against-directory-traversal-attacks/ Protecting ABAP code against Directory Traversal
Attacks .
Also, see SAP Note 1497003: Potential directory traversals in applications .
.

Figure 45: Transaction SFILE

Logical files can be used to avoid directory traversal vulnerabilities with the help of function
modules such as FILE_GET_NAME and FILE_VALIDATE_NAME.
Logical and physical file and path names are defined in transaction SFILE (old transaction
FILE). Reserved words such as <HOST> or <PARAM_1> are placeholders that are substituted
at runtime either automatically, or by the respective input parameters of function modules
such as FILE_GET_NAME.
Using transaction SFILE (old transaction FILE), the administrator can also define a file name
pattern which allows the creation of multiple files with one definition. Patterns can include
information such as the following:

Date

Time

Server-related information like hostname

Information from environment variables

© Copyright. All rights reserved. 30

 Lesson: Understanding Injection Vulnerabilities

Figure 46: Logical Path

A logical path can be used in the definitions of logical file names to enable programs to
retrieve physical file names valid for the OS on which the application server is running.

Figure 47: Logical File Name

The file name portion defined can be absolute (start from a root) or relative.
File name patterns may include predefined patterns such as date, time, OS, or patterns based
on profile parameters.

Figure 48: Retrieve File Names Using FILE_GET_NAME

"Physical file" or "physical path" refers to the actual resource path in the OS-specific file
system, whereas a logical path/file can be defined in ABAP and is used by the actual ABAP
application.
Based on definitions maintained in Customizing tables for platform-independent file names,
FILE_GET_NAME converts a logical file name to the corresponding physical file name and
path for the hardware platform concerned.

© Copyright. All rights reserved. 31

Unit 2: Secure Programming

For more information about the function module, see https://help.sap.com/

saphelp_nw73ehp1/helpdata/en/48/dff95bab21280ce10000000a42189c/content.htm .

Figure 49: Validate File Names Using FILE_VALIDATE_NAME

FILE_VALIDATE_NAME checks if a physical file name corresponds to the rules of the logical
file name.
When validating a file name using FILE_VALIDATE_NAME, you should not use parameters
(PARAMETER_1, PARAMETER_2, or PARAMETER_3) based on user input.
If the file name given is not absolute, for instance, 'test.txt', FILE_VALIDATE_NAME will make
it an absolute one by adding the working directory of the application server based on profile
parameter DIR_HOME. For this reason, you need to put the intended directory in front of
relative file names before calling FILE_VALIDATE_NAME.
During the call of FILE_VALIDATE_NAME, it executes the function module FILE_GET_NAME to
determine the complete physical file name and the appropriate OS. FILE_GET_NAME will
return the physical file name to FILE_VALIDATE_NAME and the system will then compare the
two. If the two file names match, the user can access the file. If the two file names do not
match, function module FILE_VALIDATE_NAME triggers the exception VALIDATION_FAILED
and the program can deny the user access to the file.
For more information about the function module, see https://help.sap.com/
saphelp_nw73ehp1/helpdata/en/4c/b27910d9173d8ce10000000a42189e/content.htm .

Figure 50: Checking for Relative File Names With CL_FS_PATH

FILE_VALIDATE_NAME automatically assumes the physical file name provided for validation
to be relative to the work directory of the application server when the file name is not an
absolute one. Therefore, validation will fail for relative file names if the directory to validate
against is outside the server work directory.

© Copyright. All rights reserved. 32

 Lesson: Understanding Injection Vulnerabilities

Figure 51: Directory Traversal - Countermeasures

The figure, Directory Traversal - Countermeasures, is language-independent. ABAP-specific

countermeasures that are briefly mentioned at the bottom will be explained in more detail in
later figures.
Directories and files accessible to the application must be identified already at design time.
This is the basis for whitelists implemented later.
Normalization (or canonicalization) comprises, for instance, the following:

Removing upward directory references (..)

Resolving (decoding) any encoded characters (such as %20 for space, as known from URL
encoding)

Figure 52: Directory Traversal: Attacks Based on Input to OPEN DATASET

An attacker can try to perform a directory traversal attack whenever the ABAP developer
accesses the file system based on user input. In this example, the user input results from an
HTTP request, simulating that the file name is given in an HTML input form field (for example,
<input type="text" name="file">).
An ABAP developer can get access to the hosting file system via statements such as OPEN
DATASET and DELETE DATASET. Whenever the ABAP function invokes such methods based
on user input, it exposes the system to directory traversal vulnerabilities.
In order to exploit a directory traversal vulnerability, the attacker tries to access sensitive files
or folders by means of relative pathnames.

© Copyright. All rights reserved. 33

Unit 2: Secure Programming

OPEN DATASET is commonly used in ABAP functions (unlike some ABAP developers may
think). Code scanning efforts in 2010 resulted in about 500 vulnerable OPEN DATASET
statements.
In Unix-like OSs, the /etc/passwd file is a text-based database of information about users
that may log in to the system or other OS user identities that own running processes. Whether
the application can access the file depends on the file access permissions, and the user with
which the application server runs.
Normalization is the process of transforming a resource path into its shortest possible
representation.

Figure 53: Directory Traversal - Logical Files (1/4)

Use logical files to avoid directory traversal vulnerabilities. They have been significantly
improved in 2010 to include new security features. This is THE solution against directory
traversal path attacks. On top of this, they abstract from the actual OS on which the
application server runs. The scenarios provided exemplify how logical files may be used.
The term "physical file" or "physical path" refers to the actual resource path in the OS-specific
file system, in contrast to the "logical path/file", which can be defined in ABAP, and which is
used by the actual ABAP application.
The following authorization checks are automatically performed:

When you access sequential files on the application server using the statements OPEN
DATASET, READ DATASET, TRANSFER, and DELETE DATASET, the system automatically
checks the user's authorization against the authorization object S_DATASET. This object
allows you to assign authorizations for particular files from particular programs. You can
also assign the authorization to use OS commands as a file filter.

When you access sequential files on the application server using the statements OPEN
DATASET, TRANSFER, and DELETE DATASET, the system automatically checks against
table SPTH. This table controls general read and write access from ABAP to files, and
controls whether files should be included in security procedures. Unlike authorization
checks which use the authorization object S_DATASET, the authorization check against
the authorization object S_PATH is independent of the ABAP program used to access the
files.

For more information, see Automatic Checks in File Operations .

© Copyright. All rights reserved. 34

 Lesson: Understanding Injection Vulnerabilities

Figure 54: Directory Traversal - Logical Files (2/4)

A data format DIR was introduced, which allows you to check whether a provided file name is
beneath the specified root folder (a common scenario).
Depending on the hosting OS, logical files are mapped to a physical file on the file system.
Transaction SFILE (old transaction FILE) enables ABAP developers to define logical files.
With the definition of logical files, we define a list of restricted accessible files on the hosting
file system.
Reserved words, such as <HOST> or <PARAM_1>, are placeholders that are substituted at
runtime (either automatically, or by the respective input parameters of FILE_GET_NAME).

Note:
If these parameters are used and they can be influenced by external input then
one must check the generated physical filename with function module
FILE_VALIDATE_NAME. Or use FILE_GET_NAME_AND_VALIDATE.This is
because in the parameters you can use strings like "../../../".

Figure 55: Directory Traversal - Logical Files (3/4)

FILE_GET_NAME
This method resolves a given logical name to a physical file name.
<Param_1>, <Param_2>, and <Param_3> are input parameters you can instantiate in calling
this method (if part of the logical file definition).

© Copyright. All rights reserved. 35

Unit 2: Secure Programming

FILE_VALIDATE_NAME
This method checks if a physical file name (provided by a user) corresponds to the rules of
the logical file name (defined up front, and pointing to authorized files/directories). As such, it
can check a user-provided file name.

Figure 56: Directory Traversal - Logical Files (4/4)

This figure shows how FILE_VALIDATE_NAME works in two of the previously introduced
scenarios.

1. The user provides a physical file via the user interface. The application uses
FILE_VALIDATE_NAME to see if the provided physical file name corresponds to the
upfront defined logical file name. In the example, both are equal, and the application
continues.

Note:
This is not sensible anyway; the application should use the logical file name in
the user interface.

2. The user provides a physical file via the user interface. The application uses
FILE_VALIDATE_NAME to see if the provided file is beneath a certain directory, which has
been defined upfront by a logical file. Again, the check is successful (the provided physical
file is beneath c:\tmp\my_folder).

For more information, see http://help.sap.com/saphelp_470/helpdata/en/9f/

db95e635c111d1829f0000e829fbfe/frameset.htm .

© Copyright. All rights reserved. 36

 Lesson: Understanding Injection Vulnerabilities

Figure 57: Directory Traversal: Code Snippets BEFORE and AFTER Fixing

For more information, refer to https://blogs.sap.com/2013/08/05/protecting-abap-code-

against-directory-traversal-attacks/ Protecting ABAP code against Directory Traversal
Attacks

Figure 58: Directory Traversal: Attacks Based on URLs

Directory traversal attacks cannot be simply avoided by searching for "..". Multiple encodings
make it much more complicated for developers to cover all malicious input in a blacklist
approach. As such, you should define a whitelist of accepted characters, rather than vice
versa.
The following vulnerabilities were contained in early web server releases (Windows IIS,
Apache), but are less frequent nowadays:

1. Simple directory traversal attack without encoding

2. Simple encoding: Same as (1), but / is encoded by %2F

3. Double encoding: Same as (2), but % is encoded by %25

4. A web server is supposed to deliver only HTML files (and filtering on the basis of the
extension) may be tricked by the null character %00.

© Copyright. All rights reserved. 37

Unit 2: Secure Programming

%00: 0 (null, \0, ^@) was originally intended to be an ignored character, but is now used by
many programming languages to terminate the end of a string.
For AS ABAP, this all has no meaning; double URL encoding does not achieve anything, and
OPEN DATASET does not convert %2F to / on its own.

Figure 59: Directory Traversal - URL Validation (1/3)

The ABAP class CL_HTTP_UTILITY should be used to validate URLs that are provided as input
to your application.
One can argue that this topic belongs instead to the section on web-based vulnerabilities. It
was put here because past URL-based attacks often tried to leave the web server's root
directory. However, URL-based attacks may also be used to, for instance, load content from
servers other than the permitted servers.
In this figure, we focus on the NORMALIZE_URL method, which aims to normalize a relative
URL path into an absolute URL following RFC1808.
The ABAP code is self-explanatory.
For more information, see RFC1808. (https://www.ietf.org/rfc/rfc1808.txt)

Figure 60: Directory Traversal - URL Validation (2/3)

Whereas the previous method NORMALIZE_URL changes the provided URL, IS_VALID_URL
simply checks the validity of the provided URL. The check follows RFC2396.
The ABAP code is self-explanatory.

© Copyright. All rights reserved. 38

 Lesson: Understanding Injection Vulnerabilities

For more information about RFC2396, see RFC2396. (http://www.ietf.org/rfc/rfc2396.txt)

The flag RESTRICTIVE looks for iframe and object tags (on top of script tags).
For more information about IF_HTTP_UTILITY, see http://help.sap.com/saphelp_nw70/
helpdata/en/fd/778c3a045c7b73e10000000a11405a/frameset.htm .

Figure 61: Directory Traversal - URL Validation (3/3)

In this figure, we focus on the CHECK_WHITELIST method, which checks whether a given URL
is in the table HTTP_WHITELIST.
The method CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST is available
in the Web Application Server/ABAP to check URL-like parameters against a whitelist of
patterns in the table HTTP_WHITELIST (the table can be maintained in transaction SE16).
This process can be used to verify if a URL from external sources can be accepted.
The trainer can use transaction SE16 in order to show the content of this table. However, it is
empty in the training system. One reason for this is that normally this information is only
known at deployment time (for customer systems), but not at development time. The table is
type C (no SAP import).
For more information, see the following:

Security Risk List https://help.sap.com/saphelp_nwmobile711/helpdata/en/

48/69f794e8a607d6e10000000a42189c/frameset.htm

SAP Note 853878

What is the required role in order to maintain this table? This is not known; the table is not
assigned to an authorization group (at least in the training system).

Figure 62: Injection Vulnerabilities - Wrap-up

A secure approach to deal properly with input is to assume that this input is malicious.

© Copyright. All rights reserved. 39

Unit 2: Secure Programming

Developers should assess and address the risk associated with the input and should not
blindly rely on a possible check done somewhere before in the callstack.
The input verification should cover all the properties described previously.
When doing input validations:

Be sure to cover all input

Use an "accepted known good" input validation strategy; that is, use a whitelist of
acceptable inputs that strictly conform to specifications. Reject any input that does not
strictly conform to specifications, or transform it into something that does.

Do not rely exclusively on looking for malicious or malformed inputs; that is, do not rely on
a blacklist. Blacklists can be useful for detecting potential attacks or determining which
inputs are so malformed that they should be rejected outright.

When performing input validations, consider all potentially relevant properties including
length, type of input, the range of acceptable values, missing or extra inputs, syntax,
consistency across related fields, and conformance to business rules

Web-Based Threats

Figure 63: Web Technologies Overview

Web applications are built on a client/server architecture.

The client uses a browser to display the application UI. The server holds the data and business
logic and provides web pages to the client.
The communication protocol of the web application is HTTP. The web pages are described
using the HTML language, which is based on XML elements and attributes.
By default there is no security in web applications. All the data is exchanged in plain text. In
order to secure these transactions, there are already solutions like HTTPS (HTTP over SSL)
but you must take care of certificate checking. Secure Socket Layer (SSL) does not solve all
security issues and we need to understand all the different types of web-based vulnerabilities
in order to find the right solution.

© Copyright. All rights reserved. 40

 Lesson: Understanding Injection Vulnerabilities

Figure 64: Introduction to the Core Web Technologies: HTTP/HTML

The communication protocol of web applications is HTTP. This protocol proposes two main
methods (GET and POST) that contain all the necessary information to exchange data and
metadata. Further methods exist (such as HEAD, PUT, and DELETE) but are not explained in
detail here.
HTTP request and response messages contain the following:

A header with metadata

A body with the message payload

Communications are in plain text by default.

HTTP communication is readable by proxies. HTTPS (a secure version of HTTP) provides a
solution to secure the communications.

Figure 65: Introduction to the Core Web Technologies: HTTP GET

This figure shows an example of the interaction between browser and server in the context of
a given web application.
There are three HTTP messages involved:

1. HTTP request message (GET) to ask the server for the index.html page

2. HTTP response message of the server, delivering the page (that comprises a web form)

3. HTTP request message (GET) where the user submits the form back to the server,
thereby providing a variable called user, and the value test (which the user filled into the
web form). Note that the form data in HTTP GET is appended as a query string parameter
(?user=test) to the URL of the server page (http://example.com/prova.php).

The web form displayed corresponds to the HTML fragment below. It shows how the front end
(browser) renders the HTML provided by the server. The HTML tag <INPUT> becomes a GUI
input element where the user can enter his user name.

© Copyright. All rights reserved. 41

Unit 2: Secure Programming

Figure 66: Introduction to the Core Web Technologies: HTTP POST

This figure shows an example of the differences between HTTP GET and HTTP POST. Form
data in HTTP GET is appended to the URL (see previous figure), whereas form data in HTTP
POST is put into the HTTP message body. Apart from the HTTP method used, the remainder
of the example is the very same as before.
This figure introduces HTTP header fields, which are used to transport all kinds of metadata
between client and server. Including, for instance, authentication information.

Figure 67: Introduction to the Core Web Technologies: HTML Hidden Parameters

This figure introduces so-called "hidden parameters". Even though the name suggests some
sort of security, such parameters are only hidden from the UI, and remain visible in the source
code and during transmission (see the HTML code and HTTP message in the figure).
Hidden parameters are not a security mechanism as such.
After accessing the web page, the user fills the form (entering, for example, username=test)
and "posts" it to the server using the HTTP POST method (POST http://example.com/
prova.php). In this case even though it is not displayed in the form of the web page, a hidden
parameter (in this example, id=SecretID) is sent to the server.

© Copyright. All rights reserved. 42

 Lesson: Understanding Injection Vulnerabilities

Figure 68: Introduction to the Core Web Technologies: Cookies

HTTP is a stateless protocol which means each request is executed independently without
any knowledge of the requests that were executed before it.
No information about the client's previous calls (state) is maintained. To overcome this
problem, servers can store some information on the client using client-side cookies.
Cookies are automatically appended by the browser to each request for the domain that the
cookie originated from.
Cookies are used in the stateless protocol HTTP as a method for session tracking. They are
small text chunks containing information usually created by the web server or application.
They are used to persist and pass variables back and forth between the browser and the web
server/application.
Cookies come in two flavors:

Session cookies are temporary and they are deleted when the browser is closed or when
they expire.

Persistent cookies stay in a dedicated directory on the file system until they are explicitly
deleted or when they expire.

Cookies with session identifier (for session management) have the following characteristics:

Random, hard-to-guess strings generated and remembered by the web server

Work like shared secrets between client and server

The server can be sure of the identity of the client and does not need to re-authenticate

If the session ID can be guessed or intercepted, an attacker can "hi-jack" your session

Cookies are often used for security and authentication purposes so the content can be very
sensitive. It can contain session identifiers, shared encryption keys, and so on. This secure
information should not be exposed or intercepted by an attacker.

© Copyright. All rights reserved. 43

Unit 2: Secure Programming

Figure 69: User Authentication and Cookies

After successful authentication through username/password in this example, the browser

sets up a cookie on the client side which is automatically appended to every further request
made by the client. This cookie proves to the server that a session has been established after
the successful initial authentication. There is no more need to request the user's credentials
during the session since all the messages exchanged will contain the session cookies.

Figure 70: Client-Side Cookies

This figure shows HTTP message examples for a server response that sets a cookie, and a
client request where a cookie is automatically added to the HTTP request.
Cookies have the following variables:

Name and value: The actual cookie content

Expiration date: Determines the validity period of the cookie

Path: The application path that the cookie is valid for

Domain: The domain that the cookie is valid for

Secure flag: If set, the cookie is only sent over a secure connection (HTTPS)

HttpOnly flag: If set, the cookie is not accessible by JavaScript

Path and domain are used for letting the browser know to which applications a cookie shall be
sent.

© Copyright. All rights reserved. 44

 Lesson: Understanding Injection Vulnerabilities

Figure 71: Cookie Manipulation

Since cookies are stored on the client side, there is a possibility that they have been edited or
modified. This is why a server cannot trust the input provided by cookies and cookies should
not hold sensitive information.
Example 1: In this example, the cookie stores authorization information for the authenticated
user. In the first cookie, the user has no admin rights, but after a simple modification of his
cookie, he becomes an administrator for the session. Such cookie manipulations can be easily
done by commonly available browser plug-ins.
Example 2: A naïve shopping cart application is storing pricing information in cookies. As
such, attackers can manipulate the actual prices.
Part of the application's cookie is
item1_ID=12369&item1_pr=27,95&item2_ID=10334&item2_pr=19,95 , resulting in a
total amount of $47.90.
The manipulated cookie contains
item1_ID=12369&item1_pr=0,95&item2_ID=10334&item2_pr=1,95 , resulting in a
total amount of $2.90.

Figure 72: Cookies - Recommendations

Recommendations for cookies:

Use server-side cookies for application-related session data instead of client-side cookies.

© Copyright. All rights reserved. 45

Unit 2: Secure Programming

- Class CL_BSP_SERVER_SIDE_COOKIE can be used to manage server-side cookies.

For anonymous sessions (where no user is authenticated but a technical user is used):
Make use of the parameter SESSION_ID (only referring to the user name is
ambiguous).
- No size restrictions as cookie data is stored in database
- Inaccessible to malicious users

Never store confidential information in cookies.

With regard to the recommendation for anonymous sessions:

If you link server-side cookies to anonymous users, cookie data can be accidentally shared
between different users who use the same anonymous technical user.
For more information, see http://help.sap.com/saphelp_nw70ehp1/helpdata/en/9f/
389f2d3bdf44e88b51f203a4178ae7/content.htm .
The code snippet shows how a server could store sensitive pricing information on the client
side, which in turn can be manipulated by the attacker.
Client-side cookies should be avoided if there is interest to the client (user) in changing their
content such as the pricing information. In contrast to this, session identifiers may be
contained in a client-side cookie as the client (user) has no interest in changing it, and also
wants to have his own session.

Figure 73: Other Relevant Web Technologies - JavaScript

JavaScript is a client-side interpreted language. The scripts are imbedded into HTML pages
and interpreted by browsers.
Overview of JavaScript:

Interpreted language but all modern browsers compile it on the fly

Programming code written by web application developers

Delivered as part of the HTML page and executed by the browser (which is a problematic
mixture of data and active, executable code)

JavaScript is useful for the following:

Creating interactive pages (that, for example, react to mouse or click events)

© Copyright. All rights reserved. 46

 Lesson: Understanding Injection Vulnerabilities

Handling asynchronous events

Offloading some of the backend checks to the browser (for example, checking if the user
has filled all the form inputs)

Figure 74: Overview of Relevant Web Technologies: JavaScript

JavaScript has access to everything in the page, which includes the following:

All the content

All the cookies coming from the same domain as the JavaScript, unless the HttpOnly flag is
set to prevent this access

The purpose of embedding JavaScript is to add more dynamicity and interactivity to the web
page. Since this language is interpreted on the client side, the execution can be compromised
and non-controlled.

Figure 75: JavaScript - Same Origin Policy

This figure explains an important security concept of browsers, namely that content of
different domains (sites) must be strictly separated from each others. This concerns the
following:

Access to cookies (on the client side)

Transmission of cookies from the client to the correct servers (where they originated)

Access to content of other pages that come from other domains (again, on the client)

Any compromise of this security concept on the browser (client)-side has an impact on
security, and specially crafted websites that leverage such browser vulnerabilities will come
up quickly.
For more information, see the following references:

http://en.wikipedia.org/wiki/Same_origin_policy

http://www.w3.org/Security/wiki/Same_Origin_Policy

© Copyright. All rights reserved. 47

Unit 2: Secure Programming

Figure 76: Web-based Attacks - HTTP Request Tampering

An actual issue is the Java floating point issue in which some header fields can have float
numbers attached, causing denial of service to the entire AS Java.

Figure 77: Web-based Attacks - HTTP Response Tampering

Cross-Site Scripting

Figure 78: Cross-Site Scripting

In a typical cross-site scripting (XSS) attack, malicious JavaScript content is loaded from/
reflected by domain 1 and sensitive cookies are sent to domain 2.
XSS doesn't need an authenticated session and can be exploited when the vulnerable website
doesn't parse or validate the inputs properly. An attacker can send inputs via any kind of

© Copyright. All rights reserved. 48

 Lesson: Understanding Injection Vulnerabilities

client-side inputs like cookies, form fields, or URL parameters. These can then be written back
to the screen, executed remotely, or persisted in the database.

Figure 79: Cross-Site Scripting Simple Example (Reflected XSS)

XSS problem:

Web applications accept user input which is displayed on subsequent HTML pages (either
immediately or some time after).

If the user input is not parsed, malicious JavaScript can be injected into HTML pages which
are a mix of data and code.

The example is a "reflected XSS" attack where malicious input is directly printed on an output
page. Malicious input is typically a JavaScript code that accesses sensitive content of the
attacked website.
What happens quite often is that a given library or tool is vulnerable to XSS, such as a content
management system, causing all websites that make use of it to be vulnerable.
To solve the problem, one possibility is to disable JavaScript (through browser settings or
plugins such as NoScript) but this makes many pages unusable because they need it for
dynamic content/interaction.
Again, it should be noted that XSS is programming language-independent.

Figure 80: Cross-Site Scripting - Introduction

Input validation refers to checking the data type, format, length, and content of input data
provided by users to ensure they match with what has been described in the software
specification. It helps to prevent other errors as well, such as format conversion errors.

© Copyright. All rights reserved. 49

Unit 2: Secure Programming

Output encoding refers to creating safe representations of data that results from user input
before using this data in another context. The context could be the display of such data in a
HTML page which requires encoding of special characters.

Figure 81: Types of XSS

There are two types of XSS, as follows:

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

Figure 82: Cross-Site Scripting - Example (Stored XSS)

This is an example of a stored XSS attack where the malicious code (JavaScript) is stored in a
database and presented to all other users that visit the forum entry at a later point in time.
Such forum functionality (discussion lists, consumer feedback, and so on) exists on almost
every website and must be secured against XSS.
This kind of attack can occur in all kinds of applications that accept, store, and echo user
input, such as news pages, bookstores, and so on.

Figure 83: Cross-Site Scripting - Impacts

Because the JavaScript language can access all the properties of the browser including
cookies, it is then quite easy to access authentication information. Also, the scripts can

© Copyright. All rights reserved. 50

 Lesson: Understanding Injection Vulnerabilities

display any kind of alert or logging messages that can mislead the users and invite them to
provide personal sensitive information.
XSS impacts can be huge and can cause a lot of damage for companies. Here are some
examples:

Access to authentication credentials such as cookies, username, and password

For normal users, this will lead to:
- Access to personal data (credit card, bank account)
- Access to business data (bid details, construction details)
- Misuse of account (order expensive goods)

For highly privileged users, this will lead to:

- Control over web application
- Control/access web server machine
- Control/access backend/database systems

Access to users' machines

- Use ActiveX objects to control machine (install botnet client, keylogger, and so on)
- Upload local data to attacker's machine

Denial of service
- Crash users' browsers, pop-up-flooding, redirection

Spoil public image of company

- Load mainframe content from "other" locations
- Redirect to dialer download

The most severe XSS attacks involve disclosure of the user's session cookie, allowing an
attacker to hijack the user's session and take over the account. Other damaging attacks
include the disclosure of end user files, installation of trojan horse programs, redirection of
the user to some other page or site, or modification of the presentation of content. An XSS
vulnerability allows an attacker to modify a press release or news item which could affect a
company's stock price or lessen consumer confidence. An XSS vulnerability on a
pharmaceutical site could allow an attacker to modify dosage information resulting in an
overdose.
An ActiveX control can be an extremely insecure way to provide a feature. Because it is a
Component Object Model (COM) object, it can do anything the user wants from that
computer. It can read from and write to the registry, and it has access to the local file system.
From the moment a user downloads an ActiveX control, the control may be vulnerable to
attack because any web application on the internet can repurpose it; that is, use the control
for its own ends whether sincere or malicious. Developers should take precautions when they
write a control to help avert an attack.
For more information about ActiveX controls, see http://msdn.microsoft.com/en-us/library/
aa752035%28v=vs.85%29.aspx .

© Copyright. All rights reserved. 51

Unit 2: Secure Programming

Figure 84: Cross-Site Scripting Vulnerability in ABAP Code

ABAP code can be vulnerable to cross-site scripting. Here are some examples:

Plain HTML pages produced from ABAP and Business Server Pages (BSP)

Pages using the HTMLB taglib

Pages produced with ITS BusinessHTML

BSP

BSPs allow this mixture of HTML tags and ABAP code. Java Server Pages (JSP) work the
same way with HTML and Java. As such, XSS vulnerabilities in BSP and JSP are very similar.

Figure 85: Cross-Site Scripting - Countermeasures (1/3)

The general idea of the countermeasures is as follows:

Prevent the injection of executable code in the web page; that is, address the problem of
HTML pages being a mixture of code and data

Find a "harmless" representation of user input

The input validation activities are almost identical to what has been discussed previously
about injection vulnerabilities. Unwanted input has to be filtered.
SAP NetWeaver implements a HTTP filter against only simple XSS attacks:

Pattern-based blacklisting of dedicated patterns

Configurable by default blocking patterns like <script> and alert

Cannot guarantee full protection due to its blacklisting nature; applications must be
developed securely

© Copyright. All rights reserved. 52

 Lesson: Understanding Injection Vulnerabilities

Figure 86: Cross-Site Scripting - Countermeasures (2/3)

Ensure that the provided input matches what the application expects.

Figure 87: Cross-Site Scripting - Countermeasures (3/3)

With regard to output encoding, another guideline is to 'encode late' when you are sure about
the output channel for which you need to encode. Early encoded data may be inadvertently
used in other output channels at a later point in time.

Figure 88: Overview of ABAP Output Encoding Technologies

The basic technology for output encoding in ABAP is the SAP Output Encoding Framework
(class CL_HTTP_UTILITY). This framework can be used directly by calling the methods of that
class, and is also the basis of any of the web front-end frameworks where the developer does
not need to call the class methods directly. It has the following characteristics:

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 front-end frameworks:

- Web Dynpro ABAP
- BSP extensions (HTMLB, XHTMLB, and PHTMLB)
- ITS BusinessHTML (BHTML)

© Copyright. All rights reserved. 53

Unit 2: Secure Programming

Developers should use the encoding framework (call the class methods) if they need to
produce HTML code that will not be encoded automatically at a later point in time. Example:
Creation of HTML code with user input for an email. Here, the developer cannot rely on the
framework but needs to encode the data manually.
For all of the front-end frameworks (Web Dynpro ABAP, BSP, and ITS businessHTML), the
developer can ensure output encoding much more easily. CL_HTTP_UTILITY can also, of
course, be used in BSP or ITS pages but the recommended solution is to use the page
directives, which are explained later.
The web front-end frameworks have the following characteristics:

Web Dynpro ABAP

- Does not require developers to 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) (see next figures)

- Various encoding methods must be used in the HTML page

For more information, see the following documentation:

Web Dynpro ABAP

BSP Pages

ITS BusinessHTML

Figure 89: Cross-Site Scripting - Recommendations for Web Dynpro ABAP

Input Validation
Web Dynpro ABAP (WDA) automatically performs some initial input validation (type check
like data type and length), but CANNOT perform a semantic check (for example, of a string
value supposed to contain a ZIP code). As a result, the semantic check of input data still
needs to be done by the developer to prevent SQL injection attacks if the input is later on used
in dynamic SQL queries.

© Copyright. All rights reserved. 54

 Lesson: Understanding Injection Vulnerabilities

Output Encoding
This is done automatically by the framework and the developer does not need to do anything
in that regard.

Isolation of WDA Applications

WDA applications are not isolated by default; that is, scripts running in the same environment
(such as in the Portal) can access sensitive data from one another. Isolation of WDA
applications deals with specific security parameterization for each application. To isolate
security-critical applications, set the WDA parameter WDPROTECTEDAPPLICATION = X
which specifies that the application should run with SSL (HTTPS) and that no scripting
between the portal and the application is allowed.
For more information about the WDA parameter, see https://help.sap.com/viewer/
7b44f2a7728810148a4b1a83b0e91070/7.5.9/en-US/
88fd00618e7e477592b19fd784e19aae.html .

Figure 90: Cross-Site Scripting - Recommendations for Non-BSP Extensions (1/2)

Use the class CL_ABAP_DYN_PRG for non-BSP extension files (HTMLB, XHTMLB, or
PHTMLB) whenever the developer produces HTML code which will not be encoded later on by
one of the previously introduced frameworks (BSP, ITS, or WDA).
The ABAP built-in function ESCAPE gets the content of the character string in text, and hides
certain special characters with escape characters according to a rule specified in format. For
more information, see https://help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/
abenescape_functions.htm .
CL_ABAP_DYN_PRG is the successor of CL_HTTP_UTILITY. It offers different methods
(ESCAPE_XSS_XML_HTML, *_URL, *_CSS, and *_JAVASCRIPT), and which one should be
used depends on the HTML context to which the data is written.
For example:

ESCAPE_XSS_XML_HTML
- Used if the output data is used between or inside of tags, but not in a URL, style, or
script
- Has an optional exporting parameter to prevent numeric characters being escaped

ESCAPE_XSS_URL
- Used if the output data is used in a URL or style

ESCAPE_XSS_JAVASCRIPT / ESCAPE_XSS_CSS
- Used if the output data is used in a script/CSS context

© Copyright. All rights reserved. 55

Unit 2: Secure Programming

For more information about the SAP Encoding Functions for AS ABAP, see http://
help.sap.com/saphelp_nw73/helpdata/en/a6/87890ae991441b89bf418d0198ddcc/
frameset.htm .

Figure 91: Cross-Site Scripting - Recommendations for Non-BSP Extensions (2/2)

In the example, the method ESCAPE_XSS_XML_HTML is used, and the output is written into
the result HTML page (target context = HTML).
ESCAPE_XSS_XML_HTML prevents the injection of JavaScript into user inputs. The user
input is not interpreted as a script but as a text field. Any instances of < and > are encoded to
&lt; and &gt; and are displayed in the browser without any interpretation by the client
browser.

Figure 92: Cross-Site Scripting - Recommendations for BSP Extensions (1/2)

To prevent XSS in BSPs, use the attribute forceEncode in the BSP page directive.
The following encoding schemas can be used with the forceEncode attribute:

html

url

javascript

In order to prevent any interpretation of malicious user inputs, forceEncode=html is set at the
beginning of the BSP. As a result, any input <%= input %> is HTML encoded.
In order to force the interpretation of user input as URL or JavaScript, the ABAP developer
has to mention it explicitly via <%url = input%> or <%javascript = input%>.

© Copyright. All rights reserved. 56

 Lesson: Understanding Injection Vulnerabilities

If you use forceEncode="url" at the page level then every output is URL-encoded even if it is
used in plain HTML. Of course, this is not recommended.

Figure 93: Cross-Site Scripting - Recommendations for BSP Extensions (2/2)

An alternative for the BSP extensions HTMLB, XHTMLB, and PHTMLB is to set "forceEncode"
in the HTMLB content tag.
The attribute forceEncode has to be set to "ENABLED". This switches encoding on for all
other HTMLB tags in the page.
For more information about forceEncode, see http://help.sap.com/saphelp_nw73/
helpdata/en/a6/87890ae991441b89bf418d0198ddcc/frameset.htm .

Figure 94: Cross-Site Scripting - Recommendations for BHTML

In BHTML pages, it is recommended to use specific functions to sanitize user input. The
following BHTML encoding functions are recommended to prevent XSS attacks:

xss_url_escape

xss_html_escape

xss_wml_escape

xss_js_escape

xss_css_escape

The automatic mechanism can be temporarily switched off to use one of the dedicated
encoding methods, for example, if the output context is a HTML tag containing JavaScript.

© Copyright. All rights reserved. 57

Unit 2: Secure Programming

WML stands for Wireless Markup Language.

Cross-Site Request Forgery

Figure 95: Cross-Site Request Forgery

Cross-site request forgery (XSRF or CSRF), also known as a one-click attack or session riding,
is a type of malicious exploit of a website whereby unauthorized commands are transmitted
from a user that the website trusts. Unlike cross-site scripting (XSS) which exploits the trust a
user has for a particular site, XSRF exploits the trust that a site has in a user's browser.

Figure 96: Cross-Site Request Forgery Introduction

During XSRF attacks, web applications perform actions based on input from trusted and
authenticated users without requiring the user to authorize the specific action.
The root causes of XSRF attacks are:

Cookies that often hold authentication credentials are automatically sent to the server

URLs that are easy to guess for the attackers

© Copyright. All rights reserved. 58

 Lesson: Understanding Injection Vulnerabilities

Figure 97: XSRF Sample Attack Scenario (1/4)

The first part of this XSRF example explains the legitimate authentication of a user (the future
victim) to a website vulnerable to XSRF.

Figure 98: XSRF Sample Attack Scenario (2/4)

The second part of this XSRF example shows the victim visiting a malicious web page
prepared by the attacker.

© Copyright. All rights reserved. 59

Unit 2: Secure Programming

Figure 99: XSRF Sample Attack Scenario (3/4)

In part 3 of this scenario, the prepared HTML web page returned to the victim contains an IMG
tag. Upon reception of the web page, the victim's browser automatically calls the URL
provided in the SRC attribute of the IMG tag. However, the URL of the malicious web page
does not point to an image but makes a call to the vulnerable website to which the victim was
authenticated in the beginning. Note that the attack only works if the user session at the
vulnerable website (in this case, worldbank.com) is still valid. Only in this case, the
authentication cookie will be automatically sent by the browser to the vulnerable website .

Figure 100: XSRF Sample Attack Scenario (4/4)

As a result of the previous call, unwanted action was executed in the vulnerable website.
A few quick points about SXRF attacks:

Is the IMG tag approach the only way to send malicious commands?
- No, there are many ways in which a malicious website can transmit problematic
commands; image tags, hidden forms, and JavaScript XMLHttpRequests, and so on.

Does the attack work only via a GET request?

© Copyright. All rights reserved. 60

 Lesson: Understanding Injection Vulnerabilities

- No, other HTTP methods can be used as well.

Are we safe if we switch to POST?

- No, POST requests can be forged as well.

Would a confirmation step help?

- Not by itself, since the result from the confirmation can be forged as easily as the prior
request.

Would an additional "XSRF cookie" help?

- No, since the cookie is submitted by the browser automatically and the backend cannot
determine whether the user action is intended or not.

Would evaluating the HTTP "Referrer" help?

- Yes, if the existence of the HTTP Referrer could be relied upon (which is currently not
the case due to browser filtering, for example for privacy reasons).

Is XSRF also relevant for RESTful services?

- Yes, it is. API providers such as Google (with the Google Web Toolkit GWT) have
introduced dedicated services to obtain an anti-XSRF token. For more information, see
http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html .

Figure 101: Cross-Site Request Forgery - Recommendations

With most countermeasures against XSRF, the initial request is not secured yet because a
regular user must be allowed access to the application.
If a token-based countermeasure is used, the XSRF protection token which is contained first
in the page is returned to the user's browser as a result from that initial request. From then
on, all follow-up requests are protected by the countermeasure as the attacker will not be able
to create a valid request.
However, the initial request could have been requested from the application server as a result
of a successful attack. Because the countermeasure cannot protect this initial request, the
application developer needs to ensure that the initial request does not immediately lead to
any state change or sensitive action.
What this also means is that the application server cannot distinguish "one-click-actions"
from XSRF attacks as both would lead to an immediate state change upon start of the
application. Therefore, the use of such actions must be evaluated more carefully.
The following are some XSRF countermeasure recommendations:

Applications must use the available anti-XSRF mechanism.

© Copyright. All rights reserved. 61

Unit 2: Secure Programming

For ABAP in general, no manual efforts are required on code level:

- The mechanism is automatically used in WebDynpro ABAP.
- The mechanism can be enabled via checkbox in BSP/ITS.

Developers must avoid sensitive actions (= state changes) at application start and in all
automatically reachable pages (= pages reachable without user interaction).
All other pages are protected by the anti-XSRF mechanism.

Some examples of sensitive actions or state changes are as follows:

Writing data to the DB

Starting workflows

Starting resource-intensive activities (denial of service)

The following scenario is an example of avoiding state changes on a start/entry page:

The workflow for approving leave sends e-mails to managers with a link for approval. The
leave must not be approved directly upon clicking the link. The application can be more
secure if we display a form with leave information first when the application is started and
then the user is able to choose either the Approve or the Cancel button. The leave is not
actually approved until the Approve button is clicked.

Figure 102: Cross-Site Request Forgery - Countermeasure Details

As a countermeasure against XSRF, one possible solution is to use secure tokens in the
cookies in order to authenticate a transaction. Instead of putting two parameters in the
request (destination and sum) we add a unique hash key (token) that authenticates the
transaction initiated by the user. Since the attacker does not know the value of the token, he
cannot replay the request. The secure token is usually a huge, impossible-to-guess random
number.
Note that POST is better then GET but it cannot prevent XSRF attacks on its own. Even
though POST requests cannot be issued by forging link URLs, an attacker can set up an
intermediate website to which he can direct the victim. An attacker could craft a web form on
site A and, using JavaScript, auto-submit the form to a target location of site B. If the
application containing the XSRF payload uses a browser component that runs in the local
zone, then sending remote POST requests to any website is possible using XMLHTTP or
similar objects.

© Copyright. All rights reserved. 62

 Lesson: Understanding Injection Vulnerabilities

Figure 103: Example: Session Identifier Used as Additional Form Variable

The HTML snippet in this figure shows what an anti-XSRF secure token looks like. It is a HTML
form parameter in which the value is random and not easy to guess by the attacker as
compared to, for example, the account number of a bank transfer.

Figure 104: Cross-Site Request Forgery - Countermeasure Details: Don'ts

Confirmation pages as well as HTTP POST requests can be forged by means of creating
automatic HTML forms on faked websites.

Figure 105: Cross-Site Request Forgery - Recommendations for ABAP (1/2)

Developers do not need to create an anti-XSRF token mechanism themselves; this is done by
the respective ABAP front-end frameworks.
For ABAP, in general, no manual efforts are required at the code level:

The mechanism is automatically used in Web Dynpro ABAP

The mechanism can be enabled via checkbox in BSP/ITS

© Copyright. All rights reserved. 63

Unit 2: Secure Programming

For BSP applications, developers need to select the XSRF Protectioncheckbox. Furthermore,
select the Start BSP checkbox on any page with flow logic or on the controller so that it is
reachable without the anti-XSRF token. These pages must not result in any state change.
Technically, the mechanism relies on JavaScript code that is called at the onLoad event and
enhances every link and web form with the token.
It injects a hidden input field containing the XSRF token which works whenever you use simple
<forms> or hrefs. The BSP mechanism does not work if URLs are invoked via JavaScript
which cannot be reached by DOM manipulation. This case will require manual efforts.
XSRF protection is disabled by default because activation can lead to problems for existing
applications. Extensive application testing has to be done before enablement.

Figure 106: Cross-Site Request Forgery - Recommendations for ABAP (2/2)

Developers must avoid any state changes at application start, that is, on pages that cannot be
protected by the anti-XSRF token.
"Subsequent page" refers to any web page that is reachable without user interaction, for
example, through automatic redirects at application start.

Figure 107: Web-based Attacks - Wrap-up

Validate input
- The entire HTTP request must be considered as input, including HTTP headers,
cookies, and web forms
- Client-side checks cannot be trusted; always re-do the check on the server side
- Follow the advice given in the section on injection attacks (whitelist vs. blacklist, and so
on)

Encode output
- User input must not become executable; use the existing mechanisms for output
encoding

Use strong session management

- Use the session management provided by the SAP NetWeaver platform and do NOT
build your own session management

© Copyright. All rights reserved. 64

 Lesson: Understanding Injection Vulnerabilities

- Use short sessions (achieved through cookie expiration)

Inaccurate Programming

Figure 108: Inaccurate Programming - Introduction

Vulnerabilities related to inaccurate programming may happen due to lack of knowledge of

the programming language specifics, incorrect usage of functions or methods from the
programming libraries, tight development schedules, or simply a lack of security awareness
from the developers. Beside application bugs, inaccurate programming can lead to very
dangerous threats like buffer overflows or exploitation of non-protected exceptions.

Figure 109: Backdoors - Introduction

A backdoor in a computer system is a method of bypassing normal authentication, securing

remote access to a computer, obtaining access to plaintext, and so on, while attempting to
remain undetected.
The backdoor may take the form of an installed program or may subvert the system through a
rootkit, which is software that enables continued privileged access to a computer while
actively hiding its presence from administrators by subverting standard operating system
functionality or other applications.
Developers sometimes use backdoors not with malicious intent but as a rescue entry that
enables them to access all the functionalities of the application without any restriction.
However, even if not created with malicious intent, it can have a severe impact on the system
security if such undocumented code is used by attackers.
Backdoors typically provide means to:

Extract specific or arbitrary data

Call specific or arbitrary functions

Subvert authentication

© Copyright. All rights reserved. 65

Unit 2: Secure Programming

Subvert authorization checks

Inject code into the system and execute it on the fly

Typical properties of backdoors include:

Often hidden, disguised, or obscured

Activation on-demand

Activation time-triggered

Activation on specific events

Code injection possibilities (for example, detected through code scanning) themselves are
not rated as backdoors, even though sometimes they can be used to CREATE backdoors.

Figure 110: Backdoors - Examples

Here are some examples of what can be considered as a backdoor in ABAP:

Using conditions on sy-uname:

- If the username matches the hard-coded value, the program behavior changes, for
example to grant additional privileges
- Do not make use of hard-coded credentials

Using undocumented OK codes:

- If the OK code is entered, programs enter a special mode, such as skipping
authorization checks

Using hidden input fields, such as invisible (transparent) buttons on web pages

What is common to these examples is that they realize some functionalities that are not
documented for the customer/user. This is not acceptable even if the original purpose of this
coding is not malicious. When used by an attacker, a seemingly harmless mechanism
originally developed for debugging or testing purposes may become dangerous and harmful
from a security perspective.

© Copyright. All rights reserved. 66

 Lesson: Understanding Injection Vulnerabilities

Figure 111: Not Failing Securely ('Failing Open') - ABAP Example

In this example, a developer has made the explicit choice of not failing securely ("failing
open"). If an authorization check cannot be done on a remote system, for example the remote
connection for target destination DEST cannot be established, the program flow continues as
if the authorization check has succeeded.
Here, an authority check is done on a remote system. All return codes 1 to 4 indicate an
exceptional case. As explained in the comment, the developer decided to grant authorization
in all of the cases.
Of course, this code is just a sample example but it nevertheless shows the main idea of
"failing open" in which the system allows access and the program continues.

Figure 112: Failing Open vs Failing Closed - Recommendations

Ensure that error situations are properly handled. In the case of doubt, go for the secure
solution.
There are situations where it is more appropriate to fail open and at other times more
appropriate to fail closed. Making incorrect security assumptions could lead to logical
security flaws and serious vulnerabilities. During application development, explicit error
handling behaviors have to be well planned. We need to analyze all these situations in our
applications and also have a good understanding of the core security concepts.
However, in many cases, it is often a design decision how an application should behave by
default, it is sometimes usability vs. security.

© Copyright. All rights reserved. 67

Unit 2: Secure Programming

Tools to Detect Security Vulnerabilities and Sanitization Techniques

Figure 113: Tools for Detecting Security Vulnerabilities

There are a lot of standard tools and logs in the SAP NetWeaver infrastructure that we can
use to check for security vulnerabilities in the system.
Here are some examples:
SAP NetWeaver Application Server, add-on for code vulnerability analysis, also known as the
Code Vulnerability Analyzer (CVA), is a product that carries out static analysis of ABAP
source code and reports possible security risks. CVA is integrated in the ABAP Test Cockpit
(ATC), the central infrastructure for functional, performance and security code checks.
Change documents track changes to an SAP object, for example, financial accounting data.
When changes are logged, you can find out what was changed, when it was changed, and how
the change was made. The change documents sometimes simplify error analysis and are
used to facilitate auditing.
Version management records changes made to repository objects such as programs and
Data Dictionary objects.
The authorization trace helps to analyze authorization issues. From the trace, you can see the
authorization objects, the field values which are handed over for authorization check, and the
return code. If the return code is 0, the authorization check is successful.
The security audit log collects information about security-related events and helps you to
monitor the activities in the system.
For more information about these tools and logs, see the SAP documentation or the SAP
Education course ADM950: Secure SAP System Management.

Figure 114: Sanitization of Security Vulnerabilities

Sanitization and various security vulnerabilities have already been discussed earlier. More
examples on escaping and quotes are shown here.

© Copyright. All rights reserved. 68

 Lesson: Understanding Injection Vulnerabilities

Figure 115: Sanitization Using Class CL_ABAP_DYN_PRG

The class CL_ABAP_DYN_PRG can be used to implement input checks.

Given a type c or string value that is used as a literal value of type string, method
cl_abap_dyn_prg=>quotes_str escapes the backquotes by doubling them and adds
backquotes around the value.
The input value with escaped backquotes is returned as a string.
Similar methods are:

cl_abap_dyn_prg=>escape_quotes: Essentially the same, but single quotes are escaped

rather than backquotes.

cl_abap_dyn_prg=>quote_str: Also essentially the same, but a backquote is put in front of

the value, backquotes within the value are escaped, and a backquote is appended at the
end of the value.

The method cl_abap_dyn_prg=>escape_quotes_str must not be called if the quotes have

already been escaped, for example, by a REPLACE statement.

Figure 116: Excursion: Type C Versus Type STRING

Figure 117: Sanitization Using Class CL_ABAP_DYN_PRG - Escaping Methods for ABAP and Open SQL

© Copyright. All rights reserved. 69

Unit 2: Secure Programming

The pure escaping (last two examples) can also be achieved through the REPLACE
statement.

Figure 118: Excursion: Web Techniques

In the example, to create an HTML page that displays Is a<b? , just writing Is a<b? in the
HTML source code would lead to a syntax error because the < character is interpreted as the
beginning of a HTML tag.
Therefore it must be escaped: Is a&lt;b?
There are quite a lot of similar cases for HTML, XML, and other markup languages.
For JavaScript, completely different escaping is required.
Each context requires its own escaping.

Figure 119: Sanitization Using Class CL_ABAP_DYN_PRG - Escaping Methods for Web Techniques (Cross-Site
Scripting)

Note: XSS escaping can also be achieved through the built-in function ESCAPE (SAP_BASIS
>= 7.31).
This function gets the content of the character string in text, and hides certain special
characters with escape characters according to a rule specified in format.
For more information about the built-in function ESCAPE, see https://help.sap.com/doc/
abapdocu_750_index_htm/7.50/en-US/abenescape_functions.htm .

© Copyright. All rights reserved. 70

 Lesson: Understanding Injection Vulnerabilities

Figure 120: Sanitization Using Class CL_ABAP_DYN_PRG - Check Methods

CL_ABAP_DYN_PRG supports the following types of checks:

Whitelist check

Validity check for: DB table or view names, DB column names, variable names

Integer check

Char literal check

Figure 121: Sanitization Using Class CL_ABAP_DYN_PRG - Hints

The following are some important SAP notes related to CL_ABAP_DYN_PRG:

SAP Note 1487337 - Downport CL_ABAP_DYN_PRG (initial release of the class)

SAP Note 1852318 - Overview on the availability of the class CL_ABAP_DYN_PRG

LESSON SUMMARY
You should now be able to:

Understand injection vulnerabilities

Explain web-based vulnerabilities

Understand inaccurate programming vulnerabilities

Describe tools to detect security vulnerabilities and sanitization techniques

© Copyright. All rights reserved. 71

 Unit 2

Learning Assessment

1. Which of the following describes the characteristics of injection vulnerabilities?

Choose the correct answer.

X A Injection vulnerabilities are affected by user input which is processed without being
validated first.

X B Injection vulnerabilities are all web-based threats.

X C Injection vulnerabilities bypass the SAP authorization concept.

X D Injection vulnerabilities can be fixed by implementing cross-site scripting.

2. Which of the following are injection vulnerabilities?

Choose the correct answers.

X A SQL injection

X B Code injection

X C Cross-site request forgery injection

X D Command injection

3. Cross-site Request Forgery is a type of malicious exploit of a website whereby

unauthorized commands are transmitted from a user that the website trusts.
Determine whether this statement is true or false.

X True

X False

4. Not failing securely is a typical vulnerability resulting from inaccurate programming.

Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 72

 Unit 2

Learning Assessment - Answers

1. Which of the following describes the characteristics of injection vulnerabilities?

Choose the correct answer.

X A Injection vulnerabilities are affected by user input which is processed without being
validated first.

X B Injection vulnerabilities are all web-based threats.

X C Injection vulnerabilities bypass the SAP authorization concept.

X D Injection vulnerabilities can be fixed by implementing cross-site scripting.

You are correct! Injection vulnerabilities are affected by user input which is processed
without being validated first. Refer to the lesson ‘Understanding Injection Vulnerabilities’
for more details.

2. Which of the following are injection vulnerabilities?

Choose the correct answers.

X A SQL injection

X B Code injection

X C Cross-site request forgery injection

X D Command injection

You are correct! SQL injection, code injection, and command Injection are examples of
injection vulnerabilities. Refer to the lesson ‘Understanding Injection Vulnerabilities’ for
more details.

3. Cross-site Request Forgery is a type of malicious exploit of a website whereby

unauthorized commands are transmitted from a user that the website trusts.
Determine whether this statement is true or false.

X True

X False

You are correct! Cross-site Request Forgery is a type of malicious exploit of a website
whereby unauthorized commands are transmitted from a user that the website trusts.
Refer to the lesson ‘ Understand injection vulnerabilities’ for more details.

© Copyright. All rights reserved. 73

Unit 2: Learning Assessment - Answers

4. Not failing securely is a typical vulnerability resulting from inaccurate programming.

Determine whether this statement is true or false.

X True

X False

You are correct! Not failing securely is a typical vulnerability resulting from in-accurate
programming. Refer to the lesson ‘ Understand inaccurate programming vulnerabilities’
for more details.

© Copyright. All rights reserved. 74

 UNIT 3 Security Testing Tools

Lesson 1
Describing Security Testing Tools 76

Lesson 2
Explaining ATC and CVA 79

UNIT OBJECTIVES

Describe security testing tools

Explain ATC and CVA

© Copyright. All rights reserved. 75

 Unit 3
Lesson 1
Describing Security Testing Tools

LESSON OBJECTIVES
After completing this lesson, you will be able to:

Describe security testing tools

Security Testing Tools

Figure 122: Application Security Testing Solutions at SAP

In the past, application testing of the running application (often called dynamic application
security testing or DAST) was used to evaluate the security. This is an outside-in approach,
where you look at the installed application looking for potential vulnerabilities. With DAST it is
often difficult to figure out all the entry points into the application.
Another approach is to review the sources for security vulnerabilities (static application
security testing or SAST). This is an inside-out approach which involves using the source code
to identify potential issues. This can help developers not to fall into security traps already at
the time they create the source code. However, SAST does not enable you to find insecure
usage of a system due to incorrect configuration of security mechanisms.
In this course, we are focusing on SAST using CVA as the tool. We will discuss only the ABAP
side.

© Copyright. All rights reserved. 76

 Lesson: Describing Security Testing Tools

Figure 123: SAP NetWeaver Application Server Add-on for Code Vulnerability Analysis: Feature Set

SAP NetWeaver Application Server add-on for code vulnerability analysis (CVA) has the
following features:

Ensures security and compliancy of custom developed code

Supports the developer's requirements in his daily work in a convenient way

Supports automated scanning, notifications on issues, and workflows for exemptions

Figure 124: ABAP Test Cockpit

The ABAP Test Cockpit (ATC) is a framework integrated into the ABAP Workbench. It
considerably simplifies the handling of the tests required during development. The ATC allows
you to execute and display results for various tests on development objects by calling other
tools like SLIN. It also provides exemption handling mechanisms to all test engines. ATC is
fully integrated into the development environment and transport tools, along with instant
navigation, documentation, fix recommendation, and more.

© Copyright. All rights reserved. 77

Unit 3: Security Testing Tools

Figure 125: Overview of Code Check Tools in ATC

SAP Code Inspector (SCI) is a tool for checking repository objects regarding performance,
basic security, syntax, and adherence to naming conventions. The Code Inspector is a generic
tool, used to check static objects. It provides a flexible extension mechanism to be used as a
testing framework by customers, partners, and SAP to develop code-related checks
SLIN is the ABAP Program Extended Syntax Check tool, which is used to perform static
checks that are too time-consuming for the normal syntax check. It is basically performs sort
of a code review of the program, checking for package errors and executing tests that are too
time-consuming for standard checks
Syntax checks are integrated checks of the IDE which do basic syntax checks of a program.
Code Vulnerability Analyzer (CVA) allows the scanning of customer-created ABAP source
code for code patterns indicating security vulnerabilities, taking into account contextual
information from the code unit of the source code.

LESSON SUMMARY
You should now be able to:

Describe security testing tools

© Copyright. All rights reserved. 78

 Unit 3
Lesson 2
Explaining ATC and CVA

LESSON OBJECTIVES
After completing this lesson, you will be able to:

Explain ATC and CVA

ATC and CVA

Figure 126: Motivation for ABAP Test Cockpit

ATC is an ABAP check framework which allows the running of static checks and unit tests for
ABAP programs.
ATC combines quick ad-hoc checking by the developers and centralized quality checking in
one single framework.

Figure 127: ATC Architecture Overview

© Copyright. All rights reserved. 79

Unit 3: Security Testing Tools

ATC is fully integrated into the development environment and transport tools, along with
instant navigation, documentation, fix recommendations, and more.
ATC allows you to execute and display results for various tests on development objects by
calling other tools like SLIN. It also provides exemption handling mechanisms to all test
engines. SLIN is the ABAP Program Extended Syntax Check tool used to perform static
checks on your programs.
ATC is also available in Eclipse (ADT). The ATC in Eclipse is tightly integrated with the ABAP
developer tools so that you can run ATC checks during development from the Project
Explorer or editor.
In this course, we will use the ATC in the ABAP Workbench.

Figure 128: Working With ATC - ABAP Workbench

ATC checks can be done for single objects or groups of objects. If ATC is started from a
package then it checks all development objects in the package and the package hierarchy.
ATC can also be run on ABAP unit tests as part of the checks.

Figure 129: ATC Integrated Into the ABAP IDE

To perform an ATC check in the development system:

1. Choose a development object, for example, a program or package from the navigation
panel in SE80 (Object Navigator).

2. Open the context menu and choose Check ABAP Test Cockpit .

3. The ATC reports the progress in the status line. It presents its findings automatically when
it is done.

© Copyright. All rights reserved. 80

 Lesson: Explaining ATC and CVA

Figure 130: ATC Roles: Authorizations

Users need specific authorizations to use ATC. Customers can make use of the ATC-specific
template roles to create roles for their environment.

Figure 131: ATC Developer Role

ATC has the following features for developers:

Start ATC within different ABAP workbench tools: SE80, SE24, SE38, SE11, and so on.

ATC automatically runs during release of transport requests.

Easy access to central ATC results in the development systems

User-centric display of ATC results, including powerful filter, navigation, re-check

Figure 132: ATC Quality Expert Role

ATC has the following features for quality experts:

Exemption approval process

E-mail ATC result to "responsible" contact person

Statistics showing aggregation of ATC findings using different criteria

© Copyright. All rights reserved. 81

Unit 3: Security Testing Tools

Execution of ABAP unit tests

Figure 133: ATC Administrator Role

ATC has the following features for administrators:

Powerful parallelization engine to run mass tests very effectively

Restart capability in case of a canceled/crashed ATC run

Possibility to schedule regular ATC runs

Powerful monitoring tool and flexible logging

Distribute ATC results to multiple target systems (such as from consolidation to

development systems)

Figure 134: Integration in SAP Solution Manager - Scaling and Reporting

ATC results from different systems can be viewed centrally from SAP Solution Manager.

Drill down results by user and package

Overview of open exemptions from different consolidation systems

Navigation from SAP Solution Manager to managed system to access exemptions

Released with SAP Solution Manager 7.1 SP10

Advanced ATC results and exemptions reporting are available with SAP Solution Manager
SP12

© Copyright. All rights reserved. 82

 Lesson: Explaining ATC and CVA

Figure 135: ATC integration in SAP Solution Manager

ATC results and ATC open exemptions are integrated into SAP Solution Manager. They are
triggered as background jobs from the SAP Solution Manager application CCLM.
If you want to access ATC results and open exemptions in a standard Web Dynpro
application, perform the following actions:

1. Schedule and execute ATC in the managed system.

2. From SAP Solution Manager, wrap the function modules

AGS_CUSTOM_CODE_GET_ATC_RESULT and AGS_CUSTOM_CODE_GET_ATC_EXEMPT
in an ABAP program and call it in the background (periodic job) to read the results into
SAP Solution Manager.

3. If the jobs are run and if results are available, they can be called via the Web Dynpro
applications ags_atc_open_exemptions.

SAP provides full-blown BW reposting capabilities for ATC results and exemptions as of SAP
Solution Manager SP12.

Figure 136: ABAP Test Cockpit: Setup and Administration

To configure the basic ATC settings, use transaction ATC.

Before performing a check with ATC, a check variant is required. The check variant controls
what type of checks to perform. SAP provides a global default check variant named

© Copyright. All rights reserved. 83

Unit 3: Security Testing Tools

'DEFAULT' which can be maintained using the Code Inspector (transaction SCI ); additional
local check variants can also be created.

Figure 137: SAP NetWeaver Application Server, add-on for Code Vulnerability Analysis: Features

The product SAP NetWeaver Application Server add-on for code vulnerability analysis, also
known as SAP NetWeaver Code Vulnerability Analyzer (CVA), is available for performing
security checks. CVA allows the scanning of customer-created ABAP source code for code
patterns indicating security vulnerabilities. The tool also comes with extensive documentation
which provides developers with information about the issues reported by the tool.
The checks are made available with specific releases of SAP NetWeaver. For more
information about which checks are available with which releases, see SAP Note 1921820.
CVA is a separate licensed feature which is disabled by default and has to be activated in the
system
The following are some general features of CVA:

Ensures security and compliancy of custom developed code

Supports the developer's requirements in his daily work in a convenient way

Supports automated scanning, notifications on issues, and workflows for exemptions

Figure 138: Supporting the Developer in Fixing Code

CVA supports direct navigation to the following:

© Copyright. All rights reserved. 84

 Lesson: Explaining ATC and CVA

The location in the source code

The related documentation and explanation of the issues

The workflow to create an exemption to allow efficient handling of findings

Figure 139: Fine Granular Control of Priorities

In the Code Inspector, you have the option to change the priority of check messages and also
get an overview of the available checks, documentation, and handling of check messages.

Figure 140: Overview of Available Security Checks

CVA offers various security checks that you can use to detect if there is any vulnerabilities in
your system.

Figure 141: Overview of Available Security Checks - SQL Injection (Open SQL)

© Copyright. All rights reserved. 85

Unit 3: Security Testing Tools

Figure 142: Overview of Available Security Checks - SQL Injection (ADBC)

ADBC is an API for the Native SQL interface of AS ABAP that is based on ABAP objects. The
ADBC methods can be used to pass Native SQL statements to the database interface. This
makes it possible to do the following:

Send database-specific SQL commands to a database system and process the result

Establish and administer database connections.

The ADBC classes all begin with the prefix CL_SQL_ or CX_SQL_.
For more information about ADBC, see https://help.sap.com/doc/
abapdocu_750_index_htm/7.50/en-US/abenadbc.htm .

Figure 143: Overview of Available Security Checks - Code Injection (ABAP)

Figure 144: Overview of Available Security Checks - Call Injection

Figure 145: Overview of Available Security Checks - OS Command Injection

Figure 146: Overview of Available Security Checks - Directory Traversal

© Copyright. All rights reserved. 86

 Lesson: Explaining ATC and CVA

Figure 147: Overview of Available Security Checks - Backdoors and Authorizations

Figure 148: Overview of Available Security Checks - Web Exploitability

Figure 149: To Secure ABAP Code - Summary

Figure 150: Recommendations (½)

Figure 151: Recommendations (2/2)

For developers to learn more about safeguarding their applications, the ABAP keyword
documentation can serve as a starting point, and it has been enhanced for critical statements.
Also, knowing how to use the ATC toolsets and CVA will definitely help to assess and secure
your applications.
For more information, see the following resources:

© Copyright. All rights reserved. 87

Unit 3: Security Testing Tools

ABAP Keyword documentation for SAP NetWeaver AS ABAP Release 750

Security Curriculum Learning Journey

We highly recommend that you visit the Security Curriculum Learning Journey for the
latest training in security.

LESSON SUMMARY
You should now be able to:

Explain ATC and CVA

© Copyright. All rights reserved. 88

 Unit 3

Learning Assessment

1. ABAP Test Cockpit is an ABAP check framework which allows running static checks and
unit tests for ABAP programs.
Determine whether this statement is true or false.

X True

X False

2. Which of the following are correct about the CVA?

Choose the correct answers.

X A CVA offers exemption workflows to ease handling of false positives.

X B CVA is integrated into the standard ABAP development infrastructure.

X C CVA generates automated alerts for security vulnerabilities.

X D CVA is a separate licensed feature which is disabled by default.

© Copyright. All rights reserved. 89

 Unit 3

Learning Assessment - Answers

1. ABAP Test Cockpit is an ABAP check framework which allows running static checks and
unit tests for ABAP programs.
Determine whether this statement is true or false.

X True

X False

You are correct! ABAP Test Cockpit is an ABAP check framework which allows running
static checks and unit tests for ABAP programs. Refer to the lesson ‘Explaining ATC and
CVA’ for more details.

2. Which of the following are correct about the CVA?

Choose the correct answers.

X A CVA offers exemption workflows to ease handling of false positives.

X B CVA is integrated into the standard ABAP development infrastructure.

X C CVA generates automated alerts for security vulnerabilities.

X D CVA is a separate licensed feature which is disabled by default.

You are correct! CVA is integrated into the standard ABAP development infrastructure
and CVA is a separate licensed feature which is disabled by default. Refer to the lesson
‘ Explaining ATC and CVA’ for more details.

© Copyright. All rights reserved. 90