How To Prevent Your LP From Loading Without Your Tracking Link? (9)

Ive seen some ppv landing pages where if you grab the url of the lp and try to load it again in another tab or browser it wont show / just redirect them to the offer.

Im pretty sure CPVLab has this function, not sure what its called, but how would one go about doing this with Prosper202? Pretty sure it has something to do with cookies but not sure then why it wont show if you open a new tab?


Anyone know how to do this with p202?

Thanks

It's referrer cloaking... you can fake referrer to emulate this if you absolutely need to load in another tab/window (just save the page would be my opinion). More and more people are doing this these days, not just on PPV...
I don't think CPVLab/Prosper can do this, but proper cloaking services have the ability, it's also easy to code yourself, just some basic PHP I think. Maybe somebody will chime in with the code for you.

Yeah I actually wanted to save a ppv pop up that I got and i went to save it in my browser and it wouldnt show up. Tried it in IE and it still didnt show up even though the cookies are there... If i was gonna emulate the referrer how would I find that? I mean lets say it was a leadimpact popup? Arent their referrers usually some long digits?

There are two ways that come to mind that one might do this:

1) Cookies. Cookie someone on first visit. On any visit, check if they have the cookie, if so -> redirect to another page.
2) Referrer check. If referrer =/= to something, e.g. outbound link from traffic source -> redirect to another page.

Number #1 is easily avoided by clearing cookies for that site. If that doesn't work it's probably referrer based. For number #2, if you want to get around it, use something like https://addons.mozilla.org/en-US/fir...ol/?src=search for FF or https://chrome.google.com/webstore/category/apps?hl=en for Chrome and you can play with the referrer for that page, i.e. set it to spoof whatever the traffic source links that take users to the page are like. Likely the domain itself will work, e.g. track.leadimpact.com or something like that. If the person is on to it they might have some nifty coding to expect track.leadimpact.com/out.php?click=20digitsgohere, if you get my drift. If you can spoof a legitimate outbound click link that'd be grand. They would have to have logging to thwart you there.

For doing it yourself, I don't think it's so much a tracking platform thing as it is an on-page thing. I.e. would probably code it to the top of your lander, or, if it were me, I would link ads to file X that checks referrer and includes landing page A if rules are satisfied, includes landing page B if they are not. I would use include() rather than a header redirect, otherwise they bounce to your lander which then makes it so someone can reload that lander normally, unless you have more code on that page making things more complicated. May take some testing to figure out how to get your tracking links working properly - if your lander is expecting to $_GET variables from the URL then you should set these before doing include() whereas if they need to be in the URL of the landing page tracking link it may be better to include the file with it's full path rather than a local file name. Example:

[PHP]
<?php
$referrer = $_SERVER['HTTP_REFERER'];

$subid1 = $_GET['subid1'];
$subid2 = $_GET['subid2'];
$subid3 = $_GET['subid3'];

if (preg_match("/domain1.com/",$referrer))
{
include 'landers/lander1.php';
}
else
{
//Want to change a subid if someone is a repeat visitor or not from intended traffic source?
//$subid3 = 'repeat';
include 'landers/lander2.php';
};

//If you need subids/querystrings to be included in the landing page tracking URL you would do something more like:

if (preg_match("/domain1.com/",$referrer))
{
include 'http://mydomain.comlanders/lander1.php?subid1='.$subid1.'&subid2='.$subid2.'& subid3='.$subid3;
}
else
{
include 'http://mydomain.com/landers/lander2.php?subid1=repeat';
};
?>
[/PHP]

That's my take on things. Note the second approach can be iffy depending on PHP version and some setting I believe. Something about including a non-local URL being risky or something, can't remember.

Awesome stuff as usual, Zeno!

I think the vulnerability you're referring to would be "allow_url_fopen", which you should DEFINITELY check is not enabled if you're going to do something like this. Otherwise you risk the insertion of malicious code from any other site the attacker cares to use - here are some unpleasant potential exploits.

I'd also be a bit worried that option 2 would open you up to a SQL injection attack- good old little Bobby Tables.

However, you can avoid both of those problems by checking the format of your subid input. If you change your GET lines to

if (preg_match("/^\d+{1,10}$/", $_GET['subid3'])) { $subid3 = $_GET['subid3']};

Originally Posted by caurmen

Awesome stuff as usual, Zeno!

I think the vulnerability you're referring to would be "allow_url_fopen", which you should DEFINITELY check is not enabled if you're going to do something like this. Otherwise you risk the insertion of malicious code from any other site the attacker cares to use - here are some unpleasant potential exploits.

I'd also be a bit worried that option 2 would open you up to a SQL injection attack- good old little Bobby Tables.

However, you can avoid both of those problems by checking the format of your subid input. If you change your GET lines to

Code:

if (preg_match("/^\d+{1,10}$/", $_GET['subid3'])) { $subid3 = $_GET['subid3']};

that should avoid the problem altogether. It's hard to see what nasty injection attacks can be performed with only 10 numbers...

(note - that assumes your subids are only 10 numbers max long. Adjust the number in the regular expression as appropriate for your subids. )

You're not going to need Caurmen's code in this implementation, you only need to be worried about SQL injection if you're putting a user-modifiable value directly into the database. CPVlab/202 already handles this.

Zeno's code has a few bugs, when you call 'include' all the parent file's values are passed onto the included file, so you don't need a separate version for subid's etc. Simply:

[PHP]
<?php
$referrer = $_SERVER['HTTP_REFERER'];

if (preg_match("/leadimpact.com/",$referrer))
{
include 'landers/reallander.php';
}
else
{
include 'landers/fakelander.php';
}
[/PHP]

I'm not sure if leadimpact always passes a refer, so make sure you keep an eye on traffic to see if everything stays normal.

@snipe - Good fix! That avoids needing to sanitise inputs, which is nice.

Includes with user-appended data are still a bit risky security-wise. In theory Zeno's code will be fine because you're hardcoding everything but the query string, but I did a bit of research, and there are tricksy/nasty things you can do with escaping parts of the URL, even if allow_url_fopen isn't set. I'm not expert enough to tell for sure if there's a way to do that in this instance, but better safe than sorry - if you were going to use that code, I'd definitely check inputs for validity. However, your approach is better, safer and simpler.

And you're right, I had a bit of a brain melt moment there. You're not risking a SQL injection directly, just a code injection - which can be plenty unfun enough, of course.

@vidivo - if you wanted to include the check, you'd use the code I posted for all 3 subid GETs, obviously changing the number each time, exactly as you said. However, Snipe's code is a more elegant solution - better just to use that.

Yeah I always thought parent file querystrings were available to included files but had a hell of a time with some FB fanpage stuff which made me think they weren't. I vagued and didn't bother checking that, pays to do your due diligence rather than trust sketchy memories! Thankfully posting code always causes code-savvy people to emerge and post corrections, just like incorrectly using you're.