If you go here:
http://armygrounds.com/jsgame/server.js
It's publicly visible and anyone could get the DB credentials.
How do I prevent this? Is it a file permission setting?
This is an issue with your webserver configuration. You should not expose your nodejs source to the web. In this case, you want to move the server side code out of the location that is visible from the website. You probably want to set up your web server to proxy to nodejs when it needs to be called.
Its a little difficult to answer your question more accurately without knowing more of your setup.
Related
When deploying a ReactJS + NodeJS application, what do you do about environment variables used on the React-side? Running NPM BUILD folds any secret API keys into the final code, making it visible to anyone who inspects the source code. Moving the .evn information to a .env file located server-side before using the npm build command doesn't solve the issue. I've tried to search around but I can't find any actual solutions.
Thanks!
You cannot make secret keys invisible on the client side. Even receiving it as an environment variable from the server, the keys will be incorporated into the build and will be publicly accessible.
So that your React app is not vulnerable, (correcting: not the only way) a possibility is to save keys and secrets in the backend. That is, the backend is the only one with access to keys and secrets. Client makes requests without storing sensitive data.
Thanks folks, all extremely helpful! I'll be moving the secret keys to the server side and changing the way my code works to compensate the adjustment. The other issue was Google Maps API, which can't be moved in the code but can be restricted to specific IP or URL use in the Google Cloud Platform.
https://cloud.google.com/blog/products/maps-platform/google-maps-platform-best-practices-restricting-api-keys
I am trying to set up NGINX so that it redirects a user either based on whether they are logged in or not.
For example, say the site is https://example.com and a user arrives at this URL, if they are not logged in we want to show a marketing page with register actions etc. If they are logged in, we want to send them right into the product. This is the same model as github, bitbucket etc. We don't use a cookie for managing session state, so trying to detect cookie from NGINX is a non starter, that is managed on the server.
So my question is this. Can anyone recommend some recipes for nodeJS and NGINX that could give me some ideas to follow on how to set this up? Do I need to create something specific at the nodeJS end to satisfy NGINX in order to tell it that the user is not logged in? Or can I achieve this with checks in NGINX? I'm trying to protect the application from the outside world as much as possible which is why NGINX is the choice we made.
I've spend quite a few days trying to figure this out and am still as stumped as when I started so any pointers would be greatly appreciated.
Nginx in this case is meant to serve as a reverse-proxy to your Node application. This is a perfectly fine setup. However the functionality you're describing (check if the user is logged in) is something you need to check at the application-level (Node), not the webserver-level (Nginx).
How you will check whether the user is logged in is dependent on your login system, which we don't know anything about other than that it doesn't use cookies (which is in fact a rather common way to do this).
When I'm connecting to database in node, I have to add db name, username, password etc. If I'm right every user can access js file, when he knows address. So... how it works? Is it safe?
Node.js server side source files should never be accessible to end-users.
In frameworks like Express the convention is that requests for static assets are handled by the static middleware which serves files only from a specific folder in your solution. Explicit requests for other source files that exists in your code base are thus ignored (404 is passed down the pipeline).
Consult
https://expressjs.com/en/starter/static-files.html
for more details.
Although there are other possible options to further limit the visibility of sensitive data, note that anyone on admin rights who gets the access to your server, would of course be able to retrieve the data (and this is perfectly acceptable).
I am assuming from the question that the DB and Node are on the same server. I am also assuming you have created either a JSON or env file or a function which picks up your DB parameters.
The one server = everything (code+DB) is not the best setup in the world. However, if you are limited to it, then it depends on the DB you are using. Mongo Community Edition will allow you to set up limited security protocols, such as creating users within the DB itself. This contains a {username password rights} combination which grants scaled rights based upon the type of user you set up. This is not foolproof but it is something of protection even if someone gets a hold of your DB parameters. If you are using a more extended version of MongoDB then this question would be superfluous. As to other DB's you need to consult the documentation.
However, all that being said, you should really have a DB set up behind a public server and only allow SSH into it, with an open port to receive information from your program. As the one server = everthing format is not safe in the end run, though it is fine for development.
If you are using MongoDB, you may want to take a look at Mongoose coupled with Mongoose Encryption. I personally do not use them but it may solve your problem in the short run.
If your DB is MySQL etc. then I suggest you look at the documentation.
Here I will describe the requirement for my project.
Basically I want to build a chat application which I can embed to different websites for example , site build using wordpress, magento, drupal, custom frameworks ... etc . What I actually need is to embed JavaScript for handling socket chat using (socket.io) on some of the website(wordpress, magento, drupal ....), so what I finally have is a set of javascript code (client side), and a server running in nodejs (with socket.io)
The problem I faced is to manage session for registered users after login. Since my code is embedded on different websites and the node server resides on other server , On each page refresh I faced difficult to validate user session session. Could you please help me how I can manage session in a best way for this application.
If you feel difficulty to understand my need , I can explain in detail with examples
Thanking You
If I understand your problem, you just need to handle user sessions? More specifically on the client side?
Based on the information you give, I will just assume you either return a unique string representing the session on the server to the client. The format of this can either be a cookie, a normal string/token, etc.
For cookies, you shouldn't have much problems, since the browser deals with this. Although you might need to set it up correctly on the server.
For tokens/strings that needs to be returned to the server for each request requiring authentication, you should store it in the session-storage/local storage of the browser, depending on your need. Then you should embed it in every requests back to the server and authenticate it.
Let's say, there is a website for an online diary. Users upload their secrets to the web server and stored in the database. Normally, a user without the password can't see the diary items. However the web admin or DB admin could still can connect to the DB and see everything.
Is there a solution to prevent this? I mean a solution for the whole web application, not only for a single user.
Client-side javascript can encrypt the content, using a key known only to the client and never sent to the server, prior to saving.
However, the server can at any time start serving up malicious JS that would send the keys back down to the server. The only way to make this impossible is to make your application an installable client-side app (via an extension or whatever - but nothing that auto-updates). Additionally, all of this paranoia is pointless unless the user can verify what the app is doing, so it would need to be open-source.
At this point you're basically writing GnuPG, so you might as well just use that.