1

Code tempering, i.e. make some code modifications is a serious threat for mobile applications, as you don't have control over a client-side app. Furthermore, accessing to javascript code source is trivial. But is modifying it also easy? How easy is JavaScript code tempering for a mobile application?

Edit: I'm interested in both website running on a server, and client-side application

closed as too broad by Anders, Tom K., forest, Tobi Nary, Xander Apr 27 '18 at 13:49

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Are you worried about an adversary tampering with the JS code that other (innocent) users receive and execute, or are you worried about an adversary manipulating your JS code and running a modified version on their own machine? – Daniel Pryden Apr 26 '18 at 9:57
  • @DanielPryden both, made an edit to make it clear – Kepotx Apr 26 '18 at 10:33
  • 2
    You have to be more precise. Where is this code? Is it server side code for e.g. Node? Or is it JS code for some webpage? Or is it JS run locally in a mobile app as opposed to a website? And who is doint the tampering? Is it a man in the middle? Is it the user herself? What scenario are we talking about here? – Anders Apr 26 '18 at 10:38
2

Assuming you are talking about a web-app running in browser because of the tags:

That depends, tampering with JavaScript is trivial, if no precautions are made and that is also true for Desktop/Laptop devices.

The simplest and most important precaution is to use HTTPS, therefore preventing the code from being changed using MITM attack.

Another more advanced ones include SRI, which require hashes of the script to be included in the header or at least a nonce being used. This improves security a lot, as an attacker would have to have significant control of the server to subvert it.

However, if an attacker has full control of the web server, there is currently no way to mitigate such an attack other than checking the script manually every time.

  • sri doesn't protect against someone compromising your server, it protects against CDN copies of scripts going rouge. If someone controls your server, they can update the hash, disable sri, redirect, etc. – dandavis Apr 27 '18 at 12:52
  • @dandavis that is what I said in the last paragraph... – Peter Harmann Apr 27 '18 at 12:57
1

There are a lot of attack vectors to defend against in a modern web application, far too many to cover in depth here.

But here are a couple of high-level points to consider:

First, your server-side application receives requests from a client-side JavaScript application, but it has no way to know whether those requests actually came from an unmodified copy of the JavaScript code, a version with other JavaScript injected into it, or a completely separate custom-built application used by an attacker. Therefore you must never trust any data coming into the server from the outside internet, whether it seems like it's coming from your JavaScript code or not: always verify that it is correctly authenticated and well-formed, for every request.

To avoid attacks like CSRF, you should also ensure that every new request coming in is linked to an existing user interaction (e.g. using anti-CSRF tokens), not coming in "out of the blue".

Remember, you are giving potential attackers all the source code to your client-side application. Nothing that ends up in the JavaScript can be considered secret or secure. Obfuscating your JavaScript is not a defense, but more of a speed bump. (Although it's useful for minification and other purposes.) Don't assume that because mobile browsers don't make it easy to access a JavaScript console, that therefore your attacker won't have access to a JavaScript console on a mobile device (or a browser that pretends to be on a mobile device). If you're serving vulnerable JavaScript to the internet at all, then you are vulnerable, period.

Addressing the client-side part of your question: the only way for your legitimate users to know that they're getting a JavaScript payload from you and not from some other attacker is for them to have already trusted a third party who in turn trusts you. SSL/TLS certificates signed by a widely-trusted CA are the normal solution here, although in some cases you may need more than that, e.g. code signing as well.

Some clients will have compromised their own security (e.g. by installing sketchy browser extensions from who knows where) and you can never defeat those entirely, although in some cases you can detect them. Neither is it really your place to defeat those: if a user has malware on their own device that's really their problem and not yours -- your primary defense against that is the first point above: don't trust the client side code.

Also, all of the above assumes that attackers have no access to your server systems. That's crucial: the only way traffic from the outside world should be able to reach your production servers is by ports you've explicitly opened to the internet (these days, port 80 and 443) and by whatever administration mechanism you use (which should ideally be protected by a strong cryptographic mechanism, e.g. SSH public key authentication, not simply by passwords). Your server-side systems should be kept up to date with all security patches and ideally should be vetted by a competent security professional to ensure there aren't any other vulnerabilities you don't know about.

Finally: all of this is an ongoing process. Today's web is filled with drive-by attackers. You should expect that maintaining and protecting your application will be an ongoing cost, not only in terms of money but also in time and energy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.