SEC261 Exercises

SECURE ABAP DEVELOPMENT: ONE BUG IS
ENOUGH TO PUT YOUR APPLICATION AT

RISK
SEC261
Exercises / Solutions
Jrgen Adolf, Shinto K Anto, Georg Becker, Poornima C,
Holger Janz, Vaibhav Raina / SAP SE
SEC261 - SECURE ABAP DEVELOPMENT: ONE BUG IS ENOUGH TO PUT YOUR
APPLICATION AT RISK
TABLE OF CONTENTS
1 Before you start ..................................................................................................................................3
2 Exercise 1: Command Injection ..........................................................................................................4
2.1 Exercise 1.1 Get acquainted with the program ...............................................................................4
2.2 Exercise 1.2 Attack the program .....................................................................................................8
2.3 Exercise 1.3 Inspect the coding and find the security bug ..............................................................10
2.4 Exercise 1.4 Create external commands ........................................................................................13
2.5 Exercise 1.5 Fix the program by using the external commands .....................................................20
2.6 Exercise 1.6 Retest .........................................................................................................................24
3 Exercise 2: Directory Traversal ..........................................................................................................26
3.1 Exercise 2.1 Create logical file names ............................................................................................26
3.2 Exercise 2.2 Fix the check function modules by using the logical file names .................................32
3.3 Exercise 2.3 Retest .........................................................................................................................35
4 Exercise 3: XSS and XSRF ................................................................................................................38
4.1 Exercise 3.1 Get acquainted with the BSP application ...................................................................38
4.2 Exercise 3.2 Attack the application with XSRF ...............................................................................43
4.3 Exercise 3.3 Attack the application with XSS ..................................................................................45
4.4 Exercise 3.4 Inspect the application ................................................................................................47
4.5 Exercise 3.5 Fix the application - XSS ............................................................................................49
4.6 Exercise 3.6 Retest .........................................................................................................................53
4.7 Exercise 3.7 Fix the application - XSRF ..........................................................................................56
4.8 Exercise 3.8 Retest .........................................................................................................................60
5 Exercise 4: Authorization Checks for CALL TRANSACTION ............................................................63
5.1 Exercise 4.1 Static CALL TRANSACTIONs ....................................................................................64
5.2 Exercise 4.2 Dynamic CALL TRANSACTIONs ...............................................................................71
2
APPLICATION AT RISK
1 BEFORE YOU START

In this hands-on session you have the opportunity to select your exercises depending on
your personal area of interest. However, we have provided the solutions to all exercises as a
reference this way you can also see the solutions of the exercises you did not finish.
Due to time constraints during the hands-on session, it is recommended that you take a look
at all the different exercises and then decide which ones you want to work through first.
We recommend to do exercises 1 (Command Injection), 2 (Directory Traversal) and 3 (XSS

and XSRF) because the presentation relates to these topics. Please note that exercises 1
and 2 are not independent of each other: You can only work on exercise 2 if you have
finished exercise 1! Exercise 4 is more or less optional in case you work pretty fast and have
some extra time or in case you don't want to work on BSPs.
Exercise 1 (recommended): Command Injection

Estimated duration: 15 minutes
Exercise 2 (recommended): Directory Traversal

Exercise 3 (recommended): XSS and XSRF

Exercise 4 (optional): Authorization Checks for CALL TRANSACTION

Level of this session
This is a session on intermediate level. We expect that you know the basic handling of the
tools of the ABAP Development Workbench like the ABAP Editor (transaction SE38),
the Data Browser (transaction SE16), the ABAP Dictionary (transaction SE11) and the
Object Navigator (SE80).
Goal of this session
In the exercises you will learn about some typical security breaches in ABAP programs and
BSP applications, and how to avoid or fix them.
System access
You can find our system TDI in the SAP Logon system overview. We use a system based on
SAP NetWeaver 7.50 SP 03. Please log into client 001 with your user name SEC261 and
language EN. The password is welcome.
Tool usage
In this document we use the classic SAP GUI-based development tools (transactions SE38,
SE80, SE16 and the like). If you are familiar with the Eclipse-based ABAP Development
Tools (ADT) and prefer to use them, feel free to do so:
Click Start -> All Programs -> SAP -> SAP NetWeaver -> ABAP Development Tools
Choose our workspace ABAP in Eclipse - SEC261
Open the project TDI_001_sec261_en. In your Favorite Packages you find the
exercises in subpackages of package TEST_SEC261.
3
APPLICATION AT RISK
2 EXERCISE 1: COMMAND INJECTION
Overview
Estimated time: 15 minutes
Objective
In the presentation we showed you what an OS command injection is and how it works. In
this exercise you will learn how to avoid this kind of attack.
Exercise Description
Get acquainted with the program

Attack the program
Inspect the coding and find the security bug
Create external commands
Fix the program by using the external commands
Retest
2.1 Exercise 1.1 Get acquainted with the program

We are dealing with program Z_SEC261_INJECTION in subpackage
TEST_SEC261_INJECTIONS of our main package TEST_SEC261.
The intended purpose of the program is:
See a list of files in folder D:\Files\Session\SEC261 with invoices

Pick one of these invoices and display it
Accept or reject the invoice
Accepted invoices shall be moved to folder D:\Files\Session\SEC261\Accept. It is
allowed to change the filename.
Rejected invoices shall be moved to folder D:\Files\Session\SEC261\Reject. It is
allowed to change the filename.
In this part of the exercise you execute the program, inspect one of the invoices and accept it
with a change of the filename.
Whenever you run out of invoices in this exercise 1 and exercise 2 you can restore the
original state by executing program Z_SEC261_SETUP_FILES.
4
APPLICATION AT RISK
Explanation Screenshot
1. Click
Student (local)
and navigate to folder
D:\Files\Session\SEC261.
Step 2
Note that there are five files in

the folder
If you want to, you can also verify
that the sub-directories Accept and
Reject are empty.
You can always restore this state
by running program
Z_SEC261_SETUP_FILES.
Step 3
2. Double-click
in your
SAPGUI window.
Step 4
3. Navigate to package
TEST_SEC261 Subpackage
TEST_SEC261_INJECTIONS
Program
Z_SEC261_INJECTION and
press F8 to execute it.
Step 5
5
APPLICATION AT RISK
You now see the five files with

invoices in
4. Double-click
on to
display the invoice.
Step 6
This is the invoice!
5. Click .
Step 7
6. Change the filename to
D:\Files\Session\SEC261\Acce
pt\Invoice1954.txt, i.e. remove
the leading zeroes before
1954.
7. Click to move the file into
Step 8
the Accept directory.
This message comes from the OS

command move.
8. Press ESC to get rid of the
popup.
Step 9
6
APPLICATION AT RISK
Note that file Invoice001954.txt

disappeared from the original
folder.
Step 10
Navigate to the Accept folder and

note that file Invoice1954.txt
(without the leading zeroes) is in
this folder now.
Step 11
7
APPLICATION AT RISK
2.2 Exercise 1.2 Attack the program

This attack will deal with the command injection. Later in this exercise and in exercise 2 we
will see another kind of attack, a directory traversal.
1. Double-click
on to see
the invoice.
Step 2
2. Click this time.
Step 3
3. Add " | echo Hello!"
behind the filename (without
the double quotes).
4. Click .
Step 4
Look what happened! You see

"Hello!" The echo command
was executed!
The program executes a move
command (which you don't see)
with two filenames as parameters.
In this attack you piped the textual
output of the move command into
an echo command which was also
executed. The echo command
ignores its input from the pipe.
Therefore you don't see a
message like "1 file(s)
moved."
Step 5
8
APPLICATION AT RISK
An echo command is of course
not a very dangerous command.
We are sure that you can think of
very dangerous commands at this
point. It might be tempting, but
please do not try such commands
here.
5. Press ESC to close the
popup window.
If you want to, you can verify that

the move command was executed
by looking at the Reject folder. The
invoice appears here. Thus, it was
moved into the folder.
In case you are messing around a

little bit and you are running out of
invoices in the SEC261 folder, you
can run program
Z_SEC261_SETUP_FILES. It will
take you back to the initial state, i.
e. all invoices will then be in the
SEC261 folder, and no invoices
will be in the Accept or Reject Step 6
folder.
9
APPLICATION AT RISK
2.3 Exercise 1.3 Inspect the coding and find the

security bug
We will have a look at the coding of program Z_SEC261_INJECTION now and find the
vulnerable part with CVA.
The OS command injection

problem obviously relates to
moving an invoice file from one
folder to an other folder. There is a
FORM routine move_file in the
program. Navigate to this FORM.
It's close to line 150. Step 2
First the popup for changing the

file name is displayed.
Step 3
An operating system command is

assembled in this step.
Step 4
In this CALL 'SYSTEM' the

operating system command is
executed.
Step 5
Finally the textual output of the OS

command is displayed on a popup
window.
Step 6
10
APPLICATION AT RISK
1. Click on
with the
right mouse button, navigate to
Check and then to ABAP Test
Cockpit (ATC). This will invoke
the Code Vulnerability Analyzer
(CVA) under the control of the
ABAP Test Cockpit.
Step 7
CVA tells us that there is

something wrong with the CALL
'SYSTEM'.
2. Double-click
Step 8
to see the details of the
finding.
3. You can click
to see a list of the available

CVA checks.
Step 9
4. After browsing through this
list click to close the
Performance Assistant window.
Step 10
11
APPLICATION AT RISK
5. Click
to learn about the problems

which are caused by using
CALL 'SYSTEM'.
Step 11
6. Click .
Step 12
7. By clicking you can

navigate to the source code
position to which this finding
relates.
Step 13
This is the position which we saw

earlier.
Step 14
12
APPLICATION AT RISK
2.4 Exercise 1.4 Create external commands

In the detailed description of the finding you probably read something about creating an
external command. In this part of the exercise you will create two external commands, one
for moving a file from the SEC261 folder to the Accept folder and one for moving a file from
the SEC261 folder to the Reject folder.
You might wonder why we are not creating one generic external command for moving files.
Here's the reason: Moving a file can be a dangerous operation. If such dangerous operations
are generic then they are even more dangerous. Therefore we create two specialized
external commands. This way the probability that they can be used for an attack is
significantly reduced.
1. Double-click
in the SAP Easy Access Menu.
Step 2
2. Click to create a new

external command.
Step 3
13
APPLICATION AT RISK
3. Enter Z_MOVE_FILE_ACC
in the Command Name field.
4. Enter cmd /c move in the
Operating System
Command field.
There is no single "move"
command in Windows (in the
sense of a single program that
does the move). This
functionality is part of the
command shell cmd. This is
why we must involve a
shell here. The /c specifies that
the move shall be executed
and that the the shell shall
terminate after that.
5. Enter
Z_SEC261_CHECK_PARAMS
_ACC in the Check
Module field.
This is the name of a function
module that is called when the
external command shall be
executed. In this function
module you can check the
parameters that are about to be
passed to the external
command.
6. Click to save your
specification of the external Step 4
command.
7. Click .
8. Click again to create an

external command for the move
to the Reject folder.
Step 5
14
APPLICATION AT RISK
9. Enter Z_MOVE_FILE_REJ
in the Command Name field.
10. Enter cmd /c move in the
Operating System
Command field.
11. Enter Z_SEC261_CHECK_
PARAMS_REJ in the Check
Module field.
12. Click .
13. Click .
Step 6
14. Click .
Step 7
15. Double-click
to launch the Function Builder.

We will have to implement the
two check modules now.
Step 8
15
APPLICATION AT RISK
16. Enter SXPG_DUMMY_CO
MMAND_CHECK in the
Function Module field.
17. Click to copy this
function module.
Step 9
PARAMS_ACC in the To
Function module field.
19. Enter Z_SEC261 in the
Function group field.
20. Click .
Step 10
21. Click .
Step 11
22. Remove the marked
comments. We don't need
them any more. They originate
from the copied function
module
SXPG_DUMMY_COMMAND_
CHECK.
Step 12
16
APPLICATION AT RISK
23. Enter the following source
code:
DATA: source TYPE

string,
target TYPE
string.
SPLIT parameters AT '

' INTO source target IN
CHARACTER MODE.
* Check for allowed

characters in the
source filename.
IF source CN
allowed_characters.
RAISE
no_permission.
ENDIF.
* Check for allowed

characters in the
target filename.
IF target CN
allowed_characters.
RAISE
no_permission.
ENDIF. Step 13
24. Click to activate the new

code.
25. Click .
Step 14
17
APPLICATION AT RISK
26. Enter SXPG_DUMMY_CO
MMAND_CHECK in the
27. Click to copy it.
Step 15
PARAMS_REJ in the To
29. Enter Z_SEC261 in the
Function Group field.
30. Click .
Step 16
31. Click .
Step 17
32. Remove the marked
comments. We don't need
them any more. They originate
from the copied function
module
SXPG_DUMMY_COMMAND_
CHECK.
Step 18
18
APPLICATION AT RISK
33. Enter the following source
code:
DATA: source TYPE

string,
target TYPE
string.
SPLIT parameters AT '

' INTO source target IN
CHARACTER MODE.
* Check for allowed

characters in the
source filename.
IF source CN
allowed_characters.
RAISE
no_permission.
ENDIF.
* Check for allowed

characters in the
target filename.
IF target CN
allowed_characters.
RAISE
no_permission. Step 19
ENDIF.

code.
35. Click .
Step 20
36. Click .
Step 21
19
APPLICATION AT RISK
2.5 Exercise 1.5 Fix the program by using the

external commands
We have our two external commands with a check function module each now. But how do
we use them in our program? Let's see in this part of the exercise.
1. Click .
Step 2
2. Enter
Z_SEC261_INJECTION in the
Program field.
3. Click Change.
Step 3
4. Scroll to the form routine
move_file (about line 150).
Step 4
5. Add ucomm TYPE sy-
ucomm as the first parameter.
We need this new parameter in

order to determine which
external command (move to the
Accept folder or move to the
Reject folder) we shall call.
Step 5
20
APPLICATION AT RISK
6. Remove the type definition
of result_line.
Remove the variable definition

of the variable command.
Instead add two variables:
commandname TYPE
sxpgcolist-name,
params TYPE btcxpgpar,
Finally, change the type of

variable result from
STANDARD TABLE OF
result_line to STANDARD
Step 6
TABLE OF btcxpm.
7. Replace the line with
command = `move ... by the
two lines
* Prepare the move.

params = source && ` `
&& target.
We don't need the explicit

move command any more.
However, we need the
parameters.
Leave the line with CLEAR

result where it is. But remove
the CALL 'SYSTEM' with the
IF / ENDIF after that.
That's our main concern! Get

rid of CALL 'SYSTEM'!
Instead we need the decision
for the command name first.
Enter the following code:
IF ucomm = 'ACCEPT'.
commandname =
'Z_MOVE_FILE_ACCEPT'.
ELSE.
commandname =
'Z_MOVE_FILE_REJECT'.
ENDIF.
Step 7
* Do the move.
21
APPLICATION AT RISK
8. But how do we do the move?
How do we use our external
commands? Here's the answer:
Place the cursor into the line

after the comment Do the
move and then click .
Step 8
9. In the popup enter
SXPG_CALL_SYSTEM in the
field after CALL FUNCTION.
Step 9
10. Click .
Step 10
11. For the sake of simplicity in
this exercise change the
function call such that it looks
like this:
CALL FUNCTION
'SXPG_CALL_SYSTEM'
EXPORTING
commandname =
commandname
additional_parameters =
params
TABLES
exec_protocol =
result
EXCEPTIONS
no_permission = 1
OTHERS = 2.
In the real productive world you

probably want exact exceptions
in order to give precise error
messages. This simplification is
just for you to save some time
in this exercise.
Step 11
22
APPLICATION AT RISK
12. Add the following code for a
minimum error handling:
CASE sy-subrc.
WHEN 0.
* Fine! Nothing to
do. Continue below.
WHEN 1.
MESSAGE 'No
permission to move the
file.' TYPE 'E'.
WHEN OTHERS.
MESSAGE
'Unspecified error when
moving the file.' TYPE
'E'.
ENDCASE. Step 12
13. Navigate to the first

PERFORM of move_file.
That's in event AT USER-
COMMAND (close to line 270).
14. Insert sy-ucomm as the
first parameter, don't touch the
other parameters (fullname
and target).
15. Find the second PERFORM
of move_file about 15 lines
further down.
16. Again: insert sy-ucomm as
the first parameter, don't touch
the other parameters
(fullname and target).
Step 13
17. Click to activate the

changed program.
Step 14
23
APPLICATION AT RISK
2.6 Exercise 1.6 Retest

Let's see what we have achieved so far.
Remember: in case you run out of invoice files you can reset the files by running report
Z_SEC261_SETUP_FILES.
1. Click to execute the

program.
Step 2
2. Double-click
(or any
other file name).
Step 3
3. Click .
Step 4
4. Enter | echo Hello! behind
the filename.
5. Click .
Step 5
Note the error message at the

bottom of the window.
That pipe trick doesn't work any

more because we are checking
the file names by a whitelist
(allowed_characters).
Step 6
24
APPLICATION AT RISK
6. Click .
Step 7
7. Append && echo Hello! to
the file name.
8. Click .
Step 8
See the error message! The &&

trick doesn't work either.
Step 9
9. Click for another
test.
Step 10
10. Change from the suggested
Accept folder to the Reject
folder.
11. Click .
Step 11
So, moving the file to the wrong

folder works. We still have some
work ahead of us!
popup window.
Step 12
Summary
You have completed the exercise!
You are now able to:

Explain what an OS command injection is
Use an external command to avoid an OS command injection.
25
APPLICATION AT RISK
3 EXERCISE 2: DIRECTORY TRAVERSAL
Overview
Objective
In the previous exercise on command injection you saw how to get rid of the possibility to
have the system execute arbitrary OS commands. In the end of that exercise we saw that it
is still possible to move invoice files to arbitrary directories. In this exercise we will take care
of this directory traversal problem.
Create logical file names

Fix the check function modules by using the logical file names
Retest
3.1 Exercise 2.1 Create logical file names
1. Click
Step 2
2. Click to acknowlegde
this.
Step 3
26
APPLICATION AT RISK
We first have to create three

logical paths and assign physical
paths to them.
3. Double-click Logical
File Path Definition.
4. Click New Entries.
Step 4
5. Enter
Z_SEC261_NEW_INVOICES
in the Logical File Path field.
6. Enter New Invoices in the
Name field.
Step 5
7. Enter
Z_SEC261_ACC_INVOICES in
the Logical File Path field.
8. Enter Accepted Invoices in
the Name field.
Step 6
9. Enter
Z_SEC261_REJ_INVOICES in
the Logical File Path field.
10. Enter Rejected Invoices in
the Name field.
11. Click to save the logical
file path definitions.
Step 7
12. Click to acknowlegde

the popup for the workbench
request (if it appears).
Step 8
27
APPLICATION AT RISK
13. Mark the first entry
(Z_SEC261_NEW_INVOICES).
14. Click
to assign the physical path.
Step 9
15. Click .
Step 10
16. Click for a value help on
the Syntax group.
Step 11
17. Click since
our application server is
running on a Windows
machine.
Step 12
18. Enter D:\Files\Session\SE
C261\<FILENAME> in
the Physical path field.
19. Click several times until
you get back to the Overview of
Added Entries.
Step 13
20. Mark the second entry
(Z_SEC261_ACC_INVOICES).
21. Click
.
Step 14
28
APPLICATION AT RISK
22. Click .
Step 15
23. Select WINDOWS NT
again for the Syntax group.
24. Enter
D:\Files\Session\SEC261\Acc
ept\<FILENAME> in the
Physical path field.
25. Click several times until
you get back to the Overview of
Added Entries.
Step 16
26. Mark the third entry
(Z_SEC261_REJ_INVOICES).
27. Click
.
Step 17
28. Click .
Step 18
29. Select WINDOWS NT
again for the Syntax group.
30. Enter
D:\Files\Session\SEC261\Rej
ect\<FILENAME> in
the Physical path field.
31. Click .
Step 19
29
APPLICATION AT RISK
Now we have to define the logical

file names. Since in our case there
is a 1:1 relationship between the
logical paths and the logical files
we will choose the same names.
32. Click
Step 20
.
33. Click .
Step 21
34. Enter
in the Log. File field.
35. Enter New Invoices in
the Name field.
36. Enter DIR in the Data
format field.
37. Enter BC in
the Applicat.area field.
38. Enter
Step 22
in the Logical path field.
39. Click .
Step 23
40. Click .
Step 24
41. Enter
the Log. File field.
42. Enter Accepted Invoices
in the Name field.
43. Enter DIR in the Data
format field.
44. Enter BC in
the Applicat.area field.
45. Enter
the Logical path field. Step 25
46. Click .
Step 26
30
APPLICATION AT RISK
47. Click .
Step 27
48. Enter
Z_SEC261_REJ_INVOICES in
the Log. File field.
49. Enter Rejected Invoices in
the Name field.
50. Enter DIR in the text field.
51. Enter BC in the text field.
52. Enter
Z_SEC261_REJ_INVOICES in Step 28
the text field.
53. Click .
54. Click .
Step 29
31
APPLICATION AT RISK
3.2 Exercise 2.2 Fix the check function modules

by using the logical file names
1. Click
.
Step 2
2. Enter
Z_SEC261_CHECK_PARAMS
_ACC in the Function Module
field.
3. Click .
Step 3
4. Insert the following code
after the SPLIT command:
* Check whether the

source is in the SEC261
directory.
CALL FUNCTION
'FILE_VALIDATE_NAME'
EXPORTING
logical_filename
=
'Z_SEC261_NEW_INVOICES'
CHANGING
physical_filename
= source
EXCEPTIONS
logical_filename_not_fo
und = 1
validation_failed = 2
OTHERS = 3.
IF sy-subrc <> 0.
RAISE
no_permission.
ENDIF.
(Again: the error handling is Step 4

simplified here.)
32
APPLICATION AT RISK
5. Insert another call of
FILE_VALIDATE_NAME after
the first IF/ENDIF statement
that checks for
allowed_characters:
* Check whether the

target is in the Accept
directory.
CALL FUNCTION
EXPORTING
logical_filename
=
'Z_SEC261_ACC_INVOICES'
CHANGING
physical_filename
= target
EXCEPTIONS
logical_filename_not_fo
und = 1
validation_failed
= 2
OTHERS = 3.
IF sy-subrc <> 0.
RAISE
no_permission.
ENDIF. Step 5

version of the function module.
7. Click .
Step 6
8. Enter Z_SEC261_CHECK_P
ARAMS_REJ in the Function
Module field.
9. Click .
Step 7
33
APPLICATION AT RISK
10. Insert the following code
after the SPLIT command:
* Check whether the

source is in the SEC261
directory.
CALL FUNCTION
EXPORTING
logical_filename =
'Z_SEC261_NEW_INVOICES'
CHANGING
physical_filename =
source
EXCEPTIONS
logical_filename_not_foun
d = 1
validation_failed =
2
OTHERS = 3.
IF sy-subrc <> 0.
RAISE no_permission.
ENDIF.
Step 8
11. Insert another call of
FILE_VALIDATE_NAME after
the first IF/ENDIF statement
that checks for
allowed_characters:
* Check whether the

target is in the Reject
directory.
CALL FUNCTION
EXPORTING
logical_filename =
'Z_SEC261_REJ_INVOICES'
CHANGING
physical_filename =
target
EXCEPTIONS
logical_filename_not_foun
d = 1
validation_failed =
2
OTHERS = 3.
IF sy-subrc <> 0.
RAISE no_permission.
ENDIF.
Step 9
34
APPLICATION AT RISK
12. Click to activate the

new version of the function
module.
13. Click .
Step 10
Exercise 2.3 Retest
1. Double-click
.
Step 2
2. Enter Z_SEC261_INJECTIO
N in the Program field.
3. Click .
Step 3
4. Double-click
(or any
other invoice file name).
Step 4
35
APPLICATION AT RISK
5. Click .
Step 5
6. Change the filename from
pt\Invoice002381.txt to
D:\Files\Session\SEC261\Reje
ct\Invoice002381.txt, thus
trying a directory traversal
attack. Step 6
7. Click .
Note the error message at the

bottom of the screen. The
directory traversal attack didn't
work. That's what we wanted to
achieve! Step 7
8. Click .
Step 8
9. Change the filename:
remove the leading zeroes from
the number in the filename.
10. Click .
Step 9
This still works. After all, the file is

moved to the Accept directory.
Works as intended!
popup.
Step 10
36
APPLICATION AT RISK
Now let's try whether the Reject

button also works as desired.
12. Double-click
.
Step 11
13. Click .
Step 12
14. Change the file name from
D:\Files\Session\SEC261\Reje
ct\Invoice006911.txt to
pt\Invoice006911.txt
15. Click . Step 13
See the error message! It doesn't

work. That's what we wanted!
You can also try an OS command

injection again if you want to
(using | echo Hello! or && echo
Hello!). It should not work either. Step 14
Summary

Explain what a directory traversal attack is
Avoid directory traversal vulnerabilities by using logical file names
37
APPLICATION AT RISK
4 EXERCISE 3: XSS AND XSRF
Overview
Objective
In this exercise we will deal with the BSP application which you saw in the demo. There is an
XSRF (Cross site request forgery) and an XSS (Cross site scripting) problem in it.
Get acquainted with the BSP application

Attack the application with XSRF
Attack the application with XSS
Inspect the application
Fix the application - XSS
Retest
Fix the application - XSRF
Retest
4.1 Exercise 3.1 Get acquainted with the BSP

application
1. Click
.
Step 2
2. Navigate: Package
TEST_SEC261_BSP BSP
Application Z_SEC261_DEMO
Page demo.htm . Double-
click .
This is an almost static HTML

page. It's sole purpose is to give
you some pieces of information
and - more important - to supply
you with a couple of links that you
Step 3
will use during this exercise.
38
APPLICATION AT RISK
The real application that we work

with is Z_SEC261_Approv.
The task of this application is the
same as in the injection example:
accept or reject invoices. You will
see the same data and the same
intended functionality, but you will
see other security challenges. In
this application the data is not in
files in the file system but in
database tables.
3. Click to launch the demo

application in the browser.
Step 4
4. Click to allow the

execution of the application.
Step 5
5. Enter sec261 aus your user
name and welcome as your
password. Then click
.
Step 6
For your information: you can

always use the first link to reset all
invoices to their initial state, i. e. all
invoices are then ready for
approval or rejection.
6. Click the second link (below
"Normal launch of our
application") now to launch
BSP application Step 7
Z_SEC261_Approv.
39
APPLICATION AT RISK
7. Since this is a new
application the system asks
you to login again. Use sec261
as your user name and
welcome as your password
again. Step 8
This is the vulnerable application.

Do the invoice numbers look
familiar?
8. Click to inspect
invoice number 001954.
Step 9
Please have a look at the URL of

this page. It ends with sap-
params=aW5wdXQ9MDAxOTU0 .
This weird value is a base64-
encoded value. The clear text is
"input=001954". This is a
parameter for the BSP page
invoice.htm.
Step 10
9. Click to accept this

invoice.
Step 11
It has been approved. Fine. Not a

big deal.
10. Click .
Step 12
40
APPLICATION AT RISK
11. Now click .
Step 13
12. Click .
Step 14
Okay, this one has been rejected.

Also not a big dieal.
Step 15
Let's have a quick look at the

database table in which the
approvals and rejections are
stored.
13. Enter /ose16 in the okcode
field of your SAPGUI window in
order to launch the Data Step 16
Browser in a separate window.
14. Enter ZSEC261_INV_HDR
in the Table Name field.
15. Click .
Step 17
41
APPLICATION AT RISK
16. Don't enter any selection
criteria. Just click to see all
the records. (Don't worry.
There are only five records in
the table.)
Step 18
Look at the STATUS column. The

value is A (for 'Accepted') for
invoice number 001954, it is R (for
'Rejected') for invoice number
002381 and blank for the other
invoices which we haven't
processed so far.
If you want to you can also have a

look at the table with the invoice
items (ZSEC261_INV_ITEM). But
this data is just used to display
(more or less) nice data in this
application. That's of minor
Step 19
relevance for this exercise.
42
APPLICATION AT RISK
4.2 Exercise 3.2 Attack the application with XSRF
1. In your browser window click
several times until you get

back to the demo.htm page.
There might be messages like
"This invoice has already been
processed." Just ignore this.
Just keep clicking the Back
button. Step 2
Do you remember the

explanations about the base64-
encoded parameter in the previous
part of the exercise? You can read
just about the same text on the
demo.htm page, too.
2. Note that you are currently
not in the Z_SEC261_Approv
application. And note that you
can craft URLs yourself. Click
the URL ending
with now. It
serves as an example for
such a crafted URL. Step 3
Think about what happened here

for a minute: You surfed to the
crafted URL from outside of the
Z_SEC261_Approv application
and it seems that the invoice has
been processed right away. You
were already logged on the
application. You didn't need to
enter your user id and password
again.
What if someone had sent you an

email with that URL telling you that
you can see her or his beautiful
holiday photos by clicking on the
link? - This is a serious security
problem called XSRF (Cross site
request forgery). The attacker
her/himself couldn't do this
because she/he was not logged on Step 4
to the application.
43
APPLICATION AT RISK
Let's make sure that there really

was an update to the database.
3. In the Data Browser window
(transaction SE16) make sure
you are dealing with table
ZSEC261_INV_HDR. Click .
Step 5
4. Click without entering any
selection criteria.
Step 6
Do you see the A in the record for

invoice number 008726?! That's
the change!
Step 7
44
APPLICATION AT RISK
4.3 Exercise 3.3 Attack the application with XSS
1. Click until you get to the

demo.htm page.
Step 2
2. Click
. That's the URL below the text
"You can also add HTML
coding to the URL ...". It ends
with
input=006911<script>ale
rt('Hello
Step 3
World!')</script> .
Okay, you got a 403 error

here. Well, that's because of the
slash in </script>. We can get
rid of that by base64-encoding the
parameter and using sap-params
again.
3. Click .
Step 4
4. Now click the URL below
"Got a 403 error? ...". It is
essentially the same URL as
the last one, except that Step 5
sap_params with the base64-
encoded value is used.
Look! Now the little script was

executed.
Keep in mind: this is so dangerous

because a user from the outside
might send you a link, you click it
and possibly malicious code is
executed on your machine.
Step 6
45
APPLICATION AT RISK
Do you remember the OS
command injection in exercise 1?
There we also did a harmless
operation with the echo
command. And we asked you not
to try more dangerous operations.
The same applies here: With
Javascript you can do nasty
things. Please only use your
imagination, but please don't try
them here.
5. Click .
Moreover, the invoice was

approved. But that's the XSRF
problem that we saw before.
6. Click .
Step 7
46
APPLICATION AT RISK
4.4 Exercise 3.4 Inspect the application
1. Click on
with the right mouse button and
navigate to Check and then to
ABAP Test Cockpit (ATC).
2. Click
to
launch CVA. Step 2
The Code Vulnerability Analyzer

found nine XSS vulnerabilities and
also the XSRF vulnerability.
3. Double-click on the
first
entry.
Step 3
Feel free to look around, e.g. have

a look at the documentation.
4. Click to get to
the source code.
Step 4
47
APPLICATION AT RISK
5. This is the place where the
XSS attack is possible. The
"unfiltered" contents of the BSP
parameter input is written into
the HTML page at this point. If
an attacker includes some
Javascript code in the contents
of the parameter input then
this code is executed at
runtime.
6. Click .
Step 5
If you want to you can have a look

at some more XSS findings. They
all look similar.
Step 6
Let's now have a look at the XSRF

finding.
7. Double-click BSP
aplication is not protected
against XSRF. Step 7
Have a look at the detail

description, at the help texts,
whatever you like.
Step 8
48
APPLICATION AT RISK
4.5 Exercise 3.5 Fix the application - XSS

We need to fix the XSRF problem as well as the XSS problems now.
Let's first think about the XSS breach for a minute:
The solution for this is escaping. That means that a couple of characters that have a special
meaning in HTML must be treated in a special way. The most obvious character here is
the < character. In cases in which it shall not have a special meaning it must be escaped, i.
e. it must be coded as < (the "lt" stands for "less than") or in one of a few other alternative
ways. For an HTML parser (which is part of a browser) this means that the character < shall
be displayed on the screen (or printed into a hardcopy). It shall not have the special meaning
"introduction of an HTML tag". If such escaping is done for the data from the outside (in our
case a parameter in the URL) this will not result in an XSS vulnerability.
In most cases this is very easy. Each BSP page has an introductory directive which starts
with <%@page . Just add an attribute forceEncode="html" to this directive. Then -
whenever text from an ABAP variable shall be written to the page - this text will be escaped
automacially. This is very easy to implement and covers the requirements in most cases.
In some cases you explicitly don't want this automatic escaping, e. g. when the data that
shall be displayed has already been escaped at some place for some reason. Then the
forceEncode attribute can't be used because multiple escaping leads to unwanted results.
Without the forceEncode attribute for each variable whose content shall be written to the
HTML page the developer must decide whether the content shall be escaped or not. If it shall
be escaped then there are various ways to it. You will see them in the next part of the
exercise.
1. Click
.
Step 2
TEST_SEC261_BSP BSP
Application
Z_SEC261_Approv
. Double-click
. Step 3
3. Click to get into change

mode.
Step 4
49
APPLICATION AT RISK
4. Add forceEncode="html"
to the page directive. Since this
is hard to read on the right
side, here is the whole resulting
directive:
<%@page language="abap"
forceEncode="html"%> Step 5
5. Activate your change: Click
.
Step 6
6. Let's try the escaping in a
different way now. Click
.
Step 7
7. On this page we want to
treat writing of the input
parameter to the page by
changing the tag from <%= to
<%html= . Do this here...
8. ... and here ...
9. ... and here.
Now scroll down.
Step 8
10. This is the fourth place a
few lines before the end of the
coding. Do the change here,
too.
Step 9
50
APPLICATION AT RISK
11. Activate your corrections by
a click on .
Step 10
12. Switch to
page .
Step 11
13. On this page we want to
use method
cl_abap_dyn_prg=>escape
_xss_xml_html( ).
Use it here...
14. ... and here...
15. ...and finally here.
Step 12
16. Activate the page.
Step 13
51
APPLICATION AT RISK
17. Now switch to page
.
Step 14
18. The last way of escaping
for this exercise is the ABAP
built-in function escape( val
= input format =
cl_abap_format=>e_xss_m
l ).
Use it here...
19. ... and here ...
20. ... and finally here.
Step 15
21. Click to activate your

changes.
Step 16
52
APPLICATION AT RISK

Let's see whether the XSS attack is still possible. We have not yet fixed the XSRF
vulnerability.
1. Go to the demo application
again. Double-click
.
Step 2
2. Launch it by clicking .
Step 3
3. Click if the popup

comes up.
Step 4
4. As before: enter sec261 as
the user name if you are asked
to logon again.
5. Enter welcome as the
password.
6. Click to logon.
Step 5
7. Click the very first link (the
one that ends with init.htm)
to restore all invoices to their
initial state.
Step 6
53
APPLICATION AT RISK
8. If requested logon
to the z_sec261_Approv
application with user name
sec261 and password
welcome, then click
.
Step 7
Resetting the DB tables worked.
9. Click to get back to the

demo application.
Step 8
10. Click the link below "Got a
403 error? ..." again.
Do you remember? The weird

value behind sap-params is
the base64-encoded version of
input=006911<script>ale
rt('Hello
World!')</script>. Step 9
Okay! The script was not executed

any more. (You didn't see the
"Hello World!" popup, did you?!)
Instead the coding of the script
was written here. After all, this is
what you sent as a parameter
value to the application by clicking
the link.
But it says that the invoice was

approved. Well, this is because in
the corresponding SELECT
statement the input parameter is
used in the WHERE condition. In
the ABAP documentation you can
read that the value that is used for
the comparison is shortened to the
correct number of characters (6 in
this case) if it is too long. And
that's just the 006911.
In the real world you should do
Step 10
some checking on the input
54
APPLICATION AT RISK
parameter, e. g. check for the
maximum length of 6 characters
plus check whether all characters
are numeric. But let's stop this
example at this point. There's
some more work to do.
11. Click .
55
APPLICATION AT RISK
4.7 Exercise 3.7 Fix the application - XSRF

Let's think about the XSRF breach for a minute now:
It is important to make sure that BSP pages which cause changes on the database can only
be reached from pages which make you aware of this fact, e.g. by offering you pushbuttons
"Accept" or "Reject". (You will see how to do this in this part of the exercise. It's easy!)
By the way, this problem is not limited to BSPs. Other technologies (be it SAP technologies,
be it technologies of other vendors) can have such problems, too.
1. Click
.
Step 2
TEST_SEC261_BSP BSP
Application
Z_SEC261_Approv. Double-
click .
Step 3
3. Switch to the
tab.
Step 4
4. Click to get into change

mode.
Step 5
56
APPLICATION AT RISK
5. Mark the XSRF Protection
checkbox.
Step 6
6. Click .
Step 7
We have now switched on XSRF

protection. With XSRF protection
the system generates a so-called
XSRF-token which is sent to the
user's browser. Upon a navigation
request from the browser it sends
back the XSRF-token to the
server. Thus, the system has a
means to check whether the
received token is the same as the
token it sent a minute ago. If so,
this is a valid request. A request
without the valid XSRF token is
rejected. This could be an attack
like the one you performed a
couple of minutes ago.
Now we need to specify one or a

few pages that can be navigated
to initially. This is certainly the
overview page (overview.htm).
Moreover, it should be possible to
call page init.htm without an
introductory page. (That's the
page with which you can reset all
invoices to their initial state. This is
a database change, but for this
exercise let's consider this as
okay.)
7. Navigate to the
page . Step 8
57
APPLICATION AT RISK
8. Switch to the
tab.
Step 9
9. Mark the Start BSP
checkbox. This means that this
page can be called without an
XSRF token. This makes sense
because it is the initial page of
this BSP application.
Step 10
10. Click to save this

setting.
Step 11
11. Navigate to the
page.
Step 12
12. Mark the Start BSP
checkbox. Thus, this page can
be called without an XSRF
token, too.
Step 13
13. Click to save your work.

14. Click to activate your
changes.
Step 14
15. On the popup click to

mark the application itself (we
set the XSRF Protection flag
here) and the two individual
pages (we marked them as
start pages). Step 15
58
APPLICATION AT RISK
16. Click to really do the

activation.
Done with the activation and with

the XSRF problem! It's as easy as
that! Step 16
59
APPLICATION AT RISK
1. Navigate to the demo
application again. Double-click
.
Step 2
2. Click to execute it.
Step 3
3. If this popup comes click
.
Step 4
4. If you are requested to logon
use sec261 as your uer name
and welcome as your
password. Click to
logon to the demo application.
Step 5
5. Just to make sure we have
enough invoices and to check
whether the init page is not
XSRF protected click the very
first link again (the URL ends
with init.htm .). Step 6
60
APPLICATION AT RISK
6. If you have to logon use
sec261 as your user name and
welcome as your password,
then click to logon to
the z_sec261_Approv
application.
Step 7
Good to know that it works! We

specified the init.htm page
as one of two start pages in the
BSP application. Fine!
7. Click .
Step 8
8. Locate the fourth link. It ends
with
approved.htm?input=0087
26 . Should it work? No,
because the approved.htm
page is not one of our start
pages. Now click on the link. Step 9
Good result! We couldn't navigate

from the demo application directly
to a non-start page of the
z_sec261_Approv application.
We have solved our XSRF
problem!
You might want to try some of the

other links, too.
Step 10
61
APPLICATION AT RISK
9. As a last step let's see
whether CVA "likes" our
application now. In your
SAPGUI window click on
with the right
mouse button and navigate to
Check and then ABAP Test
Cockpit (ATC).
10. Click
Step 11
.
Isn't this a nice result?! We are

done with this exercise.
Step 12
Summary

Explain what an XSS vulnerability is
Explain what an XSRF vulnerability is
Avoid XSS and XSRF vulnerabilities in BSP applications.
62
APPLICATION AT RISK
5 EXERCISE 4: AUTHORIZATION CHECKS FOR CALL

TRANSACTION
Overview
Objective
This exercise deals with a special characteristic of the CALL TRANSACTION statement.
When a CALL TRANSACTION is executed the ABAP runtime automatically checks the
authorizations for starting the specific transaction only in some special cases. In other cases
it is not automatically checked. The behaviour depends on settings in DB table TCDCOUPLES
and profile parameters.
SAP recommends not to rely on these complex rules any more. The developer who is
responsible for the calling program (i. e. the program in which the CALL TRANSACTION is
coded) should determine whether or not an authorization check takes place and this decision
should be visible in the coding.
Please note that it sometimes is perfectly correct not to check the transaction start
authorizations in conjunction with a CALL TRANSACTION statement. It depends upon the
context of the calling program.
We will not try to attack any transactions or programs here. We will just have a close look
at several CALL TRANSACTION statements including their environments and see what CVA
reports.
Static CALL TRANSACTIONs

Dynamic CALL TRANSACTIONs
63
APPLICATION AT RISK
5.1 Exercise 4.1 Static CALL TRANSACTIONs

In the first part of this exercise we will concentrate on static CALL TRANSACTIONs. That
means that the transaction code of the called transaction is either a literal or a constant, i. e.
the transaction code is known when the program is analyzed by CVA.
1. First we want to make you
aware of possible authorization
checks that are associated with
a transaction. - In this part of
the exercise we are always
calling transaction SE38.
Let's have a look at the
definition of this transaction.
Enter SE93 in the okcode field

and hit ENTER to get into the
transaction in which Step 2
transactions are maintained.
2. Enter SE38 in
the Transaction Code field.
3. Click .
Step 3
Note that there is a field

Authorization Object and that its
value is S_DEVELOP. If this field is
filled then at each start of the
transaction over the Okcode field
or the Easy Access Menu an
authorization check on
authorization object S_DEVELOP is
performed (in addtion to the check
on S_TCODE).
4. In order to see the
authorization fields and the
checked values click Step 4
.
64
APPLICATION AT RISK
In this case field ACTVT (activity) is

checked with value 03 (display).
5. Click .
Step 5
6. Click twice to get back to

the Easy Access Menu.
Step 6
7. Double-click
.
Step 7
TEST_SEC261_CALL_TA
Program
Z_SEC261_CALL_TA_STAT.
Double-click
.
Step 8
9. Click on
with the right mouse button and

navigate to Check, then ABAP
Test Cockpit (ATC).
10. Click
.
Step 9
65
APPLICATION AT RISK
11. Okay, four findings! Double-
click on the first
finding:
.
Step 10
12. In the details you can see
what it says: "The authorization
for S_TCODE is not checked
and neither is the authorization
object S_DEVELOP in
thetransaction code editor
(SE93)."
Click
to see the more detailed

explanation. Step 11
13. After looking at this click

to get back.
Step 12
14. Click .
Step 13
Correct! There is no authorization

check. Step 14
15. Click .
Step 15
66
APPLICATION AT RISK
16. Double-click on the second
finding: .
Step 16
17. It says: "The authorization
for the authorization object
S_DEVELOP in the transaction
code editor (SE93) is
notchecked." If you want to you
can have a look at the help
text.
Let's have a look at the source

Step 17
code. Click .
Yes! There is an authorization

check on authorization object
S_TCODE, but the check on the
authorization object that was
specified in transaction SE93
(S_DEVELOP) is missing. Step 18
18. Click .
Step 19
19. Now double-click on the
third
finding: .
Step 20
20. The message is: "The
authorization for the
authorization object S_TCODE
is not checked." You might
want to look at the help text to
see the details.
Now click to see the

source code. Step 21
67
APPLICATION AT RISK
True enough! There is an

AUTHORITY-CHECK on
S_DEVELOP with ACTVT 03, but
there is no check on S_TCODE.
Step 22
21. Click .
Step 23
22. Now let's have a look at the
last finding. This demonstrates
a special situation. Double-click
.
Step 24
23. It reads "The authorization
for S_TCODE is not checked
and neither is the authorization
object S_DEVELOP in
thetransaction code editor
(SE93).This case is not so
critical since the functions of
the transaction are restricted by
inputparameters." (Sorry about
all those missing blanks...) How
about that second sentence?
Click (possibly after Step 25

checking the help text).
Look! This is a CALL

TRANSACTION with a USING
clause. Not the whole functionality
of the called transaction can be
accessed. Often (if not always)
this means that the security risk of
calling this transaction without an
authorization check is lower
than the risk without limiting the
functionality. Depending on the
context it is often okay not to
check the authorization for the
called transaction in such a
case. Therefore, there is a special Step 26
check on such limiting clauses
68
APPLICATION AT RISK
(USING and AND SKIP FIRST
SCREEN).
24. Click .
Step 27
25. In this exercise we look at
the fixed version of the program
right away. We'll present
several ways of getting rid of
the CVA messages. Click
to get to the fixed program.
Step 28
Find FORM cva_114a (about line

10). In the body of the FORM now
there are two AUTHORITY-
CHECKS: the first one on
authorization object S_TCODE for
the called transaction SE38, the
second one on authorization
object S_DEVELOP with ACTVT 03.
If both AUTHORITY-CHECKs are

present, you have a complete
authorization check for the called
transaction. But it is somewhat
cumbersome to code all that.
There are easier ways. Keep on
going... Step 29
Now move forward to FORM

cva_114b (about line 35). Here a
more convenient way is presented.
Just use function module
AUTHORITY_CHECK_TCODE to do
the job. If you use the Pattern
feature of the Development
Workbench it is coded fairly fast.
Moreover, in case the specification
of the authorization check in SE93
is changed then you don't have to
change your coding here. Step 30
We continue with FORM

cva_114c (around line 60). Look
at this short way of specifiying that Step 31
69
APPLICATION AT RISK
you want a complete authorization
check! Just use the clause WITH
AUTHORITY-CHECK. This ABAP
feature is available as of
SAP_BASIS 740 SP 02 and it is
the recommended way. In earlier
releases we recommend the use
of the function module
AUTHORITY_CHECK_TCODE.
Finally we turn to FORM

cva_114d (close to line 70). Here
the developer decided that an
authorization check is not needed.
She or he therefore added the
clause WITHOUT AUTHORITY-
CHECK. Thus, she or he specified
that no authorization check shall
take place. There are two
differences to a CALL
TRANSACTION without the clause
WITHOUT AUTHORITY-CHECK:
1. The developer documented that
she or he thought about the
authorization check (and came to
the conclusion that it shall not take
place).
2. Really no authorization check
will be performed, no matter what
is specified in table TCDCOUPLES,
no matter what profile parameters
say.
And CVA will not complain any
more because of item 1. Step 32
26. Let's see whether the last

sentence is correct.
Click on
with the right mouse button

then navigate to Check and
then to ABAP Test Cockpit
(ATC).
27. Click
Step 33
.
Correct! No more findings from

CVA! We are done with this part of
the exercise. Step 34
70
APPLICATION AT RISK
5.2 Exercise 4.2 Dynamic CALL TRANSACTIONs

Now let's have look at CVA checks on dynamic CALL TRANSACTIONs. In this context
"dynamic" means that CVA can't find out the transaction code of the called transaction
because it is determined at runtime. Then obviously CVA can also not determine which
authorization check was specified in transaction SE93. Therefore the authorization check
can't be analyzed in such a detailed manner as for static CALL TRANSACTIONs. Moreover,
there can be serious security concerns if the transaction code can be influenced from the
outside of the program, especially if the (possibly malicious) end user can determine which
transaction is called.
1. Click
.
Step 2
TEST_SEC261_CALL_TA
Program
Z_SEC261_CALL_TA_STAT.
Double-Click on
.
Sorry for the wrong comments in

the Description column and in the
header of the programs. Step 3
3. Click on
with
the right mouse button and
navigate to Check, then ABAP
Test Cockpit (ATC).
4. Click .
Step 4
71
APPLICATION AT RISK
5. CVA found four problems
again. Let's have a look at each
of them.
Double-click on the first
.
Step 5
This is a priority 1 finding. It must

be serious.
It says: "Variable TCD can be
used externally to control dynamic
transaction calls. No authorization
check was found."
6. In order to see where the
data in TCD comes from click Step 6
.
TCD is a parameter capable of

holding a transaction code.
Step 7
7. Click .
Step 8
8. Click to see the
CALL TRANSACTION
statement.
Step 9
72
APPLICATION AT RISK
Yes! It's a dynamic CALL

TRANSACTION. The transaction
code comes from the parameter
TCD which we saw earlier. The
end user can control which
transaction is called. There is
neither an authorization check nor
a whitelist check on the
transaction code. This really looks
dangerous! Step 10
9. Click .
Step 11
10. Double-click the second
finding .
Step 12
The description of the problem is:

"Variable TCD can be used
externally to control dynamic
transaction calls. Potentially
incomplete authorization check."
11. Let's have a look at the
source code: click .
Step 13
Okay, so there is the CALL

TRANSACTION, but there is also
an AUTHORITY_CHECK before
that. In the AUTHORITY-CHECK
the authorization object S_TCODE
is checked for the relevant
transaction code.
But how about the check on the
additional authorization object that
might have been specified in Step 14
73
APPLICATION AT RISK
SE93? That's why the description
of CVA says something about
"Potentially incomplete
authorization check". We just don't
know because by looking at the
source code we can't tell which
transaction will be called at
runtime.
12. Click .
Step 15
13. Double-click the
third to
see the third finding.
Step 16
The message is: "Variable TCD

can be used externally to control
dynamic transaction calls. No
whitelist check was found."
14. Click to see the
source code.
Step 17
So there is our dynamic CALL

TRANSACTION again. This time
the authorization check is done
with function module
AUTHORITY_CHECK_TCODE. This
is a good idea because the
function can decide at runtime
which transaction shall be called
and it performs the check on the
authorization object from SE93,
too.
But there is no whitelist check on
the called transaction. - One can
argue that the user can call the Step 18
74
APPLICATION AT RISK
transaction over the Okcode field,
too. Yes, that's true. This check is
for those who just want to make
very, very sure. After all, the
priority is low. And you don't have
to use the check if you think this is
too strict.
15. Click .
Step 19
16. Double-click on the
fourth .
Step 20
Look at the description: "No

complete authorization check was
found for the dynamic CALL
TRANSACTION."
17. Let's check the source Step 21
code. To do so click .
Correct. There is no authorization

check, but there is a whitelist
check. You can only call
transactions SE24, SE37, SE38, or
SE80.
As in the last case you might
wonder whether a whitelist check
isn't enough. The priority is 3,
which is fairly low. Step 22
75
APPLICATION AT RISK
18. Click .
Step 23
19. Let's look at the fixed
version of the program. Double-
click
.
Step 24
First scroll to FORM cva_1142

(about line 10) and look at the
coding. There is an authorization
check using function
AUTHORITY_CHECK_TCODE and
there is a whitelist check using
method
cl_abap_dyn_prg=>check_wh
itelist_str( ).
Step 25
Now let's have a look at FORM

cva_114e (close to line
45). There the whitelist check is
also done with
cl_abap_dyn_prg=>check_wh
itelist_str( ). For the
authorization check the clause
WITH AUTHORITY-CHECK is used
in the CALL TRANSACTION
statement. Step 26
The same is done in FORM

cva_114f (about line 65).
Step 27
76
APPLICATION AT RISK
In FORM cva_114g (close to line

90) the solution is not quite the
same: WITHOUT AUTHORITY-
CHECK is used here. Do you
remember the explanation in the
previous part of this exercise? If
we find this clause we assume that
the developer thought about the
situation and found that an
authorization check is not required
in the particular situation.
Step 28
20. Let's see what CVA reports
on this fixed version of the
program. Click on
with the right mouse button,

then navigate to Check and
then to ABAP Test Cockpit
(ATC).
21. Click
. Step 29
Nice to see! CVA doesn't complain

any more! Step 30
Summary

Describe security problems that might be related to static or dynamic CALL
TRANSACTION statements
Fix such problems
Analyze CALL TRANSACTION statements with CVA and explain the results
2016 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://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
77

SEC261 Exercises

Uploaded by

Copyright:

Available Formats

You might also like

SEC261 Exercises

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SEC261 Exercises

Uploaded by

Copyright:

Available Formats

SECURE ABAP DEVELOPMENT: ONE BUG IS

ENOUGH TO PUT YOUR APPLICATION AT

1 Before you start ..................................................................................................................................3

2 Exercise 1: Command Injection ..........................................................................................................4

2.1 Exercise 1.1 Get acquainted with the program ...............................................................................4

2.2 Exercise 1.2 Attack the program .....................................................................................................8

2.4 Exercise 1.4 Create external commands ........................................................................................13

2.6 Exercise 1.6 Retest .........................................................................................................................24

3 Exercise 2: Directory Traversal ..........................................................................................................26

3.1 Exercise 2.1 Create logical file names ............................................................................................26

3.3 Exercise 2.3 Retest .........................................................................................................................35

4 Exercise 3: XSS and XSRF ................................................................................................................38

4.2 Exercise 3.2 Attack the application with XSRF ...............................................................................43

4.3 Exercise 3.3 Attack the application with XSS ..................................................................................45

4.4 Exercise 3.4 Inspect the application ................................................................................................47

4.5 Exercise 3.5 Fix the application - XSS ............................................................................................49

4.6 Exercise 3.6 Retest .........................................................................................................................53

4.7 Exercise 3.7 Fix the application - XSRF ..........................................................................................56

4.8 Exercise 3.8 Retest .........................................................................................................................60

5 Exercise 4: Authorization Checks for CALL TRANSACTION ............................................................63

5.1 Exercise 4.1 Static CALL TRANSACTIONs ....................................................................................64

5.2 Exercise 4.2 Dynamic CALL TRANSACTIONs ...............................................................................71

1 BEFORE YOU START

We recommend to do exercises 1 (Command Injection), 2 (Directory Traversal) and 3 (XSS

Exercise 1 (recommended): Command Injection

Exercise 2 (recommended): Directory Traversal

Exercise 3 (recommended): XSS and XSRF

Exercise 4 (optional): Authorization Checks for CALL TRANSACTION

Level of this session

Goal of this session

2 EXERCISE 1: COMMAND INJECTION

Get acquainted with the program

2.1 Exercise 1.1 Get acquainted with the program

The intended purpose of the program is:

See a list of files in folder D:\Files\Session\SEC261 with invoices

Note that there are five files in

You now see the five files with

This is the invoice!

This message comes from the OS

Note that file Invoice001954.txt

Navigate to the Accept folder and

2.2 Exercise 1.2 Attack the program

2. Click this time.

Look what happened! You see

If you want to, you can verify that

In case you are messing around a

2.3 Exercise 1.3 Inspect the coding and find the

The OS command injection

First the popup for changing the

An operating system command is

In this CALL 'SYSTEM' the

Finally the textual output of the OS

CVA tells us that there is

to see a list of the available

to learn about the problems

7. By clicking you can

This is the position which we saw

2.4 Exercise 1.4 Create external commands

in the SAP Easy Access Menu.