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
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. 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. 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:
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.
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.
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 SAP Notes/KBAs
SAP Note 83020: What is consulting, what is support
SAP KBA 12345: This is an example KBA link
Use this structure to help you compose your contributions for WIKI and at the same time will ensure spelling and grammar.