DEV Community: OWASP DevSlop

Pixi-CRS goes to the Cloud - Part 6 : Summary and Comparison

Franziska Bühler — Wed, 28 Oct 2020 14:59:30 +0000

This is the last blog post of the "Pixi-CRS goes to the Cloud" series.
In this blog post, we will sum up and compare the five Pixi-CRS pipelines we built: CircleCI, Amazon Web Services, Azure, Google Cloud Platform and GitHub Actions.

OWASP DevSlop's goal was to migrate Pixi-CRS to the cloud and we've been successful!

Comparison of the 5 Pixi-CRS Pipelines

-	CircleCI	AWS	Azure	GCP	GitHub Actions
Tool Name	Jobs	CodeBuild	Azure DevOps Pipelines	Cloud Build	Actions
Code File	.circleci/config.yml	buildspec.yml	azure-pipelines.yml	cloudbuild.yaml	.github/workflows/pixi-crs-ci.yml
Start of CRS	docker run	docker-compose up --env-file	docker-compose with FileArgs	docker-compose up --env-file	docker-compose up --env-file
Start of Pixi	docker-compose up	docker-compose up	docker-compose	docker-compose up	docker-compose up
CRS Tuning	docker cp	volumes	volumes	volumes	volumes
Testcafe Tests	docker run testcafe/testcafe	npm install testcafe	docker run testcafe/testcafe	docker run testcafe/testcafe	docker run testcafe/testcafe
Test Endpoint Pixi	http://172.17.0.1:8000/	http://localhost:8000/	http://172.17.0.1:8000/	http://172.17.0.1:8000/	http://172.17.0.1:8000/
Test Endpoint CRS	http://172.17.0.2/	http://localhost/	http://172.17.0.1:8080/	http://172.17.0.1:8080/	http://172.17.0.1:8080/
Pipeline Trigger	GitHub Webhook	Set "Primary source webhook events"	trigger: -master in azure-pipelines.yml	Set "trigger"	on: [push, pull_request] in .github/workflows/pixi-crs-ci.yml

In the table above, I compare cloud providers and pure CI tools. This comparison is a little problematic because the cloud providers and CI tools do not have quite the same strengths. CI tools are strongly designed for the continuous integration part and the cloud providers offer a lot around it.
However, while writing the code, I had more trouble with some pipelines than other pipelines:

The pure CI tool CircleCI is easy to configure and the code is easy to read. The only drawback was that I had to mount volumes in a container with a workaround.
The AWS buildspec.yml is also easy to configure and easy to read. Of all three cloud providers, this was the easiest code to write for me. Here I couldn't mount any volumes either, and I had to install Testcafe instead of using it as a Docker container.
The Azure Pipeline azure-pipelines.yml and the GCP cloudbuild.yaml was a bit more tricky to write. This code is less intuitive and you have to look up the options.
The GitHub actions were easier again and I was able to use large parts of the CI code from CircleCI and AWS.

This is a personal comparison and maybe I am not familiar with all of the possibilities that the code offers. And maybe more options are now possible than when I wrote the pipeline code.

What I learned

For me, it was super fun to get to know the three cloud providers and GitHub Actions and to learn how to write pipeline code for all of them.

I know there are different ways to implement solutions. I also wanted to try them out. Besides the fact that I sometimes needed to search for another option to implement a pipeline step, I enjoyed trying out different approaches. So, the pipelines can differ.
Maybe there are better ways to implement something. Pull Requests and contributions against Pixi-CRS or feedback are always very welcome :-)

Thank you OWASP DevSlop for giving me the opportunity to play with these cloud providers and to learn new stuff!
I hope that the pipelines provided and idea behind them, namely to test a WAF early in the delivery pipeline, or the provided code, will help some of you!

Pixi-CRS goes to the Cloud - Part 5 : GitHub Actions

Franziska Bühler — Tue, 20 Oct 2020 07:43:31 +0000

The fourth pipeline I implemented Pixi-CRS in was GitHub Actions (GHA): https://github.com/features/actions.

This is the fifth blog post in the "Pixi-CRS goes to the Cloud" series.

This is how Pixi-CRS looks on GitHub Actions:

Pixi-CRS Pipeline Code

GitHub Actions is not a cloud provider like I described in the earlier blog posts in this series. GitHub Actions is "only" a CI / CD pipeline, but very easy to configure and therefore very lightweight. I like that!
The code behind the pipeline can be found here.
GitHub Actions are written in yaml files inside the ./github/workflows subdirectory of the repository. It's pretty easy to get started with GitHub Actions. No need to configure anything. Adding a yaml file in the named directory is enough and the Actions can be run.

Let's have a closer look at our ./github/workflows/pixi-crs-ci.yml file.

I will explain the different steps below. But I also give explanations in the comments in the provided yaml file.

name: Pixi-CRS CI Pipeline

# Trigger the workflow on push
# and pull requests
on: [push, pull_request]

jobs:
  build:
    name: Start Pixi and the CRS
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@master

#      - name: Debugging 
#        run: pwd
#      - name: Debugging 
#        run: ls

      - name: Starting Pixi and CRS with docker-compose up
        run: docker-compose -f docker-compose.yaml --env-file compose-gcp.env up -d

        # Application Tests with Testcafe
        # skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
      - name: Run Testcafe Tests Pixi without and with CRS
        run: docker run --volume /home/runner/work/pixi-crs/pixi-crs/testcafe/tests_container_ip:/tests --rm testcafe/testcafe --skip-js-errors 'chromium:headless --no-sandbox'

        # Show Full error.log
      - name: Show ModSecurity logs
        run: docker exec crs cat /var/log/apache2/error.log

        # ModSecurity Log Analysis:
        # Fail if ModSecurity log is not empty
        # Show ModSecurity logs of Testcafe Tests
        # If not empty -> Repair your application OR
        #              -> ModSecurity Tuning:
        # See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ OR
        #              -> GitHub issue: https://github.com/SpiderLabs/owasp-modsecurity-crs
      - name: Fail if ModSecurity logs are not empty
        run: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep -vi MyEvilWAFTest | grep -v 949110 | grep -v 980130 | grep msg; then echo "False Positive Found! Aborting!" && exit 1 ; else echo "ModSecurity Logs empty. This is good!"; fi

        # Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
        # That means CRS is not working properly or test was aborted.
      - name: Fail if WAF Test String is missing in ModSecurity logs
        run: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep MyEvilWAFTest; then echo "WAF Test String Found. This is good!"; else echo "WAF Test String not Found! Aborting!" && exit 1; fi

Pipeline Steps

Start Pixi and the CRS

We start Pixi and the CRS with one docker-compose up command and provide an --env-file. We don't need to install Docker or docker-compose, since it's already there.

Testcafe tests

Now that the CRS and Pixi are running, we perform the Testcafe tests. This time we can run the tests with the testcafe/testcafe Docker container. The tests can be mounted easily into this container.
Again, first, we test Pixi directly, then we test Pixi through the CRS. We also test the CRS itself with a malicious string. We want to ensure that the WAF blocks it.

For our tests, we call Pixi via http://172.17.0.1:8000 and the CRS via http://172.17.0.1:8080 because we call them from inside the Testcafe Docker container.

And this is how the Testcafe test output looks:

Check results

In the end, we check the results. We take a look at the ModSecurity log inside the CRS Docker container.
This is an important step that ensures that we did not have any false positives with our legitimate tests. In addition, we ensure that our malicious test was logged.

Trigger

Because Pixi-CRS is a CI pipeline and we want to run our GitHub Actions after every push and pull request, we need to configure a trigger.
I added this in our ./github/workflows/pixi-crs-ci.yml file by adding the following lines:

# Trigger the workflow on push
# and pull requests
on: [push, pull_request]

Things to mention

Pixi-CRS is a CI Pipeline and I did not configure the CD part.
In this blog, post I only wanted to show the CI part.

Next blog post

In the next and final blog post of this series I will sum up and compare all five available Pixi-CRS pipelines on CircleCI, Amazon Web Services, Azure DevOps, Google Cloud Platform and GitHub Actions.

Pixi-CRS goes to the Cloud - Part 4 : Google Cloud Platform

Franziska Bühler — Tue, 13 Oct 2020 06:41:13 +0000

The third cloud provider I moved Pixi-CRS to was Google Cloud Platform (GCP): https://console.cloud.google.com/

This is the fourth blog post in the series "Pixi-CRS goes to the Cloud".

This is how Pixi-CRS looks on Google Cloud Platform:

In the image above, we see that the Pixi-CRS CI Pipeline on GCP is configured as a GCP Cloud Build.

Pixi-CRS Pipeline Code

The code behind the pipeline can be found here.
GCP Cloud Build code is written in a cloudbuild.yaml file in the root directory of the repository. It's pretty easy to create a new Cloud Build on GCP. First, I had to create a project and "Enable Cloud Build".

Let's take a closer look at this cloudbuild.yaml file.

I will explain the different steps below. But I also give explanations in the comments in the provided yaml file.

# Google Cloud cloudbuild.yaml
#
steps:
# Start the OWASP ModSecurity Core Rule Set and Pixi with its DB with docker-compose
# OWASP ModSecurity Core Rule Set Container (Apache Reverse Proxy)
# owasp/modsecurity-crs
# See https://coreruleset.org/
# ModSecurity Tuning:
# See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/
- id: 'Starting Pixi and CRS with docker-compose up'
  name: 'docker/compose:1.26.2'
  args: ['--env-file', '/workspace/compose-gcp.env', 'up', '-d']

# Debugging possibilities
#- name: 'ubuntu'
#  args: [ "touch", "foo" ]
#- name: 'ubuntu'
#  args: [ "ls", "-l", "/workspace/testcafe/tests_container_ip" ]
#- name: 'ubuntu'
#  args: [ "pwd" ]
# Debugging with curl
#- name: 'curlimages/curl:7.69.0'
#  args: [ "-v", "http://172.17.0.1:8000/register"]
#- name: 'curlimages/curl:7.69.0'
#  args: [ "-v", "http://172.17.0.1:8080/register"]

# Application Tests with Testcafe
# skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
- id: 'Run Testcafe Tests: Pixi without and with CRS'
  name: 'gcr.io/cloud-builders/docker'
  args: [ "run", "--volume", "/workspace/testcafe/tests_container_ip:/tests", "--rm", "testcafe/testcafe", "chromium:headless --no-sandbox", "--skip-js-errors" ]

# Copy ModSecurity Logs:
- id: 'Copy ModSecurity logs'
  name: 'gcr.io/cloud-builders/docker'
 # args: [ "exec", "crs", "cat /var/log/apache2/error.log | grep ModSecurity" ]
  args: [ "cp", "crs:/var/log/apache2/error.log", "/workspace/error.log" ]

# Show ModSecurity Logs
- id: 'Show ModSecurity logs'
  name: 'ubuntu'
  args: [ "cat", "/workspace/error.log" ]

# ModSecurity Log Analysis:
# Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
# That means CRS is not working properly or test was aborted.

- id: 'Fail if ModSecurity log does not contain WAF Test String'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: "bash"
  args:
    - "-c"
    - |
        cat /workspace/error.log | grep -q MyEvilWAFTest
# Fail if ModSecurity log is not empty
# Show ModSecurity logs of Testcafe Tests
# If not empty -> Repair your application OR
#              -> ModSecurity Tuning:
# See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ OR
#              -> GitHub issue: https://github.com/SpiderLabs/owasp-modsecurity-crs
- id: 'Fail if ModSecurity log is not empty'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: "bash"
  args:
    - "-c"
    - |
        "cat /workspace/error.log grep ModSecurity | grep error | grep -vi MyEvilWAFTest | grep -v 949110 | grep -v 980130 && exit 1 || exit 0"
#- id: 'Fail if ModSecurity log is not empty'
#  name: 'gcr.io/cloud-builders/docker'
#  args: [ 'exec', 'crs', 'cat /var/log/apache2/error.log | grep ModSecurity | grep error | grep -vi "MyEvilWAFTest" | grep -v "949110" | grep -vi "980130" && exit 1 || exit 0' ]


# Debugging docker
#- id: 'Docker'
#  name: 'gcr.io/cloud-builders/docker'
#  args: [ "ps" ]

Pipeline Steps

Start Pixi and the CRS

We start Pixi and the CRS with one docker-compose up command and provide an --env-file. We don't need to install Docker or docker-compose, since we use the docker/compose image.

Testcafe tests

For our tests, we call Pixi via http://172.17.0.1:8000 and the CRS via http://172.17.0.1:8080 because we call them from inside the Testcafe Docker container.

And this is how the Testcafe test output looks:

Check results

In the end, we check the results. We have a look at the ModSecurity log inside the CRS Docker container.
This ensures that we did not have any false positives with our legitimate tests. In addition, we ensure that our malicious test was logged.

Trigger

Because Pixi-CRS is a CI pipeline and we want to run our GCP Cloud Build after every push into the repository, we need to configure a trigger on push events.
I added this via the option Cloud Build > Triggers > Create Trigger.

Things to mention

Pixi-CRS is a CI Pipeline and I did not configure the CD part.
In this blog post, I only wanted to show the CI part. And I'm also aware that a lot more Google Cloud Platform options are available. But for this blog post, I wanted to keep it simple and concentrate on the Pixi-CRS CI part.

Next blog post

In the next blog post in this series, I will implement the Pixi-CRS CI Pipeline in GitHub Actions.

Pixi-CRS goes to the Cloud - Part 3 : Microsoft Azure DevOps

Franziska Bühler — Tue, 06 Oct 2020 08:40:40 +0000

The second cloud provider to which I moved Pixi-CRS was Microsoft Azure DevOps: https://dev.azure.com/.

This is the third blog post in the "Pixi-CRS goes to the Cloud" series.

This is how Pixi-CRS looks on the Microsoft Azure DevOps Pipeline:

In the image above, we see that the Pixi-CRS CI Pipeline on Azure DevOps is configured as Azure DevOps > Pixi-CRS > Pipeline.

Pixi-CRS Pipeline Code

The code behind the pipeline can be found here.
Azure DevOps pipeline code is written in azure-pipeline.yml files in the root directory of the repository. It's quite easy to create a new pipeline project on Azure DevOps.

Let's take a closer look at this azure-pipelines.yml file.

I will explain the different steps below. But I also give explanations in the comments in the provided yaml file.

# Azure DevOps azure-pipelines.yml

trigger:
# Branch to trigger
- master

stages:

# Start the OWASP ModSecurity Core Rule Set and Pixi with its DB with docker-compose
# OWASP ModSecurity Core Rule Set Container (Apache Reverse Proxy)
# owasp/modsecurity-crs
# See https://coreruleset.org/
# ModSecurity Tuning:
# See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/
- stage: StartContainersAndTests
  jobs:
  - job: BuildJob
    steps:
      # Debugging
      # - script: pwd
      # - script: ls
      - task: DockerCompose@0
        displayName: Start Pixi and CRS
        inputs:
          containerregistrytype: 'Container Registry'
          dockerComposeFile: '**/docker-compose.yaml'
          action: 'Run a Docker Compose command'
          dockerComposeFileArgs: |
            CRSPORTHTTP=8080
            PROXYLOCATION=http://app:8000/
          dockerComposeCommand: 'up -d'

      # Application Tests with Testcafe
      # skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
      # Another way: https://devexpress.github.io/testcafe/documentation/continuous-integration/azure-devops.html
      # Debugging
      #- script: docker ps
      - script: docker run --volume /home/vsts/work/1/s/testcafe/tests_container_ip/:/tests testcafe/testcafe --skip-js-errors 'chromium:headless --no-sandbox'
        displayName: Run Testcafe Tests without and with CRS

      # Show Full error.log
      - script: docker exec crs cat /var/log/apache2/error.log
        displayName: Show ModSecurity logs

      # ModSecurity Log Analysis:
      # Fail if ModSecurity log is not empty
      # Show ModSecurity logs of Testcafe Tests
      # If not empty -> Repair your application OR
      #              -> ModSecurity Tuning:
      # See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ OR
      #              -> GitHub issue: https://github.com/SpiderLabs/owasp-modsecurity-crs
      - script: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep -vi MyEvilWAFTest | grep -v 949110 | grep -v 980130 | grep msg; then echo "False Positive Found! Aborting!" && exit 1 ; else echo "ModSecurity Logs empty. This is good!"; fi
        displayName: Fail if ModSecurity logs are not empty

      # Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
      # That means CRS is not working properly or test was aborted.
      - script: if docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep MyEvilWAFTest; then echo "WAF Test String Found. This is good!"; else echo "WAF Test String not Found! Aborting!" && exit 1; fi
        displayName: Fail if WAF Test String is missing in ModSecurity logs

Pipeline Steps

Start Pixi and the CRS

We start Pixi and the CRS with one docker-compose up command. We don't need to install Docker or docker-compose, it's already provided. But we need to configure a few things like the dockerComposeFileArgs, for example.
Then we start Pixi and the CRS with the dockerComposeCommand "up -d".

Testcafe tests

For our tests, we call Pixi via http://172.17.0.1:8000 and the CRS via http://172.17.0.1:8080 because we call them from inside the Testcafe Docker container.

And this is how the Testcafe test output looks:

Check results

Trigger

Because Pixi-CRS is a CI pipeline and we want to run our Azure DevOps pipeline project after every push into the repository, we need to configure a trigger on push events.
I added this via the "trigger: -master" entry in the azure-pipeline.yml file.

Things to mention

Pixi-CRS is a CI Pipeline and I did not configure the CD part.
In this blog post, I only wanted to show the CI part. And I'm also aware that a lot more Azure DevOps options are available. But for this blog post, I wanted to keep it simple and concentrate on the Pixi-CRS CI part.

Next blog post

In the next blog post, we will learn the Pixi-CRS pipeline on Google Cloud Platform.

Pixi-CRS goes to the Cloud - Part 2 : Amazon Web Services

Franziska Bühler — Wed, 30 Sep 2020 05:02:03 +0000

Let's start with the first Pixi-CRS Pipeline in the Cloud, namely on AWS: https://aws.amazon.com/console/.

This is the second blog post in the "Pixi-CRS goes to the Cloud" series. The intro blog post of this series can be found here.

This is how Pixi-CRS looks on Amazon Web Services:

In the image above, we see that the Pixi-CRS CI Pipeline on AWS was added as Developer Tools > CodeBuild > Build project.

Pixi-CRS Pipeline Code

The code behind the pipeline can be found here.
AWS pipeline code is written in buildspec.yml files in the root directory of the repository. It's pretty easy to create a new build project inside AWS. We just need to provide a "Project Name", a source repository, choose the option "Use a buildspec file" and enable logs.

Let's have a closer look at this buildspec.yml.

I will explain the different steps below. But I also give explanations in the comments in the provided yaml file.

# AWS buildspec.yml
#
version: 0.2
phases:
  install:
    runtime-versions:
      docker: 19

  build:
    commands:
      # We install testcafe. We don't run it in Docker, because volumes can not be mounted!
      # They probably could be mounted in a docker-compose, but let's run testcafe another way...
      - npm install -g testcafe
      # Start the OWASP ModSecurity Core Rule Set and Pixi with its DB with docker-compose
      # OWASP ModSecurity Core Rule Set Container (Apache Reverse Proxy)
      # owasp/modsecurity-crs
      # See https://coreruleset.org/
      # ModSecurity Tuning:
      # See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/

      # We have to install a higher version of docker-compose manually
      # so that --env-file is available
      # Unfortunately -e does not work, even with a higer docker-compose version
      - curl -L https://github.com/docker/compose/releases/download/1.26.2/docker-compose-`uname -s`-`uname -m` > ~/docker-compose
      - chmod +x ~/docker-compose
      - mv ~/docker-compose /usr/local/bin/docker-compose
      - docker-compose -v
      - cat compose-aws.env
      - docker-compose --env-file compose-aws.env up -d

      # Application Tests with Testcafe
      # skip-js-errors because of: Uncaught Error: Bootstrap tooltips require Tether
      - testcafe "chrome:headless" testcafe/tests_localhost/test.js --skip-js-errors
      # Application Tests with CRS with Testcafe
      - testcafe "chrome:headless" testcafe/tests_localhost/testcrs.js --skip-js-errors
      # WAF Tests with malicous request to test WAF itself
      - testcafe "chrome:headless" testcafe/tests_localhost/testwaf.js --skip-js-errors

  post_build:
    commands:
      # Fail if ModSecurity log is not empty
      # Show ModSecurity logs of Testcafe Tests
      - docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep error | grep -vi "MyEvilWAFTest" | grep -v "949110" | grep -vi "980130" && echo "False Positive Found. Check Logs. Aborting!" && exit 1 || exit 0

      # If not empty -> Repair your application OR
      #              -> ModSecurity Tuning:
      # See https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ OR
      #              -> GitHub issue: https://github.com/SpiderLabs/owasp-modsecurity-crs

      # Fail if ModSecurity log does not contain WAF Test String "MyEvilWAFTest"
      # That means CRS is not working properly or test was aborted.
      - docker exec crs cat /var/log/apache2/error.log | grep -q MyEvilWAFTest

      # Show ModSecurity Full Logs:
      - docker exec crs cat /var/log/apache2/error.log | grep ModSecurity | grep msg

If you want to read a full description of the CircleCI Pixi-CRS pipeline, you should have a look at this blog post.

Pipeline Steps

Installing Testcafe

This is the only pipeline that uses an installation of Testcafe. All other pipelines will use Testcafe in the testcafe/testcafe Docker container.
We use an installation of Testcafe because, at the time of this writing, I was not able to mount volumes into Docker containers on AWS, and Testcafe Docker uses volumes to mount the tests.

npm install -g testcafe

Installing docker-compose

Docker-compose is already available in the base image we use. However, we use a newer version of docker-compose because we want to use the argument --env-file.

Start Pixi and the CRS

We start Pixi and the CRS with one docker-compose up command. We provide an env-file that configures the listening port of the CRS container and the backend of the CRS container:

docker-compose --env-file compose-aws.env up -d

Testcafe tests

Now that the CRS and Pixi are running, we perform the Testcafe tests. First, we test Pixi directly, then we test Pixi through the CRS. We also test the CRS itself with a malicious string. We want to be sure that the WAF will block it.

For our tests, we call Pixi via http://localhost:8000 and the CRS via http://localhost because we installed testcafe and we now call the exposed Pixi and the CRS ports on localhost.

And this is how the Testcafe test output looks:

Check results

In the end, we check the results. We take a look at the ModSecurity log inside the CRS Docker container.
This is the important step that ensures that we did not get any false positives with our legitimate tests.
In addition, we ensure that our malicious test was logged.

Trigger

Because Pixi-CRS is a CI pipeline and we want to run our CodeBuild project after every push into the repository, we need to configure a trigger on push events.
This can be done in: Developer Tools > CodeBuild > Build projects > Pixi-CRS > Edit Source > Webhook. I want to trigger a build every time a code change is pushed to the Pixi-CRS GitHub repository.
I also see this webhook in GitHub then.

Things to mention

I didn't configure an AWS CodeDeploy or an AWS CodePipeline. These would be the next steps to deploy Pixi-CRS somewhere and also have Continuous Deployment. In this blog post, I only wanted to show the CI part. And I'm also aware that a lot more AWS options are available. But for this blog post, I wanted to keep it simple and concentrate on the Pixi-CRS CI part.

Next blog post

In the next blog post, we will get to know the Pixi-CRS pipeline on the Azure DevOps Pipeline.

Pixi-CRS goes to the Cloud - Part 1: Intro

Franziska Bühler — Tue, 22 Sep 2020 11:30:01 +0000

Some of you may have heard of DevSlop's Pixi-CRS pipeline.
This Continuous Integration (CI) pipeline ensures that developers receive feedback early and often on their Web Application Firewall (WAF) and their application behind the WAF.
The first Pixi-CRS pipeline was built on CircleCI.

DevSlop's goal is to learn about and teach security. And, of course, we also want to learn about pipelines and security in the cloud!
So, implementing the Pixi-CRS pipeline on cloud providers (such as Google Cloud Platform (GCP), Amazon Web Services (AWS) and Microsoft Azure) and as a GitHub Action was obvious.

But first, let's take a step back and see what problem the Pixi-CRS pipeline solves for us.

What is a Web Application Firewall?

Of course, a web application should be implemented securely. But we never have a guarantee that the code is 100 per cent secure.
A Web Application Firewall (WAF) is an additional layer of defense in front of a web application against attacks. It's not a silver bullet against all attacks, but it makes it harder to exploit an existing vulnerability in a web application. A WAF logs and inspects the HTTP traffic and blocks malicious traffic based on patterns or rules.

A very popular and widely used Web Application Firewall is ModSecurity with the OWASP ModSecurity Core Rule Set.

What is Pixi?

Pixi is one module in the OWASP DevSlop project. It is an intentionally vulnerable web application and API for learning about web application security. More information can be found in one of my earlier blog posts.

As the name suggests, Pixi-CRS is a combination of Pixi and the Core Rule Set.
What I particularly like about Pixi-CRS is that it combines two OWASP projects ❤: OWASP DevSlop and the OWASP ModSecurity Core Rule Set.

Problem

Web Application Firewalls can have so-called false positives. A false positive is a legitimate HTTP request or response that smells a bit like an attack, but is actually not an attack. These false positives can hurt in production if they prevent legitimate users from using the web application properly.

These false positives hurt even more in a DevOps environment where everything is fully automated and well-tested. In the end, a WAF is added to production without testing it! That's too late! The operator will probably turn off the WAF so that the user can work again. And that's very bad.

False positives can be tuned away, but to do this, they have to be discovered first.

Solution: Testing in CI Pipeline

If we have automated web application tests, end-to-end or UI tests in a CI Pipeline, we should add the WAF to those tests. And that's exactly what the Pixi-CRS pipeline does.

What is Continuous Integration?

Continuous Integration and Continuous Delivery together form Continuous Deployment. Continuous Deployment means that code changes are merged, built, tested and shipped to production very often.

Pixi-CRS CI Pipeline

The Pixi-CRS Pipeline is a Continuous Integration (CI) Pipeline that focuses on building and testing.
Every code change triggers a CI pipeline that performs the following steps:

Start Pixi in a Docker container
Start the WAF ModSecurity with the CRS in a Docker container in front of Pixi
Loads ModSecurity Tuning rules (in case we have already eliminated false positives)
Application tests directly against Pixi
Application tests through the WAF against Pixi
WAF test with a malicious string
Test if WAF Logs from legitimate tests are empty
Test if our malicious test string was logged

If no false positives occurred and the application tests were successful, the code change can be merged into master. We provide early feedback to the developer on false positives. This means that we always have Pixi in a deployable and runable state, even with a WAF (the CRS) in front of it.
Pixi-CRS does not have a CD portion and is currently not deployed anywhere.

Pixi-CRS Tests

The Pixi-CRS pipeline has web application tests that are used to test Pixi. The tests do the following:

Register a user in Pixi
Log in as this user
Searches for a string in Pixi's search box
Clicks "About"
Clicks "My Profile" and changes Name
Log out the user

Pixi-CRS goes to the Cloud

The first Pixi-CRS pipeline was built on CircleCI. A detailed description of this pipeline can be found in one of my earlier blog posts.

And now Pixi-CRS is going to the cloud.
We wanted to learn if we could also implement Pixi-CRS on Google Cloud Platform, Amazon Web Services, Azure Pipelines and GitHub Actions.
And we've been successful!

This was an intro blog post about the new Pixi-CRS cloud pipelines and beginning of a series.
In the next blog posts, I will show what Pixi-CRS looks like in the cloud: on Amazon Web Services, Google Cloud Platform, Azure Pipelines and as GitHub Actions...

Jobs in Information Security (InfoSec)

Tanya Janca — Fri, 27 Dec 2019 05:11:17 +0000

**This article is for beginners, not experts. :-D

Almost all of the people who respond to my #CyberMentoringMonday tweets each week say that they want to "get into InfoSec" or "become a Pentester"; they rarely choose any other jobs or are more specific than that. I believe the reason for this is that they are not aware of all the different areas within the field of Information Security (InfoSec for short, and "Cyber" for those outside of our industry). I can sympathize; I was in the same position when I joined. I knew three Penetration Testers and lots of Risk Analysts and I had no clue that there were several other areas that may interest me or even existed. I knew I didn't want to be a Risk Analyst, so I thought the only other option was PenTester. Now I know that is not at all true. This blog post will detail several other areas within the field of Information Security in hopes that newcomers to our field can find their niche more easily. It will not be exhaustive, but I'll do my best.

Image by Henry Jiang of Oppenheimer & Co.

The above image shows 8 different potential areas within the field of Information Security according to the author, Henry Jiang; Governance, Risk, Career Development, User Education, Standards, Threat Intelligence, Security Architecture and Security Operations.

Since I come from the software development side of IT, and have done almost exclusively coding, my view is going to be extremely biased. With that in mind, the first area you may want to consider is Application Security (AppSec); any and all work towards ensuring that software is secure. This is the field that I work in, so it will have the most detail. There are all sorts of jobs within this field, but the most well-known is the web app pentester (sometimes called an ethical hacker); a person who does security testing on software. Such a person is often a consultant, but can also work in large companies. They test one system, intensively, perform a lot of manual testing, and then move on.

Jobs in Application Security:

Application Security Engineer - you do a mix of all the things listed under AppSec and you are generally a full-time employee. This includes making customer tools, launching a security champion program, writing guidelines, and anything else that will help ensure the security of your organization's apps. I personally consider this the sweet spot, as I get to do changing and interesting work, and see the security posture improve over time. It is, however, usually a more senior role.
Threat Modeller, working with developers, business representatives and the security team (that's you in this scenario) to find and document potential threats to your software, then create plans to test for and fix the issues.
Vulnerability Assessment: running lots of scans, all the time, of everything. You can scan the network too. Ideally you will do more than this, to assess the security of the systems in your care, but it depends on where you work. This position is often an employee position and you tend to have prolonged relationships with the systems and teams you assess.
Vulnerability Management: Keeping Track of the vulnerabilities that all the tools and people find, reporting to management about it, and planning from a higher level. For instance; attempting to wipe out an entire bug class, implementing new tools because you see a deficiency, resource planning, etc. This is an employee position usually, and often a manager role or team lead.
Secure Code Reviewer: reading lots of code, using SAST (static application security testing) tools and SCA (Software Composition Analysis - are our 3rd party components secure?), finding vulnerabilities in written code and helping developers fix it.
DevSecOps Engineer: an AppSec engineer working in a DevOps environment. Same goal, different tactics. Adding security checks to pipelines, figuring out how to secure containers and anything else your DevOps engineers are up to.
Developer Education: this is usually a consultant role, but sometimes for large companies someone can do this full time. The person teachers the developers to write secure code, the architects to design secure apps, threat modelling, and any other topic they can think of that will help ensure their mandate (secure apps). This person is likely also to training the security champions.
Governance: writing policies, guidelines, standards, etc, to ensure your apps are secure. This job is usually someone that does all the governance stuff for your org and the person is working with the AppSec team to get the details right, OR this person is likely a consultant because this is not an activity that needs to be re-done constantly.
Incident Response: this area includes jobs as an incident manager (you boss everyone around and make sure the incident goes as smoothly as possible), and investigations (Forensics/DFIR). Investigating incidents related to insecure software is a topic I personally find thrilling; detective work is exciting! But with the stress it causes, it's not for everyone.
Security Testing: sometimes called Penetration Testing, sometimes called Red Teaming, sometimes not officially recognized as a job because management isn't "ready" to admit they need this yet. This person tests the software (and sometimes networks) to ensure they are secure. This includes manual testing, using lots of tools, and trying to break things without causing a huge mess.
Design Review: This is called a "Security Archtect" but AppSec folks are often asked to review designs for potential security flaws. If asked, say yes! It's super fun and always educational. Bonus; it's a good way to build trust between security and the developers. In AppSec you will also be asked to do a range of other things because that's how life is. Potential asks; install this giant AppSec tool and figure out how it works, create a proof of concept for an exploit to show everyone that it is/is not a problem, create a proof of value with a new AppSec tool we are considering acquiring, get all the developers to log their apps like 'so' in order for the SIEM can read the results, research how to do something securely when you have no idea how to do that thing at all, etc. Like I said, it's super fun!

ISACA Victoria, Dec 2019

SOC Analyst/Threat Hunter: SOC analysts interpret output from the monitoring tools to try to tell if something bad is happening, while threat hunters go looking for trouble. This is mostly network based, and I'm not good at networks, otherwise I would have been all over this when I moved into security. The idea of threat hunting (using data and patterns to spot problems), is very appealing to my metric-adoring brain. Note: SOC Analysist is a junior or intermediate position and threat hunter is not a junior position, but if you want to get into InfoSec they are basically always hiring for SOC Analysts, at almost every company.

Security Architect (apps, cloud, network): Security architects ensure that designs are secure. This can mean reviewing a deployment, network or application design, adding recommendations, or even creating the design themselves from scratch. This tends to be a more senior role.
Risk Analyst: Evaluate systems to identify and measure risk to the business, then offer recommendations on how to mitigate or when to accept the risks. This tends to be coupled closely with Compliance, and Auditing, which I won't describe here because I am shamefully under-educated in this area.

Security Policy Writer: Writing policies about security, such as how long network passwords need to be, that all public-facing web apps must be available via HTTPS, and that only TLS 1.2 and higher are acceptable on your network. Deciding, writing, socializing and enforcing these policies are all part of this role.

Malware Analyst/Reverse Engineer: Someone needs to look at malware and figure out how it works, and sometimes people need to write exploits (for legitimate reasons, such as to prove that something is indeed vulnerable, or… You need to ask them). If you enjoy puzzles and really low level programming (such as ARM, assembler, etc), this job might be for you. But be careful; playing with malware at home is dangerous.

Chief Information Security Officer (CISO or CSO): 'The boss" of security. This person (hopefully) has a seat at the executive table, directs all security aspects for a company, and is the person held responsible, for better or for worse. If you enjoy running programs, managing things from a high level, and making a big difference, this might be a role for you.

Blue Team/Defender/Security Engineer (enterprise security/implements security tools): The people that keep us safe! These people install tools, run the tools, monitor, patch, and freak out when people download and install things to their desktops without asking. They perform security operations, making sure all the things happen. While those in the SOC (Security operations centre), monitor everything that's happening and respond when there are problems.

There are many, many, many jobs within the field of Information Security, please feel free to list some of the ones that I missed in the comments below. I hope this information helps more of you join our industry, because we need all the help we can get!

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

DevSlop's Pixi-CRS Pipeline

Franziska Bühler — Thu, 19 Dec 2019 09:25:46 +0000

A Web Application Firewall (WAF) raises concerns that it does not fit into the DevOps methodology. The problem is that when a WAF is added to production, the impact on the application is tested too late. The application developer gets extremely late feedback and the WAF could break the application. This can lead to production issues.

But what if a WAF is involved in the DevOps process very early on and not just at the end, at production?

The whole DevOps process only makes sense when all components are part of it! A service can only be successfully complemented by a WAF if the WAF is part of the pipeline from the beginning. I will show how to integrate a WAF, specifically ModSecurity with the Core Rule Set, and its testing into continuous integration. The CI-pipeline called Pixi-CRS is one of DevSlop's modules.

For those of you who want to learn more about the web application Pixi and its known vulnerabilities, read my former blog post.

Problem

Despite the fact that the number of false positives has been massively reduced in CRS3, there is still the possibility that legitimate traffic from a legitimate user might trigger a CRS rule. This means the user receives a ‘403 – Forbidden’ message and can’t use the full application functionality. She or he gets blocked.

This problem is even worse in a DevOps culture. Everything is fully automated and well-tested and in the end, we add a WAF to production and kill the whole positive experience: When production issues arise, it is often too late to find and correct the problems. Instead, an operator is likely to disable the WAF and never re-enable it again. This is because operators have a lot of other work to do and security is not always the top priority.

Solution

The solution is to insert the WAF / CRS very early in the DevOps process and give the developers and operators early feedback:

If we automate application tests, we must add the CRS to these tests. All tests have to succeed first without, then with the CRS! Additionally, no CRS rule should be triggered by the tests.
Each commit of the application code into the repository triggers a continuous integration run. This launches the application, starts the WAF and runs the application tests.
We are thus testing an application with the CRS after every commit of the code.
We always want to have the application in a deployable and runnable state with the CRS.
This way, we know that our current app version’s traffic is not blocked by the CRS.
We guarantee this by testing the application and the CRS in a production-like environment. There can always be false positives. We can remove them by tuning the rules via the configuration.
If we have to perform these adjustments to the CRS, we already have our configuration for production because we tested it in a production-like environment.
The application should not go to release until it is fully tested with the CRS!
An application whose legitimate traffic triggers a rule should not go into production until the error is fixed either. With every false positive, we need to decide if it is something we can fix in the application, or if the CRS needs to be tuned.
This way, the application’s traffic is tested with the CRS and we don’t have to fear production issues later on.

CRS Docker Container

As you can read at https://coreruleset.org/installation, it only takes a few steps to install the Core Rule Set. And it gets even easier if you use it in a Docker Container.

The official CRS Docker image has a reverse proxy configuration to put it in front of a web application and various configurable CRS variables. With this container, the CRS can be very quickly and easily integrated into automated tests.

Here is how to run the container:

docker run -dt -e PARANOIA=1 -e \
ANOMALYIN=5 -e ANOMALYOUT=4 -e PROXYLOCATION=http://172.17.0.1:8000/ \
owasp/modsecurity-crs

Among others, the following environment variables are configurable:

PARANOIA: paranoia_level
ANOMALYIN: inbound_anomaly_score_threshold
ANOMALYOUT: outbound_anomaly_score_threshold
PROXYLOCATION: IP address and TCP port of application backend

Explanations of the individual parameters can be found in the main CRS configuration file crs-setup.conf (current version: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.3/dev/crs-setup.conf.example) or as part of the tutorial series about ModSecurity and CRS at netnea.

Proof of Concept: DevSlop's Pixi-CRS pipeline

I have implemented a proof of concept in CircleCI. This Pixi-CRS pipeline (https://github.com/DevSlop/pixi-crs) is one of DevSlop's modules. Of course, the continuous integration can also be implemented on TravisCI, Jenkins, and so on. Then I used TestCafe to write the application tests. It’s a Node.js tool for performing end-to-end tests.

In the basic setup, we have application tests that are performed against the application. Naturally, these application tests should succeed:

As a next step, we put CRS in front of the same application in order to funnel the same tests through the WAF. We expect the application tests to still succeed and the log to remain empty. This would confirm that no CRS rule were triggered by the tests.

Each of these components runs in a separate Docker container.

The time taken to pull and start the Core Rule Set container and to run the application tests are only a small part (approx. 1 minute and 30 seconds in this PoC) of the overall testing process (approx. 3 minutes and 30 seconds in my example).

The message here is: We do not waste a lot of time but get a lot of extra security.

CI Configuration

In summary, the CircleCI configuration .circleci/config.yml consists of the following steps:

# .circleci/config.yml
version: 2
jobs:
   build:
      docker:
         - image: circleci/node:stretch
      steps:
         -run:
             name: Install dependencies
             ...
         -run
             name: Install Docker Compose
             ...
         -setup_remote_docker
         -checkout
         -run:
             name: Start App Container Pixi
             ...
         -run:
             name: Start OWASP ModSecurity CRS Container in front of application for application tests
             #http://172.17.0.2:443
             #we set inbound and outbound anomaly score to 1, no tolerance
             command: |
                docker pull owasp/modsecurity-crs:v3.2-modsec2-apache && \
                docker run -dt --name apachecrstc -e PARANOIA=2 \
                -e ALLOWED_METHODS='GET HEAD POST OPTIONS PUT' -e \
                ANOMALYIN=1 -e ANOMALYOUT=1 -e PROXYLOCATION=http://172.17.0.1:8000/ \
                --expose 80 owasp/modsecurity-crs:v3.2-modsec2-apache
         -run:
             name: ModSecurity Tuning - Load rule exclusions
             command: |
                printf '# Rule 942450 (msg: SQL Hex Encoding Identified) triggers,\n' > tmp.conf
                printf '# because of random characters in the session cookie.\n' >> tmp.conf
                printf '\nSecRuleUpdateTargetById 942450 "!REQUEST_COOKIES:session"\n' >> tmp.conf
                # CRS container for application tests:
                docker cp tmp.conf apachecrstc:/etc/httpd/modsecurity.d/owasp-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf;
                docker exec apachecrstc /usr/sbin/httpd -k graceful
         - run:
             name: Application Tests with Testcafe
             command: |
                # https://circleci.com/docs/2.0/building-docker-images/#mounting-folders
                # creating dummy container which will hold a volume with config
                docker create -v /tests --name configs alpine:latest /bin/true
                # copying config file into this volume
                docker cp /home/circleci/project/testcafe/tests/test.js configs:/tests
                # starting application container using this volume
                docker pull testcafe/testcafe
                docker run --volumes-from configs:rw --name testcafe -it testcafe/testcafe 'chromium:headless --no-sandbox' /tests/test.js
         - run:
             name: Application Tests with CRS with Testcafe
             command: |
                docker cp /home/circleci/project/testcafe/tests/testcrs.js configs:/tests
                docker run --volumes-from configs:rw --name testcafecrs -it testcafe/testcafe 'chromium:headless --no-sandbox' /tests/testcrs.js
         - run:
             # Fail if ModSecurity log is not empty
             name: Show ModSecurity logs of Testcafe Tests
             ...
         - run:
            # Fail if ModSecurity log does not contain WAF Test String "My evil WAF Test"
            # '<script>alert("My evil WAF Test")</script>'
            name: Search for WAF Test String "My evil WAF Test" in ModSecurity logs
            ...

For all details see Pixi-CRS on GitHub:

https://github.com/DevSlop/pixi-crs/blob/master/.circleci/config.yml

Let’s go through the steps and take a closer look:

Step “Spin up Environment”

First, we have to tell CircleCI which image to use for the primary Docker Container. That is where all of the following steps are performed.

Steps “Install dependencies”, “Install Docker Compose” and “setup_remote_docker”

Then we want CircleCI to install some dependencies, docker-compose and docker.

Step “checkout”

The configuration .circleci/config.yml is in the root of the application repository. And in step ‘checkout’, CircleCI checks out the application code, where the .circleci/config.yml resides.

Step “Start App Container”

In the next step, we start the application Pixi in a container.

Step “Start OWASP ModSecurity CRS Container in front of application for application tests”

Then we start our CRS container in front of the application we have just started above.

Step “ModSecurity Tuning – Load rule exclusions”

In this step, we have the ability to tune the ModSecurity / CRS setup. We exclude certain rules or we hide certain parameters from the set of over 150 rules to avoid false positives and to keep the logfile empty.

Step “Application Tests with Testcafe”

Here, we perform the application tests against the TCP port of the application container. We do this to be sure that the application and the application tests are working. We want to distinguish failed application tests caused by the application itself from false positives introduced by CRS.

Step “Application Tests with CRS with Testcafe”

We repeat the application tests, but this time via the WAF / CRS. This is done by pointing the tests against the TCP port of the CRS container. Of course, these tests must be successful, too. In addition to the existing application tests, we add a WAF test to be sure that the CRS really triggers: We send an Cross Site Scripting (XSS) payload to a search form and expect the CRS to block the attack.

Step “Show ModSecurity logs of Testcafe Tests”

In the end, we check the results: The ModSecurity log should be empty. This means that no CRS rule was triggered by the standard application tests.

Step “Search for WAF Test String “My evil WAF Test” in ModSecurity logs

We also test that our intentionally added XSS string appears in the log. If it does not appear, either the tests have been aborted or the CRS did not work properly and we should look into this.

In the image above, we don't see any problem. That means this application can be released.
The message here is: If and when every step is successful and the application works behind the CRS, then the application can go into production!

Recommendations for Production

This PoC covers the continuous integration part. But of course, it could be extended to an entire deployment pipeline.

To do all this in production, I recommend the following:

The more tests you write, the better!
But at least test your login process. I often see false positives in cookies and cookie names in production, if, for example, special characters or random strings are used.
Click through your entire application. Testing all GET and POST arguments covers a broad part of the application. I also often see problems there.
The broader the tests are, the better the chance to get all possible false positives caused by the application’s legitimate traffic.
Perform your tests during continuous integration with a very low inbound and outbound anomaly threshold.
We want to see and alert every false positive.
If there are false positives in production (lack of tests?), then write a test for every issue discovered this way. This makes sure the false positives goes away.
Each new feature of the application should be covered by a test. Of course, this should always be the case, but it’s even more important with CRS in place.
You will probably have to adapt the CRS Docker container to fit into your organization.
Take the CI pipeline and the Docker container of this PoC and customize it for your organization. This PoC is meant to give you free samples of how to implement a pipeline with a WAF in it.

References

The backend application I tested in this PoC is the Pixi application from the OWASP project DevSlop.
The OWASP DevSlop project consists of several modules, all aimed at either presenting proof-of-concept DevSecOps pipelines, or insecure implementations of DevOps to teach better practices.

The CircleCI configuration can be found on GitHub. Please take this example and customize it for your organization.

The CRS Docker image can be found at DockerHub.

One of the triggers of the idea behind this blog post is the book ‘Securing DevOps’ by Julien Vehent.

The ModSecurity Guides by Christian Folini provide the basic knowledge to understand the concepts and inner working of CRS and ModSecurity.

This is a crosspost from https://coreruleset.org.

How the OWASP ModSecurity Core Rule Set protects the vulnerable web application Pixi by OWASP DevSlop

Franziska Bühler — Sun, 01 Dec 2019 06:56:16 +0000

How could the functionality of a WAF be better demonstrated than with a vulnerable web application?

In this blog post I introduce Pixi, an intentionally vulnerable web application by the OWASP project DevSlop. I show its known vulnerabilities and examine how the OWASP ModSecurity Core Rule Set (CRS) protects against these vulnerabilities.

What is Pixi?

Pixi is a deliberately vulnerable web application that is part of the OWASP DevSlop project. It's a hacker playground written by Nicole Becher. Most of you may know the DevSlop YouTube shows with Tanya Janca and Nancy Gariché.

The good news is, the vulnerable web application Pixi can be protected with the Core Rule Set in a very effective way!

What is the OWASP ModSecurity Core Rule Set?

The CRS is a rule set for a Web Application Firewall (WAF) such as ModSecurity. Its purpose is to defend against common web application attacks. It's the first line of defense in front of a (potential vulnerable) web application.

Setup

To start Pixi and the CRS in front of it, I use the official docker-compose.yaml provided by the Core Rule Set and I add the Pixi part below the CRS part:

# This docker-compose file starts owasp/modsecurity-crs

version: "3"

services:

  crs:
    image: owasp/modsecurity-crs
    ports:
      - "80:80"
      # only available if SETTLS was enabled:
      - "443:443"

    environment:
      - SERVERNAME=localhost

      #############################################
      # CRS Variables
      #############################################
      # Paranoia Level
      - PARANOIA=1
      # Inbound and Outbound Anomaly Score Threshold
      - ANOMALYIN=5
      - ANOMALYOUT=4
      # Executing Paranoia Level
      # - EXECUTING_PARANOIA=2

      #######################################################
      # Reverse Proxy mode
      # (only available if SETPROXY was enabled during the
      # parent ModSecurity image)
      #######################################################
      # PROXYLOCATION: Application Backend of Reverse Proxy
      - PROXYLOCATION=http://app:8000/

  db:
    image: deadrobots/pixi:datastore
    container_name: pixidb
    expose:
      - "27017"
      - "28017"

  app:
    image: deadrobots/pixi:app
    ports:
      - "127.0.0.1:8000:8000"
      - "127.0.0.1:8090:8090"

The image owasp/modsecurity-crs is the new official OWASP ModSecurity Core Rule Set container image. It supports the TLS and PROXY mode per default.
We use the standard installation, the Paranoia Level 1 and an inbound anomaly threshold of 5 and outbound anomaly threshold of 4. The backend, Pixi, runs on port 8000 and we set the PROXYLOCATION env var to the service app with port 8000. The CRS Reverse Proxy listens on port 80 and 443.

I will use port 80 for demonstration, but it’s very easy to mount a valid TLS server certificate into the container and provide proper TLS.

Pixis Vulnerabilities

Let’s now dive into Pixi’s weaknesses:

Authentication bypass

With a simple Mongo DB injection, the authentication can be bypassed. For further reading about this class of vulnerabilities, see here.

Unfortunately, I can not show this vulnerability. As soon as I replay this request in ZAP (OWASP Zed Attack Proxy) the application Pixi dies. You could say it’s a remote DoS on top of the authentication problem. One more reason the use CRS to protect us from this problem!

When I replay the request through the CRS, Pixi doesn’t die anymore, because CRS blocks the request at Paranoia Level 1:

The logfile tells us that the MongoDB injection was detected (id: 942290). It says that the access was denied (id: 949110) and that the Inbound Anomaly Score of the request at PL1 was 5 (id: 980130). The last two log file entries (id: 949110 and 980130) always occur with a blocked request.

[Mon Sep 09 07:40:47.839300 2019] [:error] [pid 44:tid 139999475324672] 
[client 192.168.0.1:59602] [client 192.168.0.1] ModSecurity: Warning. 
Pattern match “(?i:(?:\\\\[\\\\$(?:ne|eq|lte?|gte?|n?
in|mod|all|size|exists|type|slice|x?or|div|like|between|and)\\\\]))” at 
ARGS_NAMES:pass[$ne]. [file “/etc/modsecurity.d/owasp-crs/rules/REQUEST-
942-APPLICATION-ATTACK-SQLI.conf”] [line “367”] [id “942290”] [msg “Finds 
basic MongoDB SQL injection attempts”] [data “Matched Data: [$ne] found 
within ARGS_NAMES:pass[$ne]: pass[$ne]”] [severity “CRITICAL”] [ver 
“OWASP_CRS/3.2.0”] [tag “application-multi”] [tag “language-multi”] [tag 
“platform-multi”] [tag “attack-sqli”] [tag “OWASP_CRS”] [tag 
“OWASP_CRS/WEB_ATTACK/SQL_INJECTION”] [tag “WASCTC/WASC-19”] [tag 
“OWASP_TOP_10/A1”] [tag “OWASP_AppSensor/CIE1”] [tag “PCI/6.5.2”] 
[hostname “localhost”] [uri “/login”] [unique_id “XXYB-
5tiXQGQt80jpPMnxgAAAJc”], referer: http://localhost:80/login


[Mon Sep 09 07:40:47.845881 2019] [:error] [pid 44:tid 139999475324672] 
[client 192.168.0.1:59602] [client 192.168.0.1] ModSecurity: Access 
denied with code 403 (phase 2). Operator GE matched 5 at 
TX:anomaly_score. [file “/etc/modsecurity.d/owasp-crs/rules/REQUEST-949-
BLOCKING-EVALUATION.conf”] [line “91”] [id “949110”] [msg “Inbound 
Anomaly Score Exceeded (Total Score: 5)”] [severity “CRITICAL”] [tag 
“application-multi”] [tag “language-multi”] [tag “platform-multi”] [tag 
“attack-generic”] [hostname “localhost”] [uri “/login”] [unique_id “XXYB-
5tiXQGQt80jpPMnxgAAAJc”], referer: http://localhost:80/login


[Mon Sep 09 07:40:47.849314 2019] [:error] [pid 44:tid 139999475324672] 
[client 192.168.0.1:59602] [client 192.168.0.1] ModSecurity: Warning. 
Operator GE matched 5 at TX:inbound_anomaly_score. [file 
“/etc/modsecurity.d/owasp-crs/rules/RESPONSE-980-CORRELATION.conf”] [line 
“86”] [id “980130”] [msg “Inbound Anomaly Score Exceeded (Total Inbound 
Score: 5 – SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): 
individual paranoia level scores: 5, 0, 0, 0“] [tag “event-correlation”] 
[hostname “localhost”] [uri “/login”] [unique_id “XXYB-
5tiXQGQt80jpPMnxgAAAJc”], referer: http://localhost:80/login

As the logfiles are a bit hard to read, I will shorten the output of the next vulnerabilities and use Christian Folini’s alias melidmsg. For further information about his aliases, see Christian’s tutorials.

Angular Constructor Injection

Under special circumstances an Angular template injection is possible. This can happen when client side security checks are disabled (that must not be disabled). For further reading, please see here.

So let’s see what Pixi does with this command in the login mask:

{{constructor.constructor('alert(1)')()}}

Ooops, we showed a popup window through XSS!

So let’s see what the Core Rule Set does with this command:

The CRS at Paranoia Level 1 does not detect this Angular injection. Why could this happen?

That’s possible because the CRS is not meant to protect us from every exploit at Paranoia Level 1.

There are 4 Paranoia Levels available. If our web application is critical and if we want to assure that our web application is well protected we should consider raising the Paranoia Level. This will enable additional rules giving you a rule set with better coverage. But unfortunately also with more false positives.

Let’s do this and see what the CRS does at PL2:

The request is now blocked and the log confirms this:

$ cat my-alert-error.log | melidmsg
941380 AngularJS client side template injection detected
942370 Detects classic SQL injection probings 2/3
942430 Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)
949110 Inbound Anomaly Score Exceeded (Total Score: 13)
980130 Inbound Anomaly Score Exceeded (Total Inbound Score: 13 - SQLI=8,XSS=5,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 0, 13, 0, 0

An Angular template injection was discovered. That’s correct! By the way the rule 941380 is one of many new rules in CRS 3.2.

And also two SQLi rules triggered. That’s possible, because the SQL Injection is the most covered vulnerability and the detection is very strong there. Therefore very often SQLi rules, especially at higher PLs, also trigger. But that’s not a problem as far as they protect us and as far as they do not generate False Positives. If they protect us, they are very welcome.

XSS on search field

The next vulnerability is a XSS weakness in the search field.

The following string entered in the search field shows a popup, that demonstrates us the XSS weakness:

<script>alert('xss')</script>

The Core Rule Set at PL1 blocks this XSS test request:

In the logs we see that three XSS rules were triggered by this request and we got a Inbound Anomaly Score of 15 at PL1!

$ cat my-alert-error.log | melidmsg
941100 XSS Attack Detected via libinjection
941110 XSS Filter - Category 1: Script Tag Vector
941160 NoScript XSS InjectionChecker: HTML Injection
949110 Inbound Anomaly Score Exceeded (Total Score: 15)
980130 Inbound Anomaly Score Exceeded (Total Inbound Score: 15 - SQLI=0,XSS=15,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 15, 0, 0, 0

Verbose Errors

When not logged in as an admin of the application, the access to the admin path throws an HTTP 500 error. This error reveals some information about the application:

When accessing the secret page, the error even shows a hint to a server.conf file:

When running at PL1 this response error remains undetected but not at PL2:

In the logs we see that the response code 500 was blocked at PL2 due to potential information leakage:

$ cat my-alert-error.log | melidmsg
950100 The Application Returned a 500-Level Status Code
959100 Outbound Anomaly Score Exceeded (Total Score: 4)"]
980140 Outbound Anomaly Score Exceeded (score 4): individual paranoia level scores: 0, 4, 0, 0

Insecure Direct Object Reference

In the error message above we saw that there must be a server.conf. So let’s access the file and see what it reveals to us:

The server.conf even shows a session_secret. That is very awful!

Does the Core Rule Set protect us?

The log confirms that a request to a .conf file is potentially dangerous:

$ cat my-alert-error.log | melidmsg
920440 URL file extension is restricted by policy
949110 Inbound Anomaly Score Exceeded (Total Score: 5)
980130 Total Inbound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 5, 0, 0, 0

The triggered rule 920440 at PL1 blocks potentially dangerous file extensions. The extension .conf is part of this list. Of course, these file extensions can be configured. But the standard installation protects us. With the CRS in front of Pixi this session_secret will never be exposed!

Conclusion

The CRS standard installation at PL1 already protects us from a bunch of vulnerabilites. But to be protected from more vulnerabilities and exploits a higher Paranoia Level is highly recommended.

In the examples above the highest Paranoia Level I had to configure was PL2 and there are even PL 3 and PL4!

This is a crosspost from https://coreruleset.org.

2FAnotifier and multi-factor authentication

Tanya Janca — Tue, 27 Aug 2019 20:23:12 +0000

Tanya Janca, one of the OWASP DevSlop Project Leaders, is currently obsessed with convincing people to enable multi-factor authentication on all of their important accounts. To this end, she created a video that shows users how to install a browser plugin called "2FAnotifier", which will alert users if a site offers the option to use multi-factors of authentication on your user account.

If you want to know more about what MFA is and why it's important, please read Tanya's post here; Multi-Factor Authentication (MFA).

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

Global AppSec 2019 - Tel Aviv

Tanya Janca — Mon, 03 Jun 2019 18:41:15 +0000

Nancy Gariché and I (Tanya Janca), traveled to Tel Aviv, Israel to speak at Global AppSec, the international OWASP conference, which serves as the foundation's main income generating event. The conference concentrates on the topic of application security, which includes DevSecOps, white hat hacking, code review, and so much more. It was prefaced with formal training.

It is no secret that OWASP's AppSec conferences are my favorite, as OWASP is my main professional community that I participate in, so you are not likely to be surprised when I write about how great it was...

I took the training course "An Introduction to Hacking Blockchain Applications and Smart Contracts", with trainer Mick Ayzenberg. I absolutely loved the training, even though I arrived a bit late Mick made sure I was caught up over lunch on the first day. We created our own crypto currency, learned very basic solidity, learned common security vulnerabilities in blockchain (including reentrancy), participated in a custom smart contract CTF, and so much more. Mick is a fantastic teacher; patient, knowledgeable, fun and very open to feedback so that he can improve. No wonder he's so good!

During the training, and throughout the entire conference, we were provided with tasty and high-quality Israeli food: humus, breads, dates, chocolates, fruit, vegetables, cheeses, grilled meats, etc. I'm a huge fan of Israeli food, and I was not disappointed; I've rarely been so well fed at a conference. A+ on food!

Unfortunately I really wasn't feeling well for much of the conference: head colds don't care that I'm at work and doing important stuff, which resulted in me missing the entire first day of the conference as well as several social opportunities. :-/

That said; I still got to see a bunch of kick-ass talks.

Day 2 started with a keynote by Astha Singhal, the head of the AppSec team at Netflix. I happen to think Astha's a pretty awesome human, and you might want to know she's hiring for some cool positions; Security Partner and Security Software Engineer, Application Security.

I skipped the talk "How Online Dating Made Me Better At Threat Modeling" by Isaiah Sarju, but only because I had already seen it at B-Sides Vancouver. It was a great talk, if you have a chance to see a video of it I suggest checking it out. Also, even though Isaiah is a new speaker, he's great on stage; funny, thoughtful and very well spoken. I can't wait to see what his next talk will be about.

The talk I saw instead was "Defending Cloud Infrastructures with Cloud Security Suite" by Jayesh Chauhan; it was really good. His tool that he created for auditing all of the 3 major cloud providers is amazing, I can hardly believe it's free! I definitely plan to try it out. Also, he happens to be in charge of the DefCon Cloud Village, and the CFP is still open in case you were wondering. (Of course I applied!)

Right before my talk with Nancy was "Can We Automate Security?" by Sasha Rosenbaum. Sasha just started at Microsoft a month ago, and already she's on stage being awesome. I was disappointed I didn't get a chance to see her entire talk since Nancy and I were last-minute prepping, but since I work with her now I'm pretty sure she will share her slides with me that detail the inner workings of DevSecOps at Microsoft. :-D

Then came my big talk with Nancy, "DevSecOps with OWASP DevSlop". We demoed the "Patty" module of our OWASP project DevSlop, an Azure Pipelines DevSecOps pipeline, which included; SonarCloud, White Source Bolt, Azure Key Vault, Cred Scan, OWASP Zap, and more. Most of our talk was demo after demo, but we also talked about about our project, OWASP, and what DevSecOps actually is. If I do say so myself: we were great!

The last talk I got to see was "OWASP Serverless Top 10" by Tal Melamed. Tal is the leader of the OWASP Top Ten Serverless project and also someone who I have waited a long time to meet in person; it was worth the wait. We've been submitting talks together, trying to spread the word of serverless security together. If you haven't checked out his project, maybe you should?

At this point I went back to my hotel room and fell asleep for the next 18+ hours. Head colds have no mercy!

I also had the chance to connect with several people who I rarely get to see in person, and what follows are various images from the trip that were already shared publicly on Twitter, so I hope it's okay that I am sharing them here as well.

It has become a tradition for Anne Gauthier, leader of OWASP Montréal, and I to take photos with other female OWASP Leaders at each global event, I think this might be our 5th event together! Right to left: Nancy Gariché, Vandana Verma, Tanya Janca and Anne Gauthier. It should be noted that Anne Gauthier is leading a campaign to host #GlobalAppSec in Montréal, Canada in 2020. You can help her and the Montréal chapter by showing your support on social media, messaging OWASP directly or retweeting and/or liking this tweet.

Nancy and I with Shira Shamban, the chair of the speaker selection committee.

Vandana Verma and I. She travelled all the way from India! It was so wonderful to see her in person again, it had been too long. Vandana taught a penetration testing course which was offered for free to women. She's also the Bangalore OWASP Chapter Leader, active member of WIA (Women in AppSec), InfoSec Kids and InfoSec Girls leader, and WoSEC Bangalore Chapter leader. What can't this woman do?

Nancy Gariché, Dominique Righetto, and I. Dominique is one of the project leaders of the OWASP Cheat Sheets Project!

Final Photo: Astha Singhal, Anne Gauthier, Vandana Verma, Nancy Gariché and Tanya Janca

Thank you for reading, and BIG THANKS to the huge number of volunteers who worked for months to make this wonderful event possible.

Security Headers for ASP.Net and .Net CORE

Tanya Janca — Sat, 23 Mar 2019 23:51:08 +0000

For those who do not follow myself or Franziska Bühler, we have an open source project together called OWASP DevSlop in which we explore DevSecOps through writing vulnerable apps, creating pipelines, publishing proof of concepts, and documenting what we’ve learned on our YouTube Channel and our blogs. In this article we will explore adding security headers to our proof of concept website, DevSlop.co. This blog post is closely related to Franziska’s post OWASP DevSlop’s journey to TLS and Security Headers. If you like this one, read hers too. :)

Franziska Bühler and I installed several security headers during the OWASP DevSlop Show in Episode 2, 2.1 and 2.2. Unfortunately we found out that .Net Core apps don’t have a web.config, so the next time we published it wiped out the beautiful security headers we had added. Although that is not good news, it was another chance to learn, and it gave me great excuse to finally write my Security Headers blog post that I have been promising. Here we go!

Just now, I added back the headers but I added them to the startup.cs file in my .Net Core app, which you can watch here. Special thanks to Damien Bod for help with the .Net Core twist.

If you want in-depth details about what we did on the show and what each security header means, you should read Franziska’s blog post. She explains every step, and if you are trying to add security headers for the first time to your web.config (ASP.Net, not .Net CORE), you should definitely read it.

The new code for ASP.Net in your web.config looks like this:

**<! — Start Security Headers ->**
<httpProtocol>
 <customHeaders>
 <add name=”X-XSS-Protection” value=”1; mode=block”/>
 <add name=”Content-Security-Policy” value=”default-src ‘self’”/>
 <add name=”X-frame-options” value=”SAMEORIGIN”/>
 <add name=”X-Content-Type-Options” value=”nosniff”/>
 <add name=”Referrer-Policy” value=”strict-origin-when-cross-origin”/>
 <remove name=”X-Powered-By”/>
 </customHeaders>
 </httpProtocol>
**<! — End Security Headers ->**

And the new code for my startup.cs (.Net CORE), looks like this (Thank you Damien Bod):

//Security headers make me happy
app.UseHsts(hsts => hsts.MaxAge(365).IncludeSubdomains());
app.UseXContentTypeOptions();
app.UseReferrerPolicy(opts => opts.NoReferrer());
app.UseXXssProtection(options => options.EnabledWithBlockMode());
app.UseXfo(options => options.Deny());
app.UseCsp(opts => opts
.BlockAllMixedContent()
.StyleSources(s => s.Self())
.StyleSources(s => s.UnsafeInline())
.FontSources(s => s.Self())
.FormActions(s => s.Self())
.FrameAncestors(s => s.Self())
.ImageSources(s => s.Self())
.ScriptSources(s => s.Self())
);
//End Security Headers

In future episodes we will also add:

Secure settings for our cookies
X-Permitted-Cross-Domain-Policies: none
Expect-CT: (not currently supported by our provider)
Feature-Policy: camera ‘none’; microphone ‘none’; speaker ‘self’; vibrate ‘none’; geolocation ‘none’; accelerometer ‘none’; ambient-light-sensor ‘none’; autoplay ‘none’; encrypted-media ‘none’; gyroscope ‘none’; magnetometer ‘none’; midi ‘none’; payment ‘none’; picture-in-picture ‘none’; usb ‘none’; vr ‘none’; fullscreen *;

For more information on all of these security headers, I strongly suggest you read the OWASP Security Headers Guidance.

We now have good marks from all of the important places, https://securityheaders.com, https://www.ssllabs.com and http://hardenize.com), but hope to improve our score even further.

For more information, watch our show on YouTube!