We have come across similar problem, need your help to resolve this.
Can you please either let us know your contact number so that we can reach out to you or if you can provide your script if possible so that we can refer to
Here is the problem we are stuck with:
I am trying to test a Rest service through HTTP sampler using Jmeter. Not sure how to capture token from the sampler generates a token and to use this token for authorization in the header manager of another HTTP.
Loadrunner is not displaying the web address when trying to enter in the truclient browser. Below is the problem as this web address automatically redirect to another web address which is the authentication server.
Can you please suggest another solution for the below issue?
Here is the exact scenario we are trying to achieve
we want to loadtest the portal however due to redirect and different authentication method being used we are unable to do it using truclient protocol in loadrunner. Also tried Multiple protocol selecting LDAP, SMTP, HTTP/HTML etc but no luck.**
Thank You,
Sonny
JMETER is going to architecturally be the HTTP protocol layer equivalent with LoadRunner, with the exception of the number of threads per browser emulation.
In contrast to the code request, I want to architecturally visualize the problem. You mention redirect, is this an HTTP 301/302 redirect or one which is handled with information passed back to the client, processed on the client and then redirected to another host? You mention dynamic authentication via header token, have you examined the web_add_header() and web_add_auto_header() in Laodrunner web virtual users for passing of extra header messages, including ones which have been correlated from previous requests, such as the token being passed back as you note?
This authentication mechanism is based upon? LDAP? Kerberos? Windows Integrated Authentication? Simple Authentication based upon username/password in header? Can you be architecturally more specific and when this comes into play, such as from the first request to gain access to the test environment through the firewall or from a nth request to gain access within a business process?
You mention RESTFul services. These can be transport independent, such as being passed over SMTP using a mailbox to broker the passing of data between client and server, or over HTTP similar to SOAP messages. Do you have architectural clarity on this? Could it be that you need to provide mailbox authentication across SMTP and POP3 to send and receive?
Related
I am developing a web application with Spring Boot and a React.js SPA, but my question is not specific to those libraries/frameworks, as i assume reporting client-side JS errors to the server (for logging and analyzing) must be a common operation for many modern web applications.
So, suppose we have a JS client application that catches an error and a REST endpoint /errors that takes a JSON object holding the relevant information about what happened. The client app sends the data to the server, it gets stored in a database (or whatever) and everyone's happy, right?
Now I am not, really. Because now I have an open (as in allowing unauthenticated create/write operations) API endpoint everyone with just a little knowledge could easily spam.
I might validate the structure of JSON data the endpoint accepts, but that doesn't really solve the problem.
In questions like "Open REST API attached to a database- what stops a bad actor spamming my db?" or "Secure Rest-Service before user authentification", there are suggestions such as:
access quotas (but I don't want to save IPs or anything to identify clients)
Captchas (useless for error reporting, obviously)
e-mail verification (same, just imagine that)
So my questions are:
Is there an elegant, commonly used strategy to secure such an endpoint?
Would a lightweight solution like validating the structure of the data be enough in practice?
Is all this even necessary? After all I won't advertise my error handling API endpoint with a banner in the app...
I’ve seen it done three different ways…
Assuming you are using OAuth 2 to secure your API. Stand up two
error endpoints.
For a logged in user, if an errors occurs you would
hit the /error endpoint, and would authenticate using the existing
user auth token.
For a visitor, you can expose a /clientError (or
named in a way that makes sense to you) endpoint that takes the
client_credentials token for the client app.
Secure the /error endpoint using an api key that would be scope for
access to the error endpoint only.
This key would be specific to the
client and would be pass in the header.
Use a 3rd party tool such as Raygun.io, or any APM tool, such as New Relic.
I am writing a REST Api gateway for an Angular SPA and I am confronted with the problem of securing the data exposed by the API for the SPA against "data thiefs". I am aware that I can't do much against HTML scraping, but at least I don't want to offer such data thiefs the user experience and full power of our JSON sent to the SPA.
The difference between most "tutorials" and threads about this topic is that I am exposing this data to a public website (which means no user authentication required) which offers valuable statistics about a video game.
My initial idea on how to protect the Rest API for SPA:
Using JWTs everywhere. When a visitor opens the website the very first time the SPA requests a JWT from my REST Api and saves it in the HTTPS cookies. For all requests the SPA has to use the JWT to get a response.
Problems with that approach
The data thief could simply request the oauth token from our endpoint as well. I have no chance to verify that the token has actually been requested from my SPA or from the data thief?
Even if I solved that the attacker could read the saved JWT from the HTTPS cookies and use it in his own application. Sure I could add time expiration for the JWT
My question:
I am under the impression that this is a common problem and therefore I am wondering if there are any good solutions to protect against others than the SPA having direct access to my REST Api responses?
From the API's point of view, your SPA is in no way different than any other client. You obviously can't include a secret in the SPA as it is sent to anybody and cannot be protected. Also the requests it makes to the API can be easily sniffed and copied by another client.
So in short, as diacussed many times here, you can't authenticate the client application. Anybody can create a different client if they want.
One thing you can actually do is checking the referer/origin of requests. If a client is running in a browser, thr requests it can make are somewhat limited, and one such limitation is the referer and origin headers, which are always controlled by the browser, and not javascript. So you can actually make sure that if (and only if!) the client is running in an unmodified browser, it is downloaded from your domain. This is the default in browsers btw, so if you are not sending CORS headers, you already did this (browsers do, actually). However, this does not keep an attacker from building and running a non-browser client and fake any referer or origin he likes, or just disregard the same origin policy.
Another thing you could do is changing the API regularly just enough to stop rogue clients from working (and changing your client at the same time ofc). Obviously this is not secure at all, but can be annoying enough for an attacker. If downloading all your data once is a concern, this again doesn't help at all.
Some real things you should consider though are:
Does anybody actually want to download your data? How much is it worth? Most of the times nobody wants to create a different client, and nobody is that much interested in the data.
If it is that interesting, you should implement user authentication at the very least, and cover the remaining risk either via points below and/or in your contracts legally.
You could implement throttling to not allow bulk downloading. For example if the typical user accesses 1 record every 5 seconds, and 10 altogether, you can build rules based on the client IP for example to reasonably limit user access. Note though that rate limiting must be based on a parameter the client can't modify arbitrarily, and without authentication, that's pretty much the client IP only, and you will face issues with users behind a NAT (ie. corporate networks for example).
Similarly, you can implement monitoring to discover if somebody is downloading more data than it would be normal or necessary. However, without user authentication, your only option will be to ban the client IP. So again it comes down to knowing who the user is, ie. authentication.
When a user register to my web application I send an email to verify his inbox.
In the email there are a link to a resource like this:
GET /verify/{token}
Since the resource is being updated behind the scenes, doesn't it break the RESTful approach?
How can I do it in a RESTful manner?
What you are talking about is not REST. REST is for machine to machine communication and not for human to machine communication. You can develop a 1st party REST client, which sends the activation to the REST service.
You can use your verification URI in the browser to access the REST client:
# user follows a hyperlink in the browser manually
GET example.com/client/v1/verify/{token}
# asking the client to verify the token
and after that the REST client will get the hyperlink for verification from the REST service and send the POST to the service in the background.
# the REST client follows the hyperlinks given by the service automatically
# the REST client can run either on the HTTP client or server side
GET example.com/api/v1
# getting the starting page of the REST service
# getting the hyperlink for verification
POST example.com/api/v1/verification {token}
# following the verification hyperlink
If you have a server side 1st party REST client, then the HTTP requests to the REST service will run completely on the server and you won't see anything about it in the browser. If you have a client side REST client, then you can send the POST in the browser with AJAX CORS or you can try to POST directly with a HTML form (not recommended). Anyways the activation should be a POST or a PUT.
It depends on what are you trying to do.
Does it fire an email after validating the user for example? If so, it is not an idempotent method and you should use POST.
Example:
POST /users/{id}/verify/{token}
If the method doesn't have any consequence besides the update, I think you should use PUT.
Aren't you overthinking REST? With e-mail verification you want the user to be able to simply click the link from whatever mail user agent he is using, so you'll end up with a simple GET on the server (presented as a hyperlink to the user) with the token either in the path or as part of the query string:
GET http://example.com/verify-email/TOKEN
GET http://example.com/verify-email?token=TOKEN
Either is fine for this use case. It is not really a resource you are getting or creating; just a trigger for some process on the backend.
Why do you think this would run afoul of good design?
I am using GWT to create my web-app.
When making RPC call from client side (browser), in inspect element my Request Payload is as below :
7|0|8|https://xxxx.xxxx.in/TestProject/in.TestProject.Main/|87545F2996A876761A0C13CD750EA654|in.TestProject.client.CustomerClassService|check_User_Login|java.lang.String/2004016611|in.TestProject.Beans.CustomerBean/3980370781|UserId|Password|1|2|3|4|3|5|5|6|7|8|6|0|0|0|0|0|CustId|0|0|0|0|0|0|0|0|0|
In this request all the details like username, password & custid are displayed in the request payload.
My question is, is it possible to encode OR hide those details from request payload?
You are looking at the wrong level of abstraction. What's the point of encoding/"hidding" these values in the payload? Everything you exchange between the server and client can be intercepted anyway... unless you use HTTPS. It ensures safe/encrypted communication between the server and client. Don't try to be "clever" and only encrypt part of the communication/payload, just use HTTPS.
But my concern is client itself should not be able to seen which method call we are making, parameter type in the request, parameter values etc. It should be hidden from client.
But those parameter values were input by the user himself or are hardcoded somewhere in the application (which the user will always be able to see/decipher, because his browser has to). So what you are trying to achieve is security through obscurity and is never a good idea. I'd focus my attention and efforts into securing the endpoints (GWT-RPC services), validating the input sent there, etc.
You have to remember one thing - that the user has access to the source code (compiled and minified, but still) of the client-side part of your application. So:
He'll always be able to figure out how to communicate with your server, because your application has to.
He can modify the application to send malicious requests - even if you created some hypothetical way of encoding parameters/addresses. Just find a place just before the encoding is done and voila. Firebug and other Developer Tools will help you immensely in this.
So "securing" client-side in this way is meaningless (of course, CSRF, XSS, etc. should be your concern), a malicious user will always bypass it because you have to give him all the tools to do it - otherwise, a "normal" user (or rather his browser) wouldn't be able to use your application.
I'm working on a REST webservice, and in particular authentication methods for browser-based requests. (using JsonP or Cross-domain XHR requests/XDomainRequest).
I've done some research in OAuth, and also Amazon's AWS. The big drawbacks of both is that I need to do either of the following:
Store secret tokens in the browser
Let a server-side script handle the signing. Basically I'd first to a request to a server of mine to get a specific pre-signed javascript request, which I'll use to connect to the real REST server.
What are some other options or suggestions?
Well, the only true answer here is proxying through a server, using sessions/cookies to authenticate and of course use SSL. Sorry for answering my own question.
Yes, jsonp call-authentication is tough, because the browser-client needs to know the shared secret.
An option would be to make the end-point anonymous (no authentication necessary). This comes with other security wholes (server is open for attacks, anyone can call it). But you could handle this by either only exposing very limited resource and/or using rate-limiting. With rate-limiting only a certain number of calls are allowed by one client in a certain range of time. It works by identifying the client (e.g. by source-ips or other client footprints).
I once experimented with one-time tokens, but they all somewhat failed because you have the problem of getting the token itself and protecting multiple retrievals of the token by bots (which comes again to the need of rate-limiting).
I havent tried this myself but you can try the following..(I am pretty sure i will get some feedback)
On the server side, generate a timestamp. Using HMAC-SHA256 an generate a key for that time stamp using a password and send the generated key and time stamp in the html.
When you make the AJAX call to the web service(assuming it is a different server) send the key and the time stamp along with the request. Check if timestamp is within a 5-15 minutes..
if it is do do the HMAC-SHA256 with the same password and key if the key generated is same.
Also on the client side you will have to check if your timestamp is still valid before making the call..
You can generate the key using the following url..
http://buchananweb.co.uk/security01.aspx