RE: Browser Sandbox Security by internal attack

Dear Mountie,

If the OS is compromised then how could a secure browser sandbox be implemented?

Could you be more specific about the threat?

Are you concerned about OS level key loggers and/or screen scrapers?

Are you concerned about the end to end communication channel security?

Are you trying to assert digital rights and thus the customer might be the threat?

Why wouldn't a HTTPS connection address the issue of a proxy modifying content and stripping the CSP header?

cheers,
Fred 

From: mountie.lee@mw2.or.kr
Date: Tue, 15 Jan 2013 11:04:13 +0900
To: bhill@paypal-inc.com
CC: fredandw@live.com; public-webappsec@w3.org
Subject: Re: Browser Sandbox Security by internal attack

script nonce is one of CSP mechanism in WebAppSec WG.but server sent headers can be stripped or changed by a proxy installed in Client Side.
a software installed on client side can access browser memory area by searching OS Virtual Memory management file (example: pagefile.sys)



OS vulnerabilities can be exposed at zeroday
Client Machine is easier than servers for hacking.
is this only dependent on browser or OS vendors?


can we add a recommendation in CSP for securing browser sandbox to implementers?




On Mon, Jan 14, 2013 at 2:10 PM, Hill, Brad <bhill@paypal-inc.com> wrote:



Mountie,



  Perhaps you could provide a more concrete example of a use case, real-world threat model, and how such protection might be practically accomplished?



  This sounds a lot like a DRM use-case, which has not been historically successful, at least from a technical point of view.  When it is even attempted in scenarios where an execution context seeks to "protect itself" from its own Trusted Computing Base, it relies almost exclusively on security through obscurity, something we can't accomplish at the W3C.






  We don't have an explicit prohibition on this scope, but we do adhere to the HTML Design Principles (http://www.w3.org/TR/html-design-principles/) and particularly the  Priority of Constituencies:






"In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once."






Judged against these principles, am concerned that creating a sandbox  of this sort is about (or has the unavoidable side-effect of) privileging content authors over users.



Thank you,



Brad Hill







From: mountie@paygate.net [mailto:mountie@paygate.net] On Behalf Of Mountie Lee

Sent: Sunday, January 13, 2013 6:19 PM

To: Fred Andrews

Cc: Web Application Security Working Group

Subject: Re: Browser Sandbox Security by internal attack



Hi.

thanks for reply.



theoretically you are correct.



but



many actual threads are coming from Internal.



do we need to touch protecting sandbox from internal attack?

it it out of scope of WebAppSec WG?





On Sat, Jan 12, 2013 at 6:34 AM, Fred Andrews <fredandw@live.com> wrote:



Hi Mountie,



The web browser does not consider the OS a threat.  The OS is privileged.



cheers

Fred

________________________________________

From: mountie.lee@mw2.or.kr

Date: Fri, 11 Jan 2013 19:04:55 +0900

To: public-webappsec@w3.org

Subject: Browser Sandbox Security by internal attack





Hi.



the current CSP's aim is protecting browser sandbox by external attack.





how strong the browser sandbox from internal attack (from OS)?



my question is based on that user environment can be easily compromised.



regards

mountie.

--

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









--

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













-- 
Mountie Lee

PayGateCTO, 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