Here's some suggested non-normative text to address clickjacking in the spec or best practices. Please review both the clarity of the wording, and the feasibility of the suggested steps to protect against the attack:
----------
Security issue: clickjacking (UI redress attack).
This vulnerability can occur when a malicious (or compromised) web application embeds an OSLC delegated dialog (or UI preview) in their own web page, obscures it from the user's view by covering it with other layers or components, then tricks the user into clicking on a button in the unseen iframe by encouraging them to click on components that they can see. The user is intending to click on the components that they can see, but the malicious web page is "hijacking" those clicks because they really activate components in the embedded iframe.
This vulnerability requires that the user loads a malicious webpage in their browser. This can happen in a number of ways, including:
-
The user is tricked into loading the page directly, believing it to be trustworthy.
-
A trusted page is compromised and "infected" to perform this attack.
-
An OSLC server administrator is tricked into configuring their server to trust a malicious server. Their server then loads the malicious page as a delegated dialog or rich UI preview, which then embeds the page under attack in a further iframe.
There are always two pages involved in this attack; the "UI consumer" page (which has the iframe embedded within it), and the "UI provider" page (which gets loaded within the iframe). I'll call the UI provider's server the "server under attack".
To protect against this attack:
-
When requesting the URL for the delegates dialog (from the ServiceProvider) or the UI preview (from the compact resource), the server under attack must require requests for these resources to be authenticated. This authentication must be for the end-user, not for the client app itself.
-
When returning a URL for the dialog or preview, the server under attack must return a URL that is specific to the authenticated user, and that cannot be guessed by merely knowing the user's username or ID.
-
When the server under attack receives a request for the dialog or preview URL itself (the request that is generated by the iframe to load the page to display within it), the server under attack must check that the URL that was requested is one that was generated for the same user that is requesting this page (i.e. the user that is identified by a session ID in the cookies sent with the request). This makes sure that the client can't get a URL for the dialog from one user that it is authenticated for, an use that to perform a clickjacking attack on another user that has not authorised that client.
-
If the users (for the URL and the cookie) do not match, then the server can either return with an HTTP error, or include an
X-Frame-Options header with value SAMEORIGIN or DENY.
-
All pages that are not dialogs or previews - that is, all pages that are not intended to be embedded - should include an X-Frame-Options response header with value SAMEORIGIN or DENY, to prevent them from being used for clickjacking attacks.
This is only required on dialogs or previews that contain controls that can be invoked with one or more clicks, and where those controls have side effects on the server. That is, if there are no controls on a preview, then there is no target for the malicious page to tick the user to click on.
By following these steps the server under attack knows that only clients that are able to authenticate against the server (e.g. for OAuth authentication they must have a valid client ID and - if required by the interaction pattern they're using - they must know the client secret), and that have also been authorized by the user to whom the the dialog is displayed, can display that dialog.
There are still some potential attack vectors:
But the exposure has been reduced as the attack cannot occur simply by loading a malicious web page in the user's browser.
----------
Martin Pain