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.
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.
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:
- 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)?
- 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?
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)
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).
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)