Here's a security problem I've encountered a couple of times when building small web-based projects interacting with a REST API service. For example, let's say you're building a casual JavaScript-based game where you want a leaderboard of highscores, so you need to post the scores of users to a database.
The easiest solution would be to build a simple web service, e.g. using PHP, Node.js or Python, that accepts GET request and saves the results to a database. Let's imagine the API looks something like this:
GET https://www.example.com/api/highscore?name=SuperGoat31&score=500
Creating such an API for posting highscores has some obvious drawbacks. A malicious user could write a three-line piece of PHP code to spam the database full of false results, for example:
for ($i = 0; $i < 100; i++) {
file_get_contents("https://www.example.com/api/highscore?name=SuperGoat31&score=5000000");
}
So, I'm looking for a way to prevent that. This mostly relates to small hobby or hackathon projects that just need some kind of protection that will prevent the most obvious of attacks, not large enterprise applications that need strict security. A couple of things I could think of:
1. Some form of authentication
An obvious way to solve this would be to have user accounts and only allow requests from logged-in users. This unfortunately has the drawback of putting up a large barrier for users, who need to get an account first. It would also require building a whole authentication workflow with password recovery and properly encrypting passwords and the like.
2. One-time token based protection
Generate a token on the server side and serve that to the user on first load, then only allow requests that serve that specific token. Simple enough, but also very easy to circumvent by finding the requests in a browser web inspector and using that for the three-line PHP script.
3. Log IP address's and ban when malicious use happens
This could work, but I feel it's not very privacy friendly. Also, logging IP addresses would require GDPR consent from users in Europe. Also doesn't prevent the actual spamming itself so you might to first clean up the mess before you start banning IP addresses.
4. Use an external service
There are services that provide solutions to this problem. For example, in the past I've used Google's reCAPTCHA to prevent malicious use. But that also means integrating an external service, making sure you keep it up to date, concerns about the privacy aspects (esp. regarding a service like reCAPTCHA), etc. It feels a bit much for a weekend project.
5. Throttle requests
I feel this is probably the easiest solution that actually works for a bit. This does require some form of IP address logging (which might give the problems stated in 3), but at least you can delete those IP addresses pretty quickly afterwards.
But I'm sure there are other methods I've missed, so I would be curious to see other ways of tackling this problem.
Taking into account all mentioned limitations, I would recommend using a combination of methods:
Simple session authentication based on one-time token
Script obfuscation
Request encryption with integrity control
Example:
let req_obj = {
user: 'SuperGoat31',
score: 123456,
sessionId: '4d2NhIgMWDuzarfAY0qT3g8U2ax4HCo7',
};
req_obj.hash = someCustomHashFunc(JSON.stringify(req_obj));
// now, req_obj.hash = "y0UXBY0rYkxMrJJPdoSgypd"
let req_string = "https://www.example.com/api/cmd?name=" +
req_obj.user +
"&data=" +
Buffer.from(JSON.stringify(req_obj)).toString('base64');
// now, your requests will look like that:
"https://www.example.com/api/cmd?name=SuperGoat31&data=eyJ1c2VyIjoiU3VwZXJHb2F0MzEiLCJzY29yZSI6MTIzNDU2LCJzZXNzaW9uSWQiOiI0ZDJOaElnTVdEdXphcmZBWTBxVDNnOFUyYXg0SENvNyIsImhhc2giOiJ5MFVYQlkwcllreE1ySkpQZG9TZ3lwZCJ9"
For casual players, this allows start playing very quickly, as no explicit registration is required. Upon generation, token might be saved as cookie for repetitive use, but this is not necessary, single-time use would also suffice. No personal info gathered.
However, if short-term storage of some client information is an option, the token might be not just some random bytes, but an encrypted string, containing some parameters, such as random salt + IP address + nickname + agent id + etc. In this case you may start silently ignore certain requests from fraudulent clients upon detection.
Obviously, this would be very easy to crack for a professional, but this is not our goal. When such simple methods are mixed with several kilobytes of logic of the game and obfuscated, figuring out how to deal with it would require significant amount of knowledge and time, which might serve as a sufficient barrier.
As it is all about balance between convenience and protection, you may implement some additional scoring logic to detect cheating attempts, like final score cannot end with '0', or cannot be even, etc. This would allow you to count cheating attempts (in addition to counting forged requests) and then estimate efficiency of implemented combination of methods.
Your list of solutions are mostly mitigations, and they are good ideas if they are your only tools. The list seems pretty exhaustive.
2 major ways to actually solve this problem are:
Remove the incentive of cheating. There's no point submitting a fake score if you are the only person who can see the score. Think about the purpose of why you even want a global high-score list. Maybe there's another way you can reach your objective that makes it uninteresting (or undesirable) to cheat.
Have the server completely manage (or duplicate) the game state. You can't cheat if the server calculates the score. For example, if you're modelling a chess game the server can compute every valid move, preventing clients from submitting moves that wouldn't be possible.
It's possible that for your specific case neither are possible, but if you can't adopt either of these strategies you are stuck to imperfect detection mechanisms.
I suspect that a perfect solution will be elusive because two of
your wishes are, perhaps, contradictory:
"You need to post the scores of users to a database" but... "prevent
the most obvious of attacks" without "Some form of authentication."
The most obvious of attacks are those from users without some form
of authentication.
You wish this system to work without placing an undue burden on
your users. You wish to avoid the usual login and password
authentication which can be cumbersome for users.
I think there is a way to accomplish what you want by creating a
very simple form of authentication by the use of a one-time token
based protection. And I would also incorporate IP tracking against
abuse. In other words, let's combine your options 1 and 2 and 3 in
the following way.
You already have implied that you will maintain a database, and that
within the database, user names will be unique (otherwise you couldn't
record unique high scores). Let people sign up freely by submitting
their requested user name, which you'll accept if not already used
by someone prior. Track the sign-up requests by IP address to detect
and prevent abuse: too many sign-ups from one IP address within a given timeframe. So far, the burden is all at the server end, not on the user.
When you process a valid sign-up (i.e. new user name) into the
database, you will also generate, record into the database, and return to the user a shared secret (a token) that will be used by the
Time-based One-time Password (TOTP) algorithm.
Don't reinvent this.
See:
Time-based One-Time Password
FreeOTP
OneTimePass
When you return a token to the user, it will be in the form of a "QR Code"
QR code
which the user will scan and store with his "Google Authenticator" or
equivalent TOTP application.
When the user returns to your web site to update his high score, he
will authenticate himself using his Google Authenticator" or
equivalent TOTP application. These are often used for "second factor"
authentication, 2FA (Multi-factor authentication), but because
of your need for less strict security, you'll be using the TOTP
authentication as the primary and only form of authentication.
So we have combined a form of authentication which doesn't place a
very high burden on the user (apps already widely available and in
use), with one-time token based protection (provided by the TOTP
app) and a little bit of IP address-based abuse protection for the initial sign-ups.
On of the weaknesses of my proposal is that a user may share his
TOTP token with another person, who may then impersonate him. But this
is no different from the risk of password sharing. And there will
be no "recover my lost password" option.
I would tackle this in a slightly different way: usernames/gamertags. Depending on how frequently you find gamertags and usernames sharing the same IP. So if you only accept a maximum of, say, 5 gamertags per IP, and you also throttle the frequency of updates per gamertag, you have a fairly spam-resistant system.
I would recommend a mix of code obfuscation and using web sockets to request the score, rather than post the score. Something like socket.io (https://socket.io/) where the server sends a request with a code in it and your game responds with the score and that code changed in some way.
Obviously a hacker could look through your code for how your game responds to requests and rewrite it, which is where the obfuscation is important, but it does at least hide the obvious network traffic and prevents them posting scores whenever they feel like it.
I would suggest using reCAPTCHA V2.
Admittedly, v3 provides better protection, but it is hard to implement, so go with v2.
Come on, it is just a few lines of code.
How it should work (according to me):
You are at the main page willing to play the game
You solve the reCAPTCHA
Then the app sends a one-time token with a script tag which establishes a websocket request with your server (using socket.io) with the one-time token and then it is destroyed immediately (from the server as well as the client) after establishment of a connection
Your server validates the token and accepts the request of websocket and then it will send the HTML content
Just create a div and set the value using obj.innerHTML
You can use styles in body (I guess)
And the most important point is obfuscating your code.
Security
Websockets are harder to reverse engineer in a test environment
Even if they create a web socket, it won't respond, because they don't know the one-time token
It prevents script blocking (as the script loads everything on the page)
It provides real-time communication
The only way out is to somehow get your hands on Google's reCAPTCHA token which is impossible, because it means going against Google
You can’t reuse any token (however immediate it be), because it was destroyed from both the sides
One more last tip: set a timeout for the one-time token to about 15 seconds
How will it help? It will prevent someone (extremely malicious) from pausing the Chrome debugger and get the token and put it in their stuff as 15 seconds is ok for slow networks also, but not a human
I'm trying to make a user log in just once, and have his information on all the servers. Any changes made to the user's information will instantly be available for all servers. Is this possible to do without having each user "log in" separately for each server?
Sort of like the $_SESSION for php, but for Node.js
Design 1 -
What I think would be best to do, but don't know how to share socket data between servers, perhaps using something like PHP's $_SESSION?
Design 2 -
What I'm currently doing:
User uses socket.emit to main.js
main.js adds user information onto the emit
main.js emits to the appropriate server
Appropriate server emits back to main.js
main.js finally emits back to user
This seems awfully inefficient and feels wrong
If your information is primarily static, you can try something similar to JWT. These are cryptographically signed tokens that your authenticating server can provide and the user can carry around. This token may contain information about the user that you want each server to have available without having the user accessing it.
If it's not, you may be looking into sharing a database across all servers, and have that be the point of synchronization between them.
Updates based on our comments (so they can be removed later):
If you decide to use auto-contained JWT tokens, you don't need to be making trips to the database at all. These tokens will contain all the information required, but it will be transparent to the end user that won't have insight into their contents.
Also, once you understand the JWT standard, you don't necessarily have to work with JSON objects, since it is just the serialization approach that you can switch by another one.
You'd provide one of these tokens to your user on authentication (or whenever required), and then you'd require that user to provide that token to the other servers when requesting information or behavior from them. The token will become your synchronization approach.
This question has cropped up a few times in various guises, but I've not seen an answer that satisfies my requirement or fills me with much confidence. Let me set the scene.
We currently have a web application, which allows users to submit responses to pre-set questions where the data ends up in an SQL Server database, we also have a Windows application that does the same thing but works in an offline capacity; i.e. it connects to the SQL Server, downloads the questions, allows the user to complete them offline and when they next have a network connection they can synchronise the data, uploading it to the SQL Server. Great!
As part of our development strategy, given HTML 5's offline capabilities and local storage,it seems perfectly sensible to attempt to consolidate these products into a single web application. This would mean we're able to work on a single code base, and this would also enable the application to run in a browser on most devices; platform independent.
Looking into this I see a couple of potential problems, I'd really appreciate a steer on these:
Users need the ability to login, in offline and on-line modes. This could mean we download the hash's of the all users usernames and passwords, or just those that have logged in whilst in on-line mode. However, even doing this there needs to be a way to check these and given that the Javascript is readable someone could easily reverse engineer their credentials. Yes you can obfuscate the code but this isn't infallible.
The data that needs to be stored locally could be highly sensitive; contain personal information etc. Therefore this also needs encrypting, at minimum AES 256.
Am I hoping for utopia? Is this something that's just not possible at this time? Do I need to be looking at another solution and dismissing this for the time being?
Any help from you lovely people would be much appreciated.
First the easier question 2: that is perfectly possible. You can generate the key on the device and on sync send it via https to your server which can decrypt the data then.
As for question 1 I'd say an offline login is not really feasible BUT do you actually need one? Once the questionaire is downloaded (which requires online mode, so requiring login is fine) you only need to transmit it on sync, where online is again required and you can ask the user for his login there, too. I'd not recommend to download any sensible user data (e.g. hashes) to the device.
What you can do is to cache the current user only after logging in online. This would mitigate the risk of enumerating the users in your local DB.
You then need to encrypt the user's data on the front-end, I'd go with a library that does the job for you (for example, RxDB). RxDB accepts a password (which you can generate on the fly) and based on it, encrypts your DB data. The user then fills in the form (does whatever he wants) and if all of the sudden the internet is gone, the user is still able to continue his work and that work must be added as pending requests in order to do the sync. (which you already have)
When the internet is restored, you're going to check whether the session has expired for the user and if so, prompt the user to log in again and do the sync if it was the same user. If it's still there, perform the sync.
My advice based on my personal experience for the offline part.
You can create a local variable that allows the user to login once using internet for the first time then he will be able to auto login for several times as much as you decided in the local variable and when the value is 0 he will need an internet again to get another offline access for the same value you decided before.
so, in a small words. offline counter that will need an internet Only after many offline logins (when the counter decrease to 0)
Flowcharts
So I'm writing a game client using WebSockets. However, I want to prevent people from cheating and sending certain data to the server. Can people modify the html and javascript on the page to change what data is sent to the WebSockets?
If so, how can I prevent this from happening?
This is the big thing about "cheating" and "hacking" in (multiplayer)games. Data that comes from the client (and sometimes even the server) can never be trusted.
Think about a "teleport hack" in a shooter game. Your client is sending your players new position to the server, as soon as you move. If you want to cheat, you can simply manipulate your client to send the coordinates of the position you want to teleport to.
Now there are two possible outcomes:
1) The developers did not care about cheaters, when coding the server side application. The server accepts the new position, although it is impossible that your client moved to that position since the last position update.
2) The developers were smart and wrote an intelligent server. Before accepting the new coordinates, the server validates if it is possible that your player moved to the given location since the last update. If it is, the server accepts it. If it is not, you get banned for the next 1000 years.
I'm currently building my first website just for practice. I threw together a quick game of pong in HTML5 and javascript. I was wondering how I could go about turning it into a networked game.
Is there anything stopping me from say, logging a user into my site, storing their information in a sql database, then looking for another person logged in and waiting to play my game. To handle the networking could I just create a sql database and use AJAX to post new information to a table that specifically handles networking?
here's a visual example of what i've been brainstorming:
[sql table: network]
[logged in user: Josh] [Josh paddle position Y]
[logged in user: Tim] [Tim Paddle position Y]
Use Ajax XMLHttpRequest to post Josh paddle position Y and Tim Paddle Position Y
to the network table, updating each client's screen accordingly (maybe use XMLHttpRequest.responseText to get the other person's information)
delete network table when both users have left the game
Anyway if you don't think this method would work, could you point me in the right direction maybe? I'm still very new to web programming, so maybe i've miss understood the way Ajax works. How is networking normally done when it comes to web applications?
There are several problems with your approach:
Can you update paddle position as fast as user moves it? Network communication have lags, DB requires time to update it's data.
Even if for few users it isn't such a problem, for many people it will become really painfull to handle with all this amount of user's requests.
How do you notify one user about another one actions? In your scheme you should ask server very frequently to get updates. This increases overall load.
The solution could be a peer-to-peer connection, but JS doesn't support it for now.
To post updates and get notified about them you can use persistent connection: instead of reestabilishing connection on each query you just do it once and then use it for bidirectional communication. Additional benefit from this is escape from need of polling server about updates.
See a Server push article on Wikipedia.
Also using DB may be unresonably costly. In fact for each game all you need is several variables that will be deleted when connection will close, so you can just store them in memory.