4 ms·

This is an incredible internship project, nice work. Does anything prevent a malicious user from polluting the client metrics? Are spans of all types accepted b

This is an incredible internship project, nice work. Does anything prevent a malicious user from polluting the client metrics? Are spans of all types accepted by the proxy?

takumo 7y ago
That’s a good question. I've had a bit of a look and it appears that the bulk of this is undertaken in the Trace Context specification itself. The data passed back for a trace includes a reference to the trace’s location within a tree. The root node for this tree should (perhaps must) be generated server-side, and the client-side can only send traces which are children of the root-trace given by the server. Specifically the `traceparent` data: traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 Where 00 is the format version, 0af7651916cd43dd8448eb211c80319c is the root trace ID given by the server and b7ad6b7169203331 is the ID of the direct parent of this trace. While this doesn't prevent a malicious user from polluting a single trace, it does limit their scope to the root trace they've been given. It should then be possible to discard the entire trace, though I think identifying tampered traces could be difficult.
draffensperger 7y ago
If you expose the OpenCensus service directly to the internet, then a malicious user could definitely send traces directly to it. We recommend in the blog post that you write an endpoint in your frontend web application that would proxy the writes of traces through it. That way you can add whatever rate limiting / authentication middleware you have for your overall application so that only logged in users can submit traces for your web app (or severely rate-limit those from unauthenticated users). Basically, we are aware of this issue and our approach right now is to ask you to handle it in an application-specific way.

4 ms·

This is an incredible internship project, nice work. Does anything prevent a malicious user from polluting the client metrics? Are spans of all types accepted b

by bowmessage 7y ago

This is an incredible internship project, nice work. Does anything prevent a malicious user from polluting the client metrics? Are spans of all types accepted by the proxy?

takumo 7y ago
That’s a good question. I've had a bit of a look and it appears that the bulk of this is undertaken in the Trace Context specification itself. The data passed back for a trace includes a reference to the trace’s location within a tree. The root node for this tree should (perhaps must) be generated server-side, and the client-side can only send traces which are children of the root-trace given by the server. Specifically the `traceparent` data: traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01 Where 00 is the format version, 0af7651916cd43dd8448eb211c80319c is the root trace ID given by the server and b7ad6b7169203331 is the ID of the direct parent of this trace. While this doesn't prevent a malicious user from polluting a single trace, it does limit their scope to the root trace they've been given. It should then be possible to discard the entire trace, though I think identifying tampered traces could be difficult.
draffensperger 7y ago
If you expose the OpenCensus service directly to the internet, then a malicious user could definitely send traces directly to it. We recommend in the blog post that you write an endpoint in your frontend web application that would proxy the writes of traces through it. That way you can add whatever rate limiting / authentication middleware you have for your overall application so that only logged in users can submit traces for your web app (or severely rate-limit those from unauthenticated users). Basically, we are aware of this issue and our approach right now is to ask you to handle it in an application-specific way.