Forem: Donghyuk (Jacob) Jang

Cryptography git commits

Donghyuk (Jacob) Jang — Sun, 18 Aug 2019 04:39:31 +0000

Git is an industry-standard version control tool used in IT fields, so it has a mandatory tool and a skill to learn for developers.

During the development stage, developers make hundreds / thousands of commits. However, it is not difficult to find unverified commits, although it would be related to security flaws and potentially impacts the vulnerability of projects.

This article will mainly focus on the importance of the signing(verified) commits. As well, there is one practice on how to pretend someone else in Git repositories.

Brief about SSH key
GPG key
An example of a security flaw without using GPG key
How to setup GPG key
How to create signing commits
Final thoughts

Brief about SSH

SSH-key added in Github

First of all, I would assume that you have already set up SSH-key on your machine to authenticate to Github and have it registered with your Github account. If not, please read Connecting to GitHub with SSH and follow the steps.

Setting up SSH-key means that you do not have to provide your Github username or password for all of your git activity. That is the main reason to set up an SSH-key. Does connecting to Github with an SSH-key mean all of your commits become secure? We will dig into this and talk more about the disadvantages of only using an SSH-key later in this article.

Then, what is GPG key?

GnuPG logo

Gnu Privacy Guard(GPG) is a tool that allows users to integrate an additional security layer easily with other applications. In this case, it will be Git.

GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as PGP). GnuPG allows you to encrypt and sign your data and communications; it features a versatile key management system, along with access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. GnuPG also provides support for S/MIME and Secure Shell (ssh).

Since its introduction in 1997, GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License .

The current version of GnuPG is 2.2.17. See the download page for other maintained versions.

Gpg4win is a Windows version of GnuPG featuring a context menu tool, a crypto manager, and an Outlook plugin to send and receive standard PGP/MIME mails. The current version of Gpg4win is 3.1.10.

The GNU Privacy Guard

What could happen if you do not use GPG key?

a costume under surveillance

One very common severe issue is that someone can set up other developers' Github username and email in their local machine, and create commits which will appear as "the someone else"' commits in the Git repository. Of course, this activity needs to meet a certain condition. The command below shows how to set up a different Github username and email within your terminal.

// setup username and email
$ git config --global user.name "No GPG"
$ git config --global user.email no.gpg@email.com

// verity username and email
$ git config --global user.name
> No GPG
$ git config --global user.email
> no.gpg@email.com

Here I want to share with you an example of two different commits that I pushed in a test Git repository(signing commit).

When I created this git repository, I made the initial push with a signed(verified) commit.

Screenshot of git commit history

And then, I asked a friend of mine (@alemesa) to follow the practice above and gave him my Github username and email. (These credentials for signing in can be found with very little effort.) He created a commit and pushed to the master branch. Check out the results below.

Screenshot of git commit history

The commit has appeared that it was created by me. However, there is no "verified" flag like the first initial commit.

If master branch is not protected like the testing Git repository, then anyone in the contributor list can push any code by pretending to be someone else. Please find details about how to protect branches here.

NOTE: If you want to test this activity, please send me a direct message that includes your Github username. I will add you into the collaborator list.

How to setup GPG key

The references will guide you on how to setup GPG key in your workstation, and how to add them into your Github account.

How to create signing commit(s)

Add file(s) before creating a commit:

// add a single file
$ git add [path file]

// add all file
$ git add .

The git command below is how to create a commit with or without your signature:

// create commit with a message without signing
$ git commit -m "commit message"

// add all file that you want to commit
$ git commit -S -m "commit message"

Once your signing commit(s) is created, the next step is to push to a git repo:

// push the commit
$ git push

The screenshot below is an example of git signing commit in the test git repository(signing commit)

detail of signing commit

Conclusion

To sum this article up, using GPG-key will increase security and authenticity level by encrypting its data, and adding a person's signature. If you or your organization have considered these, the steps above will bring its advantages and ensure trust with your commit workflow.

NOTE: this activity may not be suitable for all case. Please make sure using this for the right purpose.

References

Collaborators

Alejandro Mesa (@alemesa) - alejandro.suarez@jam3.com
Danny Paton - danny.paton@jam3.com

Managing .env variables for provisional builds with Create React App

Donghyuk (Jacob) Jang — Sun, 07 Apr 2019 21:41:41 +0000

When developing web applications by using Create React App, developers get NODE_ENV=development on their local environment and NODE_ENV=production on the production build by default. And, modifying NODE_ENV is forbidden. According to the Create React App, this is an intentional setting to protect the production environment from a mistake/accident deploying.

You will be able to see scripts like below in package.json after creating your web app.

// package.json
scripts: {
  "start": "react-scripts start", // `NODE_ENV` is equal to `development`.
  "build": "react-scripts build", // `NODE_ENV` is equal to `production`.
  ...
}

If you create or already have .env.development and .env.production in the root of your project, these files will be used for running each script. npm start will pick up .env.development, and npm build will use environment variables in .env.production.

-
What if you want to setup .env.staging?

This article will show you how to manage environment variables for provisional builds.

Let's dive into that! Oh, if you do not have any experiences of CRA, please Getting started

Story

Imagine that your project will have three separated provisional environments; development, staging, and production. Each environment is using different API endpoints. In addition to that, the project may require a REACT_APP_CUSTOM_NODE_ENV. This is because NODE_ENV will always be production for the build regardless.

Goal

Create .env.development, .env.staging, and .env.production.
Configure environment viriables for each build.
Modify scripts in package.json

Getting started

Step 1.

Thankfully, dotenv comes out of box. Let's create .env files under the root folder to manage environment variables. The files are .env, .env.development, .env.staging, and .env.production.

.env - Keep all common/shared environment variable
.env.development - Variables are used for the local development
.env.staging - Variables are used for the staging build
.env.production - Variables are used for the production build

For example;

#.env
REACT_APP_DOC_TITLE = "Document title"

//.env.developement
REACT_APP_API_ENDPOINT = "https://development-api.endpoint.com/"

#.env.staging

# NODE_ENV will always be set to "production" for a build
# more details at https://create-react-app.dev/docs/deployment/#customizing-environment-variables-for-arbitrary-build-environments
REACT_APP_CUSTOM_NODE_ENV = "staging"
REACT_APP_API_ENDPOINT = "https://staging-api.endpoint.com/"

#.env.production
REACT_APP_API_ENDPOINT = "https://api.endpoint.com/"

NOTE: The prefix REACT_APP_ is required when creating custom environment variables.

`.env.development` and `.env.production`

As a default behavior, those files will be served with no configuration. You do not even have to update scripts in package.json

`.env.staging`

Here is the main focus of this post. To target .env.staging file for the staging build, we need a library to achieve this.

1- Let's install env-cmd. This library will will help us on using/executing a selected environment file. See more detail

// execute command below at the root of project
$ npm install env-cmd --save
or
$ yarn add env-cmd

2- Add a script in package.json like below.

// package.json
scripts: {
  "start": "react-scripts start", // `NODE_ENV` is equal to `development`.
  "build": "react-scripts build", // `NODE_ENV` is equal to `production`.
  "build:staging": "env-cmd -f .env.staging react-scripts build", // `NODE_ENV` is equal to `production`.
  ...
}

3- Finally, test your build:staging script.

Conclusion

The intention of this technique is to use different custom environment variables for many provisional environments without ejecting the default CRA configs.

Resources

Special Thanks

@foxbit19 - found env-cmd version 8.x requries additional argument to link to the custom env file.
@j6000 - pointed out NODE_ENV for the build will always be set to "production" regardless.

How to prevent XSS attacks when using dangerouslySetInnerHTML in React

Donghyuk (Jacob) Jang — Mon, 04 Feb 2019 21:11:04 +0000

This article intends to show one of the techniques we use to mitigate cross-site scripting (XSS) attacks at Jam3. These vulnerabilities may appear when dangerouslySetInnerHTML is wrongly used, and our goal is to detect it ahead of time and to clean up untrusted values.

Dangerously Set innerHTML

This feature is designed to present and insert DOM formatted content data into the frontend. The use of the feature is a bad practice, especially when dealing with user inputs and dynamic data. You must consider its vulnerabilities in order to prevent XSS attack.

"Easy" to make thing safe is one of React philosophy. React is flexible and extendable which means that the bad practice can be turning into the best practice. Sanitizing props value is one obvious option and strongly recommended.

XSS attacks

Cross-site scripting (XSS) allows attackers(hackers) to inject malicious code into a website for other end-users. By doing this, attackers may have access to personal data, cookies, webcams, and even more. Read more about Cross-site scripting.

Copy https://placeimgxxx.com/320/320/any" onerror="alert('xss injection') and paste it in the input field in the xss injection example below:

Preventing XSS

This issue is not restricted to React; to learn how to prevent it in your web development OWASP has a good prevention cheat sheet. One approach to prevent XSS attacks is to sanitize data. It can be done either on the server-side or the client-side; in this article, we will focus on the client-side solution.

Preventing XSS with dangerouslyInnerSetHTML

Sanitizing content in the frontend when using dangerouslySetInnerHTML is always a good security practice, even with a trusted source of truth. For example, another development team in charge of maintaining the project changes the source of truth without realizing how it could impact the site. A change like that may cause a critical XSS vulnerability.

At Jam3 we avoid using dangerouslySetInnerHTML whenever possible. When it's required, we always apply sanitization security layers on both the back-end and front-end. In addition, we created an ESLint rule called no-sanitizer-with-danger inside eslint-plugin-jam3 to detect improper use of dangerouslySetInnerHTML.

ESLint rule

I assume that you are already familiar with ESLint. If not, Get Started.



$ npm i eslint eslint-plugin-jam3 -save-dev

Extend pluginsin the .eslintrc config file by adding jam3. You can omit the eslint-plugin- prefix. Then, configure the rules by adding jam3/no-sanitizer-with-danger to the rules. Note: error level 2 is recommended. With this option, exit code will be 1. error level 1 will give warning alert, but does not affect exit code. 0 means to turn the rule off. The plugin will check that the content passed to dangerouslySetInnerHTML is wrapped in this sanitizer function. The wrapper function name can be also be changed in the JSON file (sanitizer is the default wrapper name).

How to use it

Here is an unsafe way of using dangerouslySetInnerHTML.

Once the rule is enabled, your code editor will alert the lack of a sanitizer in dangerouslySetInnerHTML. For the purpose of this article we use dompurify, you can find an extended list of available sanitizers at the end of the article.

The sanitizer wrapper must have a name, for the purpose of this article we are creating const sanitizer = dompurify.sanitize;. However, it is recommended to create a sanitization utility to abstract your chosen sanitizer.

Sanitizer libraries

Our team has researched and tried many sanitizers and can recommend these 3 libraries.

dompurify

Strip out all dirty HTML and returns clean HTML data npm Weekly download 50k+
40 contributors
Earned 2800+ GitHub ⭐️
5.6kB MINIFIED + GZIPPED

xss

Escape HTML entity characters to prevent the attack which occurs to transform non-readable content for the end users
npm weekly download 30k+
18 contributors
Earned 2500+ github ⭐️
5.3kB MINIFIED + GZIPPED

xss-filters

Escape HTML entity characters to prevent the attack which occurs to transform non-readable content for the end users
npm weekly download 30k+
5 contributors
Earned 900+ github ⭐️
2.1kB MINIFIED + GZIPPED

Conclusion

To sum up, finding the most suitable sanitizer library for your project is very important for security. You might want to have a look at GitHub stars, npm download numbers, and maintenance routines. The use of no-sanitizer-with-danger in eslint-plugin-jam3 will be a great choice to help ensure all data is being properly purified and gain confidence that your project will be safe from XSS vulnerabilities.

NOTE: Please keep it in mind there is a performance disadvantage of sanitizing data in client-side. For example, sanitizing all data at once may slow down the initial load. To prevent this in large scale web applications, you can implement a "lazy-sanitizing" approach to sanitize on the fly.

Contributors

Donghyuk(Jacob) Jang / jacob.jang@jam3.com
Iran Reyes / iran.reyes@jam3.com
Peter Altamirano / peter.altamirano@jam3.com

Jam3 is a design and experience agency that partners with forward-thinking brands from around the world. To learn more, visit us at jam3.com.

Article by Donghyuk (Jacob) Jang

Forem: Donghyuk (Jacob) Jang

Cryptography git commits

Table of Contents

Brief about SSH

Then, what is GPG key?

What could happen if you do not use GPG key?

How to setup GPG key

How to create signing commit(s)

Conclusion

References

Collaborators

Managing .env variables for provisional builds with Create React App

Story

Goal

Getting started

Step 1.

`.env.development` and `.env.production`

`.env.staging`

Conclusion

Resources

Special Thanks

How to prevent XSS attacks when using dangerouslySetInnerHTML in React

Dangerously Set innerHTML

XSS attacks

Preventing XSS

Preventing XSS with dangerouslyInnerSetHTML

ESLint rule

How to use it

Sanitizer libraries

Conclusion

Further reading and sources

Contributors

Forem: Donghyuk (Jacob) Jang

Cryptography git commits

Table of Contents

Brief about SSH

Then, what is GPG key?

What could happen if you do not use GPG key?

How to setup GPG key

How to create signing commit(s)

Conclusion

References

Collaborators

Managing .env variables for provisional builds with Create React App

Story

Goal

Getting started

Step 1.

.env.development and .env.production

.env.staging

Conclusion

Resources

Special Thanks

How to prevent XSS attacks when using dangerouslySetInnerHTML in React

Dangerously Set innerHTML

XSS attacks

Preventing XSS

Preventing XSS with dangerouslyInnerSetHTML

ESLint rule

How to use it

Sanitizer libraries

Conclusion

Further reading and sources

Contributors

`.env.development` and `.env.production`

`.env.staging`