[Mod-security-developers] [JIRA] Resolved: (MODSEC-34) docushare users generating "Multipart: Invalid boundary in C-T (malformed)" errors

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-34.
-------------------------------------

    Resolution: Cannot Reproduce

> docushare users generating "Multipart: Invalid boundary in C-T (malformed)" errors
> ----------------------------------------------------------------------------------
>
>                 Key: MODSEC-34
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-34
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.5.7
>         Environment: CentOS5
>            Reporter: Jason Haar
>            Assignee: Breno Silva Pinto
>             Fix For: 2.6.0
>
>         Attachments: 20081027-203010--1HkuAoBPEEAACAe544AAAAa.gz
>
>
> We're seeing this several times a day on a backend docushare server with modsecurity running in monitor mode (ie non-blocking)
> [Mon Oct 27 20:30:09 2008] [error] [client 10.1.94.38] ModSecurity: Multipart parsing error (init): Multipart: Invalid boundary in C-T (malformed). [hostname "trl.trimble.com"] [uri "/docushare/dscgi/ds.py/ApplyUpload/Collection-59919"] [unique_id "-1HkuAoBPEEAACAe544AAAAa"]
> As with MODSEC-19, the client is the "Docushare client" instead of a Webbrowser. I'll attach the audit log I have (after I strip out the content), but assuming the issue is something to do with Content-Type values, they are:
> Content-Type: multipart/form-data; charset=UTF-8; boundary=354e650f45ec2927
> Content-Type: application/octet-stream
> Content-Type: text/xml;charset=UTF-8
> I have been unable to go production (block mode) with modsecurity on this Docushare backend due to their damn client that I'm tempted to just disable modsec if the User-Agent matches "DsAxess/*". Other than opening up a security risk, should the following achieve that?
> SecRule  REQUEST_HEADERS:User-Agent "^DsAxess/" "allow, nolog, ctl:ruleEngine=Off,ctl:auditEngine=Off"
>  I'm assuming in all this, that as this isn't a "rule" hit, in block mode this would mean these requests would be error'ing? i.e. I have to turn modsecurity totally off in order for these to work?
> Thanks
> Jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://www.modsecurity.org/tracker/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira