Bug 1419145 - [GSS](6.4.z) Content type can show other header value after FORM auth restores request
Summary: [GSS](6.4.z) Content type can show other header value after FORM auth restore...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web
Version: 6.4.13
Hardware: Unspecified
OS: Unspecified
Target Milestone: CR1
: EAP 6.4.16
Assignee: Jiri Ondrusek
QA Contact: Radim Hatlapatka
Depends On:
Blocks: eap6416-payload 1440846
TreeView+ depends on / blocked
Reported: 2017-02-03 17:06 UTC by Aaron Ogburn
Modified: 2020-04-15 15:13 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-06-22 09:24:55 UTC
Type: Bug

Attachments (Terms of Use)
bz1419145repro.zip (6.40 KB, application/zip)
2017-02-06 14:32 UTC, Aaron Ogburn
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBPAPP-11259 0 Major Pending Upload to Patch Repository [GSS](5.2.0 patch) content type can show other header value after FORM auth restores request 2019-03-27 19:41:59 UTC
Red Hat Knowledge Base (Solution) 2916091 0 None None None 2017-02-08 19:41:35 UTC

Description Aaron Ogburn 2017-02-03 17:06:17 UTC
Description of problem:

In particular scenarios, request.getContentType() incorrectly shows another header's value after FORM auth restores a request.

Version-Release number of selected component (if applicable):

How reproducible:

In specific scenario

Steps to Reproduce:
1. Deploy app with FORM auth (for example, the one attached)
2. Access app via ajp proxy.  Using httpd, it helps to reproduce the issue with the following in place to force a content type header in the requests:

RequestHeader set Content-Type application/x-www-form-urlencoded

3. Check the getContentType() return after following the redirect from j_security_check.  The example app will spit this out.

Actual results:

getContentType() may return incorrect value

Expected results:

getContentType() returns correct value

Additional info:

This can occur if the client provides a content type header in the request when following the j_security_check redirect.  It is also dependent upon coyote.Request.contentType() being called before the FormAuthenticator is reached.

This results in the issue in the following manner:

1) client performs form auth successfully and follows redirect after j_security_check with a request including a content-type header
2) coyote.Request.contentType() is called and stores a MessageBytes (contentTypeMB) for the content-type header
3) FormAuthenticator is reached and recycles the coyote.Request's mimeheaders. The coyote.Request is then still referring to a MessageBytes instance with contentTypeMB, although with a null value.
4) FormAuthenticator restores the request.  This can result in the contentTypeMB MessageBytes instance being reset with a new value.  Then subsequent calls to request.getContentType() may improperly return null or potentially the value from another header.

Note that AJP is more prone to this since it inherently calls Request.contentType() in its prepareRequest().  But it could be seen still on HTTP if something also results in an early Request.contentType() call prior to FormAuthenticator (for instance if the RequestDumperValve is enabled)

Comment 4 Aaron Ogburn 2017-02-06 14:32:21 UTC
Created attachment 1248046 [details]

Comment 18 Michael Cada 2017-06-07 14:01:53 UTC
Verified with EAP 6.4.16.CP.CR1

Comment 19 Petr Penicka 2017-06-22 09:24:55 UTC
Released on June 20 2017 as part of the EAP 6.4.16 maintenance release.

Note You need to log in before you can comment on or make changes to this bug.