Consider message integrity in threat model

[mikesamuel]

Security Model focuses on protecting the host machine from the deno process.

It would be nice if the security model also addressed how to ensure the integrity of messages that leave the system including:

1. Content-type:text/html response bodies since XSS is a common problem.
2. Database query strings since {SQL,NoSQL} injection are common problems.
3. Strings destined for execve since Shell injection is a common problem.

(This isn't an exhaustive list, but if deno runtimes are often glue between user agents, other service nodes, and storage systems, then consistently using tools to prevent these common cases might make it easier to handle the next most common message integrity related vuln.)

---

I've been implementing easy-to-use secure-by-construction message producers for the above for Node, along with type-safety checks where messages leave the systems that allow a security team to bound the amount of code that might participate in a vulnerability.

At the end of the day, I want an application team to be able to say

Our application is safe w.r.t. ClassOfAttack because successful attacks must involve incorrect creation of a value of type T and the the amount of code that could create Ts is small and carefully vetted.

If there's interest, I can send a PR to add message integrity goals to the deno security roadmap.

---

For more background, I've integrated a bunch of techniques into a Node target app that I'm opening up for attack review shortly.

The target application has an intentionally large attack surface. This application should be easy to breach if it were not for the security machinery under test, so if it resists breach, then the security machinery provides value. Specifically, the target application code does not filter inputs for dangerous patterns, does not explicitly escape outputs, calls require() with a URL path to dispatch to HTTP request handlers, and composes SQL queries and shell strings from untrusted strings without explicit escaping.

</shameless-plug>

---

Issue #378 (re ocaps) might have some overlap with the ideas I'm testing since the authority to create values that encapsulate authority is denied by denying access to minters, but I believe they're separable issues.

Some of the work I reference above also bears on issue #200 (re resource integrity). Allowing trusted code to intercept module loads gives a place to stand to check resource integrity.

[lucacasonato]

@mikesamuel I think this is out of scope unless you have some specific things Deno could implement to prevent these things. Do you wan't XSS sanitization on outgoing HTML? How would that work? Wouldn't this limit what people can do? Also Deno does not ship with database drivers, so database query sanitization should be left to userland IMO.

[mikesamuel]

Good questions, all.

Do you wan't XSS sanitization on outgoing HTML?

No.

How would that work?

There are four components:

1. A vocabulary of types that attest to the suitability of values: SafeHtmlFragment, SafeShellString
2. Values of those types can only be created via minters that are not globally available.
3. A way to restrict who can import those minters so that an application development team, and any security support team, can pick and choose which third-party libraries have access to them to limit the amount of code that has the ability to directly contribute to message integrity violations.
4. High reputation userland libraries for composing values of these types, and sanitizing them from strings.

Wouldn't this limit what people can do?

Third-party libraries' security assumptions do not always perfectly match application teams'.
Letting application teams restrict third-party libraries can let them confidently do more.

Also Deno does not ship with database drivers, so database query sanitization should be left to userland IMO.

In this scheme all the sanitization should be left to userland. What is hard to leave to userland is

1. the check that value leaving the system has been attested to by userland code,
2. letting application teams craft a policy that restricts import of trademarks, those functions that mark a value as safe in some context.

[kitsonk]

This seems a broad topic and unrelated to specific APIs in Deno. This really needs a more specific proposal and a plan to implement to be actionable.