Re^4: Client IP question

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

Comment on Re^4: Client IP question

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]