Our team is developing a simple Angular website that sends a form data to our backend via API. This website will be published under a public IP, so the interaction will be protected with Google reCAPTCHA v3.
Recently we decided to run some stress tests in a pre-productive environment in order to see if everything is stable and works correctly. So we set up a simple JMeter tests group with 100 users and 100 loops. This way we had 10000 requests in total to our API. So, having all that configured, we ran the frontend in order to generate a reCAPTCHA token, executed the action which sends the data to the API and copied the generated token into the JMeter configuration.
The API, before passing the form data to the backend, checks if the token is valid by making a request to “https://www.google.com/recaptcha/api/siteverify”, specifying this token and the secret key generated in the reCAPTCHA admin console.
After executing the JMeter tests, we saw that a certain amount of requests bypass the validation of the token and end up in the backend, while the token has already been used.
What we tried?
Stress test of our API with 10k requests in order to try the validation of an already used reCAPTCHA token.
What we expected to happen?
All the requests to return an error code of 401, beacause the reCAPTCHA token has already been used before and those tokens are single use only (the 401 code is returned by our API if the request to "/siteverify" returns a "success:false" in the response body or a status code other than 200).
What actually resulted?
5% of the requests bypassed the validation and ended up in the backend.
JMeter results
(The 400 bad request errors are returned by the backend, after the validation of the token has already been done, meaning that the token was assumingly valid)
We chequed the logs of our API and we've been able to verify that, in fact, the "/siteverify" requests return a status code of 200 and a response body of "success:true" in those 5% of the tests.
To me, it seems like some kind of balancing problem, maybe some node didn’t have enough time to replicate the status of that token? Or maybe the problem comes from our implementation… Hopefully someone could give us a hint!
Related
I'm doing Jmeter scripting for Login flow which is having SSO authentication.
I have correlated almost all the token values like SAML request, SAML response,Request verification token & client id request ,but I'm not getting proper response in the login call.The SSO calls is failing with 401 response code.
When we try to decode the SAML response(using online SAML decoder) which i'm getting it from the previous request call response in Jmeter, the Status is showing as Responder. but the same is showing as Success when we decode the SAML response which we are getting it from the LoadRunner or Developer Console
Note : The same script is working fine in Load Runner
Can Someone help me
enter image description here
If "the same script is working fine in Load Runner" and doesn't work in JMeter - this is not the same script. You need to figure out what are the differences and amend your JMeter configuration so JMeter will send the same requests as Load Runner (or even better a real browser)
I have correlated almost all the token values
"almost all" is not sufficient, you need to correlate all the dynamic parameters.
Use a 3rd-party sniffer tool like Fiddler or Wireshark to capture the requests originating from JMeter and Load Runner (or real browser).
The requests must be exactly the same (apart from dynamic values which need to be correlated). Once you send the same request you will get the same response. Pay attention to literally everything: not only request body matters, take a look at URL query strings, request headers and so on.
I am developing a simple website using MEAN stack that gives a logged-in user a task to complete and sends a score to the backend corresponding to their performance on that task. User can skip to next task in which case no score is sent. Problem is: How can I differentiate between a user cheating and sending score via a POST request on POSTMAN (by changing POST values to increase score) and a POST request created by my frontend code. How to work around this problem?
Welcome to Stackoverflow, to check if the request is made by POSTMAN (so locally) or by your backend (called by your front end) you just have to check if the request IP is your server or not.
This is a WhiteList solution
MEAN Stack use NodeJS, so you can use :
request.connection.remoteAddress
EDIT :
You can put a special parameter in your header when send a request with your front OR your Postman, and you check it when you receive it
I am running into an issue with an API Gateway/Lambda implementation. I've written a authentication service that works across subdomains and appears to work fine in most cases. Testing locally works perfect.
When it is deployed to AWS, with the API in a Lambda with an API Gateway in front of it, the log in system works great. The user can login, which returns a 200 and then a ReturnClaims-style endpoint returns their access, and other useful account bits.
The problem arises that after a little while (like an hour or so usually) the ReturnClaims endpoint will continue to return a 200 but the response is now empty when the page is refreshed.
The HTTP-Only cookie still lives in the browser and it's not throwing any errors.
When running locally, this issue doesn't arise at all. The user can refresh for as long as the cookie has and JWT has been instructed to last (which is 30 days but I've adjusted this for testing purposes as needed).
I am hoping someone might have an idea of what might cause an endpoint on AWS to function in this manner, perhaps some life setting I am unaware of?
I appreciate any advice or suggestions. Thanks!
I have a web api which is deployed on IIS.
Api's are going through load test using load runner and almost on all alternative api call, getting 403 error response code, struggling to identify the issue, call is not going to the API, its returned back from IIS
I am doing bearer token authorization, somehow token which were incoming with each request were not valid, that is why the issue was occurring, to overcome this we have increased the lifetime of token to 1 hour and request load test team to generate the token once and send that token only with each request so that we can now see the proper execution time for each end point.
403 error indicates that access to the requested URL by the client is Forbidden for some reason. you need to provide detailed error message snapshot and what is the sub status code. and check that you assign this permission to the site folder:1) IIS_IUSRS,2)NETWORK SERVICE,3)IUSR
I am trying to do the load testing of salesforce.com. I am logging via test.salesforce.com which is redirecting me to the console url. Now, subsequent post request accepts following post parameters.
ViewStateCSRF
ViewStateMAC
visualforce.ViewState
But this post request is failing with "invalid session" error message.
I am guessing this is because of CSRF token. I am trying to extract(post processor in Jmeter) CSRF token, but I am unable to find this token anywhere in the response/cookie of previous requests. In one of the HTML response, I can find few CSRF tokens(e.g: runApexCsrfToken, consoleAjaxCsrfToken etc). I have tried all of them but no result.
To summarize my problem: I need to pass csrf token in post login request but I am unable to find this token in previous responses.
Could you please help me with this.
PS: I have tried get request on "https://c.salesforce.com/libs/granite/csrf/token.json" after login but did not find any token in response.
Make sure to add HTTP Cookie Manager to your Test Plan
Make sure to check all response fields as the token can be a part of URL or come as a HTTP Header
You need to correlate not only ViewStateCSRF but all other dynamic parameters as well
If you have problems with identifying the source for the dynamic parameters values you can try recording your scenario using cloud-based proxy service, it is capable of exporting recorded scripts in "SmartJMX" mode with automatic detection and correlation of dynamic parameters. See How to Cut Your JMeter Scripting Time by 80% article for more details