Re: security of a client-side JS API?

for securing JS codes
I found multiple issues were involved with it.

"ISSUE-21: Requiring Content-Security-Policy"

"ISSUE-10: Making sure our API is usable with pure js environement"

Multi-Origin Issues (ISSUE-26, ISSUE-33, ISSUE-15, ISSUE-34)

also I think this concerns can be discussed under agenda (Security
Framework Considerations) at Thursday afternoon under TPAC F2F meeting.

regards

mountie.

On Wed, Oct 31, 2012 at 4:56 PM, Seetharama Rao Durbha <
S.Durbha@cablelabs.com> wrote:

> In addition to Ryan's comments, few thoughts of my own.
>
> On 10/30/12 2:43 PM, "Arthur D. Edelstein" <arthuredelstein@gmail.com>
> wrote:
>
> Hi Everyone,
>
> I've read through the WG and public comments list archives, and I am
> concerned that an objection partially raised in the WG mailing list
> ("Is our deliverable doomed ?", 18 September) hasn't really been
> clearly addressed.
>
> The API is supposed to be used inside a web app's client-side JS
> runtime. But the problem with client-side JS is that it is under the
> full control of neither the user nor the web app provider. The app
> provider (though she trusts her own web app JS code) doesn't know if
> the WebCrypto API is running correctly and honestly on a particular
> user agent instance, and the user (though he may trust the user agent)
> can't know if the client-side web app is using the API correctly and
> honestly. So in practice, neither side can have confidence in these
> utility functions.
>
> I think this is where it should be made clear how there was never an
> automatic trust between a client and a server in any crypto protocol. Even
> considering native application clients, the server they are communicating
> with cannot automatically tell that the client is their native application.
> So, the server always has to use established (by their individual designs)
> protocols to prove the identity of the client or user using the client.
> This API just lets a client implementation (running in a browser) to
> participate in such a protocol with minimal coding. The question then
> becomes how a JS is given access to keys on the client side – in my mind it
> is a combination of CSP (as Ryan mentioned) and user training. Today, there
> is already an expectation on the users to be vigilant (check the URL, check
> green bar, heed browser warnings, etc.) - this API is not intended to
> relieve the user of such vigilance. If you think about it, users are
> already performing so many sensitive operations using the browser –
> entering their username/password, checking their bank accounts, applying
> for mortgages, and so on. If all the web sites waited for a truly trusted
> client, we will not have the web of today.
>
>
> Numerous cryptographic solutions exist for the server side already, so
> it seems to me that responsible web app providers are going to prefer
> to do their cryptographic operations on the server, in an environment
> they control, rather than use this API. Worse, people who do use this
> API may have misplaced confidence in its security.
>
> So I think it would be useful, in the specification, to clearly state
> what security guarantees can and cannot be delivered by this API, and
> when it is better (for web app developers) to use server-side crypto
> libraries. Thanks in advance for considering my comment.
>
> Sincerely,
> Arthur Edelstein
> UC San Francisco
>
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World