Forem: Leah Einhorn

Secure your app in a few easy steps 🔒

Leah Einhorn — Sat, 13 Nov 2021 00:26:33 +0000

Security is a broad topic, and one that’s hard to master. However, there are some really simple things you can do to increase the security of your web application.

For starters, there are some HTTP Response Headers you can include in your web responses, that can prevent easily preventable vulnerabilities.

This will aim to outline all of the headers recommended by the OWASP Secure Headers Project, as part of a series. Let's begin with a couple.

As a caveat, these are by no means foolproof. However, they do provide a first layer of defense in depth for attackers.

How To

The recommended mechanism for configuring your web application to return these headers in every response, is by configuring your web server. Since nginx is a widely used option, I will provide examples that demonstrate how to implement these headers via nginx.

X-Frame-Options

Prevents: Clickjacking
What it is: A Clickjacking attack is when a malicious website overlays their website with another website. The content isn't visible to the user, and so they can be tricked into clicking on things on the trusted website.

Example: Malicious website overlays a bank website with their own website, with a button to win a free iPad. The user clicks the button, but instead is tricked into actually clicking on a (non-visible) button that will wire money to the attacker.

Actual Attack Headline: Facebook hit by more clickjacking attacks

Mitigation: X-Frame-Options: DENY

This header can be used to indicate whether or not a browser should be allowed to render a page in an iframe. Sites can use this to avoid clickjacking attacks by specifying that their content should not be embedded into other sites.

Since X-Frame-Options was never a formally defined standard, a new header and value, Content-Security-Policy: frame-ancestors 'none';, has come to take its place. The browser gives precedence to X-Frame-Options, which is still the most prevalent way to mitigate clickjacking. It is recommended to include both headers in the response, so as to support both older and newer browsers.

# nginx.conf
add_header X-Frame-Options "DENY";
add_header Content-Security-Policy "frame-ancestors 'none';"

X-Content-Type-Options

Prevents: MIME-sniffing
What it is: MIME sniffing is a technique used by web browsers to examine the contents of a file, when the file format is ambiguous. This is done for the purpose of determining the file format, so it can render the contents appropriately. The vulnerability comes into play when an attacker disguises a malicious script as a different file type (let's say a JPG). Doing so allows the attacker to successfully upload the malicious content. Consequently, when the content is loaded, the browser will render it as a script, rather than an image, thereby executing the malicious content.

Mitigation: X-Content-Type-Options: nosniff

This header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured.

# nginx.conf
add_header X-Content-Type-Options "nosniff";

Summary

By adding a few lines of code to your web server configuration, you can easily prevent some common vulnerabilities.

Snapshot Testing in Python

Leah Einhorn — Mon, 26 Nov 2018 00:51:54 +0000

Have you ever found yourself writing long, tedious tests that take in a large data structure, and test the output of a similar, validated data structure? Whether it's converting a dictionary to a named tuple or serializing an object, if you've ever tried testing a data model or a GraphQL model for an API, you've probably experienced this.

Writing tests and replicating the same response we expect can be a tedious and monotonous task. Snapshot testing can be a great way to ease the pain of testing these data structures. As our APIs evolve, we need to know when our changes introduce any breaking changes, and a snapshot test will tell us exactly that.

What is Snapshot testing?

Put simply, A snapshot is a single state of your output, saved in a file.

A typical snapshot test case for a mobile app renders a UI component, takes a screenshot, then compares it to a reference image stored alongside the test. The test will fail if the two images do not match: either the change is unexpected, or the screenshot needs to be updated to the new version of the UI component.

A similar approach can be taken when it comes to testing your APIs or data structures. Instead of rendering the graphical UI, you can use a test renderer, such as the SnapshotTest library, to quickly generate a serializable value for your API response.

Snapshots lets us write all these tests in a breeze, as it automatically creates the snapshots for us the first time the test is executed. Then, every subsequent time the tests are run, it will compare the output with the file snapshot. If they are different, our tests will fail, immediately alerting us of the change.

How to use the `SnapshotTest` library

First, we install the library:

pip install snapshottest

I'll provide code snippets below for both the python built-in unittest library and pytest, but you can probably use this with any testing framework you choose.

We'll begin with a simple namedtuple that we'd like to test.

'''Our Clown Code'''

from collections import namedtuple

Clown = namedtuple('Clown', 'name', 'nose_type'))

With unittest:


from snapshottest import TestCase

class TestClown(TestCase):

    def test_clown(self):
      clown = Clown('bozo', 'red and round')                                  
      self.assertMatchSnapshot(clown)  

# >> python -m unittest

With pytest:

import pytest

def test_clown(snapshot):
      clown = Clown('bozo', 'red and round')                                  
      snapshot.assert_match(clown) 

# >> pytest

This will create a snapshot directory and a snapshot file the first time the test is executed.

>> pytest
=================== SnapshotTest summary ===================
1 snapshot passed.
1 snapshot written in 1 test suites.

Next time we run our tests, it will compare the results of our test with the snapshot. Since nothing changed, we get the following:

>> pytest
=================== SnapshotTest summary ===================

1 snapshot passed.

If our data structure or output changes, the snapshot tests will fail. We can then compare the changes and determine whether they are valid. To update the snapshot we can run:

pytest --snapshot-update

Obviously the above is a super simple test case, and we're not really testing any logic. But this same pattern can be applied for testing API requests.

import requests

def test_my_api(snapshot):
    response = request.get('my_api.com')
    snapshot.assert_match(response)

Or for testing a GraphQL API

from graphene.test import Client

def test_hey(snapshot):
    client = Client(my_schema)
    response = client.execute('''{ hey }''')
    snapshot.assert_match(response)

Snapshot testing may not be a replacement for unit or integration tests, but it's a great way to quickly and effectively determine whether the state of your API or data serialization has changed.

Continuous Integration with `make` for AWS Lambda using Python

Leah Einhorn — Sun, 05 Aug 2018 19:45:35 +0000

Goal

When deploying python code to AWS Lambda, you are required to zip all your code into a single zip file, and add all your package dependencies (python libraries that you usually pip install into your virtualenv) into the root level of your directory.

I wanted a way to do this easily, without having to log into the AWS console
and using the GUI to zip all my contents every time I modify the source code. I also wanted a way to test the code and stop the process from deploying if the tests didn't pass. Kind of what you would expect if you had a continuous integration server, such as Jenkins. The goal was to be able to modify code or pip install packages, and with a single command be able to test my code, zip my code, and deploy it to lambda.

Make Intro

If you aren't familiar with make, here is a description:

A GNU build automation tool that automatically builds programs from source code by reading files called Makefiles, which specifies how to build the program.

This is commonly used in c programs to compile all source code and bundle it into a single executable file, and comes pre-installed on most UNIX systems, such as MacOS and Linux. Another great benefit to make is that it is smart enough to re-build just the files that have changed, and doesn't regenerate every file every time. Rules will execute in the order you specify, and stop executing if any of the commands fail.

Ultimately, it seems like a great use case for our needs, since we essentially
want to transform our source files to a single target result (the zip file)! We also want the deployment process to halt and stop executing commands if our tests fail.

First, just a quick intro to some make commands and syntax:

To do stuff with make, you type make in your terminal in a directory that has a file called "Makefile"
A Makefile is a collection of rules. Each rule is a recipe to do a specific thing.
Recipe syntax:

  <target>: <prerequisites...>
    <commands>

The target would be what you call from the terminal to execute commands, such as make <target>, similar to a function name.
prerequisites are anything this target relies upon, which could be a file or another target.
commands are where you can specify a series of commands you’d like to execute, like a function body.

The target is required, the prerequisites and commands are optional, but you must have one or the other.

Magic variables: This is special make syntax that allows us to easily refer to the target / prerequisites.

# Example:
libs/: requirements.txt requirements-test.txt
  $@   # refers to target: "libs/" 
  $<   # refers to the first prerequisite: "requirements.txt" 
  $^   # refers to all prerequisites: "requirements.txt requirements-test.txt"

The syntax is unique and could take time to get used to! But in my opinion it is part of what makes make (uh) a powerful tool when compiling source code, rather than using a bash script. Here's a cheat sheet for reference.

How To

We will want to do the following:

Test our code
Zip our code
Deploy our code
Clean up any files / dirs we created

This tutorial assumes you have the following installed:

pip
aws cli
make
zip

Test our code

test: mypy pylint nose tox ## Run all tests
    pip install $^ # install your test dependencies
    ## run your tests here.  some examples:
    python -m unittest discover tests/
    nose
    pylint main.py
    mypy main.py
    tox
    # etc.

Zip our code

We begin by installing the library dependencies.

# Our target is the libs dir, which has a requirements file as a prerequisite

libs: requirements.txt ## Install all libraries
    @[ -d $@ ] || mkdir $@ # Create the libs dir if it doesn't exist
        pip install -r $< -t $@ # We use -t to specify the destination of the
        # packages, so that it doesn't install in your virtual env by default

Zip the source code and the libraries.

# Our target is the zip file, which has libs as a prerequisite 

output.zip: libs ## Output all code to zip file
        zip -r $@ *.py # zip all python source code into output.zip
        cd $< &&  zip -rm ../$@ * # zip libraries installed in the libs dir into output.zip

        # We `cd` into the directory since zip will always keep the relative 
     # paths, and lambda requires the library dependencies at the root.

        # Each line of a make command is run as a separate invocation of 
     # the shell, which is why we need to combine the cd and zip command here.

        # We use the -rm flag so it removes the libraries after zipping, 
     # since we don't need these.

Deploy our code

# Our target is deploy, which has the zip file as a prerequisite 
# Note: since deploy doesn't refer to an actual file or directory, it's good 
# practice to declare this as .PHONY, so make knows not to look for that file.

.PHONY: deploy
deploy: output.zip ## Deploy all code to aws
    -aws lambda update-function-code \
        --function-name my-lambda-function \
        --zip-file fileb://$<
 # This assumes you have the aws cli, but if not, run `pip install awscli`

 # The "-" says to ignore the exit status, and continue executing even if it
 # fails.  This is so we can clean up the files when we're done, even if
 # deployment failed.

And finally, clean up files

.PHONY: clean
clean: ## Remove zipped files and directories generated during build
    rm output.zip
    rmdir libs

Then, we'll want to run all these targets and execute it with a single command:

# `make all` will execute all prerequisite targets!

.PHONY: all
all: test deploy clean

Summary

Make is a powerful tool that can be used to run a series of commands, and can be a useful build automation tool when deploying to lambda.

We use it to zip our python source code, as well as our dependencies, and push the code to aws.

Now, with a single command in your terminal, make all, we have our continuous integration pipeline set up for lambda!

Resources

Make can do a lot more with its special syntax, so if you'd like to learn more, check out this tutorial.

Forem: Leah Einhorn

Secure your app in a few easy steps 🔒

How To

X-Frame-Options

X-Content-Type-Options

Summary

Snapshot Testing in Python

What is Snapshot testing?

How to use the SnapshotTest library

Continuous Integration with `make` for AWS Lambda using Python

Goal

Make Intro

How To

Test our code

Zip our code

Deploy our code

And finally, clean up files

Summary

Resources

How to use the `SnapshotTest` library