How to get over a very high wall 🙂
The request that I have issues with are generated by the WAB Dev Edition Query widget, so I ask the question here - but technically the problem is not limited to WAB.
I have a WAB application deployed on an public facing server. It use the ArcGIS proxy application to pass request to ArcGIS Portal from the DMZ to the internal private server. No problems there.
The issue that I have is that some Query requestedts gets being blocked. I identfied two scenariois.
1) When the "where" parameter use 1=1.
2) When the "where" parameter use UPPER([myFieldname]) Like xyz
for reference:
https://help.fortinet.com/fweb/571/Content/FortiWeb/fortiweb-admin/syntaxbased_sqli_detect.htm
The first scenario I can work around by changing the source of the standard query widget to use [myobjectidfield] > 0 instead
The second scenario I cant get around without losing functionality / % of matching is lower. or customise the proxy & query widget code so that in combination it use known request formats that gets mapped in the proxy code to the correct format. Dont think it is the right solution though.
So the question is - how do other people fight the battle with Firewall admins? e.g. to reduce the number of false positives and open up rules to allow valid requests trough...
How to I defend the ArcGIS Server's ability to stop SQL injection? Are there case studies of ArcGIS servers that were penetrated?
Its for a big organisation with an entire security committee. Im not sure I have the will to fight the battle, that should actually be done on an ESRI vs Fortiweb level in my opinion.
Or the REST API use a WHERE input format that is less similar than t-sql. One can only dream right?
