Tim in the Web to Windows 8: Security article keeps referring to the idea that in a normal client-server application (like when a website consumes data from a website/server) most client-side security is for 'usability purposes' and the real security work (for example Constrain, Reject and Sanitize input or authorise data accesses) happens at the server.
Now is correct when the 'assets (and capabilities) to protect' are at the server and the client shouldn't have full access to them.
I.e. the security needs to happen at the location where there are security implications and abuse scenarios. A simple example is authorisation: we don't want the user to be able to click on 'admin' features, but the enforcement of that security measure (i.e. 'users don't have access to admin functions') must not happen on the client but on the server.
So as I read that article and got my head around the new 'Local vs Web context' I was thinking "Hold on, this has nothing to do with javascript code vs server code". What matters is 'where' the client and server code are located. And it looks to me as what is happening is that in Windows Store Apps the client is the 'Web Content' code and the server is the 'Local context' code
Looking at this code execution from the point of view of trust and capabilities boundaries, we have the same concepts and architecture as in the normal 'Browser-WebServer' model.
In the example shown in the article, there is code that running at a higher privilege mode (the Local Context code) which as access to important assets (like the local data storage) and there is code that runs at a lower privilege mode (the Web Context code) which is going to do dangerous thinks like 'fetching javascript from other sources'.
There is even an 'official' communication channel between the Web and Local contexts that uses the postMessage Html5 feature (see example in 'Communicating Between Contexts' section)
This is a typical client-server architecture where security needs to be applied at the location where the assets can be accessed (in this case the Local Context code) and 'untrusted code' is sandboxed (i.e. isolated).
Is this Microsoft inventing another Sandbox technology? (Btw I still think that CAS (Code Access Security) is by far the best Sandbox model out there , which is a shame since CAS has been killed but since there is a big different between mostly dead and all dead a 'miracle man' might bring it back one day :) )
Back to Windows Store Apps, the most important question on any Sandboxing technology, is who is enforcing the sandbox?
Practically speaking, a Sandbox is just a way to prevent 'unprivileged code' from executing 'privileged actions' or accessing 'privileged data':
- In kernel drivers: there is no sandbox
- In Windows apps: The Windows Process is the sandbox, enforced by the Kernel
- In .Net and IIS apps: The Windows Process is the sandbox, enforced by the Kernel
- In .Net apps and IIS running in partial trust: The .Net's AppDomain is the sandbox, enforced by the CLR
- In Client-Server apps: the client is the sandbox, enforced by the server's attack surface
- In Mobile apps: the app 'execution environment/process' is the sandbox, enforced by the OS (and a security policy)
- In Windows 8 Store Apps: the Web Context is the sandbox, but who enforces it?
Its the last one that I am not sure of:
- Who is actually enforcing this Sandbox? the browser? the Javascript engine, a javascript APIs? the windows process?
- What are the communication possibilities between the Web and Local contexts?
- Is there an CAS-Like security demands architecture that declares and enforces Code Access Security on specific functions (or assets)?
- Aren't they both (Web and Local contexts) javascript/html code that is running on the same browser session? (and OS process)?
- Isn't there a gazillion of objects (think Html elements and Javascript variables/objects) that are shared between them?
- How does this play with the powerful javascript capabilties to 'bend reality' and change just about everything (for example prototypes)?
- What are the rules-of-engagement for the Javascript this object?
- What about all those Html 5 security issues? (see these two cheat-sheets)
- Are there any SAST (static code analysis) tools that can scan these Windows Store Apps and identify security issues?
- Is this a javascript sandbox for javascript code? That is a hard one to pull off (and if so, surely Microsoft must have changed the way its Javascript's engine works)
Btw, let me know if there a site or page with these answers? (see the Windows 8 Sandboxing post for some good references I found)
OK, so if I'm getting this right, in Windows Store Apps:
- We have a browser (IE 10) running under an 'locked down' user identity (with for example file restrictions enforced by the OS)
- That browser loads a website which has Javascript code running under two different contexts
- 'Somebody' is enforcing/sandboxing a number of security restrictions on the 'Web Context' javascript code
- There are a number of 'Javascript accessible' assets that need to be protected from that sandboxed Javascript code (which that can come from hostile/compromised sources)
Humm... this sounds very dangerous (from a security point of view).
I bet part of Microsoft's strategy to keep Metro Apps secure, is to do a lot of security analysis on the app's submission for publishing (note: after trying very hard on this post to use the 'Windows Store Apps' (or whatever the latest name is) I agree with Hal in just keep calling it Metro , and am going to use the Metro Apps name from now on).
Appendix:
Error in plain sight: What is wrong with these two pictures (which passed MSDN publishing QA)
Image from the MSDN article:
Original image (used as inspiration for the one above)
