encrypting data on client-side via html5 javascript - javascript

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.

Related

Parse Compatibility and Security

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.

Minimizing data sent between client/server in javascript

I am trying to code a multiplayer game demo in javascipt using no libraries. Everything is going pretty good, but in order to get better performance to move forward I am going to have to try minimize the data I sent over my websockets or I won't be able to do much. I have been thinking about the best way to do this. I am using Node.JS + Express + Socket.IO.
At first I was sending the keyboard state of all the keys from each client to the server and quickly narrowed this down to true/false values for only the keys I was using. But now I am thinking that I should really be doing something like assigning decimal literal values (0, 1, 3, 4) to each possible input state that are allowed (possible combinations of inputs) and simply sending that value to the server.
I have more experience in statically typed languages such as C++, Java, etc. so I know how I would do this in those languages. But basically want I want to know is if I have a small number of possible input states. What is the best way to send this data using javascript on both ends. It will be going into a JSON object. Is there anyway for me to send a single byte?
https://gist.github.com/1437195 No idea if this works but that could the most optimized solution. I've never played with byteArray. I have no clue if they play well with socket.io.

Is there any alternative to obfuscation to make it harder to get any string in javascript?

I use DropBox and I've had some trouble reaching to my files from other computers:
I not always want to login to anything when I'm in a public computer, but I like being able to reach my stuff from wherever I am.
So I've made a simple application that when put in the public folder, ran and given the right UID, creates (still in your public folder) an HTML of all the content in the folder (including subfolders) as a tree of links.
But I didn't risk loading it anywhere, since there are slightly private things in there (yes, I know that the folder's name is "PUBLIC").
So I've came up with the idea to make it a simple login page, given the right password, the rest of the page should load. brilliant!, but how?
If I did this by redirecting to other HTML on the same folder, I'd still put the html link in the web history and the "url's accessed" history of the administrator. So I should generate itin the same page.
I've done it:
alt text http://dl.dropbox.com/u/3045472/validate.png
And currently the page is a textbox and a button, and only if you type in the right password (defined in the generator) the rest of the page (with the link-tree) loads. The fault is that everything (password, URL's) is easily reachable through the source code.
Now, assuming I only want to avoid silly people to get it all too easily, not make a bulletproof all-content-holding NSA certified website, I though about some ways to make these information a bit harder to get.
As you may have already figured, I use a streamwritter to write an html file (head, loop through links, bottom), then it's extremely configurable, and I can come up with a pretty messy-but-working c# code, though my javascript knowledge is not that good.
Public links in DropBox look like this:
Summarizing: How do I hide the URL's ande the password to show them (MAINLY the password, of course) in my source-code so that no that it should require some effort on reading ?
P.S.: It's not that personal, if someone REALLY wants it, it could never be 100% protected, and if it was that important, I wouldnt put it in the public folder, also, if the dude really wants to get it that hard, he should deserve it.
P.S. 2.: "Use the ultra-3000'tron obfuscator!!11" is not a real answer, since my javascript is GENERATED by my c# program.
P.S. 3.: I don't want other solutions as "use a serverside application and host it somewhere to redirect and bla bla" or "compress the links in a .RAR file and put a password in it" since I'm doing this ALSO to learn, and I want the thrill of it =)
Update 1:
The one answer so far gives a perfect way (according to this question) to hide my password.
Now I want a good way to hide the URL's, maby a code snippet of the example URL I gave being composed, and if it's too tricky, maby how to generate it in C#, or anything ?
Update 2:
I thought about maybe making three "obfuscating methods" and choosing them randomly in the runtime. So anyone who figures out how to read one XML, could only read about one third of them, and maybe having a hard time finding the other rest of this third..
Update 3:
Just thought about REGEX, the URL could be neatly crowded by dummy not-url-allowed characters added randomly that would be removed by something like:
regex.replace(url, ^[^\w\d/:-\.%]+$,"")
So the nosy dude should have to be pretty advanced into programming somehow, eh? could anyone tell me if it would work or not ?
Well, as it seems you already know, this is a rather poor choice of security mechanism, but if you insist...
Don't store the actual string in the source. Store, for example, its MD5 hash. Then, when the user types in a password, compute its MD5 hash and compare it with the expected one.
Check out:
MD5 in JavaScript
MD5 in C#
To elaborate on miorel's idea, you can also encrypt the whole page, using password as a key. Basically, encode all content into one big string, ask for the password and decrypt that string. If the password is wrong, it will show loads of rubbish, that is it. Like
content = "encrypted string"
function decrypt(str, key) { your algorithm of choice here }
document.write(decrypt(content, prompt('Password?')))
The only thing you need is a decrypt implementation in javascript - but that's easy to google out, for example here or here.
This also renders the separate 'login' page useless.
Granted, this is akin to asking how you can strip in public without people seeing you, but given that, I'm assuming that the password you are trying to store is the one to DropBox. I suppose you could obfuscate the password and store it in a cookie. That would at least prevent someone from simply viewing the source to see the password, but obviously wouldn't stop someone running something like Fiddler and seeing it.
[snipped server side suggestion]
EDIT: To munge the Urls, why don't you simply build the urls on the fly and have the links call a javascript function to get the url? Your server-side code would populate an array in this function with obfuscated urls and the calling code would simply pass an index into the array. Thus, on viewing the source, there would be no instances of "http" anywhere other than static unsecure links.
ADDITION Ok. now that I have a better bead on the problem, it is easier to devise solution. There are libraries for doing encryption on the net in javascript (e.g. http://point-at-infinity.org/jsaes/) but the problem comes down to key management. Since its javascript, it is going to be public but there are hoops you can devise to make it harder to determine the key. In general, those tricks involve indirection. For example, store a lengthy stream of random characters (e.g. 40-50 or more) that is generated by your C# code and stored in the HTM file. In addition, the C# code would would store into your javascript function an array numeric values that represent pointers into the long stream of text that were used by the C# code to encrypt the passwords (or just the whole url).

Ajax Highscores security

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.

javascript securty: an AJAX call to record the user's screen resolution, is it possible to prevent fake numbers?

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.

Categories

Resources