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.).
Related
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.
I would like to capture the "computer name"/"device name" of the user. (Ex: Joes-iPhone) It seems like a nice touch to be able to see what devices have connected with the users login so they can see if there is unauthorized access to their account.
Over and over I see people say this is impossible from a web page for JavaScript, HTML, PHP, etc. Yet when I log into my bank, Facebook, Google. Low and behold, there is every device I've connected with. This means it is most definitely possible.
There was one instance where one of my accounts was logged into by someone and this was a big help in identifying what was going on and I love this feature now. I would like to implement this but am stuck in a city full of dead end roads!
Does anyone have any knowledge of how they are accessing this? Or even theories? I don't care what language or technique.
I'm very curious to see what people come up with. I do have an app for Facebook, so I could see the app accessing it and storing it for the browser site, but I have no app for the bank or Google and I have devices listed in Facebook that were not used within an app, only through the browser. To my knowledge I have never authorized any access to anything beyond what the browser is capable of, so there must be something I'm missing.
Short answer: It's true, it can't be done.
But why not??
Your device name is used when your device connects to your router -- but that's where it stops. Your router doesn't allow that information to be broadcast any further. When your computer/tablet/phone requests a web page, your router is the one actually asking for the page -- and he refers to himself by his public IP, which is shared by all the devices on your LAN.
Second-Best
What can be seen by external Internet entities is your user-agent (the type of browser you're using), which can give someone a pretty good idea of what operating system you're using, and therefore what sort of device you're on (mobile vs. desktop/laptop, Windows vs. Mac, etc.). The user-agent info is available as a string, and can be accessed by PHP via the $_SERVER['HTTP_USER_AGENT'] variable.
The PC name is only accessible through LAN (another PC connected to the same modem/router), if such a request hasn't been blocked on your PC. It is not distributed by browsers.
What browsers transmit is the browser info and operating system as well as the IP address. That's all. Some sites allow you to give a nickname to each machine so you can identify them, and they can then use cookies to remember which is which.
EDIT: The only thing I can see is that they could be using Java or Flash to do it.
I'm having a difficulty with a website for work. Some users of Internet Explorer and Safari are not storing anything in their session / cookies and I need to find a way to store information while they are on the site.
Is there a way with php/javascript/something else to request they add the site to their trusted sites or to allow cookies / sessions at all? Would having a certificate of any kind do this? Does anyone have any other suggestions of ways to do this? It would need to be an array of items to be stored and can't be stored in post / get formats as it involves leaving the page to go to a third party and then coming back to the page.
In case you're concerned, it's all above board in terms of what it's doing. It's all to integrate with a 3rd party system that doesn't allow the flexibility that the site requires when it comes to rules.
For clarification:
The session has been used to store the information but a lot of complaints were coming back from people using internet explorer saying that the rules applied weren't working. These are dependent on information being stored to the session. After testing we found that sessions weren't storing on a lot of internet explorer browsers. To combat this we have tried storing a key to a cookie and then using this to reference a database which stored this information instead. However, we are finding that with higher security settings these aren't working also. It needs to function without having them log in. This is the issue.
--UPDATE--
I have tested and it appears that if a site has an SSL cert applied to it the issue doesn't exist. Will need to confirm but that may be the answer.
I do not understand your scenario as I have never had such a problem where cookies are not saved in IE or safari, these are essentials and default with a browser so there must be some software which is effecting these browsers.
On the other hand, the last case scenario I would save everything in the database which would be more ideal if you are coming and going through third party websites. Which since you are storing an array of items I am assuming you are doing an e-commerce website and you need to go to the payment gateway and come back to continue with the checkout.
If that is your scenario I will go with the database and not the cookies.
I was unable to find a way to help someone change their safe sites to include my site easily but an SSL cert seems to achieve this for me. On testing the site it worked perfectly so long as it had and SSL.
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.
How can i generate unique fingerprint of each client?
I know must use navigator object but some properties like navigator.battery cannot use in this method.
// battery included and unique may change.
var uniqueHash = exampleHash(JSON.stringify(navigator));
How can i generate correct unique fingerprint for each user just using JavaScript and without cookie.
Cross platform and older browser also must be included.
I need list of cross browser supported by navigator.X
Note:
I don't want to generate random hash. i want to generate system base hash for each user and i dont wanna save on Cookie or Storage.
How can i generate unique fingerprint of each client?
Short answer is that you can't. It's impossible to do this for every client. You can get close using invasive profiling of the client, but you'll probably only get a unique identifier in around 90-95% of cases.
and i dont wanna save on Cookie or Storage.
Is there a reason you don't want to store data client side? If you told us what you were trying to achieve then maybe we could suggest a better way to solve the problem.
One route that may be worth looking into is using the Mozilla Persona API. It exposes a navigator.id property for consumption. Getting a unique id from a user is as simple as...
navigator.id.get(function(unique_id) {
alert("this is your unique id: " + unique_id);
})
This has the downside of requiring user authorization
Example: http://jsfiddle.net/aJsL9/1/
Simplest way to keep a session without using cookies is appending a unique hash (maybe a UUID or something similar) to the urls in the page as a get parameter:
/my/fancy/url
becomes
/my/fancy/url?HASHCODE
whenever the server receives a request, it capture the HASHCODE if present, otherwise it generates one, and then append it to all links on the served page.
Please bear in mind that the user can manipulate the HASHCODE and you should take that into account when engineering your application.
Anyway, notice that it's quite ugly in the fancy-url era. Also notice that user tracking is a delicate subject and you might incur into legal problems if you do not properly declare it in the TOS.
EDIT: you cannot track a person across multiple web sites without using cookies in any of their variants (flash, session storage, etc.) and a domain shared between sites. No way, you cannot set a variable or cookie from one domain and access it from another one in any decent browser, otherwise it would be a big security hole.
EDIT: Panopticlick cannot be used as a tracking method as you suggested, because it is based on statistical matching and it is also pretty bad at that (try browsing https://panopticlick.eff.org/ from outside the USA or with the just-released Chrome/Firefox update). It's a good proof concept, but nothing that you can use for this purpose. Also, you would need a whole lot of samples to get statistically relevant results.
EDIT: Browser fingerprint identifying power is weak: many browsers are autoupdating (like Chrome or Firefox) and official builts are very few (20? 40? Maybe a bit more if you count Linux distribution-compiled ones), so you will find a consistent portion of users with the same user agent. Add that there is a pletora of consumer PCs with similar configurations.