SAP NetWeaver Developer’s Guide Release: SAP NetWeaver 2004s
Secure Programming – ABAP
Document Version 1.0 – May 2006
SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com
© Copyright 2005 SAP AG. All rights reserved. No part of this publication may be reproduced or
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP
transmitted in any form or for any purpose without the
NetWeaver, and other SAP products and services
express permission of SAP AG. The information
mentioned herein as well as their respective logos are
contained herein may be changed without prior notice.
trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the
Some software products marketed by SAP AG and its
world. All other product and service names mentioned
distributors contain proprietary software components of
are the trademarks of their respective companies. Data
other software vendors.
contained in this document serves informational purposes only. National product specifications may vary.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
These materials are subject to change without notice. These materials are provided by SAP AG and
IBM, DB2, DB2 Universal Database, OS/2, Parallel
its affiliated companies ("SAP Group") for informational
Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
purposes only, without representation or warranty of any
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP,
kind, and SAP Group shall not be liable for errors or
Intelligent Miner, WebSphere, Netfinity, Tivoli, and
omissions with respect to the materials. The only
Informix are trademarks or registered trademarks of IBM
warranties for SAP Group products and services are those
Corporation in the United States and/or other countries.
that are set forth in the express warranty statements accompanying such products and services, if any.
Oracle is a registered trademark of Oracle Corporation.
Nothing herein should be construed as constituting an additional warranty.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Disclaimer Citrix, ICA, Program Neighborhood, MetaFrame,
Some components of this product are based on Java™.
WinFrame, VideoFrame, and MultiWin are trademarks or
Any code change in these components may cause
registered trademarks of Citrix Systems, Inc.
unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these
HTML, XML, XHTML and W3C are trademarks or
components.
®
registered trademarks of W3C , World Wide Web Consortium, Massachusetts Institute of Technology.
Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not
Java is a registered trademark of Sun Microsystems, Inc.
be modified or altered in any way.
JavaScript is a registered trademark of Sun
Documentation on SAP Developer Network
Microsystems, Inc., used under license for technology
You can find this documentation at
invented and implemented by Netscape.
https://www.sdn.sap.com/irj/sdn/devguide2004s
MaxDB is a trademark of MySQL AB, Sweden.
Secure Programming – ABAP
2 / 50
Contents
Secure Programming – ABAP .........................................................................................4 PURPOSE .............................................................................................................................................................. 4 TARGET GROUP ................................................................................................................................................... 4 ABOUT THIS DOCUMENT ..................................................................................................................................... 4 DISCLAIMER ........................................................................................................................................................ 5
Secure Programming ........................................................................................................6 PASSWORD SECURITY.......................................................................................................................................... 6 SECURE STORE AND FORWARD MECHANISM (SSF) ............................................................................................ 9 SECURITY LOGGING .......................................................................................................................................... 11 SAP VIRUS SCAN INTERFACE ............................................................................................................................ 15
Secure User Interface ....................................................................................................21 CROSS-SITE SCRIPTING (XSS)........................................................................................................................... 21 SQL INJECTION ................................................................................................................................................. 30 INPUT VALIDATION ........................................................................................................................................... 35 CANONICALIZATION .......................................................................................................................................... 38 DIRECTORY TRAVERSAL ................................................................................................................................... 40 URL ENCODING AND MANIPULATION ............................................................................................................... 43 COOKIE MANIPULATION .................................................................................................................................... 46
Further Information .........................................................................................................49 Disclaimer ..........................................................................................................................50
Secure Programming – ABAP “Security is like adding brakes to cars. The purpose of brakes is not to stop you: it’s to enable you to go fast!” ---Gene Spafford
Purpose This documentation provides an overview about developing secure applications based on the SAP NetWeaver platform. It describes common security errors and weaknesses to watch out for as well as approved procedures so that your application functions “securely”. Target Group The target group of this documentation are ABAP developers who are developing applications based on the SAP NetWeaver platform. This guide is primarily aimed at developers in the IT departments of customers, consulting houses, and partners. About this Document This documentation is divided into the following sections: •
•
Secure Programming o
Password Security
o
Secure Store & Forward Mechanism (SSF)
o
Security Logging
o
SAP Virus Scan Interface
Secure User Interface o
Cross-Site Scripting (XSS)
o
SQL Injection
o
Input Validation
o
Canonicalization
o
Directory Traversal
o
URL Encoding and Manipulation
o
Cookie Manipulation
For each topic mentioned above the security vulnerability is described. Then any standard solutions that exist from the SAP NetWeaver platform are presented, including functions and interfaces that need to be used. If no solution is available from the SAP NetWeaver platform, recommendations are provided about appropriate security measures to take. In addition, example code is provided where appropriate and links to existing documentation are given.
Secure Programming – ABAP
4 / 50
Disclaimer All description of secure programming and all sample code (for the purposes of this clause hereinafter referenced together as the "Examples") contained in this document are for illustrative purposes only. These Examples have not been thoroughly tested under all conditions. SAP, therefore, cannot guarantee or imply reliability, serviceability, or function of these Examples. Any use of these Examples is at your own risk and responsibility and SAP shall not be liable for any damages caused by the use of such Examples unless such damages have been caused by SAP's gross negligence or willful misconduct.
Secure Programming – ABAP
5 / 50
Secure Programming Implementing Security Developers common problem is a lack of time, they usually struggle with design, functionality, performance, usability and so one. Therefore, they spend less of time to think about security aspects and possible insecure software design or insecure programming techniques. The attackers on the other hand have all the time to find out the software vulnerabilities. Although a clever design is certainly a good starting point, it’s not enough to achieve secure software: Implementation has tricks of its own. In the following sections we’ll give you support to secure your code. In particular this guide addresses common errors and weaknesses and describes approved procedures.
Password Security Description Passwords are a familiar way to verify the identity of users and systems. Passwords are simpler and cheaper than other, more secure forms of authentication like smart cards or biometric scanners. They provide a simple, direct means of protecting a system or an account. However, there are also known weaknesses. Password cracking is the process of figuring out or breaking passwords in order to gain unauthorized access to a system or an account. Many passwords are not random but trivial to guess. A more technical way of cracking passwords is through network sniffers, which look at the raw data transmitted across the network and decipher its contents, including passwords. Furthermore, attackers can try to crack passwords offline when they can access the hashed password string during transmission or in an insecure password store. The password-based approach of authentication can be used to protect applications when the following advices are taken into consideration.
What Do I Get from the SAP NetWeaver Platform? The overall process of password-based identification and authentication is as follows. First, the application asks for the user identification, usually the user’s account name. Then the password is read and a hash-value of the password is calculated. Often a salt, that is a random string of data, is added in order to prevent an attacker from testing known dictionary words. Some password components also wipe the memory in which the password was stored. Finally, it has to be checked, whether the hashed user input and the stored hash value of the password match. If yes, the user is successfully authenticated. The SAP NetWeaver platform provides such an authentication mechanism as described above. Generally, it is recommended to use the existing password authentication mechanism provided by the SAP NetWeaver platform instead of implementing something on your own.
Secure Programming – ABAP
6 / 50
What Do I Need to Do? The issues described above necessitate that you handle user IDs and passwords carefully. The following recommendations may help to prevent that an unauthorized person will gain access to your system: 1. Are no passwords displayed in plaintext? •
Do not display passwords in plaintext, use asterisk instead.
2. Are no passwords saved or transmitted in plaintext? •
Passwords transmitted in plain text can be intercepted, rendering the user ID and password method of identification insecure. It is better to transmit passwords using the Secure Network Communications (SNC) protocol.
•
Do not save passwords in plaintext.
•
Avoid the administrator to gain access to the password. Use secure hash functions to prevent password recovery. → The SAP NetWeaver platform uses secure hash values to store passwords.
•
Do not invent your own coding to encrypt the original password.
3. Are no passwords hard-coded in the source code? •
Use a technology such as one-time passwords.
•
Apply a changeable password in a central function, such as transaction SM59.
•
Do not invent your own encryption algorithm.
4. Are no passwords recorded in log/protocol/trace files? •
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.
•
Take into account that the Web Server logs all the URLs.
•
Passwords may also be displayed in readable form when tracing, depending on the trace settings.
5. Are passwords in plaintext overwritten in memory once they are no longer used? •
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.
6. Are user ID and password neither preconfigured nor callable through a pull down menu at the start of the application? •
Better avoid to use any pull down menu for the user ID/password entry. This is in particular important for the password.
7. Can all passwords, IDs and user names be changed? •
Non-changeable IDs and passwords often form the starting point for attacks on an application’s security.
Secure Programming – ABAP
7 / 50
Further Information 1. Checklist for secure programming (section “Password Security”) https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/4ab8b3bb-06010010-7b82-e392df20392a
Secure Programming – ABAP
8 / 50
Secure Store and Forward Mechanism (SSF) Description You can use digital signatures and document encryption in your application to provide for document security. These documents are then protected as independent objects using Secure Store and Forward (SSF) mechanisms. This means that the documents are secured irregardless of where they are stored or how they are transported. You can apply a digital signature to any digital document or message, which is comparable to a handwritten signature on a paper document. The digital signature uniquely identifies the signer of the document or message. It is not forgeable and also protects the integrity of the document. If the document is changed after being signed, then the digital signature is no longer valid. Also, the signer of such a document cannot deny having signed the document at a later time. In addition, you can encrypt documents so that only intended recipients can view their contents. The functions for digital signatures and document encryption use public-key technology. Public-key technology is based on the use of a key pair; one of which is a private key and the other is a public key. The private key is to be kept secret; the public key is to be distributed as desired. More detailed information on public-key technology is provided in Public-Key Technology [SAP Library].
What Do I Get from the SAP NetWeaver Platform? The SAP NetWeaver platform 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. More detailed information on the Secure Store and Forward Mechanism (SSF) is provided in Secure Store & Forward Mechanisms (SSF) and Digital Signatures [SAP Library].
Restrictions SSF requires the use of a third-party security product to provide its functions. As the default provider, we deliver the SAP Security Library (SAPSECULIB) with SAP Systems. The SAPSECULIB, however, is limited to providing digital signatures only. For digital envelopes, encryption, or crypto hardware (for example, smart cards or crypto boxes), you need to use a external security product. SAP provides the SAP Cryptographic Library free of charge, or you can use a certified partner product. The SAP Cryptographic Library is available for download on the SAP Service Marketplace at http://service.sap.com/download. Note however, that this library underlies German export regulations and is therefore not available to all customers. For information about supported partner products, see the SAP-certified partners (http://www.sap.com/softwarepartner).
Secure Programming – ABAP
9 / 50
There are also laws in various countries that regulate the use of cryptography and digital signatures. These laws are currently controversial and may change. You need to keep yourself informed on the impact these laws may have on your applications, and make sure that you are aware of any further developments.
What Do I Need to Do? The SSF Library for the ABAP Stack is used in applications that are written in ABAP. It supports the functions for creating and verifying digital signatures (PKCS#7), and functions for encrypting and decrypting documents. The SSF Library for the ABAP stack is available as of SAP Basis 4.0. SSF provides the following ABAP function modules from the SSFG function group: ¾ 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. For further guidelines regarding digital signatures please also see Digital Signatures in SAP Applications.
Further Information 1. Digital Signatures and Encryption [SAP Library] 2. Secure Store & Forward Mechanisms (SSF) and Digital Signatures [SAP Library] 3. Guideline: Digital Signatures in SAP Applications https://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000668332&_SCENA RIO=01100035870000000112&_OBJECT=011000358700000952762004E 4. Secure Storage and Forward (SSF) Programmers’ Guide https://service.sap.com/~sapdownload/011000358700003611992003E/SSFProgrammers Guide.pdf 5. Secure Storage & Forward / Digital Signatures User’s Guide http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/icc/Secur e%20Store%20and%20ForwardDigital%20Signatures%20User%20Guide.pdf 6. Secure Store & Forward (SSF) API Specifications http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/icc/Secur e%20Store%20and%20Forward%20SSF%20API%20Specifications.pdf
Secure Programming – ABAP
10 / 50
Security Logging Description 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.
What Do I Get from the SAP NetWeaver Platform? Depending on the data type SAP Systems offer different frameworks for logging data changes. In addition, several frameworks exist for logging events. For an overview of the different frameworks provided, please see the following table:
Data Type / Events
Framework
1. Events
Security Audit Log, System Log, Application Log
2. Repository Data
Version Management
3. Customizing Data
Table Protocols
4. Master Data
Standard Change Documents
5. Transaction Data
(Note: No framework is provided. It is not useful to log transaction data.)
What Do I Need to Do? Every time a log is required to trace data changes or system events, verify, whether a logging mechanism is already provided by the SAP System which fulfills your demands. The use of standard functionality should be preferred. In this case, you automatically inherit all functions from the framework (for example, archive routines for change documents). a) Security Audit Log The Security Audit Log is available on the SAP Web Application Server. The tool is designed for auditors who need to take a detailed look at what security-related events have occurred in the SAP System. The Security Audit Log may be activated or deactivated. By activating the audit log, the system keeps a record of those activities the customer considers relevant for auditing. The information may be evaluated by an audit analysis report. The Security Audit Log enables insight in the daily work processes and system events, such as failed logon attempts or transaction starts. The audit log's main objective is to record: •
Security-related changes to the SAP System environment For example: ¾ Changes to user master records ¾ Changes to the audit configuration
Secure Programming – ABAP
11 / 50
•
Information that provides more transparency For example: ¾ Successful and unsuccessful dialog logon attempts ¾ Successful and unsuccessful RFC logon attempts ¾ Application server start and stop ¾ Download of files
•
Information that enables tracing of a series of events For example: ¾
Successful and unsuccessful transaction starts
¾
Successful and unsuccessful report starts
¾
RFC calls to function modules
More information is provided in Security Audit Log [SAP Library]. b) System Log Beyond the Security Audit Log the ‘normal’ System Log is written in the SAP system too. The System Log provides a more technical view on the events in a system, such as rollbacks, database read errors, dumps etc. The System Log is written on a continuous basis and may not be deactivated. Each event is recorded as a system log message under the system log numbers AU (or BU or CU since Release 6.10). More information is provided in System Log [SAP Library]. c) Application Log The Application Log is a tool that collects messages, exceptions, and errors. This information is organized and displayed in a log. Application logs are useful to bring situations, that occur at runtime of an application program, to user’s attention. In standard SAP Systems you will find application logs in QM, for example. If you provide the Application Log (events) as an infrastructure in your own programs, take into account, that it is used to temporarily store messages. 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 [SAP Library] (changed data). Developers who want to integrate the Application Log in their applications will find a detailed documentation on all function modules and archiving techniques using archiving object BC_SBAL and an overview of callback routines executing the report SBAL_DOCUMENTATION in transaction SA38. More information is provided in Application Log – Guidelines for Developers (BC-SRV-BAL). d) Audit Info System (AIS) The Security Audit is not to be confused with the Audit Info System (AIS). The Audit Info System (AIS) [SAP Library] is designed to facilitate and improve the audits performed by external auditors as well as internal auditors. The system is designed for Business Auditors, System Auditors and Security Administrators; even many System Administrators find it a useful tool.
Secure Programming – ABAP
12 / 50
e) 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]. f) Table Protocols The analysis of logged customizing objects allows the customer to answer the following questions: ¾ Who has changed customizing settings? ¾ When and what has been changed? For further information refer to Logging Customizing Objects [SAP Library]. Log files are written, in case the following prerequisites are met: ¾ The rec/client parameter in the system profile is set to allow data logging. ¾ Logging is active for the table. For technical settings see Activate/Deactivate Table Change Logging [SAP Library]. When developing your application, you have to decide for which tables you want to activate logging. You can activate table change logging in the technical settings of the table using transaction SE11. g) Standard Change Documents Many business objects are changed frequently. Therefore, it is often useful and even necessary to be able to trace the changes made. This logging is carried out with change documents. Detailed information is provided in Change Documents [SAP Library] and Creation of Events When Change Documents are Written [SAP Library].
How to Use a Logging Framework? When using a logging framework, the following advice may help: 1. Keep in mind, that the aim of a log should always be the traceability of events on the business object of interest. 2. All data and documents must be assigned to the relevant transactions. 3. Never log passwords in clear text. 4. 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.
How Not to Do It? As mentioned before, don’t 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. All existing standard logging frameworks provided by the SAP System offer the following features that are required by a good logging framework: Secure Programming – ABAP
13 / 50
1. Logging and archiving should be customizable, because every customer has different requirements. Even writing of log entries may be activated and deactivated in the system. 2. 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. 3. Logs should contain information about: ¾ The reason for logging. ¾ The user, who has created the log entry. ¾ Date and time, when the log entry has been written. ¾ System and client where the log entry occurred. 4. Consider how logs should be handled, i.e. whether they can be deleted or be archived. 5. 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.
Further Information 1. SAP Web Application Server Security Guide (Chapter 6.4 Auditing and Logging) https://service.sap.com/~form/sapnet?_FRAME=CONTAINER&_OBJECT=01100035870 0001994272004E 2. SAP documentation about BAL_* Application Log Function modules Execute program SBAL_DOCUMENTATION in transaction SE38 within the mySAP ERP 2005
Secure Programming – ABAP
14 / 50
SAP Virus Scan Interface Description 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
What Do I Get from the SAP NetWeaver Platform? The architecture of the Virus Scan Interface (VSI) allows you to combine different products, systems, and platforms to scan your applications for viruses. 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].
Figure 1: Elements of the Virus Scan Interface
The graphic below clarifies the layer structure of the SAP Virus Scan Interface (SAP VSI API) and shows which parts are delivered by SAP, and which by the relevant partners.
Secure Programming – ABAP
15 / 50
Figure 2: Software Layers of the Virus Scan Interface
The SAP Virus Scan Interface (SAP VSI API): •
Is accessed by partner products directly with the scan engine or indirectly using a separate virus scan adapter.
•
Contains the functions required to configure and to initialize the scan engine.
•
Provides the parameters and data for every virus scan.
•
Processes the check result.
ABAP or Java application programs start virus scans with dedicated classes and methods of the SAP virus scan interface, which, in turn, call a virus scan server or the J2EE Engine directly using RFC.
What Do I Need to Do? To be able to use SAP’s Virus Scan Server, you must maintain data in the Implementation Guide. 1. Scanner Groups Scanner groups bundle together one to many Virus Scan Servers or Business Add-In implementations (BADI VSCAN_INSTANCE) of scan engines. On this level, a set of configuration parameters can be maintained that contain initialization parameters for the Virus Scan Servers. Be aware that customizing settings are cross-client as the controlled entities (Virus Scan Servers or BADIs) are cross-client. Detailed information is available in Defining Scanner Groups [SAP Library]. 2. Virus Scan Servers The Virus Scan Server is an RFC-Server, that holds the connection to the scan engine using the certified Virus Scan Adapter. It is running either as part of the application server as separately started executable or as standalone program and Secure Programming – ABAP
16 / 50
communicates over RFC with the application servers. A Virus Scan Server entry always belongs to a single scanner group. The detail screen of the Virus Scan Server maintenance shows a summary of the scan engine type and the supported features. The Server may be manually started, stopped and re-initialized from the customizing. To set up customizing see Defining Virus Scan Servers [SAP Library]. The Virus Scan Interface may be integrated into own developments using the methods out of class CL_VSI. For detailed information refer to Integrating the Virus Scan Interface into Customer Developments [SAP Library]. Furthermore, the following SAP notes may help to clarify questions concerning the Virus Scan Interface: SAP Note 817623, SAP Note 786179. 3. Virus Scan Profiles For each application own Virus Scan Profiles may be created in customizing, mapping Scanner Groups to Virus Scan Servers or customer defined Business AddIns. Profiles have to be its own namespace delivered by SAP /
/ Profiles can be: ¾ marked as Default Profile ¾ activated or deactivated ¾ assigned to reference profiles. More information is supplied in Defining Virus Scan Profiles [SAP Library]. If customizing is set up for the active Virus Scan Interface, you may integrate the VSI in your application using the class CL_VSI. In order to perform a virus scan for a byte sequence check in an ABAP program, the following steps are required: 1. Use the static method GET_INSTANCE to generate an instance of the virus scan interface, which is based on the specified virus scan profile. Every application that implements VSI should use its own virus scan profiles so that the virus scan functions can be activated and deactivated for each application. Examples * Retrieve scanner instance for my application DATA: lo_scanner TYPE REF TO cl_vsi. CALL METHOD cl_vsi=>get_instance EXPORTING if_profile = '/MYPACKAGE/MYFUNCTION' IMPORTING eo_instance = lo_scanner EXCEPTIONS profile_not_active = 1 OTHERS = 2. CASE sy-subrc. WHEN 0. "OK
Secure Programming – ABAP
17 / 50
WHEN 1. * The system administrator has disabled virus scanning * for * my application '/MYPACKAGE/MYFUNCTION'. * What must happen now depends on whether virus scanning * is optional or mandatory for your application. * In the first case, you can ignore it, in the second * case * you must react with an error. This exception has a * SY-Message that leads the user to the right place in * customizing. WHEN OTHERS. * This situation is always an error (misconfiguration) * of the Virus Scan Interface. It must be reported. * Use the SY-Message that always accompanies the * exception. ENDCASE. 2. Now you can perform virus scanning of data that are present in XSTRING objects. Examples * Retrieve scanner instance CALL METHOD lo_scanner->scan_bytes EXPORTING if_data
= lf_data
if_do_clean
= ‘ABAP_TRUE’
IMPORTING ef_scanrc
= lf_scanrc
EXCEPTIONS OTHERS
= 1.
The result of the scan is any of the three situations: ¾ The return code LF_SCANRC has the value CL_VSI=>CON_SCANRC_OK. This indicates that the scan task was successfully performed and no infection was found. ¾ The return code LF_SCANRC has another value. Some most prominent error codes are present as CON_SCANRC_… attributes in class CL_VSI. Using method CL_VSI=>GET_SCANRC_TEXT a short explanation can be retrieved for an error code. In general, this situation must be treated as failed scan.
Secure Programming – ABAP
18 / 50
¾ An exception is thrown: This indicates a configuration error or severe problem during virus scanning. It must always be reported, and the virus scan is to be considered as failed. If the parameter IF_DO_CLEAN is set with the value ABAP_TRUE, a cleanup should be performed. In case of successful cleanup , the parameter EF_DATA returns EF_SCANRC = CON_SCANRC_CLEAN_OK. If the parameter IF_DO_CLEAN has the value ABAP_FALSE, it should only be checked. Beside the above mentioned method SCAN_BYTES, two other methods for virus scanning are available within the class CL_VSI: ¾ Method SCAN_FILE for scanning a local file on the application server. ¾ Method SCAN_ITAB for scanning an internal table with row type X or C. For further information about DDIC objects, tables, views, search helps, messages, function modules, class library reports and transactions of the Virus Scan Interface see the online documentation in the ABAP-Workbench. Information on integrating the Virus Scan Interface into customer developments are available in Integrating the Virus Scan Interface into Customer Developments [SAP Library] . A commented source code for the application of the VSI for scanning files that are uploaded from a workstation is accessible in Commented Example Program [SAP Library] .The report RSVSCANTEST contained in the system performs this task in an appropriate form and can also be used as a demonstration object.
Be aware of the following problems If an input channel does not implement the Virus Scan Interface itself, then a successive application may implement its own VSI. But it should be avoided that a document is scanned multiple times during its way into the system, in case the component delivering the data has performed a virus scan already.
Security Audit Log triggered by VSI Class CL_VSI automatically creates entries in the Security Audit Log for found infections and scan errors, together with the following information: ¾ about the profile, ¾ the profile step, which allows the detection of the scanner-group, ¾ the kind of virus, that was found (if available with internal virus ID of the scan engine), ¾ the user name and timestamp. The logged messages are located in message class VSCAN, using the System Log messages BU8 and BU9 (created in SE92). The severities are set to “High” and “Medium” respectively, for the Audit class it is set to “Miscellaneous”.
Secure Programming – ABAP
19 / 50
Further Information 1. SAP Tutor, Configuration of the RFC destination http://service.sap.com/~sapidb/011000358700003298652004E.sim SAP Tutor, Configuration of the Virus Scan Server http://service.sap.com/~sapidb/011000358700003298672004E.sim SAP Tutor, Virus Scan Trace http://service.sap.com/~sapidb/011000358700003298692004E.sim 2. SAP Note 786179 (Data security products: Application in the antivirus area) 3. SAP Note 817623 (Integrating a virus scan in SAP applications) 4. SAP NetWeaver Virus Scan Interface (NW-VSI) http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/icc/NWVSI%20Interface%20Documentation.pdf
Secure Programming – ABAP
20 / 50
Secure User Interface The trouble with Web applications is that you want users to come to your site and interact with the application. If the user makes unexpected entries (such as script commands) that the application does not handle correctly, an attacker could cause the server or the client/browser to perform unintended actions. Therefore, the first guideline for developing a secure Web application is: ‘Never trust any information coming from the outside, and never assume anything about it’. All security decisions must have the underlying assumption that anything that can theoretically be manipulated by someone or something will be manipulated in reality. For example, if an attacker makes entries like manipulated SQL statements and the application does not filter the entries, he can get access to the internal database (SQL Code Injection). The following sections describe examples for different vulnerabilities in Web applications and explain how to prevent them with secure programming.
Cross-Site Scripting (XSS) Description Cross-Site Scripting (XSS) attacks are set out to manipulate HTML pages by injection of malicious script code or by other indirect techniques, such as redirection to another server, logical attacks e.g. replacing images or changing style sheets. Attackers look out for HTML pages, where user input is written back to the HTML page, e.g. during a logon failure the logon screen is displayed a second time. These examples demonstrate the potential security vulnerabilities for XSS attacks, if user’s input is written back to the HTML page. Due to the fact that HTML is based on tags the browser may even interpret and execute Javascript or ActiveX controls, which might contain malicious SCRIPT commands. Those commands are executed by someone else opening this manipulated HTML page. The consequences of ActiveX attacks are as follows: ¾ The hacker might read/change/delete files on some other user’s local drives. ¾ Application actions might be executed under some other user’s privileges. ¾ The hacker might install other applications like Trojan horses. In case of Java- or VBscript potential attacks may be: ¾ To send the browser in an endless loop. ¾ To redirect the browser to a document.location.href property.
different
page
by
overwriting
the
¾ To access all user’s inputs (credit card numbers, etc.) and to send it to a rogue server. ¾ To access the user’s cookies (session hijacking, cookie manipulation). ¾ To insert new Script tags as output between tags, which for example create new event handlers that are executed when certain events occur.
Secure Programming – ABAP
21 / 50
Examples Example Code 1:
Click me! Example Code 2:
Example Code 3: