0
votes

This question came up in our project:

Security now works under HTTPS with a MobileSecurity-Test (XSRF etc) that includes App Authenticity for Android. Our adapters do not require any user/pass auth, so there are no other realms, authentication or login modules configured. The app can call adapter procedures right away after WL.Client.connect.

What is Worklight doing on the server side to prevent server side Javascript code injection attacks?

Details on this type of attack: http://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

In other words, (although difficult) let's assume someone was able to use our APK to create a new APK that was able to fool the Worklight Auth/Security mechanism, are we then vulnerable to a server side Javascript code injection attack?

It pretty much boils down to the question if all parameters for all WL server calls are evaluated and parsed from text into Javascript objects in a maximum safe way and if there is never a chance that the parameter text could be executed as Javascript code on the server?

If so, are there any additional types of possible attacks that the WL Server Javascript implementation is secured against that we might not even be aware of?

1

1 Answers

2
votes

Parameters are received by adapters as string/int/bool/array etc. Adapter framework will never evaluate and execute your params, so unless you explicitly use eval(param) somewhere in your code you're good.

Another piece of protection WL adapter framework has is wrapping adapter response in comment. E.g. if your adapter returns {val:1} the actual response body will contain

/* secure {val:1} */

This prevents JS to be executed even if automatically evaluated by a client, e.g. when loaded from a <script src="...">