I'm making a simple star rating feature in PHP to my site and my general question is, do cookies prevent people from spamming multiple votes?
As far as I know I can store a cookie with javascript and PHP. What's to prevent the spammer from testing the feature, looking at what cookies are saved and then remove/add them in the spam attack script?
A sub question would be, what should I save in the cookie? That the person has already voted? What's to prevent the spammer from automatically delete all cookies before a spam attack?
So far I've got honeypot, secret code calculated by time and some other things and IP blacklisting.
I will try to stay out of captchas and recaptchas.
Here's the fact: At the worst possible case, a user may get an entire new computer to cheat your system. And there's nothing you can do about it. So no matter which client-side protections you have, they can be broken.
Cookies are trivial to reset.
Sessions rely on cookies, hence, trivial to reset.
IP is easy enough to reset (or use a VPN or some other such service), moreover, mobile devices change IPs as you walk down the street.
The only real way is to authenticate your users (i.e. a login system) and only allow for authenticated users to vote.
Note that a Cookie will probably work for 95% of the cases, if you don't care the occasional cheat here and there. If cheating must be prevented at all costs, you need an authentication system.
Looks like you are talking about anonymous / unauthenticated users (guests) - because if it's logged in users you can validate on server-side much more easily (e.g with Zanderwar's answer on sessions).
I'm sure you already know this rule, but in case you don't know:
Don't do security validations on client side - you never know what browser, mobile or client the user is using. It's very easy to strip aside client side validations, spoof REST variables, encode/decode, replay transactions etc on the modern clients. So don't do security validations on clientside. Client side validation should only be used to enhance the user experience, and proper security validation should be done on server side only.
For unauthenticated, anonymous users I would restrict submissions by IP and time. E.g per IP they can only submit once per hour. You will have to record the IP and time on serverside and reject (or just update) submissions that are too frequent.
This is the simplest solution to your problem I can think of.
There is no way to prevent spam with cookies or sessions. Any time you spend on this concept will be entirely wasted.
That doesn't mean that the session control can not be useful but it can not by itself prevent an experienced user from anything.
Voting sites usually rely either on an authentication system or the client's IP and time stamp to limit users.
Using the browser string together with IP would make it harder but you run the risk of preventing multiple people behind the same firewall (same IP) from voting if they have very similar setup (as you could have in an office)
Aside from that login is another option but could be circumvented by creating multiple accounts.
But preventing multiple votes is always a problem unless you have an existing verified identity of the visitor.
It will never get a full protection without using Captcha or any other anti-bot protection as long as you give guests to use this feature.
The closest you can do, is to block by User-Agent + IP if they vote to much in a certain amount of time.
Another thing, you can do is to find a workaround using JWT authentication. It's a nice tool for client side session management.
Also, you can try and implement a CSRF protection. For example, you can create a unique token when loading the page of the vote, and when a user clicks on one of the stars, the system will send this token along with the vote rating.
But, again, there is no a bulletproof solution for your problem.
Related
I have a website where your able to advertise things on my website. The problem is that people are able to do it more than once. Is there a way that people are allowed to visit the website and when they join back they will be redirected to another page saying you have already advertised. People are still able to use vpn's but i have a way to stop that.
How can i use javascript or php to record the users ip first when the visit the website, But if they leave the website or reload the page they will be redirected to another page saying you have already advertised. Is this to much work?
Technically yes, you could use JS and PHP to grab a user's IP address and work with it in a database but proxies and dynamic IPs would make it a very easy check to circumvent. You can also use PHP to create a persistent cookie to identify the user and his/her actions and see if you're getting a returning visitor who posted an ad, but cookies can easily be deleted.
So it's not that what you're trying to do is too much work, it's that it's fairly easily circumvented and not very reliable. Your best bet is an authentication system that requires a valid login to post an ad, logging what the advertisers do, and creating logic which will disallow spammy behavior based on your logs.
You won't be able to stop abuses by very, very determined users but you can make it harder and make them think twice about whether it's worth investing all that time and effort into spamming on your site when there are bound to be much softer targets, giving you the time to deal with the most egregious cases personally instead of trying to stop a torrent of spammy ads.
You cannot stop people doing that 100% for sure.
if you block their IPs they use proxy.
if you use session they change their browsers or reset it to default.
if you block their hardware like in facebook block hard disk serial again they use vpn servers.
if ..
there is no way bro.
Ask for paying instead of making it for free.
If I placed a javascript game on my website and part of the game asked for user addresses (in order to refer to local landmarks for example) is it possible that some third party might be able to hijack my game to send the user addresses their way?
I understand that javascript is not very secure, but I'm also thinking that no one will be able to hijack my javascript code without hacking my site, so it's secure in that respect.
Am I being naive?
Just asking because I have an idea for a game that I'm trying to think through.
If you consider your user's addresses to truly be a secret, then yes you probably have some work to do:
XSS attacks
You need to be very careful about how you display user input. For example, if I say my name is <script>alert('hello world')</script>, are you actually going to print that out in the website? If so, can then insert their own JavaScript into your application. Here's an example of an XSS attack, and Wikipedia has more information. If attackers can insert custom JS, they can intercept secret user input like addresses or passwords or cookies.
HTTPS
When your web server sends its message back to the user, the message doesn't go directly to the user's computer. It first goes through intermediate computers in a relay race. If attackers control one of the computers in the middle of the relay race, they can modify the server's message and insert their own JS. Once again, the attackers win. To circumvent this, you'll need HTTPS, which is a protocol that among other things encrypts the message. You'll also need something called a certificate; StartSSL sells them affordably.
Note that the attacker doesn't have to be some corporation or government sitting miles away to control an intermediate computer. It could be someone running Firebug on your school campus' unencrypted Wi-Fi network, for example.
But really
A better way to structure your web application is to never send the user address back to your server in the first place. One of the first rules of information security is that it's hard to get right; the more you can rely on other people's work the better. Instead, maybe keep a fixed list of landmarks in the JS code. Or use a public API provided by a service like Google Maps, which already runs over HTTPS.
I wrote a simple demo html (SSL enabled) forms to access some university services thru it. It requires the user to login with his university ID first .
My question is , how to encrypt the logins data even from me the owner of this page ? Is it possible ? so that the user can confidently use this.
You could use HTTP Digest Authentication which does challenge-response authentication and always sends password hashed.
The problem with Digest is that UI for it is ugly and logging out is left up to the browser (you can't have a reliable logout link).
Alternatively you could implement your own challenge-response mechanism in JavaScript, e.g. http://code.google.com/p/crypto-js/
but it's rather pointless, because the user doesn't have any guarantee that you're doing it, and that you won't replace the secure script with an insecure one in the future. As the site owner (or somebody that hacks your site) you could change the script and "steal" passwords at any time.
SSL is good. That's the best real security you can do client-side.
You can ensure that you're storing passwords securely on server-side — hash it with a slow hash such as bcrypt (not md5/sha1) and use unique salt for every password.
From a lot of posts I've seen on the site, logins performed by AJAX or traditional forms are just as secure as one another. (re: Login/session cookies, Ajax and security Ajax login and javascript cookies, is this secure?)
My question(s) is/are:
If I hash the user's password (via client-side/javascript hash
libraries) before I send it to the server, do I increase security from people easedropping?
If I put a form token (one random based, another time based), does that cover CSRF attacks?
Would I have all my bases covered after all this? Would this form be secure?
Actually this could be a major security problem. The reason why passwords are hashed is a means of planning on failure. An attacker might gain access to the data store (sql injection) and then obtain the hash. If you are just logging in with a hash, then the attacker doesn't have to crack the recovered hash in order to gain access to the application.
Replay attacks are also a problem. If I sniff the hash during authentication, whats stopping me from just replaying that request to authenticate?
Protocols that use message digest functions for authentication provide the client with a nonce, which is used as a one time salt. Microsoft's SMB NTLM authentication is a good example, but it has had a lot of problems.
USE SSL, and not just for login. OWASP A9 states that the session id must never be leaked over an insecure channel. After all who cares about the password if you just spill the real authentication credentials a few milliseconds later.
Most people don't implement CSRF protection for login. After all the attacker would have to know the password in the first place, so "session riding" is a moot point.
A slight aside, but in answer to question 3. NO! Also remember that AJAX and standard forms are also just as insecure as one another.
Implementing secure authentication is hard. Unless you are doing it as an academic exercise, i would strongly recommend using the library provided by your framework, if you are lucky enough to have a good one.
You will also need to consider things such as the following, and more.
Implement a suitably random and unguessable session id for use in the session cookie.
Do not allow the session id to be forced.
When permissions or credentials are changed (e.g. because the user has now logged in or out) then
immediately invalidate the session and start a fresh one.
Provide a logout feature, and be sure to invalidate the session upon logout.
Set the cookie to HttpOnly -Preferably require HTTPS and alo set the cookie to secure only.
Consider restricting the session validity to include checking some other information that helps to match the user e.g. user-agent.
Always expire sessions after non-use and do not implement "keep me logged in" by reconnecting the user to their old http session.
Ensure 2 sessions can't have the same session id at the same time
Ensure that all session data is destroyed when a session is invalidated. A new user coming along, may just happen to get assigned a session id that has been used previously. This new session must not have any access to session data that has been set previously against that session id.
If the attacker knows what hashing you are using then they can crack it. And if you want to add a salt you have to send it to the browser and the attacker could intercept it. Using the time as a salt also won't work because there is only a relatively short amount of time so they can solve that as well.
Our company makes the web based application which is priced per workstation.
That means that user/pass credentials should only be used from one particular machine.
Currently what is happening that several users are sharing credentials and we do not have any way to prevent this if they are not doing it concurrently.
The nature on the application is such that user needs to use it once in a while so the inability to work concurrently does not bother the users much and the company loses it's possible revenues.
The application currently is purely AJAX without flash/activeX/Java applets.
The ideal solution would be to read the computer name or IP address of the client with javascript using "Shell.Network" scripting interface.
But this is impossible because of the strict security settings in Internet Explorer. I have to mention that cross browser functionality does not matter and the only browser supported is IE.
Searching google I came across this solution here http://www.reglos.de/myaddress/MyAddress.html but it requires JAVA applet so will not be very convenient.
Are there any other solutions for this?
Your licensing model is not consistent with the delivery model. Change one of them.
Set a cookie on the machine with an id. Retrieve the cookie each time the user logs in. If you see several different cookies alternating for a single user you know you've got something odd going on.
(Of course a single switch may just mean they've moved to a new PC as one off. )
Alternatively, price per usage, 'query' or some other item.
This kind of abuse can probably be detected moderately effectively using the Cookie technique that RichH suggested. At least blatant abuse can be detected quite easily (say 10 licenced users, 100 real users).
But of course, don't lock the user out, just monitor the situation and get your Sales people to call up suggesting that they buy more licences.
We do exactly the same (in terms of licensing and delivery), and I'm sure that you have good business reasons for not changing your model.
Track through sessions per user. Do not allow multiple sessions to a single user. To achieve this you will have to save the session ID into the database and check everytime a user logs in.
To help users who at times have a browser crash and relogin with new session, allow them to sign out their previous session... so you can kill the old session and instead register the new one.
Hope this is useful.
There's no easy answer as your clients (the software) are effectively anonymous and the users are self-identifying.
For IE "locking you out" (I'm hardly an IE expert), but can't the IE settings be set for particular domains? You could simply make it a requirement that the users configure their browsers to give your app superior access.
I don't see any reason why you can't have certain requirements for the users browser (i.e. only IE 6/7/8, these security settings, etc.).