Re: HTTP Method Override

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.0....TRUNCATED...

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+unsubscribe@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.