|
From: Ryan B. (JIRA) <no...@mo...> - 2013-10-01 13:27:26
|
[ https://www.modsecurity.org/tracker/browse/MODSEC-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Barnett closed MODSEC-420.
-------------------------------
Resolution: Fixed
> ModSecurity 2.7.5 for Nginx 1.4.2 duplicate charset headers
> -----------------------------------------------------------
>
> Key: MODSEC-420
> URL: https://www.modsecurity.org/tracker/browse/MODSEC-420
> Project: ModSecurity
> Issue Type: Bug
> Security Level: Normal
> Components: Core
> Affects Versions: 2.7.4
> Environment: Linux host-1 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux that serves as a load balancer
> 2013/08/29 17:27:20 [notice] 27485#0: ModSecurity for nginx (STABLE)/2.7.5 (http://www.modsecurity.org/) configured.
> 2013/08/29 17:27:20 [notice] 27485#0: ModSecurity: APR compiled version="1.4.6"; loaded version="1.4.6"
> 2013/08/29 17:27:20 [notice] 27485#0: ModSecurity: PCRE compiled version="8.30 "; loaded version="8.30 2012-02-04"
> 2013/08/29 17:27:20 [notice] 27485#0: ModSecurity: LIBXML compiled version="2.8.0"
> 2013/08/29 17:27:20 [notice] 27485#0: using the "epoll" event method
> 2013/08/29 17:27:20 [notice] 27485#0: nginx/1.4.2
> 2013/08/29 17:27:20 [notice] 27485#0: built by gcc 4.7.2 (Debian 4.7.2-5)
> 2013/08/29 17:27:20 [notice] 27485#0: OS: Linux 3.2.0-4-amd64
> 2013/08/29 17:27:20 [notice] 27485#0: getrlimit(RLIMIT_NOFILE): 1024:4096
> Reporter: veli pekka jutila
> Assignee: Breno Silva Pinto
> Labels: charset, header, modsecurity,, nginx,
>
> When I disable ModSecurity from nginx.conf my backend provides charset header correctly
> sec-176:~ wellu$ curl --head http://111.111.111.111/interface/ShopName?ffg
> HTTP/1.1 200 OK
> Server: nginx/1.4.2
> Date: Thu, 29 Aug 2013 14:34:18 GMT
> Content-Type: text/html; charset=UTF-8
> Connection: keep-alive
> Vary: Accept-Encoding
> Set-Cookie: MCFS=b4v6gu0c0fsmdtj52rla35eg06; expires=Mon, 28-May-2057 05:09:58 GMT; path=/; domain=.111.111; HttpOnly
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: -1
> X-Content-Type-Options: nosniff
> XSS-Protection: 1; mode=block
> X-Varnish: 579266232
> When I enable ModSecurity for this server and just use the basic modsecurity.conf I get duplicate charset headers and also the X-headers are removed. Also the char after UTF-8 depends on how many chars after '?' I use in the URL
> sec-176:~ wellu$ curl --head http://111.111.111.111/interface/ShopName?ffg
> HTTP/1.1 200 OK
> Server: nginx/1.4.2
> Date: Thu, 29 Aug 2013 14:35:18 GMT
> Content-Type: text/html; charset=UTF-8; charset=UTF-8?
> Connection: keep-alive
> Set-Cookie: MCFS=rknbdjna7m1oi5qh9pk6uqmrm7; expires=Mon, 28-May-2057 05:12:00 GMT; path=/; domain=.111.111; HttpOnly
> Cache-Control: no-cache
> Expires: -1
> modsecurity.conf
> -- Rule engine initialization ----------------------------------------------
> # Enable ModSecurity, attaching it to every transaction. Use detection
> # only to start with, because that minimises the chances of post-installation
> # disruption.
> #
> SecRuleEngine DetectionOnly
> # -- Request body handling ---------------------------------------------------
> # Allow ModSecurity to access request bodies. If you don't, ModSecurity
> # won't be able to see any POST parameters, which opens a large security
> # hole for attackers to exploit.
> #
> SecRequestBodyAccess On
> # Enable XML request body parser.
> # Initiate XML Processor in case of xml content-type
> #
> SecRule REQUEST_HEADERS:Content-Type "text/xml" \
> "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
> # Maximum request body size we will accept for buffering. If you support
> # file uploads then the value given on the first line has to be as large
> # as the largest file you are willing to accept. The second value refers
> # to the size of data, with files excluded. You want to keep that value as
> # low as practical.
> #
> #SecRequestBodyLimit 13107200
> SecRequestBodyLimit 22020096
> SecRequestBodyNoFilesLimit 131072
> # Store up to 128 KB of request body data in memory. When the multipart
> # parser reachers this limit, it will start using your hard disk for
> # storage. That is slow, but unavoidable.
> #
> SecRequestBodyInMemoryLimit 131072
> # What do do if the request body size is above our configured limit.
> # Keep in mind that this setting will automatically be set to ProcessPartial
> # when SecRuleEngine is set to DetectionOnly mode in order to minimize
> # disruptions when initially deploying ModSecurity.
> #
> SecRequestBodyLimitAction Reject
> # Verify that we've correctly processed the request body.
> # As a rule of thumb, when failing to process a request body
> # you should reject the request (when deployed in blocking mode)
> # or log a high-severity alert (when deployed in detection-only mode).
> #
> SecRule REQBODY_ERROR "!@eq 0" \
> "id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
> # By default be strict with what we accept in the multipart/form-data
> # request body. If the rule below proves to be too strict for your
> # environment consider changing it to detection-only. You are encouraged
> # _not_ to remove it altogether.
> #
> SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
> "id:'200002',phase:2,t:none,log,deny,status:44, \
> msg:'Multipart request body failed strict validation: \
> PE %{REQBODY_PROCESSOR_ERROR}, \
> BQ %{MULTIPART_BOUNDARY_QUOTED}, \
> BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
> DB %{MULTIPART_DATA_BEFORE}, \
> DA %{MULTIPART_DATA_AFTER}, \
> HF %{MULTIPART_HEADER_FOLDING}, \
> LF %{MULTIPART_LF_LINE}, \
> SM %{MULTIPART_MISSING_SEMICOLON}, \
> IQ %{MULTIPART_INVALID_QUOTING}, \
> IP %{MULTIPART_INVALID_PART}, \
> IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
> FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
> # Did we see anything that might be a boundary?
> #
> SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
> "id:'200003',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
> # PCRE Tuning
> # We want to avoid a potential RegEx DoS condition
> #
> SecPcreMatchLimit 1000
> SecPcreMatchLimitRecursion 1000
> # Some internal errors will set flags in TX and we will need to look for these.
> # All of these are prefixed with "MSC_". The following flags currently exist:
> #
> # MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
> #
> SecRule TX:/^MSC_/ "!@streq 0" \
> "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
> # -- Response body handling --------------------------------------------------
> # Allow ModSecurity to access response bodies.
> # You should have this directive enabled in order to identify errors
> # and data leakage issues.
> #
> # Do keep in mind that enabling this directive does increases both
> # memory consumption and response latency.
> #
> SecResponseBodyAccess Off
> # Which response MIME types do you want to inspect? You should adjust the
> # configuration below to catch documents but avoid static files
> # (e.g., images and archives).
> #
> SecResponseBodyMimeType text/plain text/html text/xml
> # Buffer response bodies of up to 512 KB in length.
> SecResponseBodyLimit 524288
> # What happens when we encounter a response body larger than the configured
> # limit? By default, we process what we have and let the rest through.
> # That's somewhat less secure, but does not break any legitimate pages.
> #
> SecResponseBodyLimitAction ProcessPartial
> # -- Filesystem configuration ------------------------------------------------
> # The location where ModSecurity stores temporary files (for example, when
> # it needs to handle a file upload that is larger than the configured limit).
> #
> # This default setting is chosen due to all systems have /tmp available however,
> # this is less than ideal. It is recommended that you specify a location that's private.
> #
> SecTmpDir /var/log/modsecurity_workdir/
> # The location where ModSecurity will keep its persistent data. This default setting
> # is chosen due to all systems have /tmp available however, it
> # too should be updated to a place that other users can't access.
> #
> SecDataDir /var/log/modsecurity_workdir/
> # -- File uploads handling configuration -------------------------------------
> # The location where ModSecurity stores intercepted uploaded files. This
> # location must be private to ModSecurity. You don't want other users on
> # the server to access the files, do you?
> #
> SecUploadDir /var/log/modsecurity_workdir/
> # By default, only keep the files that were determined to be unusual
> # in some way (by an external inspection script). For this to work you
> # will also need at least one file inspection rule.
> #
> SecUploadKeepFiles RelevantOnly
> # Uploaded files are by default created with permissions that do not allow
> # any other user to access them. You may need to relax that if you want to
> # interface ModSecurity to an external program (e.g., an anti-virus).
> #
> #SecUploadFileMode 0600
> # -- Debug log configuration -------------------------------------------------
> # The default debug log configuration is to duplicate the error, warning
> # and notice messages from the error log.
> #
> #SecDebugLog /var/log/nginx/modsecurity/debug.log
> #SecDebugLogLevel 0
> # -- Audit log configuration -------------------------------------------------
> # Log the transactions that are marked by a rule, as well as those that
> # trigger a server error (determined by a 5xx or 4xx, excluding 404,
> # level response status codes).
> #
> SecAuditEngine RelevantOnly
> SecAuditLogRelevantStatus "^(?:5|4(?!04))"
> # Log everything we know about a transaction.
> SecAuditLogParts ABIJDEFHZ
> # Use a single file for logging. This is much easier to look at, but
> # assumes that you will use the audit log only ocassionally.
> #
> #SecAuditLogType Serial
> SecAuditLogType Concurrent
> SecAuditLog /var/log/nginx/modsecurity/modsec_audit.log
> # Specify the path for concurrent audit logging.
> SecAuditLogStorageDir /var/log/nginx/modsecurity/
> # -- Miscellaneous -----------------------------------------------------------
> # Use the most commonly used application/x-www-form-urlencoded parameter
> # separator. There's probably only one application somewhere that uses
> # something else so don't expect to change this value.
> #
> SecArgumentSeparator &
> # Settle on version 0 (zero) cookies, as that is what most applications
> # use. Using an incorrect cookie version may open your installation to
> # evasion attacks (against the rules that examine named cookies).
> #
> SecCookieFormat 0
> # Specify your Unicode Code Point.
> # This mapping is used by the t:urlDecodeUni transformation function
> # to properly map encoded data to your language. Properly setting
> # these directives helps to reduce false positives and negatives.
> #
> #SecUnicodeCodePage 20127
> #SecUnicodeMapFile unicode.mapping
> #Include csr/modsecurity_crs_10_setup.conf
> #Include csr/activated_rules/*.conf
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
