Just recently I was wondering, how Google manages it with analytics to track the user but avoid any fraud (as kinda everyone could insert that JS into an HTML page).
Can anyone tell me, if they just resolve the Domain on each incoming request and validate if it corresponds to the correct account and comes from a allowed server (by looking up the IP)? If that's not the case, can anyone provide me some Idea on how Google could do this?
Google does not, by and large, avoid fraud at all. They offer an option to automatically filter for known bots and spiders, and apparently they intervened in some fashion against referral spam (which used to be a huge problem but has by now almost completely disappeared at least from the accounts I have access to).
Other than that, as you say, anyone can stick the javascript code into his HTML and send data to your account, or use the measurement protocol and not even bother with JS. Checking server IPs would hardly help (relevant here is the IP of the client and there are too many possible IPs for meaningful filtering).
Of course if you notice wrong data that follows a discernible pattern you can create filters yourself, which is at least gives you some control over what data is removed.
Related
For our web application, we want the client to be as thick as possible, and keep our server as thin as possible. The idea is to give the client all the necessary data, let the user interact with that data in a snappy Javascript application (currently GWT, but we are considering moving to Angular or Backbone). We would like to make the server completely stateless, which improves scalability and memory usage.
A fundamental problem of course is that there is some data a user is not allowed to alter. For example, when doing a password reset procedure, the user cannot change his username, because then he could alter somebody elses password. There is also a boolean that indicates if the user has passed the captcha, we cannot allow him to set that to true. And many other examples can be thought of.
The solution we thought of is the following: Together with these strings that a user cannot touch (we call them the priviledged information), we also add a signature. This is simply the concatenation of the priviledeg info, HMAC signed on the server with an AES key. When the data from the client returns we concatenate and sign the info again, and if the signatures are identical, we know that the client has not touched our info.
My questions: Does anybody see any weaknesses in this scheme, and can anybody point to resources (books, blogs) where more info about this subject can be found?
For anyone finding this question after several years: The thing I suggested was basically the same as Json Web Tokens (https://en.wikipedia.org/wiki/JSON_Web_Token). The idea I suggested was correct, but of course you should use established libraries instead of rolling your own.
I am trying to prevent fraud in a webproject I am building.
The project is a game which includes multiple websites.
Each website does a ajax check for with each pageview to a webpage on my server for a status update of the game.
The response page, lets say www.domain.com/response.cfm (it is coldfusion) normally returns nothing, but at a certain point of time within the games timeframe, it will display a JSON string with information.
This information is then used by the script that is included on the websites.
So website A has been viewed 100 times (all of its pages), which will generate 100 ajax calls.
The problem I have is that a robot could check the ajax destination too, and much faster. Now I can detect a robot, or could make it difficult for him by using a session or checking for cookies, BUT...
the biggest issue is that I found out you can do a lot in the Firebug script console, or the Safari console. Probably Chrome too.
With this console, they can even evade the crossdomain restriction. I created a simple script that does a couple of calls to the Ajax page and when I go to the same domain first, and then use the console...there is no crossdomain limitation. And you execute all kind of javascript, so in essence someone like me could commit fraud in the game by using the javascript console which masks him as regular browser user.
My question now is: Does anyone know how to prevent this? I tried to disable the usage of the console but I don't think I can. It may be possible to detect if the console is active and then disable MY scripts so the game doesn't work. But I think they can load the script source in the console manually and then the game does work.
Looks like console is a beautiful thing, but a nightmare for me now to prevent people cheating in the game I am creating.
Hope anyone has suggestions.
ps: of course I am trying to implement som server side checks to detect cheating, but most of the time it is not realtime.
UPDATE 19/3/2012
The fraud that I am trying to prevent is cheating in the game by polling the page that generates logic for the next step of the game. This is a serverscript page which generates json code which will trigger a change on the website the game is played on. For your information, websites the are involved have a script in there header, like google analytics, so they will communicate with my server every pageview.
Polling that serverpage can reveal information which will gain the cheaters knowledge or progress.
So i have to prevent people from getting knowledge ahead of other earnest players by monitoring the serverpage which will reveal information at a certain time. I don't want them auto polling it and when info is revealed, the send themselves a notifcation and check the website.
So what I will do is make sure that if people have to many pageviews per second, they are blocked. Plus you need a cookie to be able to join in and you only get a cookie by logging in. Hopefully this will give me enough tools to make it as robust as possible.
Thanks for all your knowledge, people.
It would be very, very difficult to disable web consoles across the majority of browsers, and anyone who managed to do this would probably be exploiting a browser bug. But read on...
First rule of web programming: You can never trust anything you receive from the web client. Anything that gets sent to your data might have been forged or altered intentionally or unintentionally, and even if you did manage to block a web console, what's to stop me from opening it in a different browser which specifically disallows websites with the console? So that's out. As #DCoder mentions in the comments, there are other methods as well, including browser extensions, which would allow user-defined JavaScript to be executed.
So any checking you do has to be server side. I know you're trying to do some checking already, and it's hard to give advice without having more specifics. That said, one way to do this, as far as I can see right now, is to issue each client an ID and store that in a database somewhere. They can't be sequential IDs, and make sure that they're not trivially forgeable even if someone has a bunch of different IDs (for example, you might want to salt the username, and then hash it). Each time a request is made to the server, only issue a response if the last request was >500 ms ago, and update the database accordingly. Expire the ID after logoff or some time.
The first thing you should think about is securing your server, not the client. It's impossible to hide client code from the client. While it might arguably help prevent a few people who want to cheat from cheating, it's not your primary objective. You have to do this from the server side. This means validating the requests on the server to ensure that they conform to your expectations to some degree.
Game companies will
Require user authentication of some kind so they can identify users
Create some rules about possibilities. For example, the laws of physics should apply, so you know when someone has cheated. Something they can validate as human activity.
Ban people who cheat
If you are not sending data continuously over the network, then you have an issue which is unsolvable unless you are willing to make checks on the server securely and continuously over the course of the game. This will increase server load, but that's the unfortunate cost of preventing cheats.
I've been looking for better ways to secure my site. Many forums and Q/A sites say jquery variables and HTML attributes may be changed by the end user. How do they do this? If they can alter data and elements on a site, can they insert scripts as well?
For instance I have 2 jquery scripts for a home page. The fist is a "member only" script and the second is a "visitor only" script. Can the end user log into my site, copy the "member only" script, log off, and inject the script so it'll run as a visitor?
Yes, it is safe to assume that nothing on the client side is safe. Using tools like Firebug for Firefox or Developer Tools for Chrome, end users are able to manipulate (add, alter, delete):
Your HTML
Your CSS
Your JS
Your HTTP headers (data packets sent to your server)
Cookies
To answer your question directly: if you are solely relying on JavaScript (and most likely cookies) to track user session state and deliver different content to members and guests, then I can say with absolute certainty that other people will circumvent your security, and it would be trivial to do so.
Designing secure applications is not easy, a constant battle, and takes years to fully master. Hacking applications is very easy, fun for the whole family, and can be learned on YouTube in 20 minutes.
Having said all that, hopefully the content you are containing in the JS is not "mission-critical" or "sensitive-data". If it is, I would seriously weigh the costs of hiring a third party developer who is well versed in security to come in and help you out. Because, like I said earlier, creating a truly secure site is not something easily done.
Short Answer: Yes.
Anything on the users computer can be viewed and changed by the user, and any user can write their own scripts to execute on the page.
For example, you will up vote this post automatically if you paste this in your address bar and hit enter from this page:
javascript: $('#answer-7061924 a.vote-up-off').click();
It's not really hacking because you are the end user running the script yourself, only doing actions the end user can normally do. If you allow the end user on your site to perform actions that affect your server in a way they shouldn't be able to, then you have a problem. For example, if I had a way to make that Javascript execute automatically instead of you having to run it yourself from your address bar. Everyone who came to this page would automatically upvote this answer which would be (obviously) undesired behavior.
Firebug and Greasemonkey can be used to replace any javascript: the nature of the Browser as a client is such that the user can basically have it do anything they want. Your specific scenario is definitely possible.
well, if your scripts are public and not protected by a server side than the Hacker can run it in a browser like mozilla.
you should always keep your protected content in a server side scripting and allow access by the session (or some other server side method)
Yes a user can edit scripts however all scripts are compiled on the user's machine meaning that anything they alter will only affect their machine and not any of your other visitors.
However, if you have paid content which you feed using a "members-only" script then it's safest if you use technology on the server to distribute your members-only content rather than rely on the client scripts to secure your content.
Most security problems occur when the client is allowed to interact with the server and modify data on the server.
Here's a good bit on information you can read about XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
To put it very simply:
The web page is just an interface for clients to use your server. It can be altered in all possible ways and anyone can send any kind of data to your server.
For first, you have to check that the user sending that data to your server has privileges to do so. Usually done by checking against server session.
Then you have to check at your server end that you are only taking the data you want, and nothing more or less and that the data is valid by validating it on your server.
For example if there is a mandatory field in some form that user has to fill out, you have to check that the data is actually sent to server because user may just delete the field from the form and send it without.
Other example is that if you are trying to dynamically add data from the form to database, user may just add new field, like "admin", and set it to 1 and send the form. If you then have admin field in database, the user is set as an admin.
The one of the most important things is to remember avoid SQL injection.
There are many tools to use. They are made for web developers to test if their site is safe. Hackbar is one for example.
I have a donation form which users fill out and I would like to then send the user to the charities own website with their information already filled in. Is this possible?
thanks
This is a big part of what my company does....but we have to rely on the client as well. It could be a great exercise for both you and them.
Here's the basic idea. We take a web form entry from a site. We have a script that processes the information and decides where to route the info (we do this for quite a few different clients) Then the system goes through logic for each individual site (functions in a class) that tells it how to pass the information over. In some cases, it's simply an email to a person. In other cases, we CURL a string over that the recipient site has been setup to accept. One site allows us to directly post to a "hidden" page on their site....this doesn't seem the most secure option to me, though. The key is to negotiate with the partner how they'd like to receive the information. If you're helping them get donors, I suspect they'll be willing to do anything they can to help.
Be aware, there could be some security issues with trying to forward donation information across sites....you'll want to remain as secure as humanly possible....and personally, I don't think I'd ever transmit something like a credit card number except to a processor via SSL.
I was a non-profit webmaster for quite a few years, and still have several non-profit sites I consult with. There's systems out there just for this purpose (one that comes to mind is network for good) Also, I've seen groups build non-profits specifically to accept donations on behalf of other non-profits. Point being, there's many different ways to approach this task, not all of them even code related.
For the longest time I was considering using a Javascript bookmarklet to generate the passwords for the different sites I visit to avoid the problem of "similar passwords everywhere", yet still be portable. However, after reading this paper it became clear to me that using this method would mean that a single malicious page could compromise my whole security.
Now I'm pondering the following solution: a bookmarklet, which would only do one thing: open an URL in a new page with the original URL appended (for example http://example.com/password_man.html?url=slashdot.org). The script located on the page from example.com would do the actual password generation.
Does anybody see any security problem with this approach? While it is less convenient than the original one, as far as I can see, even a malicious page could only see the password it gets and would not have access to sensitive information like the master password. Am I correct in assuming this?
More clarifications:
The generating of the password will be done entirely client-side. The "password_man.html" mentioned in the example above will contain javascript code similar to the one already contained in bookmarklets and it will contain an entry field for your to specify the master password
The interpretation of the "url" parameter will also be done client-side. I'm thinking of hosting this file as a particular revision on my google code account (ie. v1234 of password_man.html), which would provide assurances that I'm not changing the page underneath the users
Also, HTTP/HTTPS is not an issue, since all the processing is done by the client browser, no data is sent back to the server. You might argue that a MITM attack could modify the page so that it sends back the generated password for example (or the master password for that matter) in the case that you are using a clear-text protocol (like HTTP), but if you already have a MITM situation there are other avenues of attack which are easier to do (for example: snooping the password from the request which is submitting it, or snooping the session id, etc)
Update: after searching around and thinking about the problem, I concluded that there is no way this can be done securely within the same page. Even if the bookmarklet would only capture the domain and open up a new window (via window.open), a malicious site could always override window.open, such that it would open a copy of the page which would actually capture the master password (essentially perform a phising attack).
supergenpass sounds very similar to what you're proposing to make.
If requirement for being implemented as bookmarklet is portability, there are existing multi-platform password managers. For example, I'm using Lastpass, it supports all major browsers, also works in Opera Mini, also comes in bookmarklet form.
You may want to pass in a passphrase also, along with the url, that way there is two things that must be known in order to regenerate the password.
If you pass in just the url and it always goes to the same password then only one person can use this application.
The odds that two people will use the same passphrase is unlikely, and you can use the same passphrase for every site.
If you use an https connection then it would be more secure from snooping.
I believe you have some usability issues with your approach, and if you use http connection then you will also be vulnerable to snooping. The fact that someone can get the password by knowing the url means that this is more vulnerable than using the same password on each site, IMO.
Update:
Due to the clarification my answer changes.
Basically, in javascript you can have private members, so that other code can't see the values, unless something like firebug is used, but then the user is the one looking.
This link will help explain this more:
http://www.crockford.com/javascript/private.html
If you put the master passphrase and all related information into here, and do the password generation then no other javascript code can get that information, as you will create setters with no getters.
This should enable you to have a secure password generation page.
If you don't mind a Firefox-centric solution take a look at Password Hasher. There is "portable page" option that allows you to generate a page that can be used with other browsers, but I have only tried it with Chrome
The source for it is available here if you want to adapt it for another browser.
Javascripts PRNGs are usually not cryptographically strong: https://bugzilla.mozilla.org/attachment.cgi?id=349768 ; so if you use to generate passwords, other sites might be able to guess the generated password or even influence the password chosen.