Protect execution of Javascript

[Pedro Machado Santa]

Hi all.

I want to distribute a simple game on the web using Javascript and
HTML5 and to keep record time scores on the web. But for that I want
to protect client-side execution of some scripts and Ajax calls.

Does anyone have some thougths/ideas on how can I accomplish/secure
this?

Cheers.

Much appreciated.

 

[Thomas 'PointedEars' Lahn]

I want to distribute a simple game on the web using Javascript and
HTML5 and to keep record time scores on the web. But for that I want
to protect client-side execution of some scripts and Ajax calls.

Does anyone have some thougths/ideas on how can I accomplish/secure
this?

Probably yes. However, the first step in creating a security concept is not
to define how to protect, but to define what to protect from which kind of
attack from whom. ISTM you have yet to make that step.

<http://jibbering.com/faq/#posting>


PointedEars

 

[VK]

I want to distribute a simple game on the web using Javascript and
HTML5 and to keep record time scores on the web. But for that I want
to protect client-side execution of some scripts and Ajax calls.

Does anyone have some thougths/ideas on how can I accomplish/secure
this?

What exactly do you mean by "protect"? Make it not possible to view
the source code on the page? Make it unavailable to other program
running on the page? Something else?

 

[Pedro Machado Santa]

Probably yes.  However, the first step in creating a security concept is not
to define how to protect, but to define what to protect from which kind of
attack from whom.  ISTM you have yet to make that step.

Concisely, I want to protect fake score submission, either by using
javacript console to run calls/commands and by altering the code and
running it locally and thus submit fake scores, from players with
hackers skills wanting to figure on a top ten.

I thought of a possible solution wich was to send to the server the
game state in each play - or in my case in each frame, since it's a
racing game - and run the game and validate the "trajectory" on the
server, but I was wondering if there was a less call intensive way to
accomplish this.

Right now, I think that the most cost effective - even though not high
but reasonably secure - would be to, on a game start, send to the
client some sort of random key that would be used to verify game
condition calls, and somehow hide that key from the user.

Thanks for your reply Thomas.

Cheers.

 

[Pedro Machado Santa]

What exactly do you mean by "protect"? Make it not possible to view
the source code on the page? Make it unavailable to other program
running on the page? Something else?

I want to protect unwanted arbitrary execution of server calls by the
user/hacker so everyone plays - and could be rewarded - on (the most)
equal set of conditions.

I think that making the source code not visible it's a very weak way
to secure the game because Javascript is plain text and I don't know
of a proper way to do that "cloaking".

Another way to do that it's make sure that the server calls are only
originated from the javascript code, and not from any type of console,
and to make sure that the Javascript wasn't altered - I was thinking
if I can use some sort of hashcode to do that.

Thanks for your reply VK.

Best regards.

 

[VK]

I think that making the source code not visible it's a very weak way
to secure the game because Javascript is plain text and I don't know
of a proper way to do that "cloaking".

Right. I mentioned this option only to say - you would confirm that -
that it does not help.

Another way to do that it's make sure that the server calls are only
originated from the javascript code, and not from any type of console,
and to make sure that the Javascript wasn't altered - I was thinking
if I can use some sort of hashcode to do that.

And how that would be implemented? It is easy to store the "proper"
hashcode server-side. But it is as easy to find the hashcode
calculating function client-side and to replace it with
{
// The first statement is fully optional of course.
scoreSubmitAjax.setRequestHeader('Freedom-rulez', 'Ha-ha-ha');
return precalculatedHashCodeOfUnalteredSource;
}

You can write a Java applet with an empty display area of the page
background color of size 11px x 11px (the minimum size implied by
security restrictions) and place it somewhere where it doesn't affect
page layout. Let it periodically monitor the game state by querying
JavaScript functions and variables and submit results to
ServerListener over non-standard TCP/IP packets using DatagramSocket
on a particular non-HTTP port. That's something JavaScript cannot do
by definition. If someone hacks Java code as well, alters it to the
needed way and runtime planted into page then just give him/her that
damn prize - the worked really hard for that...

Just one of crazy ideas of mine... Overall I do agree with Stefan
Weiss.

 

[nick]

I want to distribute a simple game on the web using Javascript and
HTML5 and to keep record time scores on the web. But for that I want
to protect client-side execution of some scripts and Ajax calls.

I think the game would have to use a server / client model where the
game state info is maintained by the server and then pushed out to the
clients.

Say the whole game is this: While you hold the 'D' key, your player's
X velocity increases by 1 game unit per tic every tic, up to a max of
30 units per tic. When you release it, the X velocity decreases by 1
unit per tic until it reaches 0.

Now, you could just let everyone play, and whenever someone crosses
the finish line, their client sends the server 'i won,' the server
sees how long the race has been going and adds the winner to the
scoreboard. Obviously this can be hacked.

The thing to do is have the client always send *messages* to the
server... Every tic the 'D' key is held, client tells server "I'm
moving right." Immediately client uses client-side game physics
routine to move the actor right for visual feedback. When message
arrives from client, server does its physics routine (same routine as
client if client is unaltered) and calculates actor's position also.
When it is done, it calls back to client and the displayed position
based on client physics is replaced with server's calculated position,
which will ideally be close to identical to what the client calculated
(user shouldn't notice the change) if the network latency is low.

Now, if the client tries to cheat and sends the server some crazy
message like "hey, I'm moving at 1000 game units per tic," and even if
their hacked client supports showing this to the user and sending it
to the server, the server will reject the bogus input and the client
can be disconnected or left to suffer with broken gameplay.

 

[Thomas 'PointedEars' Lahn]

[...] Let it periodically monitor the game state by querying
JavaScript functions and variables and submit results to
ServerListener over non-standard TCP/IP packets using DatagramSocket
on a particular non-HTTP port. That's something JavaScript cannot do
by definition.

Nonsense, it can. But an API that provides the capability (such as XPCOM)
and a privileged environment are required.


PointedEars

 

[VK]

[...] Let it periodically monitor the game state by querying
JavaScript functions and variables and submit results to
ServerListener over non-standard TCP/IP packets using DatagramSocket
on a particular non-HTTP port. That's something JavaScript cannot do
by definition.

Nonsense, it can.  But an API that provides the capability (such as XPCOM)
and a privileged environment are required.

I am not aware of XPCOM tools
https://developer.mozilla.org/en/XPCOM_API_Reference
providing the functionality of Java's Datagram and Socket tools:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramPacket.html
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html
http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html

Is there a better documentation than of MDC?