Security threats pose a tremendous risk on your SAP system. Without the proper preparation and programming, you could be opening your system to the potential of malicious attacks. Based on my experience, you should adhere to best practices in the following five areas to ensure that your SAP NetWeaver system is secure:

• Password protection
• Front-end security
• Access control
• Data communication and security
• Proper documentation

I’ll go through some best practices and tips to secure your system in each of these areas.

Password Protection

If passwords aren’t complex enough, they represent a security lapse for an application. Applications should not display the password in plain text. Passwords should be displayed in a format that is not readable to the ordinary eye, such as by using asterisks. Also, passwords should not be saved or transmitted in plain text to prevent possible interception and deciphering. It is dangerous to have plain-text passwords stored in the memory of the application because hackers can capitalize on this information and perpetrate illegal acts. It is a best practice to use secure hash functions that disallow password recovery. You should not use a custom-developed or non-standardized password encryption mode when programming. Under no circumstance should passwords form part of the source program because if someone can read the code, they can also read the password, especially if it is not encrypted.

You should not store passwords in any directory or file, including log, protocol, profile, parameter, and trace files. Anybody who can access the directory or file can also use the authentication details. It is good to avoid transmitting passwords via networks. If you must transmit them, use secure and trusted mechanisms. You should use an HTTP POST request instead of an HTTP GET request when submitting personal data. HTTP POST requests make cross-site request forgery attacks more difficult because the parameters used are not stored in the URL or browser. Cross-site request forgery is known to trick a user’s browser to send HTTP requests to a target Web site by capitalizing on the user’s trust for the Web site. To avoid storing passwords in files and plain text, consider using trusted authentication mechanisms such as digital certificates, Secure Sockets Layer (SSL), and logon tickets for user authentication.

You should also discourage the entry of logon details (especially passwords) via a drop-down button. The management of username and passwords must be flexible. An application should offer functionality for changing not only the username, but also the password when the need arises. Capabilities that force control (e.g., password history and complexity) should be available within the application.

Front-End Security

Most applications are Web enabled, which makes front ends more vulnerable to malicious attacks because HTML pages can easily be manipulated by ActiveX and VBScripts if not properly secured. This kind of attack is known as cross-site scripting (XSS). XSS attacks occur when a malicious script is executed on a Web server and the malicious script is then propagated on other clients. ActiveX controls are small building blocks of programs or add-ons used to create distributed applications that you can use on the Internet. Java or VBScript can pose potential dangers in a browser-based system. They can hijack sessions, manipulate cookies, intercept user inputs, crash browsers, redirect Web addresses, or even send the browser into an unending loop. Furthermore, the risk associated with an XSS attack includes theft of account details, impaired system performance as a result of file modification, and installation of harmful programs on your system.

It is a best practice to adopt technologies and strategies that avoid XSS attacks when developing programs. You can achieve this by restricting input based on defined codepages, variables, and metacharacters. The system must validate all data on the server side (not on the client side) and check all input values against the defined and acceptable white list (i.e., a repository for data checks), data type, field length, data range, and URL. Also, you should enclose input values on HTML pages in quotation marks to make malicious attacks more difficult.

It is good to avoid installing ActiveX if it is not really needed because ActiveX makes Web pages susceptible to malicious attacks. Programmers who develop their own HTML codes can use the utility function in class CL_HTTP_UTILITY and util class com.sap.security.core.server.csi.util.StringUtils to guide against XSS attacks for ABAP and Java, respectively, by encoding SAP outputs. You can use Internet Transaction Server (ITS)-dependent BusinessHTML functions such as xss_url_escape, xss_html_escape, xss_wml_escape, and xss_js_escape to prevent against XSS attacks. These functions use strings as inputs and return corresponding escape strings. You can also use the encode attribute on the HTMLB content bag to protect Business Server Page (BSP) extensions such as HTMLB, XHTMLB, and PHTMLB from a possible XSS attack. The HTMLB framework is the recommended standard for front-end elements in SAP NetWeaver Portal.

Furthermore, canonicalization helps to secure the user interface against a malicious attack by ensuring that input values are presented in an appropriate standard representation before inputs are validated. It is important that programmers be aware of the modus operandi of their interpreters in use because each interpreter is unique, especially as it relates to how user inputs are treated.

Devising strategies to prevent SQL injection against the database is worth considering when developing applications. SQL injections are attacks on the database system as a result of the insertion of a malicious SQL statement or the creation of a malicious SQL statement with character strings. SQL injection can be in the form of:

• SQL manipulation: A SQL statement can be manipulated by simply changing the WHERE clause or using the UNION operation in SQL statement
• Function call injection: A function call injection involves the entry of malicious function calls into an SQL code
• Code injection: Code injections can occur as a result of the injection of malicious database commands into an SQL code or by using the EXECUTE command in a malicious code

You can prevent SQL injection attacks by defining codepages that identify characters that are malicious in a code. User input should be intelligently restricted, validated, and controlled. Errors reporting should be appropriately and securely configured to ensure that critical system information that hackers can use is not disclosed to the outside world. The restrictive use of the ABAP addition CLIENT SPECIFIED for specific activities is encouraged. The enclosing of user input in quotation marks goes a long way toward circumventing SQL injection attacks. Open SQL and Native SQL for ABAP have laudable capabilities that you can apply to prevent SQL injection attacks, especially those related to code injection. This is because Open SQL does not allow the insertion of malicious code snippets and Native SQL performs code scanning. In the Java environment, Open SQL for Java and Open SQL/SQLJ works in almost the same way as Open SQL for ABAP. Java Database Connectivity (JDBC) provides a standard interface for database developers. You can use it to prevent SQL injection in the Java environment. For example, consider using java.sql.preparedstatement as opposed to java.sql.statement, especially when specifying input values in the WHERE clause of SQL statements. The former statement supports the encoding of SQL strings, thereby enhancing application code security.

It is good practice to prevent directory traversal attacks in applications. Directory traversal (i.e., path traversal) attack can occur as a result of the manipulation of a URL by using special characters, cookies, and HTTP request headers with the intent of accessing files that are not supposed to be accessed. Although the access control lists and root directory of Web servers help to circumvent directory traversal attacks, you should ensure that user inputs are not used to access file paths. If user inputs are used in exceptional cases, ensure that a valid list of acceptable path names exists.

You should prevent the poisoning of cookies (i.e., tampering with the data stored in cookies) as much as possible. A cookie plays an important role in the transfer of data variables between the Web browser and the Web application and vice versa. You can also use it to manage session IDs, authentication, and maintenance of user specific information. You can store cookies either in a file on a client until it expires or stored in the buffer of a client pending when the session terminates. It is a best practice to send cookies in an encrypted format using secure HTTPS to circumvent cookie manipulation.

You should use the session tracking and management functionality provided by SAP NetWeaver to manage sessions. You can use the session identifiers known as sap-contextid and JSESSIONID in SAP NetWeaver ABAP and Java, respectively, to uniquely identify and track user sessions. You can activate session timeout functionality by maintaining the system parameter rdisp/plugin_auto_logout system parameter in ABAP and setting an appropriate value in the web.xml of the application in Java. You should build application idle timeout and user logout functionalities into applications to prevent user impersonation. You can set the system parameter rdisp/gui_auto_logout via transaction RZ11 to allow you to define the timeline of inactivity within which the system automatically logs out a user. While it is a bad practice to store confidential data in cookies, if you must do so, use a hash-based mechanism that allows for unidirectional encryption.

The SAP NetWeaver Application Server ABAP offers functionality that validates whether a URL from an external input can be accepted by checking URL-like parameters against the white list patterns available in table HTTP_WHITELIST. It is important to state that table HTTP_WHITELIST is empty by default and no checks are performed against it. Web Dynpro for ABAP and Java has capabilities for automatic integration of output encoding and they also perform data type validation, thus eliminating the need for an application to carry out a data type check. This represents a laudable security control because you do not have to configure additional encoding functionality manually.

Access Control 

The access right of Web application users should be properly managed and well controlled. It is important that data, files, and information are controlled in an application to guide against a malicious attack on the system. The privileges granted to an application on the operating system level should be controlled appropriately. Conscious effort should be made to ensure that the operating system security is not compromised. The granting of privileges to sensitive application and system files should be restricted to only authorized users, especially as it relates to modifying program files or accessing confidential files.

It is a best practice to ensure that once confidential data is deleted on the operating system, it should not be recoverable. Instead of storing confidential data on the operating system level, consider storing personal information on the database within the application. This approach helps in enforcing application security, authorization, event logging, and activity monitoring. You should discourage the use of hidden HTML fields, especially when the intent is to cover up some details from the user. Although hidden HTML fields are not visible to the user, they can be seen in the source code. Also, malicious scripts can use hidden HTML fields to perpetrate havoc within the application.

While it is good for applications to have built-in search functionality, appropriate controls must be in place to ensure that the displayed result does not contain what a user is not supposed to see, especially as it relates to sensitive data and confidential information. Access to sensitive system information in error messages can be dangerous for an application. Error messages should not divulge system details that can become handy for hackers to perpetrate illicit activities in the systems.

Data Communication and Security 

Applications should be designed in such a way that data is well protected within a client session and more importantly after the end of a session. Hackers can leverage data and information in temporary files to carry out malicious activities on the system or commit theft of confidential and sensitive data. It is not a good practice to store personal information on clients because clients are remotely located and as such, control over them is minimal when compared to application servers.

You can use Secure Store and Forward (SSF) to enforce data integrity, privacy, and confidentiality during and after dialog processing. The functionality provides high security and protection for data regardless of where it is stored (e.g., Internet, database, and external files). SSF is based on public-key technology in which a private key and a public key are used to encrypt and decrypt data and information. It allows you to digitally sign a document and provides unparallel protection when encrypted data is transmitted over public and insecure network such as the Internet.

SAP NetWeaver supports the use of SSF for data encryption and digital document signing. You need third-party security products (e.g., smart cards and tokens) to optimize the functionality. Secure Network Communication (SNC) is an application-level security that provides secure authentication and data confidentiality capabilities. SNC provides encryption for Dynamic Information Action Gateway (DIAG) and Remote Function Call (RFC) protocols. SSL also provides encryption for HTTP protocols, thereby securing the transmission of data over the Internet via HTTPS protocols. The key used for decrypting data must be dynamic to ensure that information is not eavesdropped. It is dangerous to have a static key for encrypting and decrypting data because when the key is known, all communications can be intercepted and deciphered. This allows for easy decryption of the supposedly encrypted data. As a matter of fact, it is a good practice to store encrypted data and the key separately to prevent a single point of attack. It is a best practice to use any of these encryption technologies because they are proven, tested, and adhere to industry standards. Avoid using encryption methods that are self developed, self tested, and self approved. They might conflict with generally accepted global standards and affect the globalization and acceptability of your program.

Logging and tracing are important functionalities that provide monitoring capabilities for system settings and events in SAP NetWeaver. Logging records normal and exceptional events.

You can generate logs for system events, repository data, master data, and customizing data. They help in troubleshooting, error handling, and system administration. Logs should not contain confidential and sensitive data such as passwords (in plain text), credit card numbers, or bank account details. The program should offer flexibility for logging, in terms of log activation or deactivation. Logs can grow very large rapidly depending on the amount of information or events to be logged. The way that you manage log file size and growth in terms of maintenance activities (deleting and archiving) is worth considering when developing applications. Because the intent of logs is to track and trace events and system changes, they should not be modifiable.

The SAP NetWeaver ABAP supports different tools and functionalities for logging and tracing. Version management functionality in SAP NetWeaver ABAP is an automated process that allows you to log changes to a repository object by performing modification adjustment by creating different versions of it. You can activate the table logging functionality by enabling the system parameter rec/client via transaction RZ11 and activating table change logging via transaction SE11. It allows you to track who made a change, what was changed, and when it was changed. Activating table logging for all tables can impair performance, so it is expedient that you identify tables to be logged when developing your application. Changes to master data are available in the corresponding master data change document. Where possible, it is a best practice to integrate your application log with the SAP NetWeaver standard application log. Report SBAL_DOCUMENTATION provides details about application log integration.

Logs are also useful for audit purposes, especially security audit logs that provide information that assists in tracking changes and user activities such as successful logon attempts, RFC calls to function modules, and even file downloads. You can activate the security audit log via the system parameter rsau/enable and read the content of the log via transaction SM20. Other types of logs available include system logs and application logs. Use transaction SM21 to access the system log to detect and analyze errors in your system and its environment. The system log records technical system events such as operation mode switch, ABAP dumps, and so on. Application logs, which you can analyze using transaction SLG1, provide details of messages, exceptions, and errors. They are important for developers because they report events that occur during program execution. The retention of logged data should determine the use of the application log as a service in your programs because it is more suitable for data that is stored on a short-term basis.

SAP NetWeaver Java also supports tools for logging and tracing of events in the system.

• SAP Logging API, which is available via the Java package com.sap.tc.logging, is an invaluable tool for performing logging and tracing functions in the SAP NetWeaver Java environment. The J2EE Engine in the SAP NetWeaver environment supports the configuration of the behavior and output destination of logging without your writing Java source code. You can activate logging for your application by performing a sequence of activities which includes defining the source area for logging and tracing, assigning severity level to the source, defining output destination, and inserting log and trace messages with appropriate severity level.
• Developers can use an application trace, which is available as a service in the J2EE Visual Administrator, for debugging a J2EE application during program runtime
• You can also use Single Activity Trace (SAT), which you can activate in the performance tracing service of the visual administrator, to trace individual user requests, especially those that run distributed across multiple components
• SQL Trace provides performance analysis of SQL statements during the program development process. You can activate SQL Trace in the log configurator service of the Visual Administrator or via URL (https://:/SQLtrace > Switch SQL Trace On/Off).
• SAP application statistics provide information that helps in troubleshooting performance problems in applications. It is displayed in the performance tracing service of the Visual Administrator.

You can use SAP NetWeaver Virus Scan Interface, an API built into the SAP NetWeaver platform, to mitigate the risk associated with virus attack. The upload of files from different sources such as external drive, Internet, or spreadsheets can allow a virus attack. This is also true for the exchange of data via RFC and SAP NetWeaver Process Integration. The idea behind this functionality is to enhance system security by integrating external anti-virus software with the SAP NetWeaver to perform virus scans on both SAP and non-SAP data. The virus scan profile allows you to define specific virus scan requirements for your application. The customization of your own virus scan profile is guided by the data upload requirement and behavior of your application. You should not define your own virus scan profile if your application uploads data that is parsed by your own application. Also, you should define your virus scan profile if your application accepts files such as Microsoft Word 2007 (.docx) and Excel (.xlsx) for upload. You can define the virus scan profile in customizing via transaction VSCANPROFILE in ABAP and Visual Administrator in Java.

Proper Documentation

A clear focus is needed in developing and implementing security in an application. A definition of the security requirements of the application should be an integral part of the system life cycle. A thorough analysis is laudable because different applications have different security and authentication needs. For example, the security needs of a banking Web application might be different from an employee self-service system. You need to document these requirements, including the intent of the security infrastructure. You also need to follow a framework to make the development successful. Then carry out an appropriate test to ensure that documented requirements are effective within the application.

Proper documentation helps the users of your application leverage defined security functionalities. If an application has security features that only the developer is aware of, the feature is as good as non-existent. As a matter of fact, these hidden functionalities can act as security risks to the application. It is best practice to have proper documentation of functionalities, user calls, and parameters used in an application. For example, the documentation should contain details of the technology (SNC or SSL) used to enforce security in the application and password rules (minimum number of characters and forbidden characters).

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.