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