RE: [oslc-core] Click jacking - suggesting that all requests for ServiceProviders require auth for a user

["Sarabura, Martin" <msarabura@ptc.com>]

Martin, I don't see problems with requiring authentication to obtain a dialog or preview. Applications should require credentials to avoid divulging potentially sensitive information to non-registered users. A resource selection dialog should present to the user only valid selections for that user, and a resource creation dialog needs to know the user in order to enforce resource creation permissions. If a server doesn't care about user permissions in relation to access to CRUD functionality, then is click-jacking much of an issue anyway?

 

As for clients implemented entirely in browser/mobile apps, assuming a cookie is being used to track the session then I see no issues.

 

Regards, Martin (S)

 

 

Dr. Martin Sarabura

R&D Fellow, PTC

 

 

 

 

From: oslc-core@lists.oasis-open.org [mailto:oslc-core@lists.oasis-open.org] On Behalf Of Martin P Pain
Sent: November-09-15 5:52 AM
To: oslc-core@lists.oasis-open.org
Subject: [oslc-core] Click jacking - suggesting that all requests for ServiceProviders require auth for a user

 

I can suggest an approach that I believe should reduce the risk of clickjacking, but it means suggesting to implementations that any requests that return a dialog or preview URI (that is, requests for Service Providers or compact resources) require authentication, and that that authentication is for a real user on the server (e.g. not auth credentials for the client app itself, but for the user who is using it).

 

However, I'm not entirely sure of the consequence of that:

1. Does anyone see any problems with servers requiring authentication in this way?
2. I'm not sure how this might affect clients implemented entirely in a browser & mobile apps.

(I'll go into this in more detail later, but the reason for requiring such authentication is so that the server can then provide a URL to the dialog/preview that is specific to that user [in a non-predictable way] then when the server is asked to display the dialog/preview in an iframe it knows: (1) for OAuth, it was a valid consumer that retrieved that URL for the dialog/preview or (2) for HTTP Basic Auth, it was a consumer who the user gave their credentials to that requested the dialog/preview URL. And: (3) the user for which the dialog was requested is the same user for which it is being displayed.)

 

Any answers to those two questions above would be appreciated - thanks.

 

Martin

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php