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

jkhazraji

Active Member
Licensed User
Longtime User
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?
 

jkhazraji

Active Member
Licensed User
Longtime User
If a user right-click the web page (in Chrome e.g.) , a menu containing “Show page source code” will appear.. A single click will take him/her to the code immediately..
 
Upvote 0

alwaysbusy

Expert
Licensed User
Longtime User
Or you write your code purely on the server side like PHP (=jServer/ABM), or you do it on the browser side (=JavaScript/BANano). Most WebApps are kind of hybrids where all the 'secret' stuff (database, credentials/access and refresh tokens) are on the server side, all the common things (UI interaction for example) are on the browser side for speed.
 
Upvote 1

jkhazraji

Active Member
Licensed User
Longtime User
Thank you for your reply ? . Is there an example, on the forum, of Javascript code made purely on the server side..
 
Upvote 0

jkhazraji

Active Member
Licensed User
Longtime User
I found this post in the forum : https://www.b4x.com/android/forum/threads/abmaterial-b4js-00-introduction.90249/ which I think is yours in a series of toturials on B4JS. It seemed a quite good point to start from for writing JS code on the server side..
BUT ? I quote the following from the introduction:
Having the browser doing some stuff using Javascript can have some advantages by relieving some pressure from your server (checking if a form is filled in correctly, or changing the visibility of an ABMcontainer if a user clicks a button). But it also demands a great resposibility from the programmer not to expose to much information to the user. Never, ever write sensitive stuff like SQL, passwords etc in B4JS!
 
Last edited:
Upvote 0

Erel

B4X founder
Staff member
Licensed User
Longtime User
And also:
Never assume that the client code, client cookies or anything else coming from the client, wasn't hacked, copied, tampered or modified in any possible way.
 
Upvote 0

jkhazraji

Active Member
Licensed User
Longtime User
And also:
Never assume that the client code, client cookies or anything else coming from the client, wasn't hacked, copied, tampered or modified in any possible way.
So, is the lack of secrecy a vulnerability or a limitation in jServer use that can be worked around?
 
Upvote 0

jkhazraji

Active Member
Licensed User
Longtime User
Nothing in this thread is specific to jServer.
jServer code runs on the backend and is secure.
Sorry I meant the use of any relevant tool (like jServer) through javascript to make a web app not the jServer itself.
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
That's true.
You cannot trust anything that comes from the client, including any output of your JavaScript code that runs on the client.
This times 1000. Never, ever trust input from the web. Always sanitize it first before using it. In Perl you can specify a special mode (taint mode: https://www.geeksforgeeks.org/perl-taint-method/) that would not allow you to just use user supplied data. And as has been mentioned above, this has nothing to do with your JavaScript code. Please note: A user does not have to go through your web page in order to feed bogus information to your web server. They can (and do) use automated tools to do that. You can use JavaScript to catch input errors on the client side, therefore cutting down on server side trips for checking input data as the user enters it. But, once the data is sent to the server, you should always re-check the data with server side code. Always.
 
Upvote 0

jkhazraji

Active Member
Licensed User
Longtime User
How would you do that in Javascript?
 
Upvote 0

jkhazraji

Active Member
Licensed User
Longtime User
Obfuscating the Javascript code may help as suggested by a post on this forum:
I tried it it and it worked!!
 
Upvote 0

jkhazraji

Active Member
Licensed User
Longtime User
It's pretty meaningless to obfuscate code running in the browser. Don't do it, it's just a crutch giving you a false sense of security.
So I will try writing the Javascript code on the server side.
 
Upvote 0

tchart

Well-Known Member
Licensed User
Longtime User
It's pretty meaningless to obfuscate code running in the browser. Don't do it, it's just a crutch giving you a false sense of security.
100%

As I said in that obfuscator thread there shouldnt be anything in b4jws.js that is a secret or needs protecting. It is just a JavaScript to communicate with the backend. The backend should implement checks against the users session eg are the signed in, are they who they say they are etc. There is little point is obfuscating javascript as it can easily be decoded.

But seriously, have you looked at the code in b4jws.js? Its 50 odd lines. Its there to do a job which it does. Dont change it. Dont add stuff to it. Dont try and "secure it".

Any event handlers (ie subs in the web socket handler) that it can call need to have sufficient security checks in them. Fiddling with the front end is a very bad idea and is not secure.
 
Upvote 0

TILogistic

Expert
Licensed User
Longtime User
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?
 
Upvote 0
Cookies are required to use this site. You must accept them to continue using the site. Learn more…