Re: Activity Identifiers - Draft Submission

On 24/05/19 8:30 am, Scott Perham wrote:
> The draft definitely needs fleshing out, this shall be done as soon
> as I can.
> 
> The header would be sent by the client of a  service (not a browser
> natively or automatically, for example) and only for those services
> that require it (as usually defined in a service API documentation
> and as it does today, but for arbitrary headers). For any request
> that originates from the service as a direct result of the original
> request and _before the response is returned from the service_ the
> implementers of that service can include the same header value in the
> subsequent requests. This would be repeated with a new (random) value
> on each request sent from the client to that service.
> 
> This allows the implementers to trace the activity through subsequent
> service calls.


Not just implementers. Any party observing that traffic will be able to
track individual clients (aka users and their specific devices) activity
down to the resolution of specific HTTP messages. A great way to leak
lots of privacy information which is currently well obfuscated by HTTP
stateless design.

That same view can be used by a malicious observer to determine what
backends to attack (and with what messages) to attack the application
from the "inside". For example; bypassing a front-end input validator
that uses HTTP to contact the data storage filesystem for records.


IMHO this is a feature which is best left unspecified so applications
can continue re-implementing as they are. Using a varied set of header
names, and per-service handling behaviour is a *good* thing.

What looks like a mess at first glance is an active barrier at each
level of API sub-transaction ("call") against that malicious observer
case. Each service by-default prunes the headers containing the tracker
with privacy/security revealing information - simply by not knowing
which varied headers to copy across.
  If it became a standard header, any two or more services using it
could not be used together without adding the risk of the above attack
becoming possible.

AYJ

Received on Friday, 24 May 2019 06:30:05 UTC