Issue Details (XML | Word | Printable)

Key: GLASSFISH-18257
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: oleksiys
Reporter: benjamin_m
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
glassfish

On URI decode exception the access log is not used

Created: 26/Jan/12 10:28 AM   Updated: 26/Jan/12 12:44 PM
Component/s: grizzly-kernel
Affects Version/s: 3.1_b43
Fix Version/s: None

Time Tracking:
Not Specified

Environment:

Linux x86_64


Tags: grizzly logging
Participants: benjamin_m and oleksiys


 Description  « Hide

When Grizzly throws an "Invalid URI character encoding" exception, the URI is part of the stack trace but the HTTP request info isn't saved on the access log.
This is a problem if the request URI makes it obvious that the requester is trying an exploit/vulnerability.
Without the access log used, there is no way of seeing the IP/hostname of the requester to identify the source of this attack attempt.



oleksiys added a comment - 26/Jan/12 10:35 AM

Can you pls. check if it's still the case in the latest promoted Glassfish 3.1.2
http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b19.zip

Thanks.


benjamin_m added a comment - 26/Jan/12 12:22 PM

After trying to replicate in a VM with the suggested build, a similar error is not thrown.
To specify, here is the stack trace of the URI decoding issue which is not being logged in the access log.

[#|2012-01-26T07:50:40.472+0100|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=23;_ThreadName=Thread-1;|Internal Server error: /../../../../../../../../boot.ini
java.io.IOException: Invalid URI character encoding
at com.sun.grizzly.util.http.HttpRequestURIDecoder.decode(HttpRequestURIDecoder.java:101)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:185)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)


oleksiys added a comment - 26/Jan/12 12:34 PM

Just to make sure, you didn't see the record in the access.log related to the corrupted request?


benjamin_m added a comment - 26/Jan/12 12:39 PM

Exactly.
Because the exception is thrown on URI decode, Grizzly gives up there and nothing is written to the access log.
Which becomes very problematic when you have a rogue client trying some exploit like it's the case here.


oleksiys added a comment - 26/Jan/12 12:44 PM

I agree, just wanted to make sure this is true for the latest 3.1.2 build.