You are right about IIS not logging the 403 error, but 403 is a response that comes from IIS, where else would I be receiving the error from as I am talking to my IIS server when I am on the website. We do not use apache or any other service to host Forms, it is an IIS application.

If I open a browser on the server and use https://localhost then the Save does work, but what is the difference?

I am not familiar with the terminology of WAF

Update:

Oh snap! Look at this:

If I check one of my servers this shows Microsoft IIS. What in the world is cloudflare? I do not see it on the operating system, everything shows it is hosted under IIS. I am checking with IT on this. If this is what a WAF is I don't trust it one bit.

The response headers ("server" and "cf-*") make it look like you are using cloudflare as a reverse proxy, and the fact that the query is not recorded by IIS suggests that it was blocked by cloudflare.

If this is what a WAF is I don't trust it one bit.

This is akin to walking through a metal detector at airport security, having it beep at a metal button on your clothing, and then declaring that you don't trust metal detectors. The metal detector is doing exactly what it's designed to. However, the sensitivity threshold may need to be adjusted so it doesn't trigger on buttons.

I recommend learning more about Web Application Firewalls (WAFs), how they work, and the important security function they serve before passing such judgements. You were surprised by the presence of one doing its job and I assure you you're not the first one. Simply something to be aware of. There's plenty of easily accessible information on the internet, but I'll write a quick summary with some actionable follow-up steps for this case.

WAFs are network security appliances that go in front of your web application. They are typically deployed in tandem with a reverse proxy like so:

Client -> WAF/Reverse Proxy -> Application

WAFs inspect incoming requests and evaluate them against a set of security rules to determine whether to block them or not. These rules can be things like:

• Client IP address matches an IP used by a known botnet
• Request body matches a pattern for possible SQL injection or cross-site scripting (XSS) attack
• Request has suspicious or missing header
• Many others

Most WAFs implement a default rule set, like the OWASP ModSecurity Core Rule Set. These contain a broad set of hundreds of rules covering all sorts of attacks and suspicious behavior and are a great baseline. A great deal of effort from the cybersecurity community goes into creating and maintaining these rule sets - they're not something you could feasibly write yourself.

However, as with any broad default configuration, there are scenarios where you'll need to add exceptions. With WAFs, it's quite common for one or more of the default rules to trigger a false positive on legitimate application traffic. Adding WAF exceptions for false positives is both routine and expected for complex web applications like Laserfiche. Cloudflare even has a WAF documentation page for Handle false positives.

You seem to have run into a scenario where those requests to https://myserver/Forms/api are triggering a Cloudflare WAF rule. Cloudflare should have logged the blocked call(s) along with the rule they triggered in Security Events. Work with the customer IT team to review the logs and handle the false positive by creating an exception for the relevant rule.

I'm sure the community here would appreciate if you replied to this thread with which WAF rule was getting triggered.

Note that WAF logging sometimes uses sampled data (records only a subset of calls) for performance reasons, so if the /Forms/api call doesn't appear there, reproduce the issue a few times and it should show up.

As Brian noted, inspecting the response headers for a "server" value other than "IIS" is often is a good way to tell if there's a reverse proxy/WAF between you and Laserfiche. You can run a WAF on IIS but I've never seen that in practice. WAF's will often (but not always) return an HTTP 403 - Forbidden when they block requests, and the Body of the request will sometimes include something like "403 ModSecurity Action".

I think a metal detector might not be a good analogy of the impact this had on many departments. We opened a case with Laserfiche support and worked with them for a couple weeks in May of last year. We eventually gave up on the ticket because they were obsessed with it being a SQL authentication issue, OS File access rights, or a bug in the version (even though it happened out of the blue). 

Only reason I re-posted here so much later was because I was coming back around to it after it persisted on their newest server with a fresh install of everything.

A metal detector would likely not cause this much in personnel costs and end user headache if it beeped because of a zipper. It is ok for metal detectors to be inaccurate, but when it comes to low level software code it can cause ripples like you would not believe.

This would be first time I have ever come across an issue like this with LF installed in hundreds of environments (in addition to this, before supporting LF, I worked with another IIS product installed across diverse environments for 6 years). We are talking big business, medical, government, and police. You can see how hidden the problem can be. Their IT had no idea, I had no idea, LF Support had no idea, so I would say this should not be a good practice of the WAF provider. Needs more clarity on their part.

However I am thankful I posted here on it again, since Shangyao was right on the money and lead to a possible solution (have not confirmed yet).

I will update the post with my findings, IT confirmed they use a service called cloudflare and is checking into it.

Cloudflare finds this specific page, /Forms/api/routing/save to be unsecure according to what they define as malicious content, which is outlined here in summary

https://developers.cloudflare.com/waf/reference/legacy/old-waf-managed-rules/

This is the most diluted explanation IMO, but that is what I got. I requested getting more specific details on the malicious content that caused a low score in the evaluation, but I am getting resistance.

Maybe if Laserfiche contacted them directly you could have more clout.

We were able to get the app working again by configuring Cloudflare not to block low score websites.

I requested that if they have any concerns with the security in the Laserfiche product they talk with us first, before injecting 403 messages causing the app to crash and the users to think the app is unstable.