If my shopping cart is stored in a DB for both anonymous and registred users, what is the best way to protect it from an attack? I found a lot of discussions about where to store shopping carts but nothing about this matter.
What if some bot just doesn't store cookies and sends requests to the shopping cart over and over again. Without cookies it's different anonymous user every time thus database will grow.
Should I check the ip address and redirect to a captcha? But real users may have same ip addresses, so the algorithm should be more complicated to not disturb them.
Any ideas or links?
Captcha's are a pretty popular way to go. I'm guessing most people (like me) rather dislike them and generally can't read them, but they're generally probably pretty easy to implement and more efficient than most alternatives.
The less effort approach to checking IPs is having all anonymous users require a Captcha.
I would also suggest having a time-out (based on activity) of no more than a few hours on carts of anonymous users (after which you can probably delete it).
You'd also want an upper limit on the number of items, and, if this number is high, also possibly prevent (though Captcha?) users from adding too many items to their cart in inhumanly short succession.
Related
We want to track users when they visits our competitor websites.
Suppose the user visits a.com(our site) and then visits b.com and c.com (our competitors) , we want to know the user has visited those sites. Is there a way to track this without using plugins like chrome extensions.
I know there is limitation in cookies. Is there a way to do this?
Thankfully, no.
From time to time accidental mechanisms to leak such information become known (such as, at one time, it was possible to inspect link styles to see if it's visited). Such things are regarded as serious security breaches and are swiftly eliminated by browser vendors.
Basic web security principles isolate the interaction with unrelated domains, unless both web pages willingly try to talk to each other. Furthermore, if a user visits your site first and the closes it, their interaction with you is finished - in no sane scenario would you be able to know what they do atferwards.
Not to mention the obvious fact that what you're asking is just plain highly unethical.
Unless you can get your competitors to give you access to their websites, either through include scripts or indirectly if you manage to track users through ad-networks or Facebook pings, it's not possible. You cannot access (should not be able, in any case) cookies set by another domain.
Some browsers allow access to the previously visited URL through document.referrer -- but that is not guaranteed to work, nor is reliable. In short, there's no way of doing it targeted.
Not being able to easily track people is a good thing; but it makes constructions like the on you are wanting a lot harder.
Good Afternoon,
I am hoping someone might be able to help me with a concept. I have a websocket server which pushes JSON messages out to users, I have coded in a number of admin functions for pushing broadcasts out to users, as well as disconnecting users if needed.
One of the things I would like to be able to do though is to come up with a 'near' foolproof way of 'banning' users from connecting to the server if required. This is where I am a bit lost, if I go the cookie route then it is possible that the cookies get cleared and it no longer works, I can't use the session ID either as once they disconnect they get a new session ID, and the IP address is also problematic as many would be on mobile dynamic connection.
Id appreciate any tips on how to best achieve a way of remembering the users so if I ban them, when they go to reconnect I can prevent them.
The server I am running is the supersocketserver whilst the client is HTML5.
Given your current constraints, there is no "foolproof" way to ban a person from accessing your web site.
For privacy reasons, there is no permanent way to identify a given browser. There are cookies, there are IP addresses, there are even some evil "perma-cookies" that attempt to store little pieces of identifying information in lots of places (such as flash cookies and other plug-in data) to try to make it difficult (but not impossible) for users to clear them. As you're already aware, IP addresses are not permanent and are not always tied to just one user either.
And, of course a user can certainly just use a different browser or computer or mobile device.
So, the usual way to control access is to require a user to create an account in your system before they can use your service. Then, if you want to ban a user, you ban that account. Since you will want to prevent the user from just creating a new account, you can collect other identifying information upon account registration. The more info you require and can verify, the harder it is for users to create more and more accounts. This gets to be quite a bit of work if you really want to make it difficult for users to create more accounts because you need to require pieces of identifying information that you can both verify and are hard for a rogue user to duplicate (credit cards, email addresses, home addresses, etc...). How far you go here and how much effort you put in is up to you on how much you want to keep a banned user out.
The requirements:
For each item in the shop, keep stat about visitor's view.
During the first 15 mins, do not count the same visitor even though that visitor re-open the web browser
Need a way to protect visitor's cheating (The above 2 requirements should always be apply)
For example of cheating, If we're using Cookies, this is not good enough, WHY? Visitor can disable cookies and press "Refresh" to increase the stat(visitor's view)
Any good solution?
You have only two possibilities:
Track cookies / flash cookies (which many people don't even know of): That means tracking on the machine of the user
Track IP addresses: That means tracking the users on your server (you keep a database of IP addresses which have visited your site during the last 15 minutes or so).
Both possibilities can be "cheated". Cookies can be deleted, IP addresses can be changed. There is no absolute bulletproof way to accomplish what you want (Thank God for that!).
OK, you could force your users to login, then you could track everything down to a specific user account - no more cheating (well also not true: what about duplicate accounts...). But without such a limitation... no way.
I already looked at the most popular Django hit counter solutions and none of them seem to solve the issue of spamming the refresh button.
Do I really have to log the IP of every visitor to keep them from artificially boosting page view counts by spamming the refresh button (or writing a quick and dirty script to do it for them)?
More information
So right now you can inflate your view count with the following few lines of Python code. Which is so little that you don't really need to write a script, you could just type it into an interactive session:
from urllib import urlopen
num_of_times_to_hit_page = 100
url_of_the_page = "http://example.com"
for x in range(num_of_times_to_hit_page):
urlopen(url_of_the_page)
Solution I'll probably use
To me, it's a pretty rough situation when you need to do a bunch of writes to the database on EVERY page view, but I guess it can't be helped. I'm going to implement IP logging due to several users artificially inflating their view count. It's not that they're bad people or even bad users.
See the answer about solving the problem with caching... I'm going to pursue that route first. Will update with results.
For what it's worth, it seems Stack Overflow is using cookies (I can't increment my own view count, but it increased when I visited the site in another browser.)
I think that the benefit is just too much, and this sort of 'cheating' is just too easy right now.
Thanks for the help everyone!
Logging an IP is probably the safest. It's not perfect, but it's better than cookies and less annoying to users than requiring a signup. That said, I'd recommend not bothering with saving these in a DB. Instead, use Django's low-level caching framework. The key would be the ip and the value a simple boolean. Even a file-based cache should be pretty fast, though go with memchached as the cache backend if you really expect heavy traffic.
Something like this should work:
ip = request.META['REMOTE_ADDR']
has_voted = cache.get(ip)
if not has_voted:
cache.set(ip, True)
#code to save vote goes here
There is no foolproof way of preventing someone from artificially inflating a count. Rather, there's the extent to which you're willing to spend time making it more difficult for them to do so:
Not at all (they click refresh button)
Set a cookie, check cookie to see if they were already there (they clear cookies)
Log IP addresses (the fake a different IP every time)
Require signin with an email they respond from (they sign up for multiple email accounts)
So, in the end, you just need to pick the level of effort you want to go to in order to prevent that users from abusing the system.
You could send them a cookie when they access it and then check for that cookie. It can still be gamed, but it's a bit harder.
I'm creating a website and I don't want to have user/membership.
However, people using the site can do things like vote and flag questionable content. Is the only way to identify and prevent users from doing this repeatedly by using cookies?
I realize a user can just clear their cookies but I can't think of another way.
Suggestions for this scenario?
Well you could map a cookie + ip-adress in a datarecord in your database. To identify the user. So if the ip exists in the database, you simply just add the cookie, but check the cookie first to avoid unessesary database calls.
This is not optimal though, since schools etc might have the same ips on a lot of computers.
You can always just adapt openid!
Marko & Visage are correct,
Just to add though, you might want to store each vote with the timestamp,IP, etc... so at least if someone does try to "game" your site, you'd be able to rollback sets of votes made from the same location or within a very short amount of time (i.e. from a bot)
+1 To all that others have already said. Here's another middle-way idea:
Use cookies as primary means of limiting voting. If a cookie is not found, check the IP address. Allow no more than, say, 1 vote per 5 minutes from the same IP.
Cookies are not enough, as you said it could be cleared/expired.
IP address tracking is also not an option because of DHCP and firewalls.
The only thing that is ~100% sure is users, but then again, one person can register multiple accounts.
I'll go with cookies, as the simplest ant least obtrusive way. If someone really wants to play the system, he will find a way whatever you try to prevent it.
Even with membership a user can register multiple times and vote.
Cookies are one way to handle this but people who know that they can delete cookie can vote again.
You can catch the IP of the voter and restrict based on that. But many people will have same IP.
Sadly there is no other way.
Yes, you are right.
HTTP is stateless, so there is no way of determining if the origin of a request you receive now is the same or different to the origin of a request you received, say, 5 minutes ago.
Cookies are the only way around this. Even server side sessions rely on cookies to maintain session identity across requests (ignoring the security nightmare of passing the sesison ID in the URL, which anyone with malicious intent can sidestep trivially).
There will always be people gaming the system if it suits them. Moreover, if you make it such that you don't need cookies at all you'd be open to very simple attacks.
I think you'll want to consider ways to increase the economic cost of users operating under a cloud of suspicion.
For example, if a user with the same cookie tries to re-submit the vote, that can obviously be stopped easily.
If a user with a different cookie but from the same IP does the same thing, it could be coming from a proxy/firewall so you may want to be cautious and force them to do something extra, like a simple CAPTCHA. Once they've done this, if they behave properly nothing new is required as long as their new cookie stays with them.
This implies that people without cookies can still participate, but they have to re-enter the letter sequence or whatever each time. A hassle, but they're likely used to sites not working without cookies. They'd be able to make an exception if required.
You really won't be able to deal with users sitting over a pool of IPs (real or otherwise) and exploiting new and dynamic attack vectors on your site. In that case, their economic investment will be more than yours and, frankly, you'll lose. At that point, you're just competing to maintain the rules of your system. That's when you should explore requiring signup/email/mobile/SMS confirmation to up the ante.
You can add GET variables and URL parts to serve as cookies - some sites do that to allow logins and/or tracking when cookies are disabled. Generate the part using source IP and user agent string, for example.
site.com/vote?cookie=123456
site.com/vote/cookie123456