Re^2: Client IP question

I thought about it and there's only one way - I think - to be sure that the domain calling the scripts is a certified one. HTTP_HOST in Perl gives my host name. But in Javascript or php, window.document.location.hostname or $_SERVER'HTTP_HOST' gives theirs... So if a request with one id matching a client domain is made and a javascript code is sent and compares the two values, I might prevent a hijack. If the hosts don't match, I make an automatic redirect. What do you think? Regards,

Kepler

Comment on Re^2: Client IP question

Replies are listed 'Best First'.
Re^3: Client IP question by soonix (Chancellor) on Dec 22, 2015 at 15:02 UTC
JavaScript `document.location` sounds plausible, but PHP `$_SERVER['HTTP_HOST']` should give the same as Perl CGI's `$ENV{'HTTP_HOST'}`, because both should come from the (supposedly same) web server — or are you using client side PHP??	[reply] [d/l] [select]
Re^3: Client IP question by thomas895 (Deacon) on Dec 22, 2015 at 21:51 UTC
It's impossible to prevent your javascript from being copied to some other site and being used from there. In fact, it's also trivial to spoof everything so as to make your service think that the actual customer is making the request. If this is a problem, find a way to restructure your service such that the APIs are private - not for being called by your customers' customers. For an example, look at Google's OAuth flow. Perhaps this will work, perhaps not - you haven't told us much about what exactly it is you're trying to accomplish. -Thomas "Excuse me for butting in, but I'm interrupt-driven..."	[reply]
Re^4: Client IP question by kepler (Scribe) on Dec 23, 2015 at 11:33 UTC
Hi, I'm sorry for the late reply... Indeed you are right. The php variable doesn't work, and the javascript can be copied - but not altered. My doubt is if the javascript hostname variable can be tampered. Still, I'm thinking in the following: before my app script is called from my client's website, a file must be written in their website with the current date and id which is also stored in my website. When the main app script is called, I catch the referer and get from my client website the file. The values must check. The hacker can't - I think - write or modify this file in my client space - he also can't fake it because I'm getting my real customer pass text file... What do you guys think...? Regards, Kepler	[reply]
Re^5: Client IP question by thomas895 (Deacon) on Dec 24, 2015 at 01:29 UTC
The "hacker" you're concerned about doesn't need to modify your files, your customers' files, or even their browser's variables. They need only set the `Referer` header, which is trivial to do. In order for the file you're talking about to be written, the customer's customer (or the "hacker") must interact somehow with your customer's website before using your API. The file will be written, and to your server, it will look like the request was valid. I hate to be a killjoy, but it's impossible to completely restrict the web. The only way to prevent your API from being called by someone you didn't intend for is to let only your customers directly access it, and to not do things in the browser. This is not a Perl problem. It's the same for any web application environment. -Thomas "Excuse me for butting in, but I'm interrupt-driven..."	[reply]