RE: Browser Sandbox Security by internal attack

Dear Mountie,

Sorry, it is still not clear to me what restrictions you would like the requested 'sandbox' to have?

It might help me understand if you could give an example of an application that you want to secure within this sandbox?

Your concern for the channel security, between the OS and the 'sandbox', suggests you are concerned about a compromised web browser.  If the web browser is compromised then it would also be difficult to implement the secure sandbox you seek.  For example, the compromised web browser might spoof the secure sandbox leading the user to think they are secure while still compromising their security.

Perhaps an external smart device, such as an Secure ID device, would be a much better solution.  PayPal appears to have a credit card sized smart card with an elink display that generates a new code each time a button is pressed.

cheers
Fred

From: mountie.lee@mw2.or.kr
Date: Wed, 16 Jan 2013 14:18:38 +0900
To: fredandw@live.com
CC: public-webappsec@w3.org
Subject: Re: Browser Sandbox Security by internal attack

let me add my comments.

On Tue, Jan 15, 2013 at 12:13 PM, Fred Andrews <fredandw@live.com> wrote:





Dear Mountie,

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

I know there's no way to secure browser sandbox when OS compromised.

I mean "WebAppSec need to recommend browser vendors that a minimum protection mechanism from internal attack to sandbox is required"this will give more cost for hackers.


the sandbox security levels(from internal) are different between each user agents.that means some browser vendor is considering it and some are not.



Could you be more specific about the threat?

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

No. 


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

Yes.SSL channels are just securing Server and OS.data sent via SSL is exposed between OS and browser sandbox.


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



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



Sorry. difficult to understand the meaning.do you mean HTTPS connection is the counter measure for proxy issue? 


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 		 	   		  


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

Received on Monday, 21 January 2013 23:56:09 UTC