Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.
AppDynamics customers and established members should click the sign in button to authenticate.
Hello everyone. I have read this article but I have some concerns. Would appreciate any help!
For context, our current configuration is as follows:
With this, my pages are injected with a large script block that also loads adrum.ext.hash.js
Now for CSP, we want to be more restrictive and do not want to enable `unsafe-inline`.
We would like to whitelist the JS file(s) to be loaded and also the injected script block by hashcode.
My questions are:
Thank you so much for reading!
Solved! Go to Solution.
What happens in above injection is the adrum.js module is written directly in the response served.
That is why you see the injected block different form the configuration one because the configuration in UI is for manual injection where both adrum.js and adrum-ext are loaded as external scripts on the page.
Please let me know if this helps.
Thanks Amit, appreciate your quick reply. I understand what you are saying and it clarified my second question. Could you also comment on my first question?
This is important to us because we are looking to whitelist script src in CSP by hashcode, so any changes to the injected <script> block will render this the setting invalid.
Thank you once again.
In the given response the complete js module will be injected as a content of the source. That code will , on execution in browser, invoke an external js file named adrum-ext.
If this information helps you evaluate whether your computation will invalidate ? If not, could you please give me a brief on how you are calculating your CSP hashcode ?
Thanks for your reply once again, Amit.
We are looking to use this technique to allow inline script: https://www.w3.org/TR/CSP2/#script-src-hash-usage
The steps are as follows:
1) Turn on appdynamics EUM
2) Check webpage and copy entire injected <script> block's contents
3) Compute sha-512 hash of the (2)
4) Configure AP to add this static CSP http header, with hash computed in (3), to every page served like such:
Content-Security-Policy: script-src 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo='
We would like to know if these block is subjected to changes, assuming we do not modify the configuration of Browser Application via the appdynamics dashboard. Possible changes that we thought of are JS logic changes or auto version up of adrum.ext.hash.js etc.
I hope I was able to explain it clearer this time! Thank you!
Thank you for the detailed explanation. To answer your query, the injected block is not subject to any change untill you change anything in the configuration on the eum side. If any config is changed that will impact the injected code even if the impact is little it may invalidate your hash calculation.
There are indirect changes which could affect this too, like agent or controller upgrade at your end. Another scenario what I can think of is if your license is changed and you change your eum account name and license key in which case the EUM app key also changes. This will indirectly reflect in the injected code and in that scenario as well the hash need to be recalculated.
To sum up below are the scenarios I could think of in which the injected block could change invalidating your CSP:
1. Any changed in EUM configuration from EUM config UI.
2. Any controller or app agent side upgrade.
3. Change in license key where the new license has changed EUM account name or eum key.
Please let me know if the above information helps.