I am new to the Parse. I was going through the docs and some questions that have been answered. But there are still a few questions in my mind.
First of all, I have learnt that the Javascript SDK doesn't work on IE9 and IE8 if the website doesn't have an SSL certificate. Can we still use Rest API to work with those browsers without an SSL certificate?
And my second question is about Javascript and API/SDK key security. I know there were other questions about this but they were mostly suggesting checking for a valid session and limiting some actions for some users. But this still wouldn't stop a user from altering his/her own score(First gets my key and then requests for a session token. Finally makes another request to the scores class and adds himself/herself a million points?). How can I secure my app against such scenarios?
Thank you all for your time and your answers in advance.
In regards to your question about Javascript and API/SDK key security, there's a limit to how much you can do. If you want your app/site to be able to post to Parse, then there is nothing to stop a user from doing the same.
Your best option is to look at Cloud Code, a Cloud Function could be used to verify information before saving, for example you could write a method that takes a levelNumber, score, enemiesKilled, livesLost and runs some checks to see if the score supplied is possible. It could be as simple as this:
// hidden knowledge only known by you, stored in your Cloud Function
var maxScorePerEnemy = 750;
if (score > (enemiesKilled * maxScorePerEnemy)) {
// we have a cheater! CRUSH KILL DESTROY!
}
A more advanced option would be to create some code that creates a temporary token that must be included with the score. It might not stop everyone, but makes it just that little bit harder.
Related
I'm currently redesigning my site - it is a game arcade with over 2,000 flash games. I had the site designed/created for me years ago and I've taken it upon myself to modernise it.
I've come upon a particular problem that I'm concerned about, in the past the site has been attacked by hackers and at one point it was vulnerable to mysql injection, but it's since been fixed.
Here's the problem though - the current site uses excessive PHP. I don't like this so I thought I'd try and reduce a lot of server strain by using javascript where necessary. For instance, it often needs to retrieve a list of games from the database.
I'm using Jquery's post() function to deliver an array of ids to a php called 'get-games.php'
a bit like this:
$.post( "ajax/get-games.php", { ids:ids } , function( data ) {
//create games list with response data
});
What's to stop someone maliciously calling this function with 500 ids repeatedly? There's an obvious answer - in the get-games.php add something like:
if (ids.length > 100) throw an error
But occasionally I might want to retrieve a list of >100 games, perhaps on the admin panel. It just seems a bit limiting and I wonder if there's a better way of approaching this kind of spammable functionality.
There's no magic bullet, sadly, you're likely to have to implement a range of measures, enforced server-side:
Rate limits (e.g., per IP) of various kinds (depends on the patterns of use of your site)
Only allow small requests except from known admin sessions
Possibly lock down the IPs from which admins sessions are allowed
If the UI of the site only allows action X after action Y, server-side deny action X if the session in question hasn't previously done action Y within the relevant time
...and so on. The Stack Exchange system has been playing whack-a-mole with these sorts of things for years (quite successfully), so it can be done, but you'll have to be vigilant and watch the patterns of use on the site for abuses, and then introduce new measures to curtail those abuses...
I recently created a website that has a voting/upvoting feature that uses jQuery's AJAX functions. The catch is: anyone can vote. I don't require visitors to be logged in, I don't track their IP, and I don't even store a long-term cookie. Normally (don't laugh), when a user votes on something, I store the ID of the item they vote for in a JavaScript array. Whenever they try to vote, the script checks if they have voted for the given item recently by checking the array for the ID. If they have, it just gives them an alert dialog. Otherwise, it casts a vote. So it goes without saying that all a user has to do to vote again is refresh the page.
I decided to see what happens if I injected some JavaScript (in the URL bar or a web console), and I wasn't really surprised to find out that voting as many times as you want very rapidly is as easy as:
for (var i = 0; i < 100; i++) { vote(itemID); }
(and that's being nice). I'm not sure why the array isn't stopping it, but that doesn't matter; it will always be easy to exploit this, right? I mean - you could even write a little HTML document with some JS that calls the voting page on my website as many times as you want.
So I want to fix this without too much trouble. Is it possible to create an immutable variable in JavaScript? A constant (though it would really help if there was such thing as a constant that could be changed only once)? The easiest way to fix this to some degree would be to keep the ID-holding array semi-constant: can't be deleted, but can be added to. Any suggestions or solutions or explanations are greatly appreciated.
No, if the users want to cheat by messing with their client-side code, they can do that. This is just like cheat patches for games.
What you are doing now is very reasonable to avoid accidental duplicate votes, if you feel that this is not enough (for example if the votes are really important), you need to take measures on the server-side. Tracking IP or setting cookies also won't work, this relies on client-side cooperation as well. You'd have to authenticate the users and mave sure everyone votes only once by storing something in your database.
I don't know why you don't track the IP, if you track the IP, then you can check if the IP voted the same item before, or if the IP voting too often.
Of course you also need to take into consideration that people might share the same IP to browse to your site.
im building a web app in html5.. basically a form with a time counter and questions and answers.
im looking for a way that the user cannot change the score (that is calculated from the time took to answer the question) via browser debugger or etc.
encrypting the raw data sounds like an options.. but when the data is at dom, the user can change it.
i added some "time checking" in server side.. but still i would prefer some client side protection as well.
any suggestions? thanks
I'm no web pro, but I'd say just stick all the validation on the server side. From what I know about people exploiting MMORPGs, there is always a way to access/change client side data.
What you're asking for is impossible. No matter how you implement it, the user can use debugging tools to alter how the code runs in their browser - or, ultimately, just generate the HTTP POST request themselves, independent of your code.
Well, since you're saying you're using html5, why don't you just use the storage support?
e.g:
var store = sessionStorage.question= new Array();
store[0]="10s";
store[1]="5s";
Now just set that programmatically! It will last for the whole session
Put that in a file and import it and the better-than-average user wont know where to look!
You can also check This Link for a more robust solution
As Nick says, a determined user will be able to get round any encryption scheme you use on the client machine. At most you can make it difficult for them to break. You need to do two things, 1) encrypt so as to make tampering difficult and 2) try to detect any tampering that does occur.
I don't know what is available off the shelf for Javascript, if available then use AES for encryption and HMAC to detect tampering. If you have to write your own then use RC4 for encryption (not as strong as AES but much simpler to code) and a checksum to detect tampering.
One thing you can do to make it more difficult for an attacker to find your encryption key and HMAC key is not to store them in one place. Have two arrays such that the real key is array1 XOR array2. That way the actual key is not explicitly in code anywhere.
I'm creating a tower-defense game in javascript and want to have a high score and other multiplayer interactions. Probably have a couple of players start the game at the same time and tell them how fast the other guys are going and that kind of stuff.
I don't know how flash games send their scores or events to make sure the information that each client is sending is actually correct and not just someone sending incredible scores. I remember a couple of years ago when flash games started having high scores, it was very common to see unreal(hacked) scores and well... that's pretty weird not; so what is the secret here?
People will always be capable of cheating at games... the best you can do is make it difficult to cheat. Scores for old flash games were very easy to rig because the score would be submitted via an HTTP request. Sniffing the traffic would reveal the submission URL and what variables needed to be passed in order to update the score. I hope that it has since changed.
If I were you I would make use of some error checking code that will be passed along with the final score in order to verify that the score is legitimate. The error-checking code algorithm should be difficult to determine from a score (if the person is sniffing it). The javascript should also be arbitrarily obfuscated. This is nowhere near ideal but it should deter a good portion of the cheaters.
The best practice I have seen for this is to do sanity checks.
Record the time elapsed, enemies killed, etc... check the score with the data, and see if they add up.
Its primarily though obscurity these days. You would generally assign a unique token per game, and form some kind of hash of the score and token and validate it on submission (or continual submission, validation and token-switching throughout gameplay).
It will be a lot harder for you to do via javascript.
Use a combination of the following tools which are used to commonly prevent fake score and progress reports.
Obscurity - compress and obsfucate the logic that calculates the score string. Distribute it and make it difficult to reverse engineer.
Randomly changing keys - When your game begins, let the javascript request a key which can be used to encrypt the string containing the high scores, etc. The server should also have the private key which will allow you to decrypt the message.
Sanity checks - While a user might change the score, make your requests also contain the number of kills, etc, which are known bounds. The server will check the hashes and make sure that the data is valid.
Consider using a comet server - Since you'll be feeding realtime data to both clients, you'll be better off using a comet server like Orbited or Jetty. This will enable streaming without crashing your server.
Make it frustrating. 'nuff said.
This is a javascript security question: suppose a page finds out the screen resolution of the computer, such as 1024 x 768, and want to use an AJAX call to log this data into the DB.
Is there a way to actually prevent fake data from being entered into the DB? I think whatever the HTML or Javascript does, the user can reverse engineer the code so that some fake numbers get entered into the DB, or is there a way prevent it from happening totally? (100% secure).
Update: or in a similar situation... if i write a simple javascript game... is there a way for the user to send back the score by AJAX and lie about their score?
If you start with the assumption that the user you are communicating with is malicious, then no; there is nothing you can do to control what data they pass you. Certainly not with 100% certainty - in the worst case, they can use network tools to rewrite or replace any "correct" content with whatever they want.
If you just want to prevent casual maliciousness, you could obfuscate or encrypt your code and/or data. This will not deter a determined attacker.
If you actually trust the real user, but suspect that others might try to impersonate them, you can use other techniques like a dynamic canary: send the user a random number, and if they return that same number to you, you know that it really came from them. (Or you're being hit by a man-in-the-middle attack, but hey; that's what SSL is for.)
It's not possible to stop users from sending any numbers they like back from JavaScript.
I think the best you could do is do some sort of check on the server-side to make sure the numbers sent back look like a realistic resolution.
I'm not sure why someone would spend the time to spoof those numbers in the first place though.
Yes, you are correct. Since you're using client-side code, you have to tell the
user's computer (and thus the user) in one way or another, whatever encryption or obfuscation you're using. There's no way around it.
For the resolution, it would basically be impossible to determine if it's valid resolution. My resolution is usually sent to the server as 5120 x 1600, which seems pretty unrealistic, but it's because the 2 screens are often sent as 1. Otherwise, there is a such a huge variety of possibilities in screen resolutions and screen configurations, you'd probably remove a lot of valid ones, although they might be few.
For the game score, you could do additional checks that make it more complicated to check. Things like sending multiple notices of the score throughout the game and requiring X number to ensure that the score received is valid. (IE, must receive one between 200-300, 400-500, 700-800 and then the final score of 1000.) With the final score, you could also have some kind of encrypted value that can only be used once or that contains some data with a CRC on it. Basically, in the end, require receiving other data than just the score, especially for higher scores.
To attempt an answer by elaborating on comments made by Dok, and yourself, there is a clear distinction between manipulating an application to 'cheat' it out of something, whether it be an online business to get something cheaper or a MMPORG to get more experience, than manipulating it in such a way that it renders the interface incorrectly and diminishes the overall user experience for that particular (hacker?) user.
Your time would be better spent focusing on other aspects of your site. I don't recommend the users of my site manipulate the HTML to make it look funny on their machines, but I'm not going to go all out and obfuscate my server output to stop them from hurting themselves. In your case, range checking against pre-defined safe values, making use of the DB, to ensure the user is viewing with an 'allowed' resolution puts unnecessary burden on your application, and takes time to do.