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¤cy_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.
Related
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.
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.
I was wondering, what is the easiest way to convert a request captured by Fiddler to Java code? For example, Fiddler captures a request, and I'm wondering if there is an easy way to turn it into Java code so that I can send the same request programmatically!
I am open to suggestions of other Chrome plugins that would work for this!
You have the possibility of:
Selecting all desired requests
Open a contextual menu
Choose "Save" and save them to a file.
Then, you can just read the file and use Apache HttpClient (one option out of thousands) to build the different types of requests (GET,POST,etc) to the hosts specified in the saved file.
For instance, this is a POST request sent to SO while I was writing this answer:
POST http://stackoverflow.com/posts/validate-body HTTP/1.1
Host: stackoverflow.com
Connection: keep-alive
Content-Length: 332
Accept: */*
Origin: http://stackoverflow.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://stackoverflow.com/questions/31931998/convert-captured- fiddler-requests-to-java
Accept-Encoding: gzip, deflate
Accept-Language: es,de-DE;q=0.8,de;q=0.6,en-US;q=0.4,en;q=0.2
Cookie: <<ommitted>>
body=You+have+the+possibility+of+selecting+...
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
I have following scenario:
App1:
My web service hosted on tomcat server :
192.168.100.123
App2:
Another application which is communicating with this web service is hosted on another machine and server :
192.168.100.456
REQUEST and RESPONSE HEADER
Allow OPTIONS,POST
Content-Length 511
Content-Type application/vnd.sun.wadl+xml
Date Thu, 02 May 2013 22:53:17 GMT
Server Apache-Coyote/1.1
----------------------------
Request Headersview source
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Access-Control-Request-He... content-type,x-requested-with
Access-Control-Request-Me... POST
Cache-Control no-cache
Connection keep-alive
DNT 1
Host 192.168.200.164:8080
Origin http://192.168.200.157
Pragma no-cache
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
After debugging the whole scenario using firebug I am sure that the issue is regarding cross domain policy. Kindly help me figure the way out of this'
HTTP 302 refers to status code having redirection information. May be the App2 tried to login to App1 and it sent back the logged in URL back as the response.
Once App2 receives such a response, proably the redirection URL out of the response can be extracted and this URL should be hit again by App2.