FortiWeb: is there a way to completely "bypass" the security profile for certain URL

[luis_abreu]

Hello guys.

Quick question: is there a way to completely bypass #Fortiweb (7.2.10) for specific URL request? For instance, suppose we have a web site with a config that looks something like this (this config inherits a default web protection profile which is shown at the end):

edit "test"

    set server-pool some_pool

    set http-content-routing-id 11698441117558787025

    config  content-routing-match-list

      edit 1

        set match-condition equal

        set match-expression site.something.org

      next

    end

  next

Is there a way of saying that all the requests for a specific url (ex.: https://site.something.org/someuurl) should completely bypass the request and response validations performed by ###Fortiweb (Ie, for this URL, #Fortiweb should not apply any scans to the HTTP request and response and shouldn't also buffer the HTTP response before sending it back to the client)?

We've tried using allow lists, but we're still seing the HTTP response being buffered (it seems like the response always gets buffered by FW before being returned to the browser - even with the chunk module enabled, chunks are being "bufered" by FortiWeb  unless one of them is bigger than 512 Kb - when this happens, everything just works as expected "after" this chunk is processed).

Here's the web protection policy that is being applied:

config waf web-protection-profile inline-protection

edit "Inline Protection - NO PERIOD BLOCK"
set client-management enable
unset threat-score-profile
set http-session-cookie disable
set http-session-timeout 1200
unset url-access-policy
set signature-rule "Protection - VERY LOW"
set x-forwarded-for-rule X-FORWARDED
unset parameter-validation-rule
unset hidden-fields-protection
set allow-method-policy "Allow Method Policy"
set url-rewrite-policy "URL Rewriting Policy"
unset http-authen-policy
set file-upload-policy WebShell
set webshell-detection-policy WebShell
unset file-exception-policy
set http-protocol-parameter-restriction "Standard Protection"
set redirect-url http://
set amf3-protocol-detection disable
set rdt-reason disable
set ip-list-policy BLOCKIP
unset file-compress-rule
set application-layer-dos-prevention "DoS Protection Policy"
unset geo-block-list-policy
set custom-access-policy "Predefined - Advanced Protection - Alert Only"
set ip-intelligence enable
set mobile-app-identification disable
unset token-secret
set token-header Jwt-Token
unset mobile-api-protection
unset site-publish-helper
unset cookie-security-policy
unset padding-oracle
set profile-id 655804019535001661
unset comment
set fortigate-quarantined-ips enable
set quarantined-ip-action alert_deny
set quarantined-ip-severity High
unset quarantined-ip-trigger
unset csrf-protection
unset mitb-protection
unset user-tracking-policy
unset http-header-security
unset xml-validation-policy
unset json-validation-policy
unset openapi-validation-policy
unset websocket-security-policy
unset cors-protection-policy
unset custom-response
set bot-mitigate-policy "Bot Mitigation"
unset api-management-policy
unset url-encryption-policy
set syntax-based-attack-detection "Protection - SQL/XSS Syntax Based Detection"
unset link-cloaking-policy
set owasp_api_top10_log_field enable
next
end

[Anthony_E]

Hello Luis,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[Anthony_E]

Hi Luis,

Did you already have a look at this document?:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-specify-which-security-profiles-to-...

Regards,

[luis_abreu]

Hello Anthony.

I believe we haven't tried that. We've tried several combinations (ex:. applying an empty web protection profile, adding urls to the allow list, etc), but nothing seemed to work.

The issue we're facing is that #Fortiweb will always "buffer" the HTTP reponse for chunked  HTTP 1.1 responses if the returned chunks from the backend server are smaller than 512kb,  When they're bigger, it seems like it will simply return everything as is to the client (which, btw, is what we want for a specific URL) instead of creating new chunks and returning them all at once.

Anyway, I'll give it a try and then I'll come back with our findings.

Thanks again and happy new year!

[luis_abreu]

Hello again @Anthony_E .

I've just noticed that the link you've sent is for FortiGate and the question is about FortiWeb (https://community.fortinet.com/t5/FortiWeb/tkb-p/TKB34).

[shafiq23]

Hello @luis_abreu,

If your requirement is to bypass security scans then URL Access feature is able to do it.

https://docs.fortinet.com/document/fortiweb/7.4.6/administration-guide/232579/restricting-access-bas...

>> Match the URL Access condition parameter and set action as Pass. FortiWeb will not scan any further security module.

Note: Refer FortiWeb sequence of scans in which security module scans prior to URL Access will still be executed though.https://docs.fortinet.com/document/fortiweb/7.4.6/administration-guide/234292/sequence-of-scans

As per my understanding, there is no option to completely bypass per URL that will let FortiWeb not parsing the request/respond.

Thanks.

Regards,
Shafiq

[luis_abreu]

Hello.

Yes, I believe you're right. The URL Access condition is only applied to the request and it's not present on the response sequence, so I think that it will not exempt the HTTP response from being scanned...

Unfortunately, we still haven't found a way to bypass the response processing run by FWB. And we've tried lots of things (from empty profiles to no profiles,etc.)...The only way to bypass the response scans is to fill the max body size buffer (when that buffer is full, FWB will simply dump everything it has received until that point and it will simply forward all the remaining packets without any processing).

[luis_abreu]

Hello again.

After opening a ticket, it seems like there's no way to exempt the response from being scanned. This is cleary a missing feature which I'd love to see in a future release (after all, there's an option to exempt the request from same scans by setting an allow list). Notice that the global allow list/allow list won't exempt the response from being scanned...