- From: Fred Andrews <fredandw@live.com>
- Date: Mon, 21 Jan 2013 23:55:42 +0000
- To: Mountie Lee <mountie.lee@mw2.or.kr>
- CC: Web Application Security Working Group <public-webappsec@w3.org>
- Message-ID: <BLU002-W2184D19F886146ACB39E8A2AA170@phx.gbl>
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