IvorD

I'm not sure our problems are the same. The problem I was addressing was someone taking one of our legitimate Revive ad URLs and replacing the "oadest" parameter with a different target than that specified for the banner so that Revive did the redirection to the bogus target. My solution was to ignore the oadest parameter when the banner ID is specified in the ad URL and use the URL associated with the banner instead. As I noted before, the open redirection problem has been described as an unavoidable feature of Revive, but so far nobody has pointed me to an explanation of why that is and I haven't delved into the code beyond looking for the narrow fix to our problem. Sorry I can't be much more help. Have you looked at the URL being used to access adclick.g.doubleclick.net to confirm it is as you expect and has not been modified by malware along the way?

If $adId is empty then you have no banner whose URL should be used in place of the oadest URL. The problem I was solving was a request that contained both a banner ID and a bogus oadest. My change forces the use of the banner's URL when the banner ID is supplied, ignoring the oadest URL. It does not affect the behaviour if there is no banner ID provided. Sorry. The alternative would be to modify the procedure return an empty string if no $adId is specified, but I have no idea how often and/or where requests without a banner ID may be generated otherwise, so that modification might break some other functionality that I don't know about.

Caveat: My solution below may or may not break something else of which I am not aware. I have not had ANY response to inquiries about under what circumstances the oadest URL would legitimately differ from the URL associated with the banner identified by the "bannerid" (aka "$adId") in the same query. I even asked someone directly who said they had spent hours unsuccessfully looking for a workaround to the open redirection requirement, but have had no response so far. It's evidently a deliberate design choice. I solved my problem (see previous post in this thread) in function MAX_querystringGetDestinationUrl with the following change to force it to use the URL associated with the banner instead of the URL supplied in the oadest parameter when the banner is identified in the request: < if (empty($dest) && !empty($adId)) { --- > if (/* id: Force use of ad's url: empty($dest) &&*/ !empty($adId)) { In the source code the function is in www/delivery_dev/ck.php but that is assembled into both www/delivery/ck.php and www/delivery/lg.php for distribution. I wrote a bash script so I can re-apply the patch to future releases for our deployment. It saves the original file with a .save suffix: #!/bin/bash # # Apply this script to the following adserver files: # www/delivery/ck.php # www/delivery/lg/php # # to avoid open redirection in ad click URLs # file=$1 tmpFile=${file}.tmp if [ "$file" = "" ]; then echo "usage: $0 filename" exit 1 fi if [ ! -w $file ]; then echo "Cannot write file $file" exit 1 fi if [ $file:h = $file:t ]; then file=$cwd/$file fi egrep "function MAX_querystringGetDestinationUrl" $file > /dev/null status=$? if [ $status -eq 0 ]; then if [ ! -e $file.save ]; then echo Copying $file to $file.save cp -p $file $file.save fi script=/tmp/sed.$$ cat > $script <<EOF s|(empty(\$dest) && !empty(\$adId))|(/* empty(\$dest) \&\& */ !empty(\$adId))| EOF sed -f $script $file > $tmpFile status=$? if [ $status -eq 0 ]; then diff -c $file $tmpFile /bin/mv $tmpFile $file else rm -f $tmpFile fi rm -f $script echo "Fixed $file" fi

It looks like I can prevent this open redirection in MAX_querystringGetDestinationUrl by forcing it to use the ad's url when an ad is specified: if (/*empty($dest) &&*/ !empty($adId)) { $aAd = MAX_cacheGetAd($adId); if (!empty($aAd)) { $dest = $aAd['url']; } } Under what legitimate circumstances would the URL specified in the dest parameter for an ad click be different from the URL specified for the ad also identified in the click URL? (Our deployment is not as a general purpose/revenue-generating ad server, but a convenient way to track referrals to affiliates who offer commissions; we have a couple of zones which serve ads through Google AdSense, but the rest are our own.)

I asked a similar question back in 2019 on the Off Topic forum, but got no response and the problem has now cropped up again: We got alerted through the Google Search Console about a "bad" link on our website. The link cited was a Revive ad link in which a different URL from the target URL of the bannerid banner had been substituted for the oadest component of oaparams The substituted URLs are to porn sites, of course. Curiously, going through the last couple of months of Apache logs, I can only find requests for lots of similarly hijacked URLs (for the same banner and zone IDs) from web crawlers, primarily Google. I find no requests from any website where the crawlers may have found the links, so I have no idea where the search engines found them to try to crawl them through our site. I've compared the live Revive installation with a separate development server and have concluded that none of the source files has been corrupted and none of the banners in the database has been corrupted. Specific questions: Has anyone else experienced and/or investigated this problem and, if so, how did you avoid it? I've seen references to "features" that require the presence the oadest URL parameter when one would think that the bannerid and zoneid should be sufficient. Where can I find an explanation of those "features" and why this security hole is "unavoidable". Perhaps I can join the club of those who have banged their heads on the wall looking for a solution to the oadest problem, given a pointer to the context.

I'm posting to see if anyone has experienced anything as curious as the following: We received an alert from the Google Search Console about an invalid redirection. (I vetted the message to ensure it was legitimate.) The link they supplied was a Revive ad link from our server with legitmate zone and banner IDs but an incorrect destination URL: https://SITE/adserver/www/delivery/ck.php?oaparams=2__bannerid=16__zoneid=13__cb=bf7c125ee0__oadest=http://asmilingmalice.tumblr.com%22%3EBeautiful whereas the correct (& current) ad link is: https://SITE/adserver/www/delivery/ck.php?oaparams=2__bannerid=16__zoneid=13__cb=d44ce9c8e3__oadest=http%3A%2F%2Fwww.freekibblekat.com%2F Apart from being the incorrect URL, the bogus one includes "> (quote, greater-than) before the "Beautiful", like it was scraped incorrectly from somewhere. I've been back through several months of nightly database backups and can find no evidence of the banner record with the bogus URL and the database is correct today. I've reviewed all of the banner destination links both visually to see that they are as intended and programmatically to checked they can be visited (and found a few that no longer work). I found no modified source files. I've upgraded from 4.1.4 to 4.2.1 anyway to ensure a fresh set of source files. So I'm currently stumped about how this one destination URL could have been tampered with, apparently temporarily, and would be very interested in similar experiences or insights into what might have transpired. Any ideas?