I have a JSP webapp developed in Eclipse as a dynamic web project.
we use a third party web application that invokes my application, I need to validate that only the requests that come from that application are allowed to create a new session in my application.
I´m tring to do it with javascript and thinking , as a last resource, to use a Filter class to know the request origin and define the behaviour.
the problem is that the user requires that the operation is done on the client side, meaning I have to use javascript or similar, I have read about document.referrer on JS, but so far nothing is shown on the console.
Anything that you do in the client using JS for handling sessions wouldn't be secure as it can be easily modified by a malicious user. Also, using the referer or any other http header params would be insecure as they can also be easily spoofed.
If this third party application is directly calling your application I imagine that you have some degree of control over it. Can you access and modify its source code or are you just using configuration params?
Ideally the third party application would use an authentication token on each request that it makes to your application. And these authentication requests as well as all the session handling logic would always be handled on the server side.
Related
I'm looking a way to securely share a token between one webapp with the front-end of a second webapp.
Environment details:
webapp.local: A PHP webapp that stories some data that are restricted to specific users. This webapp is accessible by VPN only.
otherwebapp.example: This is a Zendesk instance, it allows us to create a plugin (HTML + JavaScript) that is loaded on the client-side.
Notes:
webapp.local and otherwebapp.example use different domains (they aren't sub-domain).
otherwebapp.example is not able to access the webapp.local. But the front-end will be able (the user are connected to the VPN).
I did some research, and found some options:
HTTP Coockies: the "SameSite" need to be "None" (reference), is it a secure option? I did some tests and seems that they need to be on the same sub-domain.
JS postMessage: It will need to open a popup or a iframe, I did some tests but still trying to make it works.
The question is:
Is there a best practice or another way to share a sensitive data (token) between a webapp and a front-end located on other domain/app?
I think there is not a fully secure way to do it because you want to handle the share on the client side and that will be always exposed, though you can take a different approach like share a request token via GET param to the second webapp and there call a validation API that validates the origin of the request (should be restricted to the second webapp domain) and also validate the passed token and then return the actual session token.
I wish to build a pure front-end app with JavaScript running on client-side, i.e. browser. My app is supposed to make requests to 3rd part services, which require some sort of authentication method.
Backend frameworks provide config files for this sort of thing, but since JS code is all interpreted on the client machine, the config files cannot be part of the bundle.
Is there any way of securely storing the service API keys, credentials and such within the client or do I need a backend solution for this also?
Search for most popular frameworks (Angular and React) for config files resulted only in storing environment-specific URLs. I'm starting to think that I've hit a dead-end and this simply can't be done.
Depends... You don't want the user to be able to sniff out any secrets you have to send to the third party, but in the case of an Implicit Grant with OAuth2, you can actually initiate and complete it in the browser.
You'll redirect to the 3rd party for login/authentication, then the user will be sent back to you with an access token good for a period of time.
That token is actually sent in a URL fragment, per the spec, so it's being sent to the browser and NOT your server. If you want to get the access token to a server, you'd need front-end code to parse the URL fragment and send its contents.
If the API will allow you to connect from the browser, you could keep everything in the browser and not need a backend server to handle credentials. But not every API will allow purely front-end authentication and API calls.
So, it depends...
Can you store service api creds in the client cache, or in cookies etc? Yes. Will it be secure to send them over the wire and store in the browser? No.
If keeping credentials secure is part of the requirements, I would do the work to authenticate on the backend or use a third party service that does this for you.
I want to develop a front-end in Javascript (possibly with one of the fancy frameworks around such as AngularJS) that consumes the REST API of my Salesforce org.
I don't want to embed my project in Salesforce technologies, so basically
no Visualforce pages
no Force.com Sites
I do want to write my own front-end on a separate server that just makes AJAX calls to the Salesforce back-end.
In addition, I want the application to be accessible for any user, even if he/she does not have a Salesforce account. So the AJAX calls should not require that the user logs in on Salesforce. I want anonymous users to be able to retrieve public data from my organization and create new entries when it is useful (in the case of a survey for instance).
Even though these requirements generate some security concerns, I can imagine that Salesforce takes care about the requests rate limits on their API endpoints and that it is possible to restrict the access to the API on a host name base (e.g., only requests with origin host my-trusted-domain.com should be allowed, send a 403-Forbidden otherwise). I would be surprised if SF does not provide such basic features.
How would you proceed? Is there a minimal Javascript code that works out-of-the-box on any domain without getting into troubles with CORS?
All REST API calls to Salesforce must be authenticated. If you want anonymous API access then you will need to proxy authenticated calls through a server (like on Heroku) that adds the auth token. Or you can use Heroku Connect to expose your Salesforce data to a Heroku app as a Postrgres database.
If you go the REST route then checkout the ForceServer and my CORS Proxy for Salesforce. Both are not setup out-of-the-box for the anonymous access you are looking for but could easily be tweaked to support that use case.
BTW: When allowing anonymous access to your Salesforce data through a proxy make sure you are dealing correctly with security and request limits.
I'm trying to make a program that can be hosted by many peoples, like an app.
The app use a REST API, so I must authenticate with Oauth,
and because anyone should be able to host the program, the redirect URI cannot be static.
Further, I don't want to use any server-side processing, which means only javascript for me.
Is it even possible to make a secure and working solution with non-static redirect URI,
and only using javascript, to work in a normal webbrowser?
So you use the information provided in the request to your app to indicate the URL for your app. For instance, if the request came to http://example.com/path/to/app and you knew in your app that /to/app was part of your routing infrastructure, then the path to your app is http://example.com/path/.
That is how I would determine it, using a serverside language.
Using a javascript library, which would be loaded from the server, I would either determine it like the above, or I would just hard code it on the generation of the javascript file (when you tell people where to download the javascript, it can use a form that requires their web address first).
What is the best way to add authentication / security while calling Web service from javascript ?
I want my web services should only get called from my application , anyone else should not be able to access my web service by copying web service URL into browser.
From the first few answers it seems like its next to impossible.
So what should I reply to my client as he is unaware of word impossible ?
~Ajinkya.
Have a look at using the synchroniser token pattern so that the service can only be consumed with a piece of data known to the page which loads the service reference. There's an example of doing this with a web service in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF). This should achieve what you're after.
This is not possible. If you allow a client to access your webservice from JavaScript, the client will always be able to do that. You can only reduce access by using some kind of constraint, like a Token that needs to be sent along with the request to authenticate it. You might even turn it into a one-time token. But this will create new problems (e.g. what happens if the answer gets lost. The client javascript cannot rerun the query).