WebCrypto에서 DOM Object의 보호 관련 메일 thread

[Mountie Lee]

이건의 이슈는

WebCrypto API에서 DOM Object를 보호하는 것에 대한 의견입니다.

현재 논의되었던 사항은 API Security관련해서 Same Origin Policy만이 고려되었고

기타 다른 사항은 범위밖 (out of scope)이라고 하는데

제 생각은 

Javascript 그자체를 보호하기 위한 추가적인 방식이 필요하다는 것이고

이미 일부 의견중 Signed-JS 도입등은 거론되었었습니다.

그왜에 JS Integrity Checking 기능이나 기타 WebCrypto API가 동작하는 범위내에서는 해당 컨텐트가 보호되어야하고 이에 대한 메커니즘이 여전히 필요하다는 생각입니다.

의견이 있으시면 코멘트 바랍니다.

---------- Forwarded message ----------
From: Mountie Lee <mount...@gmail.com>
Date: Thu, Aug 2, 2012 at 11:43 AM
Subject: Re: any discussion thread for page encodings?
To: Ryan Sleevi <sle...@google.com>
Cc: "public-webcr...@w3.org" <public-webcr...@w3.org>


Hi.

I agree there are no perfect protection for compromised user environment.

but I think if we can do, we have to do to the level we know at least.

I think.

Signed JS has same purpose for keeping JS integrity.

service provider want to make sure the JS codes in user agent are same to original server sent.

if server sent

crypto.sign("I agree to pay 100");

and user switched the string

crypto.sign("I agree to pay 10");

this can be problem in real field.

var integrity = crypto.getIntegrityValue();

can be one of example for my integrity checking mechanism.

also Signed JS can be (maybe) one of alternatives.

this is very basic concern.

best regards

On Mon, Jul 30, 2012 at 2:01 PM, Ryan Sleevi <sle...@google.com> wrote:

On Sun, Jul 29, 2012 at 9:46 PM, Mountie Lee <mount...@gmail.com> wrote:
> Hi.

> thanks for your mail.
>
> for "prevent and control"
> the "same origin" policy is not enough I think.
>
> some attackers are focusing to compromise PC environment.
> many attempts are made on PC level.
>
> with "same origin" policy, well designed web application can protect XSS or
> Cross Site Scripting attack.
>
> I think we need one of followings.
> Integrity checking mechanism
> or
> protecting DOM object
>
> the description "webcrypto based methods should not permit DOM changes"
> in Transaction Security use cases
> in http://www.w3.org/wiki/KoreaWebCryptoUseCase
> is described based on same idea of me.
>
> regards
> mountie.

Thank you for the continued feedback.

Unfortunately, if I'm understanding correctly, such controls as you
propose have been agreed as out of scope according to our charter, and
would require rechartering this working group to consider them in
scope. This is listed under "Out of scope" is the statement
"access-control mechanisms beyond the enforcement of the same-origin
policy" at http://www.w3.org/2011/11/webcryptography-charter.html

However, I'm not sure I understand your comments regarding threats to
the PC level. A user agent cannot protect against a compromised
operating environment - whether malware, rootkit, or bootkit, these
attacks can all circumvent the browser security model (as well as the
OS and smart card security models, so these are not new problems).
Thus such attacks are out of scope for this WG, beyond possibly noting
this under security considerations.
 

It's not clear to me what exactly are you envisioning as suitable
controls. "Protecting DOM object" and "Integrity Checking mechanism"
are not clear, either in attacks or mitigation. Perhaps you can
provide an example of an "Attack", an example of a control, and a
description of how it would mitigate that attack. I just want to make
sure I've properly understood your question and it's out-of-scope
ness.

Note that, as I mentioned, the low-level API provides a way for
applications to provide custom integrity protection (eg: on top of
that afforded by SSL/TLS, which is the recommended means), by
protecting any sort of responses that will lead to DOM manipulation.
Also, please note that both the current low-level API and the previous
high-level API never directly interacted with the DOM, beyond the
incorporation of the DOM language for describing asynchronous event
handling.

If you're trying to prevent 'hostile' JS, then that is not a problem /
use case for this WG, and is indeed something better addressed at an
application layer (eg: via CSP).

Regards,
Ryan

>
> On Sun, Jul 29, 2012 at 6:07 PM, Ryan Sleevi <sle...@google.com> wrote:
>>
>> On Sun, Jul 29, 2012 at 1:29 AM, Mountie Lee <mount...@gmail.com>
>> wrote:
>> > Hi. Ryan.
>> > yes. I read in charter and use cases for "prevent and control"
>> > but no details.
>> >
>> > I remember someone mentioned "signed JS". but that is not acceptable for
>> > wider use.
>> >
>> > can we consider "arguments.callee" (but this is depreciated in ECMA-262)
>> > plus hash?
>> >
>> > If webcrypto api provide JS/DOM integrity checking feature in low level,
>> > web developers can use it for many purpose including "prevent and
>> > control"
>> >
>> > regards
>> > mountie.
>>
>> Hi Mountie,
>>
>> The intent of "prevent and control" is limited in the scope of same
>> origin. There are no attempts being made, and it's largely out of
>> scope for this WG, to try to change or redefine the web security
>> model. This includes the use of arguments.callee.
>>
>> All script executing in the context of the same origin is therefore
>> able to interact with this API. This is also highlighted in the
>> editor's draft under Security Concerns. Applications should thus make
>> use of available functionality, such as CSP, to reduce the risk of
>> cross-site-scripting and other script related attacks. Any further
>> refinements are better suited for the charter of the W3C's Web
>> Application Security Working Group.
>>
>> After our recent face-to-face, the question of signed JS, which is a
>> proposal that had limited qualification and was relayed second-hand,
>> was raised as a point of concern. Those who originally proposed it are
>> being asked to further clarify and refine what their use case was, to
>> better understand where it fits within the scope of this groups
>> charter.
>>
>> Note that with a low-level API, an application could certainly
>> introduce it's own signature verification methods around script
>> content that is passed to either JSON.parse or to eval, which afford
>> application-defined security without requiring this WG to define any
>> additional special APIs.
>>
>> Does that answer your question?
>>
>>
>> >
>> >
>> > On Sun, Jul 29, 2012 at 4:39 PM, Ryan Sleevi <sle...@google.com> wrote:
>> >>
>> >> On Sat, Jul 28, 2012 at 8:55 PM, Mountie Lee <mount...@gmail.com>
>> >> wrote:
>> >> > Hi. Ryan.
>> >> >
>> >> > thanks for your answer.
>> >> >
>> >> > as my understanding, the initial requirement has include "sign with
>> >> > user
>> >> > confirmation".
>> >> > that means the sign data must be same to the message shown to user
>> >> > screen.
>> >> > just with "sequence of bytes" are not enough for previous
>> >> > requirements.
>> >> >
>> >> > if it is handled in high level API,
>> >> > my additional question is
>> >> >
>> >> > is their any mechanism for preventing secret key material changes or
>> >> > other
>> >> > sensitive cryptographic values and settings changes?
>> >> >
>> >> > regards
>> >> > mountie.
>> >>
>> >> Hi Mountie,
>> >>
>> >> Yes, any scheme which relies on user agents presenting data in some
>> >> interpreted form is out of scope for the low-level API, and /may/ be
>> >> in scope for the high-level API. Because such schemes are
>> >> understandably complex (eg: PDF signatures, XMLsig,
>> >> normalization/canonicalization, etc), these are currently not the
>> >> focus of the working groups efforts, but may be in scope at a later
>> >> time. The current focus is on the low-level API, which does not focus
>> >> on such application-specific issues at this time, as even a low-level
>> >> API is a very ambitious and broad endeavor for user agents to
>> >> normalize.
>> >>
>> >> I'm not sure I understand your second question, but you may find it
>> >> answered by the Working Group charter at
>> >> http://www.w3.org/2011/11/webcryptography-charter.html , which states
>> >> that the API shall prevent or control access to secret key material
>> >> and other sensitive cryptographic values and settings.
>> >>
>> >> Regards,
>> >> Ryan
>> >>
>> >> >
>> >> >
>> >> > On Sun, Jul 29, 2012 at 10:41 AM, Ryan Sleevi <sle...@google.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Mountie,
>> >> >>
>> >> >> There were early discussions about page encodings and normalization,
>> >> >> when the API included both a high-level and a low-level component.
>> >> >> Following our recent Working Group face to face, the Working Group
>> >> >> has
>> >> >> resolved to focus on the low-level API and ensure that it's in a
>> >> >> deliverable state, and then revisit the ideas for a high-level API.
>> >> >>
>> >> >> By virtue of being a low-level API, issues such as encoding are left
>> >> >> to the application author. This can be seen also in the removal of
>> >> >> DOMString (which is UTF-16) from being a valid input to the
>> >> >> CryptoOperation.processData method, since that would have opened
>> >> >> questions of "Is it a sequence of bytes or is it a string?"
>> >> >>
>> >> >> Right now, the API's interaction with data streams is accomplished
>> >> >> via
>> >> >> ArrayBuffer/ArrayBufferViews, which are treated as opaque sequences
>> >> >> of
>> >> >> bytes. Any further normalization or canonicalization should thus be
>> >> >> done at an application layer.
>> >> >>
>> >> >> Does this answer your question?
>> >> >>
>> >> >> On Sat, Jul 28, 2012 at 5:25 PM, mount...@gmail.com
>> >> >> <mount...@gmail.com> wrote:
>> >> >> >
>> >> >> >> Hi.
>> >> >> >> I'm Mountie Lee from Korea.
>> >> >> >>
>> >> >> >> when I read http://www.w3.org/2012/webcrypto/WebCryptoAPI/ and
>> >> >> >> searched
>> >> >> >> archive at http://lists.w3.org/Archives/Public/public-webcrypto/
>> >> >> >>
>> >> >> >> I can not find discussion about page encodings.
>> >> >> >>
>> >> >> >> because WebCryptoAPI is Javascript dependent and developers have
>> >> >> >> to
>> >> >> >> consider page encodings always.
>> >> >> >>
>> >> >> >> many asian sites use local encodings (EUC-KR, Shift-JIS, GB2312
>> >> >> >> ...)
>> >> >> >> and by the page encodings,
>> >> >> >> the javascript operation result is different.
>> >> >> >>
>> >> >> >> please anyone inform me the discussio thread for page encodings.
>> >> >> >>
>> >> >> >> regards
>> >> >> >> mountie.
>> >> >> >>
>> >> >> >> --
>> >> >> >> Mountie Lee
>> >> >> >>
>> >> >> >> Tel : +82 2 2140 2700
>> >> >> >> E-Mail : mou...@paygate.net
>> >> >> >> Twitter : mountielee
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Mountie Lee
>> >> >
>> >> > Tel : +82 2 2140 2700
>> >> > E-Mail : mou...@paygate.net
>> >> > Twitter : mountielee
>> >> >
>> >> > =======================================
>> >> > PayGate Inc.
>> >> > THE STANDARD FOR ONLINE PAYMENT
>> >> > for Korea, Japan, China, and the World
>> >> >
>> >
>> >
>> >
>> >
>> > --
>> > Mountie Lee
>> >
>> > Tel : +82 2 2140 2700
>> > E-Mail : mou...@paygate.net
>> > Twitter : mountielee
>> >
>> > =======================================
>> > PayGate Inc.
>> > THE STANDARD FOR ONLINE PAYMENT
>> > for Korea, Japan, China, and the World
>> >
>
>
>
>
> --
> Mountie Lee
>
> Tel : +82 2 2140 2700
> E-Mail : mou...@paygate.net
> Twitter : mountielee
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>

--
Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mou...@paygate.net
Twitter : mountielee

--
Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mou...@paygate.net
Twitter : mountielee

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

[Mountie Lee]

본건 관련 계속 이야기를 진행해본바로는

Client Device가 침해된 경우에는 어떤 방법으로도 보호가 불가능하다는 의견이고

Integrity Check등의 DOM Object 보호를 위한 추가 기능은 불필요하다는 의견이 다수입니다.

국내 환경에서는

이용자 PC의 보호를 위한 많은 규정들 (키보드보안, 안티바이러스, 개인방화벽 등)이 존재하는데

국내 규제 당국의 사고의 "대전환"이 필요하다는 생각입니다.

즉 사업자가 이용자 환경을 보호해줘야할 의무가 있는지에 대한 근본적인 질문입니다.

[Mountie Lee]

본건 관련 주고받은 email thread 입니다. 참고하세요.

---------- Forwarded message ----------
From: Richard L. Barnes <rba...@bbn.com>
Date: Fri, Aug 3, 2012 at 7:00 AM
Subject: Re: any discussion thread for page encodings?

To: Seetharama Rao Durbha <S.Du...@cablelabs.com>
Cc: Ryan Sleevi <sle...@google.com>, Mountie Lee <mount...@gmail.com>, "public-webcr...@w3.org" <public-webcr...@w3.org>


Ok, yes, if you know out of band that a given key exists on a device and can't be exported, you know that operations using that key happened on that device.

I don't think that (2) is completely unachievable, depending on the deployment model; for example, I think the Netflix guys are building some UAs in embedded devices that they regard as trusted.  If you combine this with trusted boot, you get a pretty high level of assurance.

On Aug 2, 2012, at 2:55 PM, Seetharama Rao Durbha wrote:

> That is what I meant – your (1); though it does not have to be an asymmetric key (cert) alone, could be symmetric key as well.
> Trusted UA is just utopia, unachievable practically.
>
> On 8/2/12 3:46 PM, "Richard L. Barnes" <rba...@bbn.com> wrote:
>
> No, you can't get that guarantee (where you==server), without either (1) device certificates or (2) a trusted UA.  Otherwise, the browser can lie about where it's doing the crypto, then do things wherever it wants, post keys to Twitter, etc.
>
>
> On Aug 2, 2012, at 2:39 PM, Seetharama Rao Durbha wrote:
>
>> I think there are two use cases here.
>> We cannot support JS integrity (earlier Mountie's email) for reasons Ryan mentioned.
>> But, implicitly through the ability to interface with smart-cards (and other stores through provider interface hopefully), applications CAN get the guarantee that 'things are processed by a given device'.
>> -Seetharam
>> On 8/2/12 3:10 PM, "Richard L. Barnes" <rba...@bbn.com> wrote:
>> So, in principle, there do exist techniques for guaranteeing that things are processed by a given device.  It's just that:
>> 1. The relevant standards come from the Trusted Computing Group (not politically very popular)
>> 2. They require per-device certificates (not very practical for browsers)
>> <http://en.wikipedia.org/wiki/Direct_anonymous_attestation>
>> I'm pretty sure that these could be adapted to Javascript, though it hasn't been done yet AFAIK.  It may be that the problems Ryan notes would still stand in the way.
>> My impression is that this group doesn't really to go down that path, especially not in the first version.  If there is a desire to do this later, it can be added onto the draft API.
>> On Aug 2, 2012, at 12:25 PM, Ryan Sleevi wrote:

>>> On Wed, Aug 1, 2012 at 7:43 PM, Mountie Lee <mount...@gmail.com> wrote:
>>> Hi.

>>> I agree there are no perfect protection for compromised user environment.
>>> but I think if we can do, we have to do to the level we know at least.
>>> I think.
>>> Signed JS has same purpose for keeping JS integrity.
>>> service provider want to make sure the JS codes in user agent are same to original server sent.
>>> if server sent
>>> crypto.sign("I agree to pay 100");
>>> and user switched the string
>>> crypto.sign("I agree to pay 10");
>>> this can be problem in real field.
>>> var integrity = crypto.getIntegrityValue();
>>> can be one of example for my integrity checking mechanism.
>>> also Signed JS can be (maybe) one of alternatives.
>>> this is very basic concern.
>>> best regards

>>> Hi Mountie,
>>> I'm afraid your solution is not really compatible with the JavaScript execution model nor of the general web security best practices.
>>> A server has no way to guarantee that a client has not altered script. Nor can a user agent guarantee that either. There are lots of points where a user may alter code (they may use Web Inspector-style flows, they may open the browser process and rewrite its memory, they may inject executable code, they may inject a bootkit/rootkit, etc). This is a problem that neither can nor should be attempted by this WG.
>>> Your example use case can be perfectly addressed through existing cryptographic transforms, and has been used by a variety of protocols in the past, so I don't think there is anything special about "protecting script" or integrity values needed.
>>> If you're interested in schemes which alter the fundamental web security model and try to protect against these sorts of things, which equally exist as an unsolved problem in "native" code, perhaps the WebAppSec or SysApps WG may be more suitable.
>>> Cheers,
>>> Ryan

[Mountie Lee]

Facebook에서도 유사한 제안을 해왔습니다.

http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Aug/0057.html

일단 해당건이

Open Action Item으로는 잡혔고 ( http://www.w3.org/2012/webcrypto/track/actions/28 )

대화를 좀더 지켜보도록 하겠습니다.

[Mountie Lee]

가장 최근의 내용입니다.

참고하세요.

crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

http://www.w3.org/2012/webcrypto/track/issues/21

Raised by: Ryan Sleevi
On product: Web Cryptography API

One of the concerns with exposing the Web Crypto API to applications is the possibility for cross-siste scripting. This was particularly raised during the "signed JS" use cases, as it suggests that signed JS may act as a mitigation against an unauthenticated ephemeral XSS being turned into a persistent, authenticated XSS, by means of corrupting script stored in localStorage.

One way to mitigate this would be to specify that, in order to have this API exposed, applications MUST use CSP [1] and MUST specify a script-src [2] directive of 'self' and object-src directive of 'self'. This would prevent any inline script from being added, and would prevent the use of 'eval' to execute script.

While such solutions are not perfect, they can *significantly* reduce the risk of compromise or misuse. On the other hand, this may prevent some use cases, such as those imagined by the signed JS. A compromise might be to define "Anything that requires a key requires CSP", which would simply permit insecure applications from using key-based operations.

[1] http://www.w3.org/TR/CSP/
[2] http://www.w3.org/TR/CSP/#script-src