Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

False positive on valid ESPO traffic using OWASP core ruleset #2083

Open
analystcmyk opened this issue Sep 22, 2021 · 2 comments
Open

False positive on valid ESPO traffic using OWASP core ruleset #2083

analystcmyk opened this issue Sep 22, 2021 · 2 comments

Comments

@analystcmyk
Copy link

Is your feature request related to a problem? Please describe.

Application firewalls following the OWASP core ruleset (coreruleset.org) scan for SQL injection attempts and trigger on valid Espo traffic. Not all firewalls can be tuned to intelligently allow for eg regexps to override the SQL injection rules.

Example URL that triggers false positive :
https://espocrm.local/api/v1/Report?select=name%2CentityType%2Ctype%2CassignedUserId%2CassignedUserName%2CcategoryId%2CcategoryName&maxSize=100&offset=0&orderBy=name&order=asc&where%5B0%5D%5Battribute%5D=categoryId&where%5B0%5D%5Btype%5D=isNull

Describe the solution you'd like
Prefer not to use SQL keywords as "select" and "where". Maybe change to "sel" and "whr" in ControllerUtil.
Optional you may consider filing a request for an exemption rule.

Describe alternatives you've considered
For now only disabling the SQL injection detection rule which is not preferred.

Additional context
https://coreruleset.org/installation/
@analystcmyk
Copy link
Author

analystcmyk commented Nov 30, 2021 •
edited

Related : Azure WAF (Web application Firewall) false positive :

Upgrading extensions or uploading files may trigger the rule
"Request body length (excluding file upload fields) exceeded the limit"

This is because files are base64 encoded in the request body, not as regular attachment uploads.

Just be aware that if you are running behind an application gateway, that these errors may produce silent application fails with only a short "error 403" message.

Suggested : the client could report this type of intermediate errors back to the application server. Currently they just disappear in the rejection logs of Application Gateways that may not be under your control.

Application gateways/firewalls do not always add a specific header ( Amazon does , see https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ ) that can be tested by the client whether it is a gateway error. The client might parse the response body for keywords like "gateway" in case of a 403.

Example response of Azure WAF

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>Microsoft-Azure-Application-Gateway/v2</center>
</body>
</html>

@analystcmyk
Copy link
Author

This behaviour also occurs with servers that have modsec enabled, or that have Cloudflare protection.

Suggested : Handle 403 similar as 200 :

Add console.error('Error 403: ' + xhr.responseText);
to the 403 part at https://github.com/espocrm/espocrm/blob/master/client/src/app.js#L837

This enables at least to quickly spot that it is an error not related to EspoCRM permissions.

Even better would be that the client would report back to espo.log... in the future..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@analystcmyk