DEV Community: Manuela Redinciuc

CSP - Content Security Policy basics

Manuela Redinciuc — Wed, 19 Jan 2022 21:20:04 +0000

I am fast approaching my first year working as a Software Engineer and as I contemplate the challenges I faced and my progress so far I thought I'd write about a topic I knew nothing about a year ago.
As the team grows at Brickvest, we've introduced Friday Tech talks were we each take turns and talk about topics we find interesting.
My first presentation was about Content Security Policies and I thought I'd write a blog post about it as well.

Let's start from the beginning...

1. What is CSP?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribute malware. - MDN Web Docs

If you are a novice like myself the definition above might be a bit unclear so I will take a step back and explain what happens during an XSS attack using the diagram below.

2. Why do we need CSP?

Web security is rooted in the same-origin policy. What that means is that code from myapp.com should only have access to myapp.com's data and other applications should never be allowed access.

This is an ideal case but in reality we need to use third party apps that can potentially leave us vulnerable and attackers have found ways to break the system and exploit those vulnerabilities.

In our case we have Content-Security Policies in place for third parties like Zoho and Sentry.

The main reason we need a CSP is to protect our visitors from malicious code being executed on our website.

3. How CSP works

This is a short example explaining how CSP works:

A user visits your website. When loading, the browser fetches the websites headers (where the CSP is specified)
The browser parses the CSP and remembers which sources are allowed to be loaded.
The browser now starts to load additional resources defined in your source code, like a Zoho chat, fonts, images, CSS, inline scripts, etc.
Each resource is cross-referenced to the page’s CSP, and if a source is not specified, the resource is blocked.

4. How do I implement a CSP?

As mentioned earlier, CSP is a response header that instructs the web browser from what sources it is allowed to include and execute resources from.
All modern browser (except IE) support Content-Security-Policy HTTP headers.

The below is a very basic example of a CSP written in Python's Quart framework that uses Sentry, Zoho and Hotjar as examples. It's important to mention that each third party you want to use will have documentation mentioning what needs to be included in order to be correctly set. Here is an example from Hotjar.

Going through the above example you can notice that the CSP is split by type of resource. I'll go through the ones I included but you can find more examples and explanations here.

self means sources that have the same protocol as the file the content policy is defined in (our own scripts). Everything else after self represents other sources that we allow content from e.g Zoho.
default-src the default policy for loading javascript, images, CSS, fonts
script-src defines valid sources for javascript files
style-src defines valid sources for css files
img-src defines valid sources for images
connect-src provides control over fetch requests
report_uri keep track of the violation reports. In our case we do that via Sentry.

5. What to avoid with CSP?

The unsafe-inline keyword cancels most of the security benefits that Content-Security-Policy provides as it allows the use of inline resources, such as inline elements.

Inline scripts look like this:
<script>alert()</script>
compared to:
<script src=”main.js”></script>

Allowing this gives the CSP a much weaker protection against XSS-attacks, and it’s the reason why it's prefixed by unsafe. Having to type unsafe should be a reminder that we are doing something potentially dangerous.

Unfortunately unsafe-inline is still used today (Hotjar is an example) so it's important to weigh the benefits compared with the risks before using unsafe policies.

Lastly, to end my article, here is a little tool to evaluate the Content Security Policy of your app with notes on vulnerabilities and tips on things you can improve.

Thanks you!

5 scenarios where git commands will help you keep your commits Atomic.

Manuela Redinciuc — Fri, 19 Feb 2021 17:48:02 +0000

I recently graduated from a bootcamp and started my first Developer job.
Just like many before me, the first week was a bit overwhelming with what seemed like an avalanche of information.
This article is a reflection on my first week as a Junior Software Developer and a few new Git commands I learned in order to make Atomic commits easier to manage.

If you haven't heard before about Atomic commits you can do more reading here and here. In essence Atomic commits revolve around one independent task or one fix.

Some of the main benefits of saving your work this way are:

track your history. With git log you can easily see the history of your commits. I would also add here that it is important to document each change with a commit message that tells what you've done and why.
easy to review. If your code is focused on only one atomic change then your reviewer should be able to follow and understand your code more easily.
easy to revert. If you've introduced a new bug in your code it's easy to revert your change and fix the issue.

In order to keep a clean working tree and adhere to the Atomic principles here are 5 scenarios that can happen on everyday basis and how you can easily get passed them.

1. You've just committed your work and realised you forgot to add something

Start with a git log to check it's indeed the last commit you want to change.

commit 2df06c898ba035a0c0878e4f78032b0bd676f3ad (HEAD -> master)
Date:   Sat Feb 13 14:50:27 2021 +0000

    Frontend: Created layout for homepage

    This is a base on which we will develop the homepage and add
    new content.

Make your changes, add them to the staging area with git add. and them commit using git commit --amend.
This will allow you to override your last commit with your new additions.

If you do a git log now you can see you still have only on commit.

commit 5f7037f6e7e243e178a58b119e56c0b3337cd408 (HEAD -> master)
Date:   Sat Feb 13 14:50:27 2021 +0000

    Frontend: Created layout for homepage

    This is a base on which we will develop the homepage and add
    new content.

2. You've worked on two things at the same time but you want to commit them separately.

You could use git add <file> but there is a more powerful option.
Your key here is git add --patch or simply git add -p.

When you pass this option to add, instead of immediately adding all the changes in the file to the index, it goes through each change and asks you what you want to do, and looks like this:

diff --git a/styles.css b/styles.css
index 23d8732..470d5dc 100644
--- a/styles.css
+++ b/styles.css
@@ -2,4 +2,5 @@
     margin: 0;
     padding: 0;
     box-sizing: border-box;
+    background-color: aquamarine;
 }
(1/1) Stage this hunk [y,n,q,a,d,e,?]? y

3. You want to merge together two commits you realised are part of the same Atomic commit.

Start by doing a git log.
In the example below we want to merge f2662c5 into 5f7037f (e.g the last commit into the first one).

commit f2662c51cf2f14ccb33907267f1d823ff6b8a678 (HEAD -> master)
Date:   Sat Feb 13 16:36:03 2021 +0000

    Frontend: added style link to Index.html

    This is in order to be able to see the style changes.

commit f84f936e22a0028ad00d3c33771518f23ac192b2
Date:   Sat Feb 13 15:29:42 2021 +0000

    Frontend: Set up style sheet with default styling

    This is a base on which the rest of the homepage will be styled
    upon.

commit 5f7037f6e7e243e178a58b119e56c0b3337cd408
Date:   Sat Feb 13 14:50:27 2021 +0000

    Frontend: Created layout for homepage

    This is a base on which we will develop the homepage and add
    new content.

To achieve your rebase task start by typing: git rebase -i Head~2.

What this means is: the last commit we want to retain as-is has an index position of 2 (Git uses zero-based indexing) so we can pass in HEAD~2 to our interactive rebase command.

This will open an interactive panel where we look for our commit f2662c5 and change the word pick to f and move it right under the commit you want to merge into (e.g 5f7037f).

pick f84f936 Frontend: Set up style sheet with default styling
f f2662c5 Frontend: added style link to Index.html

# Rebase 5f7037f..f2662c5 onto 5f7037f (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.

If you check your git log now you will see that commit f2662c5 is no longer there.

4. Your code has been reviewed and you need to make some changes to your commit.

To modify a commit that is farther back in your history your best bet is the the rebase again.

Let's say you need to change something on commit ed57576.

commit e7433f8b9ff28eb819b8740c6692ffb975b426d4 (HEAD -> feature-button, origin/feature-button)
Date:   Sun Feb 14 11:53:53 2021 +0000

    Frontend: changed border radius value for the button

commit ed57576bf379fd7132eb2338b0be34b71f4a94f2 (main)
Date:   Sun Feb 14 11:55:38 2021 +0000

    Frontend: added border specifications

commit a429de8e24c1a5a05c7c4b24c599b637a4fce715 (origin/main)
Date:   Sat Feb 13 17:15:56 2021 +0000

    Frontend: Added button on landing page

In this case you can do a rebase -i Head~1 and in the interactive panel change pick for e to edit your commit.

e e7433f8 Frontend: changed border radius value for the button

# Rebase ed57576..e7433f8 onto ed57576 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.

After you save you can go ahead and make your changes followed by:

git add .
git commit --amend
git rebase --continue

If you want to push the branch to the remote repository you now need to force it in order to replace the current version.
For that use: git push -f origin <feature-name>.

5. Master has changed and you now have conflicts.

One way to integrate your branch updates into the master is through a merge. Another way is to perform a master to branch rebase. The benefit of the latter is the clean, linear, non-branched commit history that elutes.

Start by getting the latest version of master:
git checkout master
git pull

Checkout into your branch and perform the rebase

git checkout <branch name>
git rebase master

If there are any conflicts you a prompt will ask you to choose what version you would like to keep.

button {
Accept Current Changes | Accept Incoming Change | Accept both Changes
<<< HEAD (Current Change)
    border-radius: 2%;
    border: 2px solid red;
    background-color: green;
=======
    border-radius: 5%;
    background-color:green;
>>> 376b235 (Frontend: changed border radius value for the button)(Incoming Change)
}

After solving all the merge conflicts you can add the amended files to the rebase and continue the process:
git add .
git rebase --continue
git commit

Git is powerful! So much so that there are many commands you don't even know they exist.

I found that the scenario approach works best for me in learning how to harness the power of Git. I recommend these exercises if you want practice and learn more.