Possible bug in XSS threats

[mike1813]

Threats CC.AuC.DFrXSS.3, CC.AuC.DFsXSS.3, CC.AuC.DSrXSS.3 and CC.AuC.DSsXSS.3 represent stored or reflected XSS attacks on the client or server side. They assume that the goal of the attacker will be to capture a client session cookie, allowing them to access the service at least temporarily irrespective of the client authentication mechanism (unless possibly X509 client authentication used at the transport connection level). Hence they lead to a Loss of Client Authenticity. This represents a worst-case assumption, as it allows the attacker to access anything the client can access using the affected client-service relationship.

The problem is that this affects any client channel, whether direct or indirect, whereas other threats to Client Authenticity are assumed only to affect connections to services that authenticate the client.

This should be reviewed in light of any changes to address #68.

[mike1813]

It seems that session cookies can only be inserted client-side by a web-based service if the service and client communicate for authentication purposes. The client must connect to and authenticate with the service directly, or via an intermediary that forwards authentication messages from the client, or shares an authentication context with the service that can be referenced by the client.

The threat should involve any ClientChannel (since communication is necessary) that may go via another Client Channel (since the communication need not be direct) but should not support another ClientChannel (since the session in that case relates to the end-to-end indirect communication).

[mike1813]

The reason we get threats to client-service connection that are not authenticated (e.g., the service is a credential-forwarding proxy) is because there is no prohibition on this. We don't check if this client channel is to an intermediary, nor if there is a link signifying it is not authenticated. We really should check for such a link.

In principle, that means we should get XSS threats for any client channel. However, we don't because there is an assumption that such threats only work if information can be sent from the client to a service established by the attacker, and that this means the client connection should go via an IP subnet, ideally via the Internet. Note that this does not rule out indirect channels involving credential forwarding.

In reality, this may not be a consideration. It is necessary that the attacker can inject malicious content to exploit the service bug, but that is covered by the dependency on authenticity for an input to the browser. It is then necessary that the browser is able to access the attacker's service, but this need not be on a subnet between the client and the real service.

Conclusion: we just need a network path to exist from the client host to the attacker's subnet. In practice, threat likelihood would depend on the least trustworthy subnet for which there is such a network path.

Problem: there are lots of network paths so we could end up with a lot more threats of this type. One solution might be to restrict attention to cases where there is a path to the Internet. The other solution would be to construct links from the client host to each subnet accessible from that host, and formulate the threat using destinations but without using network paths.