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.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.
Re: HTTP Method Override
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/71934569-0a42-4892-9354-c8f527c22830n%40googlegroups.com.
HTTP Method Override
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/19c2d28c-e256-40fb-ba2e-0e204e31f936n%40googlegroups.com.
