GRC
HR
SCM
CRM
BI


Article

 

How SAP Protects Your Web Applications from Security Vulnerabilities

by Dr. Jurgen Schneider | SAPinsider

October 1, 2004

by Dr. Jurgen Schneider, SAP AG SAPinsider - 2004 (Volume 5), October (Issue 4)
 


Dr. Jurgen Schneider,
SAP AG

Today, most applications are realized as Web applications so that — whether they are deployed globally over the Internet or in an intranet only — they can be accessed from any ordinary Web browser. The ubiquitous access and worldwide availability of Web services is due in no small part to the HTTP protocol. HTTP is a fairly simple and standardized protocol, and it can carry all types of content through security firewalls across the globe. In fact, the simplicity and standardization of the HTTP protocol and its user interface are some of the major benefits of Web applications.

For these same reasons, however, Web applications also pose a substantial security risk for any company, as well as for software manufacturers and service providers. Many of the most common security breaches are the result of exploited Web application security vulnerabilities.

Setting up a Web application is essentially an invitation to the world to send HTTP requests through your firewall and to your server. There is absolutely no guarantee that these requests are legal or contain valid data. As shown in Figure 1, a Web request contains several fields in its header (for GET and POST requests) and content data in the body (for POST requests). All of these fields may contain invalid data or can be used to launch an attack that, for example, puts overlong data in some of the fields, or uses specially crafted URLs or content to hijack user sessions or inject malicious script code into your application.1

Header:

HTTP Protocol Version
GET / POST
URL : http://www.somesite.com/somepath?par1=val1...parN=valN
Hostname
Path
Parameters / Values
Cookies
...


Body:

form / fields / XML
Figure 1
A Web/HTTP Request

The Open Web Application Security Project (OWASP) is an open-source, noncommercial effort to provide information and guidance around the development of secure Web applications.2 Their report entitled "The Ten Most Critical Web Application Security Vulnerabilities," as well as their guide to building secure Web applications and Web services, are "must-reads" for any Web application programmer or other person interested in Web application security (see a synopsis of OWASP's top 10 list in the following sidebar).3 So how does SAP help you address some of these pressing security issues?

SAP Countermeasures for Potential Vulnerabilities in Your Landscape

With Web application security vulnerabilities looming, SAP is taking the initiative to protect Web applications running on the SAP NetWeaver platform, as well as the platform components themselves. In the following sections, I'll describe some of OWASP's top 10 security vulnerabilities in more detail. For each security issue, I'll also provide a corresponding countermeasure that discusses the steps SAP is taking to ward off these risks.

The OWASP Top 10 Most Critical Web Application Security Vulnerabilities

The Open Web Application Security Project (OWASP) created this list4 to help organizations understand and improve the security of their Web applications. According to their report, the top 10 most critical Web application security issues in 2004 are:

  1. Unvalidated Input

  2. Broken Access Control

  3. Broken Authentication and Session Management

  4. Cross-Site Scripting (XSS) Flaws

  5. Buffer Overflows

  6. Injection Flaws

  7. Improper Error Handling

  8. Insecure Storage

  9. Denial of Service

  10. Insecure Configuration Management

Broken User Authentication
How do you prevent unauthenticated users in a Web application from seeing information they shouldn't see?

The simplest solution is the user/password mechanism, with password digests or password encryption at the server side, rules to establish and enforce password policies (minimal length, special characters, etc.), and procedures for handling forgotten passwords. To improve the strength and robustness of authentication, digital certificates or two-factor authentication with or without hardware tokens can be used, as well as biometrics such as fingerprinting, face recognition, or retina scan. Usually, however, these approaches are too expensive for an ordinary Web application, and are only used for environments with special security requirements.

SAP Countermeasure: Central Routines
The SAP NetWeaver platform features central routines for user authentication and single sign-on that cannot be bypassed. Both the user management of the ABAP runtime and the Java User Management Engine (UME) enforce the authentication of users for applications that have been deployed with authentication required. Different authentication strengths can be configured, such as user/password or digital certificates, and certified interfaces exist to plug-in partner solutions. In addition, the security of the central logon routines has been reviewed internally at SAP as well as by external consultants.

Broken Access Control
Access control, also called authorization, refers to how a Web application grants user access to content, functions, and services. The consequences of a flawed access control scheme — unwanted altering or deletion of content, unauthorized execution, or complete takeover of site administration — can be devastating.

Therefore, a structured approach to authorization along with corresponding enforcement and change processes are essential. As a default, if you try to maintain access differently, it simply should not be allowed. Particular authorization focus has to be given to administrative interfaces.

SAP Countermeasure: Central Routines
The SAP NetWeaver platform has been traditionally strong in this area, with central routines for authorization. In the ABAP programming language and runtime environment, application developers are provided with the language statement AUTHORITY-CHECK to enforce authorization and extensive tool support for creating and maintaining authorization roles.

The SAP J2EE Engine features J2EE standard security roles for authorization, as well as supports the Java permission model of J2SE and Access Control Lists (ACLs) with the SAP User Management Engine (UME). These authorization mechanisms and tools are used by Java applications and by the SAP Enterprise Portal. The implementation of the SAP authorization concepts and the administrative user interfaces has also been subject to external security assessments.

Insecure Configuration Management
What strategy do you follow for patch installation and support packages? As far as security is concerned, installing new patches in a timely fashion is important — if you don't, your software manufacturer cannot provide you with current security updates to protect your users and systems.

Weakly protected default accounts and other insecure default system settings (for file or directory browsing, for example) also fall into this category of vulnerabilities.

SAP Countermeasure: Improved Patches, Support Packages, and the SAP Security Guide
The SAP default settings for secure installation and configuration have been reviewed and modified over the past years. Where modification of defaults was not immediately possible, the SAP Security Guide, available via the SAP Service Marketplace, contains detailed information about recommended security settings to be changed after installation.

The availability of patches, hot fixes, and support packages for the SAP NetWeaver platform, or any of its components, can be easily looked up on the SAP Service Marketplace (http://service.sap.com) and downloaded for installation. Customers will also find information about security updates in the patch descriptions.

Why HTTP Leads to Security Concerns

Figure 2 illustrates the basic architectural principles of a Web application.

Web requests from clients may come from an intranet or over the Internet (if the server running the Web application can be reached over the Internet). Usually, HTTP and its secure variant HTTPS (HTTP over the Secure Sockets Layer Protocol) are the only protocols that can pass through firewalls.

HTTP, however, also transparently passes request and response data to and from clients and the server, rendering most of the "perimeter security" — achieved with firewalls, load balancers, network address translators, and Web dispatchers — useless.

Figure 2
Basic Architecture of a Web Application

Buffer Overflows
Successfully launching a buffer overflow attack is not an easy task — flaws in either the Web application or in the underlying technology platform or operating system must be exploited.

A buffer overflow attack tries to corrupt the execution stack of a Web application, usually by sending overly long input in one of the fields of an HTTP request. An attacker will try field after field until finding one where no proper bounds-checking for the available buffers is performed on the server side. This results in the overwriting of the application's internal memory and the failure of the Web application process.

With repeated trials and carefully crafted input, the execution stack is eventually corrupted so that the attacker's code in the request is placed onto the stack exactly where the instruction pointer will execute the next program statement. This allows the attacker to completely take control of the target computer.

SAP Countermeasure: Source Code Reviews and Testing
SAP has conducted detailed source code reviews (also consulting external specialists) and extensive black-box and white-box testing to discover and eliminate buffer overflow problems in the Web-facing technology components of SAP NetWeaver, such as SAP Web Application Server, SAP Internet Transaction Server, and SAP Enterprise Portal.

Where concrete buffer overflows have been detected, they were fixed as quickly as possible and a patch was provided to customers. Patches are available at http://service.sap.com/patches.

Cross-Site Scripting (XSS) Flaws
Cross-Site Scripting (XSS) occurs when an attacker sends malicious code (usually script code, such as JavaScript or Visual Basic Script) to another Web application user, using an original Web application as a relay. As such, a user's browser cannot find out that the script code comes from an untrusted source and will execute the code.

This can happen if the Web application does not carefully validate the input it receives and "replays" this input to other users without removing — or at least encoding — any unwanted script code. The malicious code has full access to any cookies, session tokens, or other sensitive information that belongs to the document domain, and can even rewrite the content of the HTML page.

How can an attacker inject a malicious script into a Web application? XSS attacks come in two categories — stored and reflected (see Figure 3):

  • Stored XSS can occur in an application where message forums or mail services are based on central storage and retrieval. The attacker simply puts his malicious script into a mail or message, which then is stored in the server's database. If a user retrieves the message from the server, the script is executed in the victim's browser.

  • Reflected XSS is found in error pages or search results displays, where injected input is immediately reflected to the victim user via the target server. Here, the malicious input takes another route — perhaps in a URL contained in an email, or through any other link a victim user clicks on. The malicious code is often hidden by different encoding, such as Unicode, where the user does not immediately recognize the script's opening and ending characters (<, >).
Figure 3
A Cross-Site Scripting (XSS) Attack Scenario

XSS attacks exist in many forms, and their effects can be anything from annoying to disastrous — from reading information from the client computer's file system to compromising a user's entire account by stealing the user's session cookie.5

SAP Countermeasure: Source Code Reviews and Testing
SAP has conducted detailed source code reviews (also consulting external specialists) and extensive black-box and white-box testing to fight XSS issues.

Developers of Web applications and of the central tools to build Web user interfaces, such as Business Server Pages (BSP) and Web Dynpro, have been instructed on how to prevent XSS by carefully validating input and encoding output to disable unwanted active scripting elements.

These efforts should at least make it very, very difficult for an attacker to still find useful sources for XSS in SAP technology components.

Injection Flaws
Like XSS, directing an attack against the application or the server itself is another variant of injecting malicious script code into a Web application. Again, if the Web application does not carefully validate input, an attacker can issue operating system commands on the server, submit SQL statements against the local database, or place calls to backend systems.

This can have very severe effects, since database content can be read without authorization and content can be created or corrupted. For example, an attacker could create a new user account and give himself administrator rights.6

SAP Countermeasure: Source Code Reviews and Testing
As for buffer overflows and XSS, developer education in combination with source code reviews and extensive testing is applied at SAP to avoid injection flaws. This also led to improvements of input validation routines for some SAP NetWeaver components; these updates have been released as patches (available at the SAP Service Marketplace).

SAP's Standard Global Security Measures

In addition to these specific countermeasures, SAP also makes broader strides to combat Web security vulnerabilities:

  • The SAP-wide Solution Production Standard is an internal security standard that applies to all the requirements for secure development of SAP applications. This ensures that security in SAP products is included from the design phase through development and deployment.

  • SAP provides security training courses for developers, as well as various other documentation and architectural support for SAP development groups.

  • To verify that no design and implementation flaws with respect to security exist in any of the SAP NetWeaver components, SAP has been performing security assessments with external experts. The results of these assessments, together with internal and customer problem reports concerning security issues, are fed into a security response process. As part of this process, the SAP development leads for each component are directly informed about potential security issues in their respective areas.

  • Finally, SAP has published and maintained the SAP Security Guide, which provides SAP customers with a collection of guidelines and recommendations pertaining to SAP system security. Review the guide carefully and apply the recommendations in your own installations — it's available at http://service.sap.com/securityguide.

Summary

We've examined numerous Web application security vulnerabilities to give you a more concrete idea of the kind of attacks that today's Web-based solutions must endure. Withstanding these types of attacks requires careful review of application design and program sources, along with solid solutions and extensive testing.

SAP has been putting increasingly high efforts into Web application security. These measures must be complemented by secure installation, configuration, and administration of productive SAP NetWeaver installations at customer sites.

I invite you to participate in an open and timely dialog about security requirements, issues, and best practices. Contribute to the SAP security response process by using the SAP online problem tracking and notes system available via the new support portal on the SAP Service Marketplace at http://service.sap.com/support.

From there you can review SAP Notes (http://service.sap.com/notes), submit security problem reports (http://service.sap.com/message), and download patches (http://service.sap.com/patches). In case of doubt or if you have any questions, just send an email to security@sap.com.


1For more information on the various ways that potentially dangerous active elements can be embedded in an HTTP request, read the "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" at www.cert.org/advisories/CA-2000-02.html.

2 Visit the Open Web Application Security Project (OWASP) Web site at www.owasp.org.

3 To download the top 10 list and the Web application guide, visit www.owasp.org/documentation/guide.html. These documents contain explanations and hints far beyond the scope of this article and point to further sources on this subject.

4 Copyright © 2004. The Open Web Application Security Project (OWASP). All Rights Reserved.

5 For examples of XSS and more information on how to close XSS vulnerabilities, consult "The Ten Most Critical Web Application Security Vulnerabilities: 2004 Update" at www.owasp.org/documentation/topten.html.

6 Again, consult the OWASP report at www.owasp.org/documentation/topten.html for more examples of SQL injection attacks and information on how to cure them.


Dr. Jürgen Schneider has been involved in the design and implementation of SAP security functions since 1996. Since 1998, he was the Development Manager for SAP Web Application Server Security in SAP's Technology Development. In 2003 he has been appointed Vice President for "Security and Identity Management" in the SAP NetWeaver foundation. You can reach him at j.schneider@sap.com.

 

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ