Private authentication algorithm - web security

Question

I'm working on a project which generates audio from text(TTS) and provides player with speed/pitch control to users.

My question is related to request security.

The user got widget_id during registration on my site, he put some js in his site, and api works on his site. When the user click on send button, the api.js file sends ajax POST request to my site with widget_id data as well. Then on my side I got the widget_id and the referer:

$referer = isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : '';

I'm getting the site value related to the widget_id from my database, and comparing it with $referer.

... if($website_url == $referer) { $website_checked = true; } ...

So my question is: can the attacker using some lib(maybe Curl) change the $_SERVER["HTTP_REFERER"] value, and broke my security?

for example if he use curl and the code:

curl_setopt($ch, CURLOPT_REFERER, 'https://anysite.io/');

Thanks.

So I've updated the question cause as I was thinking that can not be trusted. So please the basic steps of Private authentication algorithm...

Update3: So I started a bounty cause I need to understand the algorithm of Private Authentication in my scenario.

Raki

It is not reliable as it can be spoofed easily. – Indies

You answered your own question: no, not trustworthy. Code can set headers to anything including zombo.com. Anything at all. zombo.com. – Bendicta

Any program or plugin that allows you to make web requests and specify whatever headers you want, makes that unsecure. – Crazy

you can't really prevent abuse if the api is publicly accessible like on your demo page the solution around this to either only allow the predefined text with each of the options (download/cache the resolved .mp3's from google text-to-speech and only serve them from your server) or remove the demo entirely and make the user sign in first (SSO etc is fast and easy), give them keys and a key quota which can be used in demos. or suck it up, your prices far cover the cost you pay for 1m chars – Radiochemistry

On my site, demo functionality, I will add google recaptcha there and make is secure... The problem is when it works on client site, and sends request to me... with regards to prices, they are not final yet, the project in process now ... anyway it will be greater than I pay for that ) – Raki

I think you need to clarify one point : whats is your concern ? What do you want to prevent ? Are you afraid someone copy the js and use it in an unauthorized website ? – Johst

No, as I said, I need to verify that the widget_id comes from right place! – Raki

Answer 1

• Securing Js

  1. When client browser try to access js library, your server should able to save the client info like complete browser name, OS, IP, Device etc. And server should generate a unique ID for that client
  2. Your Js should set cookie in client browser based on unique ID generated
  3. When user click on send button, pass unique ID from cookie. On server side, validate the client details with the details available on server againest unique ID. This is to insure that the POST request is coming from the client who have requested for JS file. A restriction to directly call POST API without initializing JS file

• Validating POST request

  1. Add token expiry date
  2. Always check unique ID generation time and Send Button click time and block suspicious API call based on it. (e.g. Time period is too short between ID generation and Send button click / getting POST request on server)
  3. Destroy/Disable unique key once server receive the POST call
  4. Monitor the IPs from which you are receiving the requests. This will help you to identify the robots and disable the server requests for them. A small program will do your work.

Haws

Answer 2

No, it is not reliable. Users can (and do) forge them, for example, with Referer Control or RefControl - though, such things are done by the user modifying their own browser.

Most referers are correct (simply because the number of people who'd go to the effort of forging them is small), but if security is an issue, you shouldn't depend on them. For this to be secure, those making requests should include private authentication, to that they can prove they're who they say they are.

Thorianite

@CertainThanks for Referer Control link, Could you describe in two words the algorithm of private authentication? I'm thinking to send secret token from client to my sever with 15minutes value for example, then check with that value... Can that be trusted? – Raki

To be fully secure, I don't think this is possible unless the sites that use your API have server-side programming of their own. Otherwise, whatever JS the site runs to authenticate, anyone who reverse-engineered the code would be able to run as well. – Thorianite

I think the solution is: their sites make a request to their backend. On their backend (which contains the actual secret data needed for auth with your site), they make a request to your API, and your API gives them a temporary token in exchange. Their backend sends the token to the frontend user, then the frontend user can send their request with the token. If the token gets compromised, it's no issue, it'll expire soon anyway, and the important secret credentials are never exposed to the client. – Thorianite

(If exposed to the client, they can be stolen) – Thorianite

The whole idea of project is that no server side code usage, just js... I've changed the question title... Sorry, but are you sure, that that can not be done without server side code? – Raki

If the code only runs client-side, you cannot be sure that only the clients that are permitted to use the API are using it, because client-side code is publicly visible. Obfuscation helps against reverse-engineering, but it's not a guarantee. Foolproof security will require server-side code. You have to decide whether the trade-off is worth it. IMO, unless explotation is a real and expensive problem, obfuscation could be enough. – Thorianite

So how Google make that? When provides ONLY js code? For example google translate widget... – Raki

I lose the link to our chat. – Raki

chat.stackoverflow.com/rooms/222420/… – Thorianite

Answer 3

So I do not see any activity here.

I think that if I generate random-token on client side, then make ajax request to my server and store the user random-token associated with his widget id, then making another request with same token, and comparing with saved value, will solve my problem!

Raki

Answer 4

To perform a secure call you can use JWT encrypted REQUEST, you can read more about JWT security here If you can decode JWT, how are they secure?:

There is a very reliable library to generate this in PHP, you can use generated token in a any client side language such as JavaScript

https://github.com/firebase/php-jwt

For example below example will include a private/public authentication keys, along side your other data which you can validate on your server side, i.e your widget_id in

use \Firebase\JWT\JWT;

$key = "example_key";
$payload = array(
    "iss" => "http://example.org",
    "aud" => "http://example.com",
    "iat" => 1356999524,
    "nbf" => 1357000000,
    "widget_id" => 123
);

$jwt_public_key = JWT::encode($payload, $key); 

You can validate REQUEST with various parameters in payload, and also look into refreshing tokens methods of the library.

Zsolway

Answer 5

Answer to your question is, as other wrote, : no. Referer cannot be trusted and can be tampered easily, or even blocked by browser.

BUT : Is this a real problem ? Security is always a tradeoff between usability and risk, so you have to measure your risks. For instance, Google Maps widget security relies on referer. It shows two things IMO :

• Google did not find/have anything better to check the widget integration comes from the right place
• Even if referer can be tampered... they don't care. It is unlikely to happen but more important : if it happens it is not a big problem (for Google at least, the client who have its Google Maps widget "stolen" won't be happy).

Again, real question is : how sensitive are your widget and your data ? If you really need security, you will have to implement some private authentication (which is just an other way to say a login) and manage credentials, and a place to store them (a database ?), and handle token exchange, and user will have to log in everytime... So yes, it is possible to have a real secured widget but as I said it is always a tradeoff, nothing comes for free.

Johst