UPDATED
overview of the problem
I am developing a public idea sharing
website, where any user(after creating
an account) can submit ideas; they
will then be reviewed & rated by our
internal reviewers. And only the best
submitted ideas will be published.
These ideas can now be voted by anyone
anonymously. And for each 1000 idea
votes, we will reward idea authors
with say $0.5.
I'm using an anonymous voting system where each vote is identified by a combination of IP address and User-agent.
But since we are rewarding users with cash , I fear this voting system could be manipulated!
Measures I've thought of taking:
Voting only with javascript enabled( using ajax) - to make sure votes come from browsers alone.
Also considering to receive votes, only from the most commonly used browsers.
Can this kind of voting work effectively without much loopholes?
Any good solutions for anonymous voting systems?
Wow! this link is helpful: What is a reliable method to record votes from anonymous users, without allowing duplicates
authentication based on the users account (credit card, checking account ..) Or how is the money payed out?
This won't work. People can easily masquerade under a different user agent, regardless of whether or not it's a "commonly used browser" or if Javascript is enabled. It doesn't make any sense why you think limiting voting to users with common browsers will do anything at all. Client-side scripts could also be written to cast votes, even if you require Javascript to be enabled. Not even IP addresses are immune from spoofing; for example, the user could work from behind a proxy server. Also consider that there could be more than one user who shares the same IP: dynamic IP addresses are quite common, and large ISPs frequently re-use IP addresses by allocating them to different users at different times.
I already voted to close this as off-topic, but it looks like it's also a duplicate: Limit 1 vote per IP Address?
Related
We have a lot of doubts concerning the changes in the Messenger Platform’s policies.
There is HUMAN_AGENT tag (for which we have already asked permission) which seems to be the one that adapts the most to our processes, but 7 days is still insufficient for us. Could we answer with this “message_tag” 20 days after a user message? What can we do in this case? We have to find a way not to leave the user without an answer.
We plan on using one of the above-mentioned CONFIRMED_EVENT_UPDATE to answer all user messages outside of the 24 hour window. Are there any penalties for us doing so? If there are, what are the penalties? Are they applied at the company level or the page level? None of the messages sent by our company contain what you want to avoid (spams, special offers, discounts, etc.) so we don’t think we should recieve any penalty even when using “message_tags”.
We have thought about using the normal answer and, if the “This message is sent outside of the allowed window” error message appears, we will answer using “message_tags”. Is there any problem for using the first call on a recurrent basis giving errors or should we avoid it? Avoiding it might cause to send unnecesary “message_tags”. Could we answer all private messages using HUMAN_AGENT when it is approved (our answers are always given by a customer service agent)?
Best regards
You do not mention your actual use case, so nobody can suggest any message tags that would match that use case.
Without knowing that use case the answer to your questions can only be:
1) There is no way to extend the 7 days window for human agent tag. If you get approved for it you have a 7 days windows, not 8 and not 20. However most user actions reset that window you should follow up within that window and and make sure the user engages with your bot so the window is reset and you have another 7 days for another update.
2) Abusing tags will most likely result in your page being restricted, make sure to only use them for the allowed use cases as listed in the docs: https://developers.facebook.com/docs/messenger-platform/send-messages/message-tags/
Over the past few months random email addresses, some of which are on known spam lists, have been added at the rate of 2 or 3 a day to my website.
I know they aren't real humans - for a start the website is in a very narrow geographical area, and many of these emails are clearly from a different country, others are info# addresses that appear to have been harvested from a website, rather than something a human would use to sign up to a site.
What I can't work out is, what are reasons for somebody doing this? I can't see any benefit to an external party beyond being vaguely destructive. (I don't want to link to the site here, it's just a textbox where you enter email and press join).
These emails are never verified - my question isn't about how to prevent this, but what are some valid reasons why somebody might do this. I think it's important to understand why malicious users do what they do.
This is probably a list bombing attack, which is definitely not valid. The only valid use I can think of is for security research, and that's a corner case.
List bomb
I suspect this is part of a list bombing attack, which is when somebody uses a tool or service to maliciously sign up a victim for as much junk email as possible. I work in anti-spam and have seen victims' perspectives on this: it's nearly all opt-in verifications, meaning the damage is only one per service. It sounds like you're in the Confirmed Opt-In (COI) camp, so congratulations, it could be worse.
We don't have good solutions for list bombing. There are too many problems to entertain a global database of hashed emails that have recently opted into lists (so list maintainers could look up an address, conclude it's being bombed, and refuse to invite). A global database of hashed emails opting out of bulk mail (like the US Do Not Call list or the now-defunct Blue Frog's Do Not Intrude registry but without the controversial DDoS-the-spammers portion) could theoretically work in this capacity, though there'd still be a lot of hurdles to clear.
At the moment, the best thing you can do is to rate-limit (which this attacker is savvy enough to avoid) and use captchas. You can measure your success based on the click rate of the links in your COI emails; if it's still low, you still have a problem.
In your particular case, asking the user to identify a region via drop-down, with no default, may give you an easy way to reject subscriptions or trigger more complex captchas.
If you're interested in a more research-driven approach, you could try to fingerprint the subscription requests and see if you can identify the tool (if it's client-run, and I believe most are) or the service (if it's cloud-run, in which case you can hopefully just blacklist a few CIDR ranges instead). Pay attention to requesters' HTTP headers, especially the referer. Browser fingerprinting it its own arms race; take a gander at the EFF's Panopticlick or Brian Kreb's piece on AntiDetect.
Security research
The only valid case I can consider, whose validity is debatable, is that of security research (which is my field). When I'm given a possible phishing link, I'm going to anonymize it. This means I'll enter fake data rather than reveal my source. I'd never intentionally go after a subscription mechanism (at least with an email I don't control), but I suppose automation could accidentally stumble into such a thing.
You can avoid that by requiring POST requests to subscribe. No (well-designed) subscription mechanism should accept GET requests or action links without parameters (though there are plenty that do). No (well-designed) web crawler, for search or archiving or security, should generate POST requests, at least without several controls to ensure it's acceptable (such as already concluding that it's a bad actor's site). I'm going to be generous and not call out any security vendors that I know do this.
I've always assumed that it's risky to identify users in urls within emails. For example, let's say my app is something like eventBrite. I'm inviting a set of users to an upcoming event. I create unique urls for each user's email which allows them to simply click those url's in the email to accept or decline. Ie, they will not have to authenticate with the website.
If they view the email on a mobile device or a public computer through webmail, then clicking the links will fully accept/decline.
Is this approach too risky? I had assumed you should avoid this as something could see those urls and make requests on them which would trigger false accepts/declines.
It'a an opinion but I would assume the link itself can be more secure than the email actually. You can make the accept link valid only through certain period of time (it would not make much sense otherwise anyways).
Moreover, you can make it pretty much arbitrary long. So it's basically arbitrarily hard to guess.
That would leave two options to "see" the link, that I can think of. Physically seeing it by eaves dropping. But you could generate a mail in the html form, which would allow you to hide the full link behind a hyper-ref text. Like Accept / Decline.
There are several parts to this answer:
Is it secure? Absolutely not. It's security through obscurity. You're betting somebody can't guess the link which, as long as it's a finite string then they totally can and as soon as they do, they can RSVP to your event.
Follow up Does it matter? Probably not. I imagine the chances of somebody trying to spoof an RSVP to an event are pretty slim. I absolutely wouldn't protect anything critical this way but if you're just doing something like event RSVP etc (no money changing hands) I don't see anything wrong with this approach. As luk32 said, you can also make the links valid for limited amounts of time etc.
The real issue here, (unless there's something you're not telling us and this is somehow a high value target) is how likely is somebody to accidentally stumble on one of these links and RSVP to an event they aren't going to? You can make the chances of that exceedingly unlikely by generating the links in a sufficiently random manner so that no two links are a like. In this case, I don't think security is the big concern so much as data integrity. That is, is the data you're receiving valid.
One of our web site is a common "Announce for free your apartment".
Revenues are directly associated to number of public usage and announces
registered (argument of our marketing department).
On the other side, REST pushes to maintain a clear api when designing your
api (argument of our software department) which is a data stealing
invitation to any competitors. In this view, the web server becomes
almost an intelligent database.
We clearly identified our problem, but have no idea how to resolve these
contraints. Any tips would help?
Throttle the calls to the data rich elements by IP to say 1000 per day (or triple what a normal user would use)
If you expose data then it can be stolen. And think about search elements that return large datasets even if they are instigated by javascript or forms - I personally have written trawlers that circumvent these issues.
You may also think (if data is that important) about decrypting it in the client based on keys and authentication sent from the server (but this only raises the bar not the ability to steal.
Add captcha/re-captcha for users who are scanning too quickly or too much.
In short:
As always only expose the minimum API to do the job (attack surface minimisation)
Log and throttle
Force sign in(?). This at least MAY put off some scanners
Use capthca mechanism for users you think may be bots trawling your data
I'm currently working on an app sending request on a server for a voting system. The problem is that people can vote without registration but I don't want them to vote multiple time and I don't know how to secure this. I thought about a key system (generated in the app and verified on the server), but I'm not sure that this is the best solution.
What should I do ?
There are two possible solutions to this.
1) Handle the code that detects the duplicate vote on the server
For each vote cast the server stores the device id against the identifier of the vote. The server ignores any duplicate votes cast for that topic and sends back a "failure" response. This is handled by the device.
Pros: Centralized voting logic. Change it once on the server and all versions of apps in the wild conform.
Cons: You have to build the server logic. If you're more comfortable with ObjectiveC this may be an issue. You have to maintain the database of voting topics and devices that have voted.
2) Handle the code that detects the duplicate vote on the device
The device downloads a list of all the voting topics then filters them by the topics that have already been voted on. When a user votes on a topic then the device adds the id of that topic to the filter list.
Pros: No database maintenance beyond having a list of voting topics.
Cons: Users could remove the app, reinstall and vote again. If you want to change the voting logic (e.g. you want people to be able to vote twice on a topic) you have to update all the existing apps.
Admittedly putting the voting logic in the app makes the app more complex. However that added complexity has to be absorbed somewhere - either in the app or on the server.