We Keep Coding

POST REST API calls not working on Chrome browser but works on IE browser

We have Web application for which, UI is hosted on one Apache server on one host and back-end REST API service is hosted on tomcat server on different host.
For UI : Node.js is used and it is hosted on Apache
For API : Java 8 , Spring REST is used and war file is hosted on tomcat 8.5.32
The Problem:
While using Chrome browser (Version: 71.0.3578.80) for all POST API calls the server responds with error code 403 (forbidden), but for IE browser(version 11.0.105), the same POST APIs returns response with status 200 (Success).
Above behavior is observed for all POST request.
Following are request and response headers for chrome browser:
Request Headers:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 6559
Content-Type: application/json
Cookie: <cookies>
Host: <myhost>.com
Origin: https://<myhost>.com
Referer: https://<myhost>.com/beta/
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36
Response Headers:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://<myhost>.com
Connection: Keep-Alive
Content-Length: 0
Content-Type: text/plain
Date: Mon, 11 Feb 2019 11:49:25 GMT
Keep-Alive: timeout=5, max=95
Server: Apache
Strict-Transport-Security: max-age=31536000
API call general details:
Request URL: https://<myhost>.com/services/v1/settings
Request Method: POST
Status Code: 403
Remote Address: <ip address>:443
Referrer Policy: no-referrer-when-downgrade
Request Payload:
{"userId":"test", "someFlag": "someValue"}
Could you help to understand what i'm missing in above headers?
Findings:
If we revert back to the tomcat version 8.5.29 from version 8.5.32 then POST API request calls works fine on all browsers.
I also found that there is fix done for Tomcat 8.5.32 to
https://tomcat.apache.org/security-8.html#Fixed_in_Apache_Tomcat_8.5.32 : Low: CORS filter has insecure defaults CVE-2018-8014 which might causing this issue but i'm not able to figure out the exact problem and what headers changes should i do to get this POST request work on Chrome browsers.

Have to mimic x-requested-with post call in java

From my browser I am doing an ajax call to the server so that it sends a response
Request URL: https://test.com/ac_helper/
Request Method: POST
**Content-Type: application/x-www-form-urlencoded**; charset=UTF-8
Cookie: xxxxxxxxxx
Host: another site
Origin: https://<site>
Referer: https://<site>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
**X-Requested-With: XMLHttpRequest**
Sending body as Form Data:
<helperQuery><somefield>something</somefield><password>123</password> <helperQuery>
Response Headers received:
HTTP/1.1 200 OK
sei_http_code: 200
Content-Encoding: gzip
Content-Type: text/xml
Content-Length: 4670
And response received:
<helperReply><res>test</res><response>Authentication Success (Y)</response></helperReply>
And I have to use java to mimic this browser action of post.
I have tried HttpURLConnection, JSoup, RestAssured.
But none of them worked. Though I managed to get a 200 response using HttpURLConnection, I can't get the response read which is a text/xml response.
Kindly help.
I heard x-requested-with is an inbuilt library browsers use to make ajax calls to the server.

Websocket connection attempt fails, returns "Connection: Upgrade, close."

I'm building a Java websocket server using Tomcat. On my dev build, it works perfectly. However when I deploy it to production, the server is automatically appending "close" to the connection response header, immediately closing the socket (which never seems to connect to the server in the first place).
Here's some context for the production environment:
Tomcat 7, Java 8 on RHEL
Communications are encrypted by SSL, websocket uses wss
The server is behind an institutional firewall (but I expect that the encryption should make this a non-issue)
My local dev environment is not an exact clone (as it's used for multiple projects). It's running Tomcat 8, but I believe Tomcat 7 should feature comparable websocket support.
Here's the request/response (as captured by Chrome dev tools) when the websocket is sent to the production server:
General:
Request URL: wss://example.com/WSServer
Request Method: GET
Status Code: 101 Switching Protocols
Response:
HTTP/1.1 101 Switching Protocols
Date: Thu, 10 May 2018 17:04:39 GMT
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Upgrade: websocket
Connection: upgrade, close
Sec-WebSocket-Accept: JFNyciPc/Cza8PFaXWVct6f21qw=
Sec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15
Content-Length: 0
Content-Type: text/plain; charset=UTF-8
Request:
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: Upgrade
Cookie: *redacted*
Host: example.com
Origin: https://example.com
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: OvMcwMxIYqBLrx9ijlFK/w==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36`
As far as I can tell, the most revealing part of this is Connection: upgrade, close, which explains the client-side behavior below.
Here's a snippet of the client-side Javascript:
var socket = new WebSocket((window.location.protocol==="http:"?"ws:":"wss:") + "//" + window.location.host + "/WSServer");
socket.onopen = function wsOpen() {
socket.send("Hello!"));
}
socket.onclose = function wsClose(reason) {
log(JSON.stringify(reason)); //debug
}
socket.onopen gets called first. Executed normally, this doesn't produce any console message, but if I delay its execution with a breakpoint I get an error message: "Websocket is already in CLOSED or CLOSING state."
socket.onclose gets called immediately after. The reason code is 1006 with no explanation.
I've also put some debug logging in the ServerEndpointConfig.Configurator.modifyHandshake method, but it never reaches that point, nor does it reach the #OnOpen-annotated method.
Any idea what's causing the connection to fail? Again, the server and client code works in dev, so I'm confident that it's not a code issue. Is it a Tomcat configuration issue (as far as I can tell, there's nothing unusual about the way it's setup). Is there something obvious I'm missing?
Thanks in advance for any help!

HTTP/1.1 enables keep-alive connections by default.
A request such as:
GET / HTTP/1.1
Host: example.com
Connection: close
tells the server to disable keep-alive on the connection (the opposite of the HTTP/1.1 default)
Upgrade is a hop-by-hop header, just like Connection, and Upgrade is only valid if listed in Connection, e.g. Connection: Upgrade
When a client makes an HTTP/1.1 request containing Upgrade, the server receiving the request is not required to upgrade, and can instead simply respond with an HTTP/1.1 response.
Connection: upgrade, close requests that the server upgrade to (one of) the protocol(s) in the Upgrade header, or else to respond with HTTP/1.1 and close the connection. If the server upgrades the protocol, then the server uses the new protocol, and the close token in Connection is ignored, as the server is now using the upgraded protocol in the Upgrade response header immediately after the HTTP/1.1 101 Switching Protocols response.

jmeter Response code: 500 Response message: Internal Server Error Response headers:

I am running jmeter and encounter this problem, i have tried cookie manager and header manager, cache manager there, the problem is still there.
POST data:
store_id=34926840&country_code=SE&amount=2.00&merchant_reference=1487698674350&bank_name=Forex+Bank&payment_reference=DHUDYTHMMTV&internal_reference=185524&currency_code=SEK&status=PENDING
Cookie Data:
JSESSIONID=A5A4905F9FBDF18DC47A376F0226A388; AWSELB=B5FF67AD1CFA5460C8C7E086624D3BB9CE4C254E9C05CAED2F8B4C138D77F2FB3E8E2D91BE28957E695EB58D84B77AABC0950A0B63FB43504A613D484F319EB551578DB7CB
Request Headers:
Connection: keep-alive
Origin: https://qa.instantinternetbanking.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: https://qa.instantinternetbanking.com/internetbanking/webPASubmitData.form
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Content-Length: 188

Server Error 5xx
The 5xx (Server Error) class of status code indicates that the server
is aware that it has erred or is incapable of performing the
requested method...
500 Internal Server Error
The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
So I can see 2 possible explanations:
Issue with your server, execute the same request manually using browser to see of it is the case.
Issue with your request. When it comes to more or less complex web applications testing you cannot just record and replay the test, you need to keep in mind that there could be some mandatory dynamic parameters which need to be handled (the process is known as correlation) or some actions are not repeatable (for instance if transaction with reference number DHUDYTHMMTV is already finished you cannot send it once again, you will need a new one), etc.

java Host Header attack

I am working on "Host Header Injection" attack for one of my client. The issue is, using Burp Suite they are capturing the request and modifying the Host header as below. The application is Java Servlet and hosted on apache (web Server) + weblogic (App servers)
Original request
GET /myContext/testServlet?rq=home&tenId=123456 HTTP/1.1
Host: beta.testinglab.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Modified request
GET /myContext/testServlet?rq=home&tenId=123456 HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
At Server side, even after modifying the "Host Header", request is submitted to "beta.testinglab.com" and when on server i use request.getRequestUrl() it gives me "www.google.com".
Is there anyway to find out what was the original host that was requested. The request is making to correct host be internal redirection the issue.
I can't maintain the predefined list of Host entries since this application is customized by lot many tenants.
Is there any other way to fix this attack by changing configuration on Servers?

As far as I see, when the web or app server starts up it starts listening on a particular port of the machine. Which host name gets resolved to that particular machine is outside the knowledge of the web/app server. It depends on your network configurations. So there is no way the web/app server could validate that the hostname coming in the HTTP request is correct.
As you've mentioned you could keep in a configuration the expected hostname and write a servlet filter to validate all incoming requests do match that hostname.Othewise in apache webserver it self you could test if the correct hostname value is present in the header. Either way the correct hostname might be needed to be configured.
http://httpd.apache.org/docs/trunk/vhosts/name-based.html