Is every client-side language more vulnerable?

Question

With web browser plug-ins like Firebug, it is easy to manipulate the source code of client-side language such as HTML and JS. Then are those languages more vulnerable than server-side ones ?

When one is building security for his site, is JS alone totally useless ?

Answer 1

This is a issue of who controls the code. Let's leave out that there are some modern framework like node for JavaScript on the server side.

The languages themselves are not necessarily more vulnerable. Most flaws are not results of the underlying language, but of the various logic checks, input sensitization, etc.

That said, you cannot control the code client side, which means that the local user can modify it. It can also be modified by man-in-the-middle attack on the network or by a man-in-the-browser attack where the attacker has compromised the local machine/browser.

On the server side, they would have to break into your server to modify the code. However, that does not mean the code is necessarily more secure.

While you can modify the JavaScript through your code inspector locally, if you did something malicious, you would be doing it to yourself. Just because you change the code doesn't mean it will affect other users. However, you can create attacks against the page request that you then send to someone else which will result in XSS or CSRF. This would result in an attack being carried out against the user. At the same time, you can change the request so that malicious requests or data are sent to the server which result in a buffer overflow or a code injection (e.g., SQL injection).

One of the differences is that you can more easily craft an attack if you have access to the code. Since you can see the source of the HTML and JavaScript, it may be easier to craft an exploit, but that same knowledge might lead to crafting a SQL injection.

Now, to your last point. You should ensure all of your security checks are performed on the server side because you cannot trust client-side validation since it only affects what's going on in the browser. An attacker locally or MiTM can still change the raw HTTP traffic, which would result in your client-side validation effectively being ignored. Client side validation is a convenience for your users and to save some cycles on your server.

Answer 2

It's not the languages themselves that are fundamentally insecure, it's the misuse of them that can be.

Performing input validation with a client-side language only is a bad idea, because anyone can just disable JavaScript or manually send requests to the server containing arbitrary values. For example, attempting to prevent XSS by blocking various characters with JavaScript on the client side won't stop someone from sending a request to your server containing various dodgy characters and markup.

However, JavaScript validation is useful from a user experience perspective because it helps prevent legitimate users from accidentally submitting the form with invalid data, allowing them to correct it before continuing. The important thing to remember is that this should only be considered a convenience, rather than a security measure.

JavaScript and other client side languages may also be somewhat useful from a security perspective when using concepts such as zero-knowledge proof, or when encrypting sensitive user content that server operators should not have access to. This can be useful in scenarios where the application provider might be forced to disclose data via warrant, because data that is encrypted on the client side with a key known only to the user is useless to the requesting party.

The key difference to keep in mind is that anyone can change the behaviour of their own client, so anything sent to you by the client should be treated as untrusted and potentially malicious. Essentially you run into the same problem as DRM does - if you give a user something, it is fundamentally possible for them to alter it and use it in any way they wish, whether you like it or not.