• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Fixed Mcirosoft Edge / HTML 5 Uploader / Cloudflare WAF

Pierce

Well-known member
#1
upload_2017-1-24_1-2-30.png

using ms edge, causes this trigger.

Before you ask... yes I disabled the rule and it loses its self with OWASP rules....

Yes its ms edge.

Yes somebody uses it.

Yes I had to disable the awesome html 5 uploader you guys have worked so hard on.

Yes I am submitting a bug report

Yes I am sorry

Yes I know, I know I know :(
 

Amin Sabet

Well-known member
#4
using ms edge, causes this trigger.

Before you ask... yes I disabled the rule and it loses its self with OWASP rules....

Yes its ms edge.

Yes somebody uses it.

Yes I had to disable the awesome html 5 uploader you guys have worked so hard on.

Yes I am submitting a bug report

Yes I am sorry

Yes I know, I know I know :(
Thanks for reporting this one.

My members reported the problem here: https://www.mu-43.com/threads/error-posting-images.89427/

I confirmed their issue to be the same one you are reporting.

Before you ask... yes I disabled the rule and it loses its self with OWASP rules....
Can you explain what you mean by "loses its self"? If you turn "Cloudflare Specials" in WAF, does the problem go away, or do the OWASP rules also have to be turned off to stop the problem?
 

Mike

XenForo developer
Staff member
#11
I believe I have a workaround for this. It appears to be related to a bug in Edge with regards to how it handles an undefined file type in the file read function. It sends a content type of "undefined" to the server. I overrode this to an empty string which is the spec-defined default, which makes it send application/octet-string (what the other browsers send already). This appears to bypass the WAF rule.

One of the workarounds mentioned above is an easy way to solve it, as is disabling the 100011 rule directly. Alternatively, you can overwrite js/xenforo/attachment_editor_new.js with our version here: https://xenforo.com/community/js/xenforo/min/attachment_editor_new.js Note that you will need to hard refresh to ensure that you aren't pulling from cached JS.
 

Brent W

Well-known member
#12
I believe I have a workaround for this. It appears to be related to a bug in Edge with regards to how it handles an undefined file type in the file read function. It sends a content type of "undefined" to the server. I overrode this to an empty string which is the spec-defined default, which makes it send application/octet-string (what the other browsers send already). This appears to bypass the WAF rule.

One of the workarounds mentioned above is an easy way to solve it, as is disabling the 100011 rule directly. Alternatively, you can overwrite js/xenforo/attachment_editor_new.js with our version here: https://xenforo.com/community/js/xenforo/min/attachment_editor_new.js Note that you will need to hard refresh to ensure that you aren't pulling from cached JS.
Is this in the latest version because I just had this triggered on 1.5.13
 

Mike

XenForo developer
Staff member
#13
It should be. Worth checking that the latest version of the file is being delivered (I've seen CDNs not update, depending on settings).
 

Brent W

Well-known member
#15
I am still getting this (purged cache from CloudFlare).

Code:
{
  "id": "3484357ba845380a",
  "country": "US",
  "ip": "75.131.113.23",
  "protocol": "HTTP/2",
  "method": "POST",
  "host": "www.christianforums.com",
  "user_agent": "Mozilla/5.0 (Linux; Android 7.1.1; Pixel Build/NOF27B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Mobile Safari/537.36",
  "uri": "/attachments/do-upload.json?hash=5cc7fa470b07cc17e5a48d6dff18c010&content_type=post",
  "request_duration": 0,
  "triggered_rule_ids": [
    "100011"
  ],
  "action": "block",
  "cloudflare_location": "ATL",
  "occurred_at": "2017-03-31T15:05:48.1Z",
  "rule_detail": [
    {
      "id": "",
      "description": "ARGS:UPLOAD"
    }
  ],
  "rule_message": "Request arguments containing NUL byte",
  "type": "waf",
  "rule_id": "100011",
  "zone_id": "a4cf2ba1548dd21e9766a88865a21265",
  "cookie": ""
}