Registration

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

Purpose

The Purpose of the Document is to understand what Cross-site Request forgery is and the scope of this vulnerability in SAP Business Objects XI 3.1

Overview

The Document contains

.1.What is Cross-site Request forgery ?
 2. Examples of  CSRF
 3.Limitations of CSRF
 4.Situation with Business Objects XI 3.1

What is CSRF or XSRF?

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

Example and Characteristics

The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.[1] For example, one user, Joe, might be browsing a chat forum where another user, Jill, has posted a message. Suppose that Jill has crafted an HTML image element that references an action on Joe’s bank's website (rather than an image file), e.g.,
Jill: Hello Joe! Look here:
   <img src="http://bank.example.com/withdraw?account=Joe&amount=1000000&for=Jill">
If Joe’s bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Joe’s browser to load the image will submit the withdrawal form with his      cookie, thus authorizing a transaction without Joe’s approval.
A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Joe’s Web browser which is confused into misusing Joe’s authority at Jill's direction.
The following characteristics are common to CSRF:
• Involve sites that rely on a user's identity
• Exploit the site's trust in that identity
• Trick the user's browser into sending HTTP requests to a target site
• Involve HTTP requests that have side effects
At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.
CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript.

 

Limitations


Several things have to happen for cross-site request forgery to succeed:
1. The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin that allows referer spoofing (which is rare).
2. The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
3. The attacker must determine the right values for all the forms or URL inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
4. The attacker must lure the victim to a Web page with malicious code while the victim is logged into the target site.
Note that the attack is blind; i.e., the attacker can't see what the target website sends back to the victim in response to the forged requests, unless they exploit a cross-site scripting or other bug at the target website. Similarly, the attacker can only target any links or submit any forms that come up after the initial forged request if those subsequent links or forms are similarly predictable. (Multiple targets can be simulated by including multiple images on a page, or by using JavaScript to introduce a delay between clicks.)
Given these constraints, an attacker might have difficulty finding logged-in victims or attackable form submissions. On the other hand, attack attempts are easy to mount and invisible to victims, and application designers are less familiar with and prepared for CSRF attacks than they are for, say, password-guessing dictionary attacks.

Situation with SAP Business Objects XI 3.1

The CMC does use encrypted URL and user session specific tokens for the main and most risk prone forms (server management, user rights assignment, etc) and as such are not CSRF vulnerable.Infoview is not using the same token protection because of scalibility concerns (*). The portal does however have other forms of protection for the most important user actions, including (not limited to) : 

password change : the user is prompted for his old password, making the POST information totally unpredictable;

object scheduling (any destination but specifically to FTP or unmanaged server) : the URL is protected by an unpredictable delta id. The delta id is calculated by an combination of the delta between default scheduling settings and user-defined, and a number is shared by all portal users and incremented each time a user sends a schedule request;

object (report, folder, etc) deletion, folder creation and other forms throughout Infoview are relying on the Java Server Faces (JSF) technology and use a view id. That view id is an unique identifier generated by the JSF runtime. The correct value has to be submitted with the request, otherwise the business logic is not executed.

(*) It involves a lot of string parsing, which would potentially be happening at every single user action, dramatically impacting the performance of the system. 

As of today, the two following user actions are known as vulnerable although it is detabable whether it carries much risk. They can be either worked around, or are harmless to the system, or not compromising any data: 

scheduling an object with the default settings : the delta would be nil and therefore no delta id not present. This action should be harmless to the system as we assume (and recommend) the default scheduling options do not expose any data outside of a controlled and secured area.As raised by CGI and New York City, the logout URL is confirmed as vulnerable but, here again, the action does not expose or compromise any secured data.

Related Content

Related Documents
http://en.wikipedia.org/wiki/Cross-site_request_forgery

Related SAP Notes/KBAs

SAP Note 83020: What is consulting, what is support

SAP KBA 12345: This is an example KBA link

https://service.sap.com/sap/support/notes/1544441
__________________________________________________________________________________________________________

Use this structure to help you compose your contributions for WIKI and at the same time will ensure spelling and grammar.

  • No labels