B4J Question Is exposure of source code a weak point in web socket or jServer web apps?

[jkhazraji]

Putting a file containing a script code as javascript in a web socket or jServer web app will expose its source code .. How would you be able to protect it?

 

[tchart]

Yo

A question:
If I have access to b4j_ws.js and the javascripts (jquery element) it communicates with the backend via b4j_raiseEvent (websocket).

Are you not unprotected?

You need to define what unprotected means.

Your website should be over https/ssl and therefore the web socket will also be over https. This means the data going to and from the server is encrypted.

That is standard practise. Encrypt data between the user and the server.

b4j_ws is simply sending data over this encrypted channel. So there is little chance of security issues unless someone/something is in the middle - like a proxy.

Encoding, obfuscating etc your JavaScript has nothing to do with how the data is sent to the server.

 

[TILogistic]

Yo

You need to define what unprotected means.

Your website should be over https/ssl and therefore the web socket will also be over https. This means the data going to and from the server is encrypted.

That is standard practise. Encrypt data between the user and the server.

b4j_ws is simply sending data over this encrypted channel. So there is little chance of security issues unless someone/something is in the middle - like a proxy.

Encoding, obfuscating etc your JavaScript has nothing to do with how the data is sent to the server.

I am not referring to the protection of the communication protocol between client and server, it is to the protection of the code that runs on the client.

If you expose your javascripts to the client, you are more likely to know your processing logic and be attacked by XSS.

 

[tchart]

I am not referring to the protection of the communication protocol between client and server, it is to the protection of the code that runs on the client.

If you expose your javascripts to the client, you are more likely to know your processing logic and be attacked by XSS.

Ok we just seem to be going around in circles here. You’ve got advice from many people on the forum here so there is no point repeating what’s been said.

Obfuscation of JavaScript will NOT protect you or your users from XSS.

 

[alwaysbusy]

You can add a filter in jServer to protect from XSS. To close the gate even more, you need the 'Content-Security-Policy' header. But in that case, be prepared to do A LOT of work (hashing all your inline scripts, not use eval anywhere, ...) and avoid using big frameworks like jQuery, Bootstrap, etc... because they do contain unsafe code and will not work if the CSP header is set.

Public Sub Filter(req As ServletRequest, resp As ServletResponse) As Boolean
    resp.SetHeader("server", "Yeah, right!") ' hide the Jetty fingerprint

    ' adding this one (without 'unsafe-inline' 'unsafe-eval') is a real nightmare to get it right.
    ' resp.SetHeader("Content-Security-Policy","script-src 'self'  cdn.jsdelivr.net;")

    resp.SetHeader("X-Frame-Options", "SAMEORIGIN")
    resp.SetHeader("Strict-Transport-Security", "max-age=31536000;includeSubDomains")
    resp.SetHeader("Referrer-Policy", "strict-origin-when-cross-origin")
    resp.SetHeader("X-Content-Type-Options", "nosniff")
    resp.SetHeader("X-XSS-Protection", "1; mode=block")
    Return True
End Sub

Instead of 'Content-Security-Policy', we check anything incoming into the server if it is valid. For example all our url parameters need to be encoded.

https://xxx-yyy.com/MyApp/MyPage/?id=2uvIH3z%2BH24HOB8uJb%2Bxqo8IkeCnyF2Eia2rnu9O48ITpbxIRZAjsQ%3D%3D

You have to live with the fact that, not matter what you do to protect your work, someone will be able to do bad stuff to it IF they really want to. Doesn't mean we have to make is easy for them

Alwaysbusy

 

[TILogistic]

You can add a filter in jServer to protect from XSS. To close the gate even more, you need the 'Content-Security-Policy' header. But in that case, be prepared to do A LOT of work (hashing all your inline scripts, not use eval anywhere, ...) and avoid using big frameworks like jQuery, Bootstrap, etc... because they do contain unsafe code and will not work if the CSP header is set.

Public Sub Filter(req As ServletRequest, resp As ServletResponse) As Boolean
    resp.SetHeader("server", "Yeah, right!") ' hide the Jetty fingerprint

    ' adding this one (without 'unsafe-inline' 'unsafe-eval') is a real nightmare to get it right.
    ' resp.SetHeader("Content-Security-Policy","script-src 'self'  cdn.jsdelivr.net;")

    resp.SetHeader("X-Frame-Options", "SAMEORIGIN")
    resp.SetHeader("Strict-Transport-Security", "max-age=31536000;includeSubDomains")
    resp.SetHeader("Referrer-Policy", "strict-origin-when-cross-origin")
    resp.SetHeader("X-Content-Type-Options", "nosniff")
    resp.SetHeader("X-XSS-Protection", "1; mode=block")
    Return True
End Sub

Instead of 'Content-Security-Policy', we check anything incoming into the server if it is valid. For example all our url parameters need to be encoded.

https://xxx-yyy.com/MyApp/MyPage/?id=2uvIH3z%2BH24HOB8uJb%2Bxqo8IkeCnyF2Eia2rnu9O48ITpbxIRZAjsQ%3D%3D

You have to live with the fact that, not matter what you do to protect your work, someone will be able to do bad stuff to it IF they really want to. Doesn't mean we have to make is easy for them

Alwaysbusy

I like your answer.
And yes, it is another security policy to consider.

 

[Magma]

1) ...You (All - we) must always using SSL certs and methods that will make user login/logout every some minutes (i know that is very bad for webapps the log-in-out)
2) Also checking public ips, for example with iplocation DBs for country, use custom firewall routines that if someone has many wrong password/failures to login will be banned (i have an example here in forum) or Fail2ban for debian/linux solutions
3) It is also good using only one protocol IPv4 (and not IPv6) because will be more easier for fail2ban...
4) Also it is good to monitoring your services... check network use, disk use, bandwidth, clients...

Do not leave anything in luck... There are bad guys everywhere... at any solution small and big i ve made (for custom - exclusive use) + had million of attacks !! not to say billions... every second attack ! Do not leave nothing without big password 20-30 characters ! (not a joke)

 

[jkhazraji]

Some frequent attacks when exposing javascripts.

just to keep in mind.

Cross-site scripting - Wikipedia

en.wikipedia.org

Well , I suppose then whatever you do to secure your Javascript code, it is there for the 'peeking' eyes,

 

[alwaysbusy]

Well , I suppose then whatever you do to secure your Javascript code, it is there for the 'peeking' eyes

Correct, but I do not have any problem with that as there is nothing in the Javascript part of my WebApps that I consider 'unique' or 'special'. All that stuff is safely on the server side.

 

[OliverA]

Putting a file containing a script code as javascript in a web socket or jServer web app will expose its source code .. How would you be able to protect it?

So I will try writing the Javascript code on the server side.

I still don't quite 100% get what the author is looking for. There seems to be a lot of talk about JavaScript on the server side. This is a B4X forum and if you use B4J and jServer, then you'll use B4X on the server side, not JavaScript. That code is not exposed. Any JavaScript you add to the HTML page, be it statically by adding it to the page itself or dynamically via JQueryElement is exposed/visible. But what is the big deal? If there is some processing that you absolutely do not want a user to see, don't do it on the front end. That simple. So @jkhazraji, why not give us an example of insecure JavaScript that you are trying to avoid? Why would it need to exist in the first place? What issues are you trying to avoid (give us an example, concrete, instead of hypothetical).

my question refers to this, check the code with a right click on the mouse option see source code.
https://www.b4x.com:51041/dbutils/index.html ??

And? What do you see as a security risk in this example?

 

[jkhazraji]

So @jkhazraji, why not give us an example of insecure JavaScript that you are trying to avoid? Why would it need to exist in the first place? What issues are you trying to avoid (give us an example, concrete, instead of hypothetical).


And? What do you see as a security risk in this example?

Attached is a small jServer B4J app. If you run it and navigate to the relevant address then right click the webpage , all of the Javascript code behind the web app will be revealed ( which is not a big deal in this example
As shown :