Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

Summary

This guide is to provide developers with an overview of the security aspects and recommendations for ABAP applications. It describes common security errors and weaknesses to watch out for as well as approved procedures so that your application functions “securely”.

Author(s):    Aveek Ghose

Company:   Bristlecone India

Created on: 28/11/2010

Author Bio

Aveek Ghose has 12+ years of IT experience and has worked across the globe in SAP Implementations. Aveek has an MS in Information Systems from George Mason University in USA and a MS in Economics / Mathematics / Statistics from Virginia Tech in USA

Table of Contents

Create a Table of Contents in Microsoft Word. To change, right-click on the TOC and select Update Field.

Security Guidelines for ABAP. 4

About this Document 4

A. The SAP Authorization Concept 4

B. Security Logging Concept 6

C. Handling User names and passwords. 6

D. Authorization Checks. 8

Programming authorization checks in Your Own Developments: 9

AUTHORITY-CHECK: 9

E. Security Logging. 10

System Log. 10

Local Logs. 10

Central Logs. 10

Profile Parameters and File Locations. 11

Function Module: Z_SYSLOG_SAMPLE. 11

ABAP Program: ZBCSAMPL01. 12

Application Log. 12

Version Management 13

Logging Customizing Objects and Tables. 13

Standard Change Documents. 13

Concept: 13

How to use the change document functionality?. 15

Creating Change Documents. 15

Reading and formatting Change Documents. 16

Logging Changes Made Using the Change & Transport System.. 16

Logging Changes Made to User and Authorization Information. 17

Additional Information on Auditing and Logging. 17

Guidelines on using the Logging Framework: 18

F. Securing User Interface. 19

SQL Injection. 19

SQL injection attacks categories. 19

1.  SQL Manipulation: 19

Original SQL statement: 19

Example for SQL injection attack: 19

2. Code Injection: 20

3. Functional Call Injection: 20

1. Protection in Open SQL against SQL Injection. 20

2. Protection in Native SQL against SQL Injection. 20

Input Validation. 21

1. Existence Check. 21

2. Range Check. 22

G. Additional Topics. 22

Executing logical operating system commands in SAP systems. 22

Preventing or Logging List Downloads. 22

1. Customer exit SGRPDL00 (as of Release 3.1I) 23

2. Authorization object S_GUI (as of Release 4.0) 23

Secure Store & Forward Mechanisms (SSF) and Digital Signatures. 23

SAP Virus Scan Interface. 24

Related Content 24

Copyright 25

Security Guidelines for ABAP

This guide is to provide developers with an overview of the security aspects and recommendations for ABAP applications. It describes common security errors and weaknesses to watch out for as well as approved procedures so that your application functions “securely”.

About this Document

This documentation is divided into the following sections:

A. The SAP Authorization Concept

 

The ABAP authorization concept protects transactions, programs, and services in SAP systems from unauthorized access. On the basis of the authorization concept, the administrator assigns authorizations to the users that determine which actions a user can execute in the SAP system, after he or she has logged on to the system and authenticated himself or herself.

To access business objects or execute SAP transactions, a user requires corresponding authorizations, as business objects or transactions are protected by authorization objects. The authorizations represent instances of generic authorization objects and are defined depending on the activity and responsibilities of the employee. The authorizations are combined in an authorization profile that is associated with a role. The user administrators then assign the corresponding roles using the user master record, so that the user can use the appropriate transactions for his or her tasks.

The following graphic shows the authorization components and their relationships.

Explanation of the graphic:

Single Role: Single Role is created with the role administration tool and allows the automatic generation of an authorization profile. The role contains the authorization data and the logon menu for the user.

 

Composite Role: Consists of any number of single roles

 

Generated authorization profile: Is generated in role administration from the role data.

Composite profile: Consists of any number of authorization profiles.

Authorization: Definition of an authorization object, that is, a combination of permissible values in each authorization field of an authorization object. Authorizations allow you to specify any number of single values or value ranges for a field of an authorization object. You can also allow all values, or allow an empty field as a permissible value.

If you change authorizations, all users whose authorization profile contains these authorizations are affected.

 

Authorization object: An authorization object allows complex tests of an authorization for multiple conditions. Authorizations allow users to execute actions within the system. For an authorization check to be successful, all field values of the authorization object must be appropriately entered in the user master record.

 

Authorization field: Contains the value that you defined. It is connected to the data elements stored with the ABAP Dictionary.

 

 

B. Security Logging Concept

SAP Systems keep a variety of logs for system administration, monitoring, problem solving, and auditing purposes. Audits and logs are important for monitoring the security of your system and to track events in case of problems.

SAP Systems offer different frameworks for logging data changes as well as events. For an overview of the different frameworks provided, please see the following table:

Data Type / Events

Framework

Events

Security Audit Log, System Log, Application Log

Repository Data

Version Management

Customizing Data

Table Protocols

Master Data

Standard Change Documents

 

In this document, we shall discuss System Log, Application Log, Version Management, Change Documents and Logging Customizing Objects/Tables in detail.

 

 

C. Handling User names and passwords

User ID and Password Authentication prevents unauthorized access to the system This helps in maintaining data privacy, integrity and safeguards critical information..

User ID and password authentication enables you to enforce access control to the ABAP systems with an authentication mechanism that offers basic access protection with relatively low complexity of security configuration tasks.

The following guidelines can be followed while developing and application in ABAP that requires user authentication.

  1. The password should be displayed in the screen using asterisk .Do not display in plain text.
  2. The password should be always saved using hash-value.
  3. Avoid the administrator to gain access to the password. Use secure hash functions to prevent password recovery.
  4. Do not hard-code passwords in the source code. Passwords in the source code are not protected from inspection.
  5. Do not record passwords in log/protocol/trace files.
  6. Use encryption and decryption feature to protect the password.
  7. Do not use HTTP GET-requests since all parameters will be found in the URL. Use HTTP POST-requests instead. In general, you should avoid transmitting passwords, in particular with every request you send. Use secure mechanisms instead, such as digital certificates for example.
  8. Passwords may also be displayed in readable form when tracing, depending on the trace settings.
  9. Do overwrite passwords in memory, otherwise they might still exist in memory even after completion of the application and could thus be read by a malicious application.
  10. User ID and password should neither be preconfigured nor callable through a pull down menu for the user ID/password entry.
  11. Non-changeable IDs and passwords often form the starting point for attacks on an application’s security. Provide for ID/password change to the application user.
  12. Secure the password when doing and FTP connect. This is done by encrypting the password before passing it to FTP connection.

Before connecting to the FTP Server it is required to scramble the password using the function module HTTP_SCRAMBLE by passing the password, password length and the key it can be any numeric value.

Example:

data: l_hdl TYPE i,
         l_pwd(30) TYPE c,
         l_slen TYPE i,
         l_key TYPE i VALUE 26101957,
         l_cmd(120) TYPE c.

l_pwd = p_pwd.
l_slen = strlen (l_pwd).

 

*Scrample the password
CALL FUNCTION 'HTTP_SCRAMBLE'
  EXPORTING
        source         =   l_pwd
        sourcelen    =   l_slen
          key            =   l_key
  IMPORTING
       destination = l_pwd.

*Connect to FTP server
CALL FUNCTION 'FTP_CONNECT'
     EXPORTING
               user                  = p_user
               password         = l_pwd
               host                 = p_host
               rfc_destination = p_dest
     IMPORTING
               handle             = l_hdl
     EXCEPTIONS
               not_connected = 1
    OTHERS = 2.

IF sy-subrc 0.
       clear l_hdl.
        message i001(zz) with
           'FTP Connect error. Download failed.'(001).
        exit.
endif.

 

 

D. Authorization Checks

To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.

The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:

  1. 1.    Starting SAP transactions (authorization object S_TCODE):

Every time a user starts a transaction from the menu or by entering a command, the system checks whether the user has authorization to start the transaction. If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization.

  1. 2.    Starting reports (authorization object S_PROGRAM):

You can perform additional authorization checks by assigning reports to authorization groups (using report RSCSAUTH).

Example: You can assign all PA* reports to an authorization class for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the appropriate authorization to execute reports in this class.

  1. 3.    Calling RFC function modules (authorization object S_RFC)

When RFC function modules are called by an RFC client program or another system, an authorization check is performed for the authorization object S_RFC in the called system. This check uses the name of the function group to which the function module belongs.

  1. 4.    Table maintenance with generic tools (S_TABU_DIS)

You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, SAP delivers tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

Example: You can assign a table to authorization group Z000 (Use transaction SM30 for table TDDAT). A user who wants to access this table must have authorization object S_TABU_DIS in his or her profile with the value Z000 in the field DICBERCLS (authorization group for ABAP Dictionary objects).

Programming authorization checks in Your Own Developments:

 

AUTHORITY-CHECK:

Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the program, to check whether users have the appropriate authorization and whether these authorizations are suitably defined; that is, whether the user administrator has assigned the values required for the fields by the programmer. In this way, you can also protect transactions that are called indirectly by other programs.

AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the authorization object specified in the AUTHORITY-CHECK. If one of the authorizations found matches the required values, the check is successful.

 

Example:  A programmer wants to make an authorization check before bookings for business customers can be changed.

To do this, the programmer should create authorization fields (ACTVT and CUSTTYPE) and assign for each field defined the value to be checked (02, B). Authorization fields are created under Tools ® ABAP Workbench ® Development ® Other tools ® Authorization objects ® Fields (transaction SU20).

Programmers should also create an authorization object (here S_TRVL_BKS) and assign the authorization object to an object class.

Authorization fields are created under Tools ® ABAP Workbench ® Development ® Other tools ® Authorization objects ® Objects (transaction SU21). Authorization objects can also be created in the Object Navigator (transaction SE80).

You program the authorization check using the ABAP statement AUTHORITY-CHECK.

AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'                 ID 'ACTVT'    FIELD '02'
                ID 'CUSTTYPE' FIELD 'B'.
IF SY-SUBRC <> 0.
MESSAGE E...
ENDIF.


Guidelines:

  1. Assign Authorization group to every transaction, report or table you create.
  2. As a rule, authorization checks should always be used in any program to verify the access level of the user executing the program. They must be positioned when validating input data (if applicable), at the event AT SELECTION-SCREEN.
  3. Existing authorization objects should be used as much as possible.
  4. If you call a transaction indirectly, that is from another transaction, the authorization check is not automatically performed. You must use transaction SE97 to set the check indicator check for the entry for the pair of calling and called transaction to ensure that the called transactions are also subject to an authorization check (see SAP Note 358122).

For more information on the Authorization checks, refer to SAP Authorization Concept.

 

E. Security Logging

System Log

The System Log provides a technical view on the events in a system, such as rollbacks, database read errors, dumps, system errors, warnings, user locks due to failed logon attempts from known users etc. The System Log is written on a continuous basis and may not be deactivated. You can use the log to pinpoint and correct errors occurring in your system and its environment.

Use transaction SM21 to access the system log output screen. With this transaction, you can read any of the messages that are contained in the system logs. You can modify the view to meet your needs.

There are to two different types of logs created by the system log:

• Local Logs

• Central Logs

Local Logs

Each SAP System application server has a local log that receives all the messages output by this server. The system log records these messages in a circular file on the server. When this log file reaches the maximum permissible length, the system log overwrites it, starting over from the beginning.

Central Logs

It is recommended that you also maintain a central log file on a selected application server. Each individual application server then sends its local log messages to this server. The server that you designate to maintain the central log collects the messages from the other application servers and writes these messages to the central log.

The central log consists of two files: the active file and the old file. The active file contains the current log. When it reaches the maximum size, the system performs a "log file switch". It deletes the old log file, makes the previously active file the “old” file, and creates a new active file.

Profile Parameters and File Locations

The table below shows some of the profile parameters for the system log along with their standard values:

Profile Parameters and File Locations for the System Log rslg/local/file

Specifies the location of the local log on the application server.

/usr/sap/<SID>/D20/ log/SLOG<SAP-instance_number>

rslg/collect_daemon/host

Specifies the application server that maintains the central log.

<hostname of main instance>

rslg/central/file

Specifies the location of the active file for the central log on the application server.

/usr/sap/<SID>/SYS/ global/SLOGJ

rslg/central/old_file

Specifies the location of the old file for the central log on the application server.

/usr/sap/<SID>/SYS/ global/SLOGJO

rslg/max_diskspace_local

Specifies the maximum length of the local log.

500,000 bytes

rslg/max_diskspace_central

Specifies the maximum length of the central log.

2,000,000 bytes



This is not a complete list. There are additional profile parameters that refer to the system logs; they all begin with rslg*. However, we do not discuss them all here. You can use the transaction RZ11 to access the rest of the parameters.

For more information on System Log, see System log [SAP Library].

You can also write to the System Log. A sample function module is shown below which writes messages to R/3 System Log.

 Function Module: Z_SYSLOG_SAMPLE

 

This function module has the following two parameters:

  1. URGENCY: LOW or HIGH (Default is LOW)
  2. PROGRAM_ID: Program ID

In case, any error message gets generated, URGENCY parameter needs to be set as HIGH. Otherwise, LOW status can be used for URGENCY parameter.

Also a sample program has been created to call "Z_SYSLOG_SAMPLE."

ABAP Program: ZBCSAMPL01

 

If the program above is run as a background job, something like below is written to R/3 System Log (SM21). JobID will be the job name that is chosen.

ZAE : Batch App Error Urgency=LOW JobID=JOB_NAME01 ProgramID=ZBCSAMPL01

 

No message will get logged to System Log in case program is run in online mode.

 

Application Log

Application Log provides an infrastructure for collecting messages and exceptions in a log, saving, reading and deleting logs in the database and displaying them.

Application Log provides multiple advantages:

- System-wide uniform event logging

- Accessible standardized UI based on ABAP List Viewer (ALV)

- High capabilities for analysis of log data

Application logging records the progress of the execution of an application so that you can reconstruct it later if necessary. Whereas the system log records system events, you can use the application log to record application-specific events.

The application log is a table structure consisting of several tables. Applications write their entries to these tables using SAP function modules. (These modules conform to the SAP authorization concept.)

You can also find out who accessed these function modules over a where-used list by using the report RSFKT100 (function group: SLG0).

Transaction code related to application logging are-

SLG0 -> Used to maintain the log object

SLG1 -> Used to view the log

SLG2 -> Used to delete logs

Example: A typical use of the Application Log is within delivery processing. Negative results of a dangerous goods check are written to the Application Log.

For more information on integrating Application Log in your application, see Application Log – Guidelines for Developers (BC-SRV-BAL).

     

 

Note: Application Log is designed for temporary logs, but not for mission critical data: Data that, for reasons of revision security, have to be available for a long period of time, should not be stored with the Application Log but with the change documents.

 

 

Version Management

You use the version management function for Repository objects when making modification adjustments. The aim of version management is to keep track of all changes made to a Repository object. Therefore, the system automatically creates versions. More detailed information is provided in [Version Management SAP Library|http://help.sap.com/saphelp_nw2004s/helpdata/en/87/0a6b3ae886e511e10000000a114084/frameset.htm].

 

Logging Customizing Objects and Tables

As with business objects, we recommend that you activate the logging of changes to table data for those tables that are critical or susceptible to audits. (See the SAP – Audit Guidelines R/3 FI, in Section 4.3.5, for examples of important tables. This document is available at +http://www.sap.com/germany/aboutSAP/revis/infomaterial.asp+.) You must also explicitly activate this logging. Note the following:

• You must start the SAP System with the rec/client profile parameter set. This parameter specifies whether the SAP System logs changes to table data in all clients or only in specific clients. We recommend setting this parameter to log all clients in your productive system.

• In the technical settings (use transaction SE13), set the Log data changes flag for those tables that you want to have logged.

If both of these conditions are met, the database logs table changes in the table DBTABPRT. You can view these logs using the transaction SCU3. You can use the report RSTBHIST to obtain a list of those tables that are currently set to be logged.

For more information, also see SAP Notes 1916 and 112388.

Standard Change Documents

Business data objects (like Company Code, Purchasing Organization) are changed frequently. We recommend that you log these changes for objects that are critical or susceptible to audits. You may find it helpful, and sometimes necessary, to be able to trace or reconstruct such changes later, for example for investigating or auditing purposes. SAP Systems log changes to business data objects in change documents.

Concept:

For changes to a commercial object to be able to be logged in a change document, the object must have been defined in the system as a change document object. A change document object definition contains the tables which represent a commercial object in the system. The definition can also specify whether the deletion of individual fields is to be documented. If a table contains fields whose values refer to units and currency fields, the associated table, containing the units and currencies, can also be specified.

It must be specified for each table, whether a commercial object contains only one (single case) or several (multiple case) records. For example, an order contains an order header and several order items. Normally one record for the order header and several records for the order items are passed to the change document creation when an order is changed.

The name under which a change document object is created is an object class.

Example: The object class BANF was defined for the change document object "Purchase requisition", which consists of the tables EBAN (purchase requisition) and EBKN (purchase requisition account assignment).

Changes to this commercial object can then be saved in the system under the object values of this change document object, i.e. the object ID and a change document number. The object ID is the key to the object value, i.e. all records which are defined as belonging to a given change document object.

All changes to a commercial object constitute an object value under this key. This is for example the order number for orders or the number range object name for number range objects. All changes to a given order or to a given number range object can be accessed in this way.

Example: The object value BANF with the object ID "3000000000" consists of the records of the tables EBAN and EBKN with the order number "3000000000".

If changes are not yet to be made, but are planned, they can be logged as planned changes. A planned date for the changes can be specified. The planned changes can be analyzed and copied into the tables. You must program the copy yourself.

All logging functions are supported by SAP function modules. The application development must contain certain INCLUDE programs. Old and new statuses are passed to the change document creation. The included function modules determine the changes for all table fields which are flagged as being change-relevant in the Dictionary.

The change document structure is as follows:

  • Change document header
    The header data of the change to an object ID in a particular object class are stored in the change document header. The change document number is automatically issued.
  • Change document item
    The change document item contains the old and new values of a field for a particular change, and a change flag.
    The change flag can take the following values:
    • o U (Update): Changed data. (Log entry for each changed field which was flagged in the Dictionary as "change document-relevant")
    • o I (Insert): Data inserted.
      Changes: Log entry for the whole table record
      Planned changes: Log entry for each table record field
    • o D (Delete): Data were deleted (log entry for the whole table record)
    • o I (Individual field documentation): Delete a table record with field documentation
      1 log entry per field of the deleted table entry, the deleted text is saved
    • Change document numberThe change document number is issued when a change is logged, i.e. when the change document header is created by the change document creation function module (function group SCD0).

Note: The change number is not the same as the change document number. The change document number is issued automatically by the function group SCD0 function modules when a change document is created for a change document object. The change number is issued by the user when changes are planned. The same change number can be used for various change document objects.

How to use the change document functionality?

To activate a change document for an object, perform the following steps:

1. Create the change document. (Use the transaction SCD0.)

2. Activate the change document for the object. (Use data element maintenance: transaction SE11.)

3. Generate an update for the object. (Use the transaction SCD0.)

4. Insert the appropriate calls in the corresponding programs.

To view change documents for an object, also use the transaction SCD0.

 

Creating Change Documents

Object-specific update change documents for a particular object ID are created with the function modules in the function group SCD0.

 

Note: These function modules are called, in the right order, by the object-specifically generated update program, as soon as it is called. They are generally not required for application developments. Only in exceptional cases, in which an individual update is to be programmed, should the change document creation be programmed by the user with these function modules.

CHANGEDOCUMENT_OPEN

Initializes the internal fields for a particular change document object ID.

CHANGEDOCUMENT_MULTIPLE_CASE

Creates change document items. The change data are passed in a table.

CHANGEDOCUMENT_SINGLE_CASE

Creates change document items. The change data are passed in a work area.

CHANGEDOCUMENT_TEXT_CASE

Change document-relevant texts are passed in a structure.

CHANGEDOCUMENT_CLOSE

Writes the change document header for a particular change document ID, and closes the document creation.

CHANGEDOCUMENT_PREPARE_TABLES

Compares the records in two tables, which you pass as TABLE_OLD and TABLE_NEW.


You can specify via a parameter, whether these internal tables should be prepared for the multiple case. Identical records are then deleted, and a processing flag is set in changed records.

 

Reading and formatting Change Documents

Function groups SCD1 and SCD2 provided function modules to read and process Change Documents.

CHANGEDOCUMENT_READ_HEADERS

Reads the change document numbers, with the associated header information, for a particular change document object.

CHANGEDOCUMENT_READ_POSITIONS

Reads the change document items for a given change document object number, and formats the old and new values according to their type.

CHANGEDOCUMENT_PREPARE_POS

Formats a previously read change document item for printing.

CHANGEDOCUMENT_READ

Read change document headers and the associated items for a given object class and format the old and new values according to their type.


For more information, see BC - ABAP Dictionary [SAP Library] and Change documents [SAP Library].

Logging Changes Made Using the Change & Transport System

It is important to keep track of all changes made to your productive system. In addition to application logging, change documents, and table recording, all changes that you make to your productive system using the Change & Transport System are documented in the CTS and TMS logs.

The table below shows the logs created by the Change & Transport System.

Change & Transport System Logs Log (File or SAP System Table)

Description

<transport_directory>/data

Data files containing the contents of the transport

<transport_directory>/cofiles

Status files containing a list of the transport steps

<transport_directory>/log

Logs containing the keys of the transported objects

Table E070 in the SAP System

Header information for the transport request

Tables E071 and E071K in the SAP System

Object list and keys from table entries



Because the transport directory is a central location that contains most of the transport information, we recommend you regularly archive its contents and keep the archives for auditing purposes.

Logging Changes Made to User and Authorization Information

SAP Systems log changes made by a user administrator in non-transparent tables in the database. Access to these tables is protected by the SAP authorization concept. Once these logs have been archived, they are deleted. (Use SAP archiving tools to archive these logs.)

Depending on your release, use either the Authorization Infosystem or transaction SU01 to access these logs. You can view the following changes:

• Changes made directly to a user's authorization.

These are changes made to the profile list in the user's master record. This does not include indirect changes that occur when authorizations or profiles are changed. View the change documents for the profiles and authorizations to check those changes.

• Changes to:

  • The user password (hashed representation only)
  • The user type
  • The user group
  • The validity period
  • The account number

• Changes made directly to profiles or authorizations.

Additional Information on Auditing and Logging

For more information, see User Maintenance Functions [SAP Library].

Type / Number

Title

Audit Info System

SAP Note 77503

Audit Information System (AIS)

SAP Note 100609

Audit Information System (AIS) - installation

SAP Internet

SAP Arbeitskreis Wirtschaftsprüfung und Revision (SAP Auditors User's Group) + http://www.sap.com/germany/discsap/revis/index.htm+

SAP Service Marketplace

SAP Audit Information System + http://service.sap.com/ais+

Security Audit Log

SAP Library

Security Audit Log

System Log

SAP Library

System log



Statistical Records

SAP Library

R/3 Accounting Interface

Application Logging

SAP Library

Create application log

Logging Workflow Execution

SAP Library

WebFlow Engine (BC-BMT-WFM)

Logging Using Change Documents

SAP Library

BC - ABAP Dictionary
Change documents

Logging Changes to Table Data

SAP Note 1916

Logging table changes in R/3

SAP Note 112388

Tables are subject to logging

SAP documentation

SAP – Audit Guidelines R/3 FI / MM

Logging Changes to User and Authorization Information

SAP Library

User Maintenance Functions


Guidelines on using the Logging Framework:

1. Keep in mind, that the aim of a log should always be the traceability of events on the business object of interest.

2. Do not create your own logging framework! Instead, use a logging mechanism already provided by the SAP System. If no standard functionality is provided that fulfills your demands, try to get your required features included into the existing standard frameworks.

3. All data and documents must be assigned to the relevant transactions.

4. Never log passwords in clear text.

5. Logs should not contain potentially confidential data such as credit card numbers or social security numbers. Instead, log such sensitive data in specially protected logs with authorization checks.

6. Logs should only be readable and never be changeable, due to traceability. Make sure, that there is a check implemented to deny unauthorized access to logs.

7. Take into account that log file creation alters performance. Secondly, many users access this log table in parallel. This could cause lock situations even though the users are working with different application tables.

 

 

F. Securing User Interface

SQL Injection

Today all Web applications are accessed by Internet and so face the risk of being exposed to manipulation. Most of the Web applications rely on RDBMS (Relational Database Management System) servers representing a possible vulnerability to SQL injection attacks arising from direct integration of user input into SQL statements without appropriate validation or filtering.

The basis of this vulnerability lies in the creation of SQL commands with character strings. An attacker manages to place SQL commands into an input string that is used as a parameter in a database query. Entry points can be for instance input boxes in Web forms or URLs. The results could be unauthorized information access, information disclosure, unauthorized data modification or data loss.

SQL injection attacks categories

1.  SQL Manipulation:

  • Using the operation UNION.

  • Changing the WHERE clause.

Example:

Original SQL statement:

SELECT fieldlist

FROM table1

WHERE field = 'userinput'.

Example for SQL injection attack:

SELECT fieldlist

FROM table1

WHERE field = 'UNION ALL SELECT other_field

FROM other_table WHERE '='.

2. Code Injection:

• Inserting new database commands into the vulnerable code.

• Append a SQL server EXECUTE command to the malicious code.     

Example:

Original SQL statement:

SELECT *

FROM table

WHERE name = 'userinput'.

Example for SQL injection attack:

SELECT *

FROM table

WHERE name = ' a'; DROP TABLE users; SELECT * FROM table1 WHERE name = '%''.

3. Functional Call Injection:

• Insertion of various database function calls into a vulnerable SQL code.

Importance During ABAP Development

The information in Relational Database Management Systems is stored and retrieved with SQL statements. Therefore the following information will be helpful in ABAP development to circumvent SQL injection attacks:

 

1. Protection in Open SQL against SQL Injection

Open SQL for ABAP already offers some implicit protection against SQL code injection as follows:

  • Since all statements are being prepared, it is not possible to insert malicious code snippets using host variables, as for example the comparison values of a WHERE clause.
  • The SQL statements SELECT, MODIFY, UPDATE, INSERT, and DELETE may all have dynamic clauses. But:
    • The leading keyword of a clause has to be static.
    • No SQL statement can be executed within a clause of another statement completely dynamically.
    • Sub queries can contain dynamic clauses but the leading SELECT keyword is always static.

2. Protection in Native SQL against SQL Injection

Native SQL for ABAP is always static from the ABAP language point of view.      There are no dynamic Native SQL statements at all.

 Due to its static nature, a source code scan may be done:

• For the following fields, e.g. MANDT or CLIENT and

• For the statement EXECUTE PROCEDURE.

Guidelines:

  • Do filter user input, while retrieving user information for your SQL statement.
  • Restrict the dynamic program generation done with the following  ABAP key words
  • Use the ABAP addition ‘CLIENT SPECIFIED’ in a restrictive way, e.g. for client copy.
  • Try to avoid dynamic select queries if possible.
  • Never include any coding like the following, unless you take full control

     over the content of the dynamic clauses:

SELECT (select_clause)

FROM (from_clause) CLIENT SPECIFIED INTO <fs>

WHERE (where_clause)

GROUP BY (groupby_clause) HAVING (having_clause)

            ORDER BY (orderby_clause).

Input Validation

Whenever software processes input, it should make sure that this input is in the expected form. From a functional point of view, this will ensure a high data quality level. From a security point of view; this will prevent unexpected data from altering the intended execution of the program. If input is not validated sufficiently, the application processing the data might crash or could be tricked into performing unwanted tasks.

Guidelines:

Basically you should validate your input parameters or select options in report programming and the screen fields in dialog programming. To achieve that goal, you have to provide a validation check for each input variable.

You can do following checks to validate the input fields.

1.Existence check

2.Range check

1. Existence Check

It must not be possible to attack the application simply by omitting a necessary variable. So, first of all, your validation routine shall check if the variable of interest exists in database. If the check cannot find a value in the database you can stop further processing.

 

Example:

For Parameters in report you can give following check

  AT SELECTION SCREEN ON FIELD(P_MTART)

    SELECT SINGLE MTART FROM t023

     WHERE MTART = P_MTART

2. Range Check

You should check if the variable's values are in the correct range. Clearly, this is only possible for variables with a definable range of values (like numbers). It is imperative to define the limits exactly here. For all input you should think about where the boundaries lie.

In addition to the above checks, you can also provide F4 Help for every screen field. To create and display input help, you can either link search helps to fields. When you create screen fields with reference to ABAP Dictionary fields, the corresponding search helps are then automatically available. If a field has no search help, the ABAP Dictionary still offers the contents of a check table, the fixed values of the underlying domain, or static calendar or clock help. You can also call ABAP dialog modules in the POV event of the screen flow logic and program your own input help.

G. Additional Topics

Executing logical operating system commands in SAP systems

Users can execute logical operating system commands as external commands in SAP system.

Both the maintenance and execution of external commands are protected by SAP system authorizations. External commands can be maintained and executed either on-line (from the CCMS menu, transaction SM49) or in ABAP programs, using special function modules.

 

Guidelines:

To call external commands in your own developments, you should use the function module SXPG_COMMAND_EXECUTE instead of CALL_SYSTEM.

With SXPG_COMMAND_EXECUTE, you can enforce a more extensive authorization check by including authorization profile arguments in the parameter ADDITIONAL_PARAMETERS. In addition, unlike CALL_SYSTEM, SXPG_COMMAND_EXECUTE does not use RFC for its purposes.

 

Preventing or Logging List Downloads

There are two types of list downloads in SAP Systems:

- Standard list download

This category is accessed either over the menu option System à List à Save à Local file or other implementations of the function module LIST_DOWNLOAD.

- Application-specific implementations for downloading

Often applications implement their own download methods (for example, an Excel download) that they can protect with their own authorization objects. These implementations use the function modules DOWNLOAD or WS_DOWNLOAD.

Guidelines:

Although you cannot prevent a user from saving data from a displayed list to a file (for example, creating a screen shot and saving it in a separate file), you do have the following options to hinder a user from downloading large SAP System lists:

1. Customer exit SGRPDL00 (as of Release 3.1I)

As of Release 3.1I, you can use the customer exit SGRPDL00 to prevent or log list downloads. For example, you can explicitly program restrictions such as users or user groups in the customer exit or use an authorization object. You can also implement a trace function if you wish.

The customer exit SGRPDL00 applies to both the standard list download option as well as application-specific implementations.

2. Authorization object S_GUI (as of Release 4.0)

As of Release 4.0, you can use the authorization object S_GUI to prevent a user from downloading lists.

Using the S_GUI authorization object applies as follows:

It applies only to the standard list download function and not to application-specific implementations.

It also does not consider what type of list the user downloads; if the user is allowed to download lists, he or she can download all lists.

 

Secure Store & Forward Mechanisms (SSF) and Digital Signatures

The SAP Web AS ABAP provides Secure Store & Forward (SSF) mechanisms as internal means to protect arbitrary data in the SAP system. SAP applications can use the SSF mechanisms to secure data integrity, authenticity and confidentiality.

By using SSF functions, you can "wrap" data and digital documents in secure formats before they are saved on data carriers or transmitted over (possibly) insecure communication links. The data must not remain within the SAP System; if you save the data in a secure format in the SAP System, it remains in its secured format even if you export it out of the system.

SAP provides the SAP Security Library (SAPSECULIB) with its systems for providing digital signatures.

SSF provides the following ABAP function modules from the SSFG function group for creating and verifying digital signatures (PKCS#7), and functions for encrypting and decrypting documents:

SSF_SIGN / SSF_KRN_SIGN

Creating digital signatures

SSF_VERIFY / SSF_KRN_VERIFY

Checking digital signatures

SSF_ENVELOPE/SSF_KRN_ENVELOPE

Encrypting documents

SSF_DEVELOPE/ SSF_KRN_DEVELOPE

Decrypting documents



For a detailed description about these SSF function modules as well as example code about how to call the appropriate function modules see the Secure Store and Forward (SSF) Programmer's Guide.

SAP Virus Scan Interface

The SAP NetWeaver platform provides the Virus Scan Interface (VSI) architecture which can combine different products, systems, and platforms to scan your applications for viruses.

Virus scanning should be performed every time potentially polluted data is imported via input channels into the SAP system. Possible input channels are:

  • File upload from front-end PC’s or file system on the application server
  • File upload via Internet
  • Document exchange via RFC, XML, XI

On the SAP side, different VSILIB layers are used to include the ABAP and Java worlds, and to deal with platform dependencies in the integration of the virus scan interface. For further information see [Architecture of the Virus Scan Interface SAP Library|http://help.sap.com/saphelp_nw2004s/helpdata/en/8d/67f441c6fb6324e10000000a1550b0/frameset.htm].

Related Content

Please include at least three references to SDN documents or web pages.

Reference 1

Reference 2

Reference 3

Copyright

© Copyright 2010 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group 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.

  • No labels