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