Fix Insecure Default Configuration #1554
Conversation
Accidentally pushed with OED_PRODUCTION set to yes
huss
left a comment
huss
left a comment
There was a problem hiding this comment.
Thanks to @Zachary-Squires & @Zach-O-Bates for this contribution. I've made some comments to consider. I'm happy to discuss them. I did some testing but not complete as I'm going to wait for any changes to do that.
| if [ -f ".env" ]; then | ||
| if grep -q "^OED_TOKEN_SECRET=" .env; then | ||
| sed -i "s/^OED_TOKEN_SECRET=.*/OED_TOKEN_SECRET=$OED_TOKEN_SECRET/" .env | ||
| else |
There was a problem hiding this comment.
This comment applies in a general way but put here. I'm thinking about the fact that there are settings in .env and docker-compose.yml that apply to the same case. I think originally it was designed to allow flexibility in how the values were given and to override them. I think the reality is that people don't use this ability. Also, security has become more important so I'm thinking having it in two places is less desirable since people might miss one. Finally, I think OED will be adopting new ways to set values that is more secure and easier so getting to one way now might help for that future effort. First: What do you think about getting rid of one of the ways to set these values? Second: If yes, then should we only use the docker-compose.yml file?
src/scripts/installOED.sh
Outdated
| echo "OED_TOKEN_SECRET=$OED_TOKEN_SECRET" > .env | ||
| fi | ||
| fi | ||
| #If the user is in production and their postgres password has been left default, generating a random one |
There was a problem hiding this comment.
I'm not sure this is actually changing the password for Postgres. I'm not an expert but from what I understand, the POSTGRES_PASSWORD environment variable is used when the DB is initialized. This happens at an earlier stage so the original value is used. I'm also unsure if it changes it if done on a later startup. I tried checking with login and it was not clear but seems it might be an issue. We should discuss this.
I don't know how the token is impacted or if that is okay.
There was a problem hiding this comment.
Yeah I did some testing and it seems like you're exactly right, for the first time since the database is created before this is run it uses the default password but after that it uses the new one. I'm not sure if there's anything I can do about that but I'm open to ideas.
Added: 1. Banners for the make sure to change this value notifications, also added a notification for the token secret. 2. Fixed spelling error. 3. Added spaces to comments. 4. A variable that checks what the installation type is at the start and is used for all checks.
src/scripts/installOED.sh
Outdated
| npm run start | ||
| else | ||
| printf "%s\n" "Starting OED in development mode" | ||
| elif [ "$INSTALL_MODE" = "development" ]; then |
There was a problem hiding this comment.
Given the checks above, can this now be an else? I'm not sure it is that risky to do development if something went wrong (which it should not).
src/scripts/installOED.sh
Outdated
| elif [ "$INSTALL_MODE" = "development" ]; then | ||
| # Warning the user if they've left their token or postgres password default, we don't randomly generate it in dev mode | ||
| if [ -z "$OED_TOKEN_SECRET" ] || [ "$OED_TOKEN_SECRET" = "?" ]; then | ||
| printf "\n********************************************************************************\n" |
There was a problem hiding this comment.
I'm thinking about the banners here. I think most developers will simply leave the default values as they are generally safe. Given this, do you think there should be banners? If not, how much do you think should be all uppercase?
src/scripts/installOED.sh
Outdated
| fi | ||
|
|
||
| # Creating a centralized variable to keep track of the type of installation. | ||
| INSTALL_MODE="invalid" |
There was a problem hiding this comment.
I'm wondering about not initializing to a bad value and changing the second if to be an else on the first one. I think it has the same impact in a clean way in the code. What do you think?
2 participants
Description
Changes installOED.sh and docker-compose.yml to automatically generate POSTGRES_PASSWORD and OED_TOKEN_SECRET when OED is launched in production mode. This should remediate an issue where OED_TOKEN_SECRET could be forged to allow a login as an admin. Will also make the postgres database more secure as the password will be much more robust by default. Additionally, installOED.sh now specifically checks if OED_PRODUCTION is no rather than just checking if it is not yes.
Developed and implemented by:
Zachary Squires - https://github.com/Zachary-Squires
Zachary Bates - https://github.com/Zach-O-Bates
Type of change
Checklist
Limitations
In order to fully remediate the insecure default configuration we will need to use a separate docker file when launching in development and production, this will be done in a separate PR since it will be intrusive to every OED developer.