Hi Everyone,
I am new to New-Relic.
I have doubt about the security of header sending to other websites.
I implemented new relic in RUBY, I am fetch few URLs and on testing on my server I found it is sending Newrelic: <base64 string>........... header in every request.
Is there any security risk? Or Iti s ok.
I would also like to know if this isn’t a security risk then what extend can anybody misuse it? Because it is public and decodable.
Thanks
Hello @rahulsharma007
Welcome to Explorer’s Hub! Happy you are trying out the Ruby agent!
What you found is a Distributed Tracing header:
When you enable distributed tracing, New Relic agents add HTTP headers to a service’s outbound requests. HTTP headers act like passports on an international trip: They identify your software traces and carry important information as they travel through various networks, processes, and security systems.
The headers also contain information that helps us link the spans together later: metadata like the trace ID, span ID, the New Relic account ID, and sampling information. This header information is passed along each span of a trace, unless the progress is stopped by something like middleware or agents that don’t recognize the header format
That document provides an overview, but doesn’t give much detail from a security side so I did file an issue for our documentation team to cover this in more depth!
Onto your security questions, you can see what information the Ruby agent sends in headers here:
And a little more information on what these are:
| Name | What it is |
|---|---|
| version & data key | This identifies major/minor versions so if an agent receives a trace header from a version with breaking changes from the one it is on, it can reject that header and report the rejection and reason |
| parent type | The source of the trace header, as in Mobile, Browser, or in this case, a Ruby app. This becomes the ‘parent.type’ attribute on the Transaction triggered by the request this header is attached to |
| accountId | This is your New Relic account Id but only those on your account and New Relic Admins will be able to associate this Id with your account information in any way |
| appId | This is the application Id of the application generating the trace header. Much like account Id, this identifier is not going to provide any information unless you are a user on the account |
| guid | With Distributed Tracing, each segment of work in a trace will be represented by a Span and each span has a ‘guid’ attribute’. The ‘guid’ of the last span within the process will be sent with the outgoing request so that the first segment of work in the receiving service can add this ‘guid’ as the ‘parentId’ attribute which we think use to connect data within the trace |
| traceId | The unique ID (a randomly generated string) used to identify a single request as it crosses inter- and intra- process boundaries. This ID allows the linking of spans in a distributed trace. This also is added as an attribute on the Span and Transaction data |
| trusted account key | This is a key that helps identify any other accounts associated with your account. So if you have multiple sub-accounts that the trace crosses, we can confirm that any data included in the trace is coming from a trusted source and tells us what users should have access to the data |
| priority | A randomly generated priority ranking value that helps determine what data is sampled when sampling limits are reached. This is a float value set by the first New Relic agent that’s part of the request so all data in the trace will have the same priority value. |
| sampled | A boolean value that tells the agent if traced data should be collected for the request. This is also added as an attribute on any span and transaction data collected. If you want to read more about this sampling process, this guide goes into more detail. |
| timestamp | Unix timestamp in milliseconds when the payload was created |
| transactionId | The unique identifier for the Transaction event |
So while there are ID’s in the trace header, you would need to be a user on the account the header is from to be able to associate that ID with any real information. If someone contacts support with any of these ID’s asking for access to or information on the account, we have strict processes in place to ensure no ill-intending people gain access to accounts.
Let us know any other questions or concerns!
P.S. - If you are using the Browser agent, you may have similar questions on the New Relic script. This post covers security in the Browser agent!
This topic was automatically closed after 365 days. New replies are no longer allowed.