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.

Answer 1

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.

Answer 2

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!

Answer 3

• 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.

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.

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.