I'm currently working on my Referral System, but I have a problem with protecting it of frauds.
Okay, here's how it works for now:
user registers and activate it's account
user now have access to the control panel and there is it's uniqe link in following format: domain.tld/ref/12345
when someone other click to user's link, he or she must to click a specific button to confirm that is not some kind of fraud (like "click here, you'll get $100" or something)
system writes visitor's IP in a database and some data to cookies to prevent re-pressing the button. User now have +1 point.
But, the problem is that visitor can change it's IP, clear cookies and hit button again. It takes a few seconds, and that's not OK, that's cheating.
How to prevent it? Is there some trick to get some unique computer ID or something can't be changed that easy?
Really the only options are to tie the process to something which is not so easily manipulated by the user - super cookies, browser fingerprints, OpenID, Email addresses and telephome numbers (the latter 2 using some sort of validaton step before a vote is counted)
The only way you can be certain a referred party does not reuse a referral code is for the original user to send different one-time-use-only referral URLs to each person. Once the code has been used, it is flagged as such in (or removed entirely from) your database so that it can not be used again.
How you prevent the original user from sending multiple links out to the same person is another matter - and not an easy one to resolve.
Who do you perceive to be the threat?
Although it's certainly not 100% accurate, you can still fingerprint visitors using for example a combination of their ip, browser user agent, and with some javascript you can even go for screen size or installed fonts. Using these pieces of information you can set up a system where you save the fingerprints in datatable and in the same record you store the session id (from the cookie). Now when a new visitor arrives you can test their fingerprint against the db of recent fingerprints with different visitor ids. If you find a large number of matching fingerprints (you define the threshold) with different sessions then you can alert for the possibility of fraud.
Cheers
How about storing the link with with the user when they navigate to the link. then in the database you will have the link and if the users has already been to the link then deny them. Seems like it could work then you wouldn't have to worry about the cookies etc...
Related
Is it at all possible to retrieve user information that can be used as a unique identifier between domains?
As a quick example of what I am trying to do (not exactly this but the theory is the same) say you had a main website at UK-news.com. You also had three other sites - England-news.com, Scotland-news.com and Wales-news.com, all hosted on the same server.
All 4 sites will share the same database and each would just pull the relevant info out of it. If a user becomes a member of one of the sites, they will also be given the option to become a member of any or all of the others. If a user signs-in to one of the sites he is a member of, and then goes to another how can I get that site to recognise him from the one he signed-in on so he is automatically logged in?
My theory was to store some user information (IP, USER_AGENT, browser, screen resolution, computer name, OS) in the database via PhP and then check against all of those as the user moves between sites. however, even checking against all of these, I am sure it will be possible for two different people to have exactly the same details.
Are there any truly unique identifiers that will guarantee that a person is recognised between domains?
Thanks
Steve
I dont know what is the configuration of your server, but. If one site is under something.domain.com, and another something2.domain.com, and the domains England-news.com and Scotland-news.com are only links to those sites, you can use url overwrite, and cookies sharing over subdomains option in php. But I think that this is not the case. So...
There is no 100% sure user recognition. And this is great, imagine what will happen if there would be. You can NEVER trust user data, and headers data, while sometime you can not even trust $_SERVER array. So there is no option to recognize the same user over few domains.
1) The only answer that is useful is to suggest you to share the user mysql table, and make all the logins and passwords same for each site. IN that case someone can login into another site using the same data.
2) You can try to rely on second hand services like google acount or facebook acount to verify users on your site. But you must remember that there are people without gmail and facebook, and availability of such a site will be reduced.
3) Use a serrvice like forever cookie, or something like that, but this is also not 100% sure. It is using html5 storage, flash objects, and everything to verify if this is the same user. But as far as I know, everything can be ommited, if you are patient enough.
Best regards!
So I have a site that let's you buy and download mp3's. The mp3's are all made by me. But when the user goes through the PayPal checkout process (I have buttons and IPN all setup already) my IPN script stores the order ID as well as the IP address of where the user bought the MP3 from. The IPN script generates a download link and emails that link to the users PayPal email.
So whenever the user clicks the download link, it takes the user to my download page. On the download page, it finds the download ID in the database as well as the order ID, the MP3 ID, and the IP Address the user was on when they purchased the MP3. Is it a good idea for me to have to verify the databases IP Address with the users current IP Address and let the user download it? I store the IP Address using:
getenv('REMOTE_ADDR') in PHP.
Or should I just skip any verification and let anyone who clicks on that link download the file?
alright, first of all you should think about the logic behind your question.
just as an example:
an user buys a song from your site. first question should be, if you allow him to access this download link temporarily (1,2,3 hours, days...) or is it just once possible to call that download link or is it lifetime garanteed that this user has access to it.
after you have set this basic information you can go ahead.
case 1 (temporarily access):
storing $_REMOTE_ADDR is a good beginning but what in case this user sits behind a vpn network, in a lan and so on... there are some more ways. you should read about HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, HTTP_X_FORWARDED... and so on!
you even should have in mind that all $_SERVER attributes can be manipulated. So just as an advise: you should sanitize all variables before storing them into your database instead of trusting them blindly.
back to the issue: you have stored now the ip, for security reasons, okay. maybe you fear to get cheated. doesn't matter. your script generates a download-link that will be sent to the paypals email address. now you have two options:
first: an user has already verified through paypal and everthing is fine. so you dont need to fear anything.
in this case you should think of delimiting the time that an user has acces to your files. now imagine this user has a few million friends and you would be justin timberlake for example, than the user would sent the link that he has received to all of his friends that would try to access your server and download your files - assumed your servers hardware would do so!
so first of all a better way is to delimit the time to access the link for example for 1,2,3 hours... after buying - still not perfect but this would avoid the above.
If you restrict it further to the IP - assumed you will learn how to get that the right way - an user just can download your mp3s from the IP address where he bought it from. what when the user has a smartphone and wants to download it from anywhere else than home? am i right, that the users have to create an account to use your offers?
than the solution could be to store the frequency that a mp3 has downloaded by a certain user. here you could set a limit to 50 times, that should be quiet much for one song to download again and again and again.... you even get an overview if an user will be logged once or has this user published his login data for illegal sharing issues.
seccond: an user has not verified through paypal and tries to cheat on you. imagine he will create an account at paypal and leaves incorrect bank/account information. paypal would pay you first and tries to regain the money afterwards from an incorrect account information. when paypal has recognized that the information left in the user account are wrong they surely will cancel the whole transaction and regain it from your account. in the end you`ll be always the loser when accepting paypal. sorry.
and to be quiet honest to yourself: how are the chances to catch some people that try to cheat on you?! 0,0000000032423 percent maybe with an the whole risk on your site to lose much money for pursuing investigations.
I'm making a survey site and I'm trying my hardest to avoid user logins - I want people who answer my surveys to be anonymous members of my university, who open a link and answer the questions directly. So I'm tracking questions/surveys finished by the user through session variables
But what I don't want is one user submitting tens of questions/surveys by clearing cookies and thus effectively resetting his/her sessions. Anyone know how to deal with this?
(If anyone thinks of other ways by which people can make multiple submissions, let me know that too! I'm also looking at articles to prevent same users using different browsers)
Never trust the user. Ever.
You have a few options. All have pros/cons
By IP address - limit responses to 1 IP address per computer. This suffers from dynamics IP address problems as well as only response is allowed per computer that holds its IP for long periods
Send single use response token - Send every respondent a unique link. Each link contains a single-use token that may be redeemed to take one survey.
Collect their email address - Redact this information in the results. I'm not sure of your setup, but I thought I'd mention this in case you're just the data middle-man
At the moment, I'm working on a website that could use some extra user usability, so I want to launch a couple of modal windows to aid users on their first time visiting of a couple pages.
I want to check if it is a users time time viewing a specific page. I've read about how you can run into problems when using cookies to do this. They can be deleted, the user can use a different PC or device, etc.
Also, I want to check for multiple pages if it's their first time viewing, not only directly after login.
I'm guessing a good idea for this would be to make a separate table with the pages in it that I need and setting a boolean for it if it is viewed or not.
Would this be the best way going about doing this?
There isn't a highly reliable way of doing that:
You can use cookies, but as you said, they are not reliable, a user can change PC, delete cookies, change browser, etc.
You can try using an IP address, but that's also not reliable. If a user switches address (which can today happen as you walk down the street with your mobile phone) he'll see the page over and over again. Moreover, if some other user happens to stumble upon the IP address the first user used, he won't see your tour/tutorial.
What I can suggest you is that you use cookies to detect if the user is new, but don't automatically throw the help modules on him, but prompt him using an non-obstructive toolbar at the top or bottom (never a popup window or lightbox).
That way, you get most of the users (because many people use the same browser and computer and rarely delete all their cookies), and even if a user has deleted his cookies/he still won't be disturbed that much.
There is no reliable approach if user is not registered and logged in with her/his username & password.
As mentioned before, there is no reliable way of detecting users ( and detecting if the user visits the site the first time), I also recomend Madara Uchiha's aproach, also you colud use html5 local storage in addition to cookies, both are not 100% reliable
u can however try user recognition without relying on cookies or html5 storage, but this is extremly complicated, u dont want to do this.
Just to satisfy your curiosity about how to do this, check this epic answer on a related question:
User recognition without cookies or local storage
I think, as I believe, there is no way with no solution. I think, a possible way consists of some parameters which first to be said and and finally by considering those, we can be able to talk about possibilities and impossibilities.
My parameters are in the below;
talk about features of a webpage as "User Detection" and detail them
think about reactions (I mean being fast to click on any elements of a page or not) on a webpage
inspect elements
URL injection
other reactions like click on some parts as spots placed on the page
stay on that page up to a time defined for being and checking authorizing
and so some solutions like the ones above.
I currently have a website built in PHP, I'm hoping to build a referral system tonight.
My theory is that if I dynamically generate a url and place it on my users' homepage such as
"Referral url = www.mysite.co.uk/referral.php?user=myuser"
Then I could have a script in the page referral.php which gets the username and runs an sql query updating their corresponding row in my table.
The only thing is anybody could then add there own name and sign up multiple accounts.
What is the best way to go about building something like this?
Thanks
Suppose to get the referral url my users had to click a button which generates the referral url as a rand ie mysite.com/refer.php?user=234234, at the same time storing it in a the db.
Once somebody visits the page refer.php, the referrer then gets his credits or benefit added to his row in the db, at the same time setting his referral code to 0, making the code only available once.
Each time he hits the button on his page, his referal code would change.
Would this be valid do you think?
You generally have the right idea, but protecting against fraud in a referral system is difficult. You can check for unique IP addresses in $_SERVER and add that to the database for each request, throwing away duplicates or limiting referrals from IP addresses that don't come from the user who signed up. Like HTTP_REFERRER, this can be spoofed as well with ease (using TOR for example).
It's a tough problem that isn't something you can truly "solve." Like most fraud cases, you can only do your best to mitigate the effect.
EDIT TO ADD: You can also require referrals to "mature" by forcing the referred user to be active on the site for a defined period of time (say, 30 days) to increase the effort of spammers/cheaters. But again, this doesn't "solve" the problem - all you can do is make it tougher for them to game the system. And occasionally, by doing this stuff, you can ruin user experience. So how do you balance it? Tough question. :)
EDIT TO ADDRESS YOUR EDIT: Contemplate the following scenarios if we implement your plan:
1) I click the button and get my code. Then I paste it to... who exactly? One person? That's not particularly good for sharing on Facebook, MySpace (does this exist?), or my personal blog. I have to generate a referral code for EVERY person I send to the site? That not only scales terribly, but is a horrible user experience as well.
2) Let's say I figure out what you're doing. I develop a bot that clicks that button 4 trillion times. What now?
You could use the 'HTTP_REFERER' value to check what page the request came from, and only allow votes for that user from their page. This can be spoofed, but most people won't know how.
You can count the referral points for some additional action on your site, for example registration or payment or anything that is behind captcha check.
But do not build any obstacles for your regular legit users!
you could embed this information in the POSTDATA - it's a tad more secure.
Or you can add a restriction that any user may be upvoted ONLY by any other EXISTING user only once. And to make it more "secure", generate userIds with a random seed.