Authentication on both user and ajax application level

squirrel · 2015-12-01 04:12:11

Hi guys

I have written an interface based server with functions that can be used as an api by ajax clients. I've also created a few helper javascript files which are compiled into the server exe and served to these ajax clients to make integrating into our product easier. One of these scripts is used to do the login encryption and session handling.

Now I need to write our own ajax client which will use this same api. However, there are a number of system configuration type functions which my own ajax client must be able to call, but not 3rd party clients. The limitation here must not only be which user can access these functions, but also which application can. As with the api js files, I intend on including all the html and js files for this ajax client compiled in as a resource and served as files with mormot. This helps a lot in ensuring that the js files are "readonly" and that they are all at a version that is compatible with the api.

Do you have any suggestions what would be the most secure way of ensuring that only a certain ajax application can make certain calls? If, for example, I send an extra parameter with our login to identify our app, that parameter will be clearly visible in the web browser console, enabling 3rd parties to use the same parameter. If I package it as a seperate exe containing just these files to be served and let that exe interface with our api server, third parties can still just look at the calls our client makes to authenticate and do the same by using this server as an api instead of the real api server.

Not sure if I properly explain the idea here. If anybody have any ideas or suggestions or questions, please let me know? This will be deployed on third party servers which I will not have any access to.

danielkuettner · 2015-12-01 07:04:16

I also have only html/ajax clients (the same configuration as yours). For security I use https and wss. To give the server a better choice who the client are I use Fingerprintjs. This in combination with user and password should be secure enough.

The client is never read only. You could read the code in browser a user/hacker can change it.

squirrel · 2015-12-01 08:14:45

Thanks, I'll take a look at Fingerprintjs. I suppose if Fingerprintjs can give me the real url of the request page (Referer in header can be spoofed) I can make an assumption on serverside and either allow it or not.
Already using https. I'm still worried that any 3rd party developer can open my client and with Firebug get the url of for example myapp/login_funcs.js and just use the same (instead of publicapi/login_funcs.js) to get access to the full api.

You are right that code can be changed live in browers. By readonly I mean that an administrator can't override the JS with old / custom versions without either replacing the exe (full set) or rerouting the urls. Being able to release a full set of code together as one version is fantastic.

Last edited by squirrel (2015-12-01 08:39:11)

ab · 2015-12-01 09:30:54

Embed the .js files as resources to the server is a good idea.
It would be efficient, and safe.
All the static content could be served from the .exe, e.g. via a dedicated method-based service. It would increase the server safety and maintainability/upgrade.

To secure the application at service level, you could use the built-in security.
See http://synopse.info/files/html/Synopse% … ml#TITL_43

You would need to authenticate over the mORMot server, and create a mORMot session for a given user.
Then, there is tuned security policy for the interface based services.
See http://synopse.info/files/html/Synopse% … ml#TITL_77

squirrel · 2015-12-01 09:35:53

It looks like it basically boils down to: anything my web application can do/call can be done/called by any 3rd party as well. So leave the system configuration far away from html - do that as a standard exe on the server. Doesn't look like there is a way to create the session knowing that it was created via a specific call or application. Still, any ideas will be welcome, if something like this can be done, it opens a lot of doors. Custom nonce based on referer for a specific file only, maybe?

Last edited by squirrel (2015-12-01 11:52:59)

ab · 2015-12-01 12:27:36

This is the purpose of the authentication.

squirrel · 2015-12-01 13:19:22

Usually I would agree that a username and password is enough. But sometimes it is important to ensure that 3rd party Applications can not use some parts of your code, regardless of whether they have the admin username and password.

ab · 2015-12-01 13:38:38

This is why you have several groups, and a per-interface/per-method security policy.
Everyone is not admin!

See my links to the doc.

danielkuettner · 2015-12-01 13:50:44

You can also put in the header what ever you want, e.g. "I'm the third party tool". In the service you decide what the client is allowed to and what not.

ab · 2015-12-01 15:12:57

danielkuettner wrote:

You can also put in the header what ever you want, e.g. "I'm the third party tool". In the service you decide what the client is allowed to and what not.

Yes, but
- it is not very secure - see https://en.wikipedia.org/wiki/Man-in-the-middle_attack
- it is difficult to implement with interface-based services, since the HTTP header is hidden in the execution context: the method may even be not executed in a context of a HTTP request, but directly on the server side

danielkuettner · 2015-12-01 15:45:04

I never had problems to get the header in my interfaced based services.
To security: First I have a ssl connection between client and server. Nobody can neither read my url nor header nor body, but in the case of an MitM (theoretically).
Than the client have to authenticate with username and password to get access to my services.
The optional header I only use to indentify the type of client. Sure, this is not secure, but it also shouldn't be a security feature.

I think more security isn't necessary.

There are many sites which explain the MitM attac, but if I read the articles than I become depressed.

The bigger security risk are the employees. The don't need a MitM. They can get the company data with their username/password combination over the browser. But that's the price of networking.

Last edited by danielkuettner (2015-12-01 15:51:27)

ab · 2015-12-01 15:46:44

mORMot Open Source

#1 2015-12-01 04:12:11

Authentication on both user and ajax application level

#2 2015-12-01 07:04:16

Re: Authentication on both user and ajax application level

#3 2015-12-01 08:14:45

Re: Authentication on both user and ajax application level

#4 2015-12-01 09:30:54

Re: Authentication on both user and ajax application level

#5 2015-12-01 09:35:53

Re: Authentication on both user and ajax application level

#6 2015-12-01 12:27:36

Re: Authentication on both user and ajax application level

#7 2015-12-01 13:19:22

Re: Authentication on both user and ajax application level

#8 2015-12-01 13:38:38

Re: Authentication on both user and ajax application level

#9 2015-12-01 13:50:44

Re: Authentication on both user and ajax application level

#10 2015-12-01 15:12:57

Re: Authentication on both user and ajax application level

#11 2015-12-01 15:45:04

Re: Authentication on both user and ajax application level

#12 2015-12-01 15:46:44

Re: Authentication on both user and ajax application level

Board footer