logback / LOGBACK-1581 [Open] loback-access should not use Request.getParameterNames ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1581 ============================== Issue created ------------------------------ Joakim Erdfelt created this issue on 09/Oct/21 3:39 PM Summary: loback-access should not use Request.getParameterNames Issue Type: Bug Assignee: Logback dev list Components: logback-access Created: 09/Oct/21 3:39 PM Priority: Major Reporter: Joakim Erdfelt Description: logback-access has exposed an interesting DOS attack. logback-access uses the `HttpServletRequest.getParameterNames()` API during it's attempt at logging the request. The use of `getParameterNames` should never occur in request logging. The use of the getParameterNames API has side effects that will cause the Request body content to be read (if it hasn't been read before, and the Content-Type is `application/x-www-form-urlencoded` or `multipart/form-data`). This in combination of when the request logging occurs means your request logging is subverting the intended behavior of the application, and the request logging is now also impacting the behavior of the request / response exchange. Scenario 1: * Request arrives, it's a POST request, with `Content-Type: multipart/form-data`, and contains 2GB of body content. * Container dispatches to the Application, it determines that the request should not be processed (missing headers, bad authentication, bad authorization, etc. It can be countless list of things). * Application uses HttpServletResponse.sendError(403) * Dispatch to the Application is done. * Container finishes sending the response. * Container calls the request logging implementation. In this scenario, `logback-access` just read the request body content, all 2GB, just to throw it away. And there was no protection on sizes or MultipartConfigElement as the context dispatch is done and the request logging occurred on Server level. Your request logging now consumed server resources that the application wasn't in control over. Scenario 2: * Request arrives, it's a trash, complete garbage, not even recognizable as HTTP. * Container responds with status code 400. * Container calls the request logging implementation. The request is bad, the status code is 400, logback-access should not be attempting to access the request details at all in this scenario, but it does. Scenario 3: * Request arrives, it's from a bad, but well meaning HTTP Client. * Request contains something that breaks the HTTP spec (like using a `Content-Length` + `Transfer-Encoding` at the same time) * Container responds with status code 400. * Container calls the request logging implementation. The request is bad, the status code is 400, logback-access should not be attempting to access the request details at all in this scenario, but it does. But in this scenario, the request is actually HTTP, but the request body content is suspect. It could be valid, it could be malicious. logback-access should not be attempting to cause a request body read by using the `HttpServletRequest.getParameterNames()`. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)