[jboss-jira] [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data

[Anil Saldhana (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12438933#action_12438933 ] 

Anil Saldhana commented on JBAS-6213:
-------------------------------------

It is generating an AuditEvent to be passed to the audit framework.  It is the configuration from the user that decides whether the audit event is logged or not.  It is no different from the requestdispatcher or access log valves.  We need this as part of the security audit.

> Securing web-app REALLY cause incorrect character encoding in GET/POST data
> ---------------------------------------------------------------------------
>
>                 Key: JBAS-6213
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6213
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>    Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
>         Environment: Fedora 8
> JDK 1.5+
> IE 7/Firefox 3
>            Reporter: jimyip
>            Assignee: Anil Saldhana
>            Priority: Critical
>
> Similar problem found as stated by JBAS-5976.
> I also found the problem as stated by Igor. After several days work, it is the problem of JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From "AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and caused the encoding set according to the OS before any character encoding filter can be applied.
> I use a wrapper Request to show the calling path. Below are the stacktrace:
>         at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
>         at org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
>         at org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
>         at org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
>         at org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
>         at org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
>         at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
>         at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>         at java.lang.Thread.run(Thread.java:595)

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