I am quite determined to do a pure Javascript front-end (Using JS and GWT) connecting to a back-end using Ajax on a separate server. My concern is with security.
What could be a solution for a Pure Front-end application?
For example, a user-generated content site:
When we look at it at a perspective of an app that to gain access to it it needs to ask user to login, so here Oauth can take over. The app is authenticated properly and access to any content is based on the authorization given.
The problem is here: For an application that can allow anonymous users to view user generated content without logging in thus there is no chance for Oauth to take place.
Connecting to a BaaS:
There will be no Java middleware to store application key for Baas access (e.g. Kinvey etc.)
Even if obfuscated the application key can easily be snooped from the HTTP requests.
What could be a solution for a Pure Javascript front-end to connect to a BaaS or independent backend? In terms of securing application keys? Where Baas or independent backend can know if it is to serve data to the requesting client (even its a web app) since its not from the same domain.
Related
I wanted to know how I can do that only my android application, developed with native react, can access my API node js. So my server will be accessible only from my site, using a simple whitelist of domains, and from my app
There is no way to guarantee this. A client controls everything that happens on client side. If an application contains protection mechanisms against client interference, it can be reverse-engineered.
A way to protect unauthorized clients from connecting to the backend is make backend requests with API key that is transmitted as encrypted (hashed) string and verified on server side. Abused API keys need to be blacklisted.
Since hashed keys can be extracted from API requests, a way to make this more complicated is to make hashed API key dependent on specific requests, e.g.:
fetchData(url + '&api_key_hash=' + md5(SALT + url + SECRET_API_KEY))
api_key_hash still can be verified on server side but is useless for a client who wants to get unauthorized access to backend API. The only way for a client is to get SECRET_API_KEY.
Since client application can be reverse-engineered to get unencrypted API key, a way to make reverse engineering more complicated is to not store the key as plain string and obfuscate the application.
Note that while these measures don't guarantee that the application won't be reverse-engineered to extract API key, obfuscation can complicate things for application developer, e.g. debugging and analyzing crash reports. To my knowledge, reverse engineering of React Native application that doesn't make use of any protection besides JS obfuscation is trivial.
I am building a HTML/JavaScript application using AngularJS. It doesn't have a backend except some Perl scripts that spit JSON through a URL through which I display the data. One of the pages on this dashboard needs privileged access for which I had to add LDAP authorization.
The application is deployed on a WAMP server. Active directory is being used in the organization; but I am not quite sure how to establish the authentication in a pure html application without a backend. What is the usual process followed to handle such authorizations and how to achieve it?
You should write a web service (REST) in any language you want (JAVA C# PHP Node.js ...) who autenticate against your Open LDAP server and you'll consume it in AngularJS.
It's quite a classic problem.
Appears to be a perfect candidate for OpenID Connect. Use one of the many available libraries available.
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.
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.
On the last section on Platform Security, it mentioned a way to secure the source code in PhoneGap apps.
Reverse engineering is a concern of many people that use PhoneGap since one can simply open an application binary and look at the JavaScript source code of the application. One could even go so far as to add malicious JavaScript code, re-package the application and re-submit it to app stores / markets in an attempt at app phishing. This practice could be undertaken with any application whether it is written with PhoneGap or otherwise since it is a similarly simple task to decompile either Java or Objective-C.
PhoneGap can actually get around this security concern since application developers can download JavaScript in their application at runtime, run that JavaScript, and delete it when the application closes. In that way, the source code is never on the device when the device is at rest. This is a much more difficult prospect with Java or Objective-C let alone the restrictions in the App Store around dynamically running Objective-C code.
However, I would like to know how can I prevent others to download my source code on server?
I'd suggest annotating your code and then running it through Google's Closure Compiler, which will obfuscate it and perform certain optimizations. This will make it very difficult for people to read your code, but beyond that you're just going to have to live with the fact that JS is a client side language.
How about the following pattern:
Embed a bootstrap JavaScript with your app that does enables user/device authentication against your server. Do what you can to obfuscate the bootstrap code.
Keep the main logic of your app as JavaScripton on your server (can be accessed by authenticated users)
After authentication, download the main logic JavaScript at runtime, run that JavaScript, and delete it when the application closes
Continuous upgrading follows painlessly.
I would suggest:
Obfuscate most/all of the JS code. Google's Closure Compiler is good option.
When App gets started:
Have some hashcode stored on device which needs to be verified before making a call to server for dynamic data fetch
During App startup, first push the App hashcode to server in order to verify the App authenticity and Server will check that hashcode in order to verify the legitimacy of the App
Once Server has verified the App legitimacy then Server can send another hashcode or keep using the same one. Plus server can set custom cookie parameters too...it all depends on the architecture of the App & Server communication. So set whatever is best to your needs
Once App legitimacy has been verified then all calls from device to server should contain the same hashcode or cookie and server will verify it first before answering to the call.
Rather then sending new js code , its better to push json dynamic data and keep the js code obfuscated on the device.