Adobe Workfront Proof causing OWASP Core Ruleset Inbound Anomaly Score Exceeded
We have been running the Cloudflare OWASP Core Ruleset with an anomaly score threshold of High - 25 and higher.
Our web content creators and their internal business customers (just under 4k users overall) use Adobe Workfront Proof in the process of developing new pages on our site, and have been running into issues with a Managed Challenge infinite loop that I'm trying to resolve.
I've been able to determine the cluster our Workfront account is tied to and have created a WAF Custom Rule to bypass managed rules for the Adobe-specified IP addresses associated with their cluster. Unfortunately, this does not resolve the issue, as the WAF Event shows the Inbound Anomaly Score Exceeded is associated with the end-user's IP address. It looks like the Workfront Proof app uses an embedded Chrome browser with no way to inject any custom headers or mods. Typically my approach has been to create a unique User Agent string and write a rule to narrowly bypass the rules that are causing the managed challenge, but I'm not seeing any way to inject anything like this to uniquely identify our Workfront Proof traffic. There are far too many users to try to whitelist their IP addresses (and with many staff working from home or other off-site location that's a moving target all the time).
The WAF Events anomaly score is coming back as a 35, which would require relaxing the OWASP anomaly score threshold to Medium - 40 or higher for all traffic, not just the Workfront traffic. I'd really rather not have to downgrade our security posture for all traffic just to allow this tool to work for a small subset of all site visitors.
Looking for recommendations on how to identify and allow specifically OUR Workfront Proof traffic as an ideal solution. Less ideal would be to just allow Workfront Proof traffic from any user (whether one of our staff or a different Adobe user outside of our company).
Thanks!
Our web content creators and their internal business customers (just under 4k users overall) use Adobe Workfront Proof in the process of developing new pages on our site, and have been running into issues with a Managed Challenge infinite loop that I'm trying to resolve.
I've been able to determine the cluster our Workfront account is tied to and have created a WAF Custom Rule to bypass managed rules for the Adobe-specified IP addresses associated with their cluster. Unfortunately, this does not resolve the issue, as the WAF Event shows the Inbound Anomaly Score Exceeded is associated with the end-user's IP address. It looks like the Workfront Proof app uses an embedded Chrome browser with no way to inject any custom headers or mods. Typically my approach has been to create a unique User Agent string and write a rule to narrowly bypass the rules that are causing the managed challenge, but I'm not seeing any way to inject anything like this to uniquely identify our Workfront Proof traffic. There are far too many users to try to whitelist their IP addresses (and with many staff working from home or other off-site location that's a moving target all the time).
The WAF Events anomaly score is coming back as a 35, which would require relaxing the OWASP anomaly score threshold to Medium - 40 or higher for all traffic, not just the Workfront traffic. I'd really rather not have to downgrade our security posture for all traffic just to allow this tool to work for a small subset of all site visitors.
Looking for recommendations on how to identify and allow specifically OUR Workfront Proof traffic as an ideal solution. Less ideal would be to just allow Workfront Proof traffic from any user (whether one of our staff or a different Adobe user outside of our company).
Thanks!
Welcome to the official Cloudflare Developers server. Here you can ask for help and stay updated with the latest news
85,042Members
Resources
Was this page helpful?
