hvital
commented
5 years ago Hi @mwittenbols
In order to double check which rule is blocking those requests, I would recommend to activate AWS WAF logs (https://docs.aws.amazon.com/waf/latest/developerguide/logging.html)
If it is a real SQLi false positive, then I would handle it like we recommend for XSS false positives: https://docs.aws.amazon.com/solutions/latest/aws-waf-security-automations/considerations.html#xss-false-positives
We are experiencing issues with WAF enabled when HTTP requests to an Elastic Beanstalk instance get blocked if the POST formdata of those requests contains the word "ON" preceded by a space. We found that, if the space is represented by its URL encoded variants, such as + and %20, it will also trigger the WAF blocking the request. If, however, we would replace the space with any other character such as - or remove the preceding space altogether, the request will no longer be blocked with a 403.
We have all the default rules enabled in our WAF configuration, and we think it is either the Cross-site scripting protection or more likely the SQL-injection protection that is causing the issue. As "ON" is a SQL keyword it may be that WAF blindly triggers with the existence of SQL keywords in the POST formdata, surrounded by spaces.
We isolated the issue by extracting the cURL commands from the browser logs and in essence this is what we saw:
BLOCKED WITH 403:
curl "https://abc.xyz.com" -H <header1> -H <header2> -H <headerN> --data "ReturnPageAfterAddOrUpdate=PlanDesign^&CanSave=True^&DeleteRow=0^&AddButton=^&DeleteButton=^&ReportButton=^&ProposalNumber=000000000^&NumberOfPlans=3^&DisableReportButton=False^&NumberOfPlanRowsOnPage=1^&AbcWebNumberOfPlansValidationMessage=+ON^&LastPageAction=PageLoad^&CaseInformationAddItem.CaseNumber=^&CaseInformationAddItem.SitusTypeId=044db6d9-fe01-47b9-b452-7a57b36b5c4a^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.AbcWebPlanNumber=^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.PatriotPlanNumber=^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.EffectiveDate=05^%^2F01^%^2F2019^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.Notes=^&CancelButton=+Cancel"WORKED:curl "https://abc.xyz.com" -H <header1> -H <header2> -H <headerN> --data "ReturnPageAfterAddOrUpdate=PlanDesign^&CanSave=True^&DeleteRow=0^&AddButton=^&DeleteButton=^&ReportButton=^&ProposalNumber=000000000^&NumberOfPlans=3^&DisableReportButton=False^&NumberOfPlanRowsOnPage=1^&AbcWebNumberOfPlansValidationMessage=-ON^&LastPageAction=PageLoad^&CaseInformationAddItem.CaseNumber=^&CaseInformationAddItem.SitusTypeId=044db6d9-fe01-47b9-b452-7a57b36b5c4a^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.AbcWebPlanNumber=^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.PatriotPlanNumber=^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.EffectiveDate=05^%^2F01^%^2F2019^&CaseInformationAddItem.CaseInformationPlanRowItems^%^5B0^%^5D.Notes=^&CancelButton=+Cancel"Notice the value for AbcWebNumberOfPlansValidationMessage in the POST data where changing the + (which is essentially a space) into a - symbol, makes all the difference. The - symbol is just an example, any other symbol would work as long as it is not a space when URL decoded.
I think having the string " ON" appear in a POST form data is not uncommon so this may affect other customers. Perhaps there is a relation with some of the headers we use, which I left out of the code snippet above, but it looks to us a problem with the regular expressions that are built into WAF to parse POST form data before the request is handled.