IS there, a cross browser, way to identify each browser window uniquely?
I need to store some values which are unique for a window.
Even if the user opens two windows on the same browser to the same site.
There is no Ajax involved, every click on a link will load a new page.
And how would I access that name from the server? (for this, assume I use php, but example in any other language, is also good)
You could identify the windows by putting and maintaining unique arguments into the query strings of all the urls. For example, if the current url is /foo.php?windowid=abhn7y76g7hygy7yhnui98u8mc then each url in that pages html would have an id distnct from the url and the others in the document. uniqid() is perfect for this as it uses time, and so they're lexicographically increasing id's.
The one edge case you need to handle is when someone opens the exact same link twice(maybe via clicking, or maybe via copy pasting the url and manually opening a new window). I think the only real solution is to have the server keep track of which id's have been used, and if it notices a second request for the same id, it redirects the request to the same url, but a new id. This would maintain unique id's across all browser windows.
on second thought, dont even bother attaching the ids to urls in the html. Just make the server do the logic if no id, redirect to same url with a new id. if id, and the id has been used before, redirect to same url with new id.
make sure to send no cache headers for the html pages because you need the browsers to recheck with your server if the back button is used.
window.name can be set via JavaScript. Strangely, it can also hold a few megabaytes worth of string data and is sometimes used as client-side storage.
You'd have to pass the name back to the server with each request in order to know which window in the caller.
Related
I'm seeking to utilize an iframe to embed some html in customers websites that will list some information from my database using a simple GET request like so:
// customer would copy/paste this code onto their site
// value of key would be unique key for that customer
<iframe src='http://mydomain.php/api?key=1234j1lj1hj124kh' ></iframe>
Now I want to be able to verify that the request is coming from customer that owns the key, and not just anybody who copy/pasted that code onto their page.
I've done some research and found that $_SERVER['HTTP_REFERRER'] can give me this information, but with mostly mixed reviews saying it isn't always reliable (and most of the questions I came across were a couple years old).
QUESTIONS
1.) Is this method of using an iframe/GET request the standard way of achieving this functionality?
2.) Is there a standard, SECURE and RELIABLE way to verify the origin of the GET request?
Unfortunately this is not possible in a secure way.
To answer your questions: In fact this is not a standard functionality itself. I mean, there is no standard secure way of allowing content to be loaded only through iframes from allowed websites.
There are three parties in this communication:
1) Your website
2) Customer website that loads your website's data in an iframe
3) End user visiting customer website
When an end user visits customer web site, he will perform a GET request to your website through the iframe. At this connection, 2nd party above (customer website) is not involved. In this case, there is no reliable way for your website to know whether this request is coming through the iframe or not. Only favor that party 2 does here is adding HTTP_REFERER header to end-user's request. But this header cannot be trusted.
For example, if I want to abuse this and show that content on my website, I can create a proxy page on my application, where I perform a back-end call to your app (adding a valid HTTP_REFERER header) and display results back.
Personally I would never use iFrames for this functionality. I am assuming that this has to be reasonably secure, which is why only your specified customer can view it? If for whatever reason you can't use PHP to embed the content you need to display (through the use of an "included" file for example), I would instead use AJAX which would still use any PHP user verification you have in place to dynamically load content into a secure webpage.
This is because your PHP user verification will (should!) use cookie/session information to determine which customer is viewing the page and therefore decide whether the content should be delivered, since Session variables are determined by a single unique code stored client-side, which match up to as much information as you want to collect about a user server-side (Which could include the last page they visited, which is what the "HTTP_REFERRER" variable would give you, if they came from another page on your website).
'$_SERVER' variables aren't reliable because they rely on the information given to them by the web browser when the request is made, and such information can easily be forged, by most people who have a basic understanding about how headers are sent.
In summary, use a NONCE (cookied), validate IP and user agent.
Steps:
When you deliver the outer frame, generate a unique identifier
(totally random, long string) and return that in a cookie with the
HTML content.
At the same time, note the IP and the user agent string you have
sent that unique identifier to, and store in a DB with the time.
When requesting the inner frame, assuming the same domain, the
cookie will come too. (If a different domain, you'll need to attach
the unique identifier as a visible string, but that's not really of
concern, just uglier)
If the user agent or IP do not match those you stored against the
unique string, or the request is too long (i.e. after an hour, or
whatever is reasonable for your application) or the unique string is used more than once
(or whatever other restrictions you place on it) then reject the
request and invalidate (delete) the unique identifier.
Not 100% foolproof, but just combine more options to make it less and less likely to be abused.
I've media website once member is logged successfully it creates session
$_SESSION['login_id'] = $username;
I wonder how to prevent members to watch two channels in same time.
I mean for example if member is viewing page video.php?id=4 and open in new tab page video.php?id=5 it shows him error have to close the page of video.php?id=4 before viewing the new page.
1st thing came into my mind is random token key that cleared on page exit but i don't know if it good idea or not, does anyone known how to do it or have better idea ! ~ thanks
At first thought
You could use requests to a php script that tells you if the user is still opening a web page.
For that you can use a loop of timed out ajax requests ( using jQuery for example)
Hint:
Instead of making Requests you can try and load tiny images ( 1px h/w ) and of course load this image using a php script (you can trick the url using htaccess),
So when the image is requested, your php script will do the trick (setting the currently watched video) then serve the image (don't forget to set the proper content-type )
and keep loading the image at certain interval (you will need to generate url token to avoid caching ;) )
A second solution could be
Serving your videos using php script as proxy, like that you can know when a video has been streamed completely, then if a user request a second video, knowing his is still streaming a previous one, you deny his request, show him an appropriate message or do as you like :)
I guess, using the 2nd solution would be better for you and the visitor, since he would be able to start caching a 2nd video once the 1st one has been cached completely
1st solution will use many request which can overwhelm the network or both the client side and server side
Both Solutions would not track a user that is using more than one browser, which means he would have more than one session, unless the user is registered and logged in
if ($_SESSION['login_id'] = $username && COUNT($_GET['id'])>1 )
Now after you check this condition I don't know what you could do to prevent the user from opening 2 tabs..
Just my thoughts
Since the video has to stream, it pings the server . The session can have assigned to it, the last video clicked. then once a new video is clicked, the session on the server will use the new video id and once the first video pings the server and find out the session is pointed at a different page, then the video can return an error message
Alternatively, You could assign an ID to each instance of form OR a hidden field with an ID, then use AJAX to ping the server with that ID. If the user tries to request the same form when there's an active ID, it should display an error message.
I have
echo <a href=\"javascript:;\" onClick=\"window.open('". $link ."','no','scrollbars=yes,width=550,height=400')\" >View report</a>
$link contains sensitive information, so I'm wondering if there is a simple way to prevent this link showing up explicitly when you "view source code" on the browser. Any alternative to href would be fine. I just need to give the user an option to click and see his processing result after he submits some data. I would like to avoid having auto popups as soon as the processing is submitted.
UPDATE: so the $link is a GET URL that includes a user ID and password.. It's internal right now so it's fine, but I'm thinking of putting this on our online server in the future. I'm very much a novice with PHP, so this is probably not in the near future as I don't know much about security features that need to be implemented for a live site on the Internet. Right now, it seems that utilizing a database would be the best way to go. Correct me if I'm wrong, please, and thanks for all of the support!
If the user has to navigate to the link, there is no way to actually hide the information. You should rethink how your process works so sensitive information is not displayed in the link.
Perhaps you can store the information in a database table and the link would just use the id of the row that has the information.
Simply put: No. If you send me to a URL, I will be able to see it using some sort of tool. Wireshark, Fiddler, etc. Consider using a different link structure.
If the user already owns a session, this is an option:
If you render a page and need to protect this given sample secret URL
http://www.MyHost.com/?what?secret&id=23232
save the URL in the user's session and associate a hash value with the secret URL.
Instead of sending the URL to the result HTML-page, insert another URL, e.g.
http://www.MyHost.com/?continueWith=<hashValue>
If this URL gets called, check the user's session and retrieve and delete the secret URL. Then continue to evaluate, as if the user had called the secret URL.
This way, no parameter of the original secret URL ever reaches the user's browser.
To refine the schema, attach a lifetime to the URL saved in the session. If a request comes later as the end of life, return an error.
If you protect all URL in such a way, users won't be able to call arbitrary URLs, since all acceptable URLs are those inside their sessions. Thus, a user will even not be able to change parameters of less secret URLs.
How is $link generated in the first place? If it is sensitive, this implies that the user has already been authenticated somehow. Thus, the information in $link can be stored in the session where it's safe
Save all the information in your PHP session (or preferably the session system your PHP framework uses) and then just send some kind of non-db-associated identifier in the link so that the code knows what you want to do next.
For example you could have a link to "http://www.yourdomain.com/sec/special_action/4" with "sec" meaning secure, "special_action" being the name of the action to take, and "4" being the action id reference.
So lets say you have to have it associated to their social security number. Then you would in your back end use a salted hash to encrypt the SSN and save it to the session data. You then append it to the end of your session array and get an array count. If it returns 5 then you know that the encrypted SSN is saved in index 4 (since PHP uses 0 based indexing). So you send along that index as part of the link to confuse things even more. Heck you can even salt and hash the index if you want.
The user clicks on the link, the code finds the index, grabs the encrypted content, decrypts it, then uses it. Easy and secure.
I am working on "Email this page" Popup page. I want to send url of base page as an email, but it should be a popup window.
I have used HTTP_REFERER, it is working fine on Firefox, but not working on Internet Explorer.
I am getting the url of current page but I want that url in new popup window page.
Is there any alternative than HTTP_REFERER.
On the page you wish to grab the URL of, you can use $_SERVER['REQUEST_URI'] to get the requested URI (except the scheme & hostname; in other words, you get the path and query string). Pass this to your other page either using a query string or sessions. The former is preferable, as the latter isn't RESTful. There may be times when it's OK to break REST's rule against server side state, but this probably isn't it.
There is no way unless you store it or send it yourself. This page has one example of how to do it, but only really if you set it beforehand. If the site is your own then you should be ok. If not then you will struggle.
That happens because the HTTP_REFERER is sent by the client browser, which means that it's value can be totally manipulated or can even be null. This means that this variable isn't very reliable. But if the site is yours, there are other solutions.
You can send the url or any other identification like an ID by QueryStrings. So you'll have the link URL like this the_send_page_name.php?ref=index.php
Be aware that this method only works if you're opening the Pop-up in a site that's yours.
I have an affiliate tracking script that is currently being exploited by an affiliate. In the main, site I track the affiliate clicks using this url www.example.com?member=affiliatecode,
then I capture the query string $_GET['member'];
Problem is, an affiliate is exploiting this simple system and page loads on his site is being recorded as clicks going to mine.
What measures can I add to prevent this without changing the affiliate link to my site? An idea that I had is to check if my page has actually been loaded, but how would I do that in PHP?
Thanks
I don't quite grasp the exact problem (or more to the point, exactly how the affiliate is logging hits), but a solution may be to put a image on your page which should ensure that a browser has loaded it. So at the bottom of you page you should insert
<?
if ( isset($_GET['affiliate']) ){
echo '<img src="affimg.php">';
}
?>
And then in the affimg.php, you would log the affiliate and then output a 1x1 image (remembering to set the headers). The downside is that there is no way to stop an affiliate just simply putting that image in to his page and if the affiliate is using an iframe, the image would still be loaded.
A better way may be to simply do some tracking. Rather than just requiring that one page gets visited, change it so that you require two or more using a database to track the ip addresses.
There may be a better way, but then I don't know the exact details.
First, you can never be sure that a bot/script instead a human "clicks" on an image, this is a fact. Secondly, you can make things a bit difficult. An idea would be:
Deliver a banner including a unique link that is triggered via a Javascript-click-event, like:
<img src="http://www.targetsite.com/image.jpg" />
Save the token in your database before and give it a expiration time of some minutes. Then, only count the click if the token is valid later. So your affiliate has to change the "onClick"-Event or parse the source code to extract the token.
As said, it only makes things more difficult. You could also parse your affiliate's site source to see whether there, your banner is "clicked" automatically (which would be very cheeky).
Another addition would be to read a cookie on the client side and attach it to the generated link to implement a check if the client has already requested your target site.
Since you can't protect yourself completely from fakes, you can build several little tools like these that increase safety.
HTH