I am working on a big team (around 15) for a web application that use Google captcha. As you might know, is necessary a public and a secret key that are associated to a URL.
We have multiple environments where we test our work. Therefore, for have a valid captcha, we need multiple google keys for our captcha.
The problem is when we commit our work, many of us modify this keys and when we deploy it, captcha not works because we have put an invalid value.
I am looking a way to automate this and solve this problem. I have think two ways:
Put them as global variable when we start our nodeJS app, but is a very big string to remember it, so is easy to fail when we write them.
Automate it with Jenkins, bubt I am not sure if is a good practice to add it in this step (I think to make a shell script that replace the value for a value in the code -i.e. CAPTCHA_KEY-).
I don't like any of these ideas, so I am open to hear new options
Add the keys using environment variables on your machine.
A good example of this can be found in this link: Storing Keys
This is also good practice because you should not be committing and pushing the keys to the repo. It is best to add any file with private information to .gitignore so that these keys are not stored with the project. If the project were ever compromised, whoever obtains the code would not have the keys because they would not be stored in the repo.
Related
I would like to share my NodeRed Code in Github as part of an IOT project, however I would like to keep some of my data private (wifi password, database password, etc).
I could manually erase this information, but this would not be very practical, since I would have to do it every time I update the file.
In my python scripts I use os.environ.get to save my passwords and upload to GitHub securely.
¿Is there some way to set up Node-Red to easily push to GitHub without revealing sensitive information?
Node properties can be pulled from environment variables using the ${} syntax. This is implemented by the runtime so should work in all nodes. If the node uses the typed input widget then they should also support environment variables directly.
Details are in the documentation here: https://nodered.org/docs/user-guide/environment-variables
Secondly any node options that are explicitly tagged as credentials are stored in a separate encrypted file _creds.json. By default this is encrypted in a randomly generated key on first run and stored in a hidden file in the userDir, but you can set your own key in the settings.js file.
If you use the Projects feature to store your flows in a git repository then you will be prompted for the encryption key needed as part of setting up the project or when you check it out. Documentation for projects is here:
https://nodered.org/docs/user-guide/projects/
I am using mongoose with MongoDB in a NodeJS application. Right now, in development, I have a configuration (.env) file which stores sensitive information my code needs to run. For example, the MongoDB password & URL, emails & passwords needed to email using the code, etc.
When I put it into production, it would obviously be wrong to upload this configuration file anywhere on the cloud, given the information in it. How can I make it so my production code, hosted somewhere such as Heroku, can access these needed variables without letting undue access to them?
Thanks in advance!
You are right, pushing your env file to production is pretty bad from a security perspective.
The way you would go with storing your environmental variables differs between cloud platforms, but essentially you should get a secure way of adding them through either an user interface or through terminal (You usually find these information easily by looking into your provider documentation).
To store them in a project deployed on Heroku, you will need to:
Log to Heroku
Open the newly deployed project
Head over the Settings tab
Find the section named Config Vars
Click on Reveal Vars
Add your variables in there
And you are good to go!
I'm trying out a yesod applications which I will eventually put up on github or similar.
I will use oauth2 with google which means I have to provide an email and secret token. Which I obviously do not want up on github.
What is a good place to store these in a yesod scaffolded application? I'm hoping to store it in a seperate, config/secret.yml for example, so I can put that into the ignore file of git/mercurial and never commit it.
But i can't find out how to include such a file. Or if such a file already is provided by yesod. config/settings.yml seemed possible, but there's entries there which I would like in github.
So my question is, in a yesod scaffolded application. Where can I store secret keys in a way I can easily exclude it from version control systems?
There are many approaches to this, mostly depending on what flavor of devops/hosting your prefer. One option is to put a dummy value in the config file and override it with an environment variable at runtime (see: https://github.com/yesodweb/yesod/wiki/Configuration#overriding-configuration-values-with-environment-variables). You can also having an extra settings file for production that overrides the values in the default config file, which is how the test suite works. A completely different approach would be to use a system like vault in production and query it for your secure credentials.
EDIT To spell out one of the approaches:
Create a new YAML file with the settings you won't to override, e.g. in config/production.yml:
copyright: This is a copyright notice for production
When you run the application, pass in a command line argument giving the location of the config file
I'm trying to find all of the (javascript) resources located on a specific site.
What would be a efficient way of finding them?
Everything I could think of is bruteforcing every possible name and check whether there's a file with this name at the server, although this isn't exactly that efficient.
Yes you can do this. The thing which you actually want to do is web directory traversal..
It is a kind of web vulnerability which is usually taken in to consideration by the web master so you get 403-Forbidden or 404-Not Found Error. Manual exploitation on this is surely possible with trial and error basis in case u get to know directory that contains .js files. For automation You can take use of Python/Perl for ease of use. I am personally working on a same project targeting the same objective using PHP and cURL. At very present I can not help about any source code but for sure I'll be posting same.
I have a number of SSIS packages that are launched by Windows Services. These packages point to any number of different databases, and the connection information is known only by the service at run-time.
I know that I can't save connection strings inside the package, but it seems that I can't even pass in a complete "connection string" as a variable; when I do, the package errors out and it appears that the password is removed.
What I can do, however, is pass in the parts of the connection string that I need and then re-assemble them into a working connection string. I do NOT want to do this; it seems sloppy and ill-advised.
Anyone have any thoughts on how to accomplish this?
You can save XML package configuration files. They too will strip out the passwords, but you can add them in by hand. I just keep them on a secure location on the servers, since they are XML, and the passwords are not encrypted. Anyone who can get to XML file can get to the database on that server anyway.
When you're creating a job to run the package, you can specify the config file to use and its location. If you're developing, the config file is on your computer. Once it's on the server, have the config file put in a secure location on that same server.
The proper deployment and configuration of SSIS packages isn't as easy as it first seems. There's a really good walk-through on MSDN about the right way to do it (including connection string configuration and password storage):
Depoloying Integration Services Packages
...in the end you end up with a deployment package that you install on the server, and then use a combination of XML Configuration files and Environment variables to configure the package.
You can pass data in to SSIS packages as variables, and the values in those variables can be "passed on" to virtually any property or attribute within the package.
One way I've done it is to pass in a servername as a variable, and then for the requisite connection I used Expressions to assign the variable to the connection's ServerName property. I can't (quickly) find a website that describes in detail how to do this, but I learned it from going through the SSIS tutorials in Books Online. (And, looking at a sample package, it appears that yes, you could pass in an entire connection string and assign it to a connection via expressions.)
This is great stuff if you need a fine level of control over what goes into your packages. XML configuration files are effective if your requirements are more straightforward. And definitely be paranoid about storing passwords in C:\Login.txt files -- if you at all can, use NT authentication.