I think Thomas is on the right track - the tester ran the query with the
method override headers indicating “PUT” instead of “POST”, and saw that
the response came back “200 OK”, and assumed that the attack had worked.
Instead what happened is that gwt-rpc couldn’t understand the request, and
sent back an error - see the “//EX” prefix on the last line of the reply -
but since it always leaves a 200 status code and, the tester believed that
the request was handled properly.
It might be important to communicate with them about what gwt-rpc is and
does, and clarify what the attack that they believe succeeded should have
done (and confirm with your own application that it did not), and likewise
confirm their expectations for an HTTP call like this (did they expect that
for any unknown header that the call would simply fail, etc).
On Wednesday, April 26, 2023 at 5:32:09 AM UTC-5 Thomas Broyer wrote:
> Those headers don't come from GWT itself, they've been added by the
> application or some library/framework it uses on top of GWT. It looks like
> that app is using something like gwt-dispatch, gwt-sl or spring4gwt or
> something like that, but maybe homemade.
> What I'd do to tell if they're actually used/useful (in this specific
> case!):
>
>1. open the WAR and look at the WEB-INF/web.xml (or possibly some
>other configuration files if it uses, e.g., Spring or whatever) to try to
>find the servlet class mapped to the /dispatch/GetCompaniesAction path
>(could be as easy as a class named GetCompaniesAction)
>2. Decompile that class (using javap or an IDE) and look for a
>doPut(ServletRequest,ServletResponse) method. Possibly go up the class
>hierarchy until you find the RemoteServiceServlet.
>
> Depending on the application, that may not lead to anything, but if
> there's a doPut, changes are it will be used.
>
> Also look at the WEB-INF/web.xml for servlet filters, and at other
> configuration files (Spring mainly, if used) to see if there'd be some
> filter dedicated to handling those kind of headers.
>
> Anyway, as said: this doesn't come from GWT itself.
>
> (actually, I'd be more concerned about a Firefox 98 being used 😅)
>
> Now I don't know Fortify WebInspect so maybe I'm also misinterpreting
> what's reported here: if this is a request made by Fortify WebInspect
> (rather than one made "on the wild" and intercepted by the solution) then I
> don't see why it'd be reported as a vulnerability, it could be that the
> server completely ignores the headers, right?
>
> On Wednesday, April 26, 2023 at 11:37:00 AM UTC+2 cyclop...@gmail.com
> wrote:
>
>> We have a web app (GWT 2.7 ) from a vendor and we don't have any source
>> codes.
>> Now we faced a vulnerability about *HTTP Method Override* for http
>> header below
>>
>> *X-HTTP-METHOD*
>>
>> *X-HTTP-Method-Override*
>> *X-METHOD-OVERRIDE*
>>
>> Fortify WebInspect report
>>
>> Attack Request:
>> POST /CustomPortal/dispatch/GetCompaniesAction HTTP/1.1
>> Host: 10.4.202.26:8861
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0)
>> Gecko/20100101 Firefox/98.0
>> Accept: */*
>> Accept-Language: en-US,en;q=0.5
>> Accept-Encoding: gzip, deflate
>> Content-Type: text/x-gwt-rpc; charset=utf-8
>> X-GWT-Permutation: 3EE8E625356CC9E9E724C10285609299
>> X-GWT-Module-Base: https://10.4.202.26:8861/CustomPortal/custom/
>> Referer: https://10.4.202.26:8861/CustomPortal/
>> Content-Length: 311
>> Origin: https://10.4.202.26:8861
>> Pragma: no-cache
>> X-HTTP-METHOD: PUT
>> X-HTTP-Method-Override: PUT
>> X-METHOD-OVERRIDE: PUT
>> Connection: Keep-Alive
>> X-WIPP: AscVersion=22.2.0TRUNCATED...
>>
>> Attack Response:
>> HTTP/1.1 200 OK
>> Set-Cookie: JSESSIONIDSSO=; path=/; HttpOnly; Max-Age=0; Expires=Thu,
>> 01-Jan-1970 00:00:00 GMT
>> X-XSS-Protection: 1; mode=block
>> X-Frame-Options: SAMEORIGIN
>> Referrer-Policy: strict-origin-when-cross-origin
>> Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri
>> 'none'; style-src 'self' 'unsafe-inline'; img-src 'self'; scriptsrc
>> 'self' 'unsafe-inline' 'unsafe-eval';connect-src 'self' https: localhost;
>> Content-Disposition: attachment
>> Date: Fri, 21 Apr 2023 06:10:56 GMT
>> Connection: keep-alive
>> X-Content-Type-Options: nosniff
>> Content-Length: 177
>> Content-Type: application/json;charset=utf-8
>> //EX[3,0,2,1,0,1,["com...TRUNCATED...
>>
>> Is there any way to disable these headers ?
>> Or is there any description to let me tell user this is NOT vulnerability
>> ?
>>
>> AP server is JBoss EAP 7.3.8 GA
>>
>> Many thx!
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit/87c805d5-53c3-498b-bc27-ac6ea3728861n%40googlegroups.com.
