Fluid Attacks logo
Contact Us
Young hacker smiling
Zero false positives

Expert intelligence + effective automation

Contact logo Contact Us
GET A DEMO

Asserts

1. Description

Asserts is an engine that automates attacks to verify the status (open or closed) of vulnerabilities found by a security analyst. Asserts can be included in CI/CD environments as security gate.

Asserts
Figure 1. Use case

2. Installation

Asserts is hosted on PyPI, so you can install it easily using pip3 on a system with Python 3:

asserts installation
1
$ pip3 install -U fluidasserts

For normal/interactive usage, you should set the environment variable FA_STRICT to false (see below). In an UNIX -like OS:

1
$ export FA_STRICT="false"

In Windows:

1
> set FA_STRICT="false"

Now you’re ready to begin testing vulnerabilities’ closings.

Inside a Docker Container

If you have Docker you can check out and run Asserts inside a container. Just:

1
$ docker pull fluidattacks/asserts

And then go inside the container:

1
2
3
4
5
6
7
8
$ docker run -it fluidattacks/asserts sh
/ # asserts

#  ___
# | >>|> fluid
# |___|  attacks, we hack your software
#
# Loading attack modules ...

Make sure to do the docker pull before every docker run to ensure you are running the latest Asserts version.

From inside the container you could run Asserts from the Python interactive shell, or quickly whip up a script using vi. But it would be much more useful to mount the directory where your exploits live into the container:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
$ docker run -v /home/me/myexploits/:/exploits/ -it fluidattacks/asserts sh
/ # asserts /exploits/open-sqli.py

#  ___
# | >>|> fluid
# |___|  attacks, we hack your software
#
# Loading attack modules ...

check: fluidasserts.proto.http.has_sqli
status: OPEN
message: A bad text was present
details:
  bad_text: Warning.*mysql_.*
  fingerprint:
    banner: "Server: nginx/1.4.1\r\nContent-Type: text/xml\r\nTransfer-Encoding: chunked\r\
      \nConnection: keep-alive\r\nX-Powered-By: PHP/5.3.10-1~lucid+2uwsgi2"
    sha256: 588702eb0b53294654f934d86664956e9739db47c34ffd8d703550cd5fd670a0
  url: http://testphp.vulnweb.com/AJAX/infoartist.php?id=3%27
when: 2018-09-06 08:33:08.781518

Usage in a CI (Continuous Integration) pipeline

If you have an application subscribed to our Continuous Hacking Service which includes the use of Asserts, you can integrate it into your CI pipeline to ensure that your software builds and ships with no open vulnerabilities. We will provide a custom Docker container with the specific tests you need and maintain the build-breaking exploit.

To achieve this, follow these steps:

  1. Add the required environment variables FA_ORG and FA_PROJECT, FA_${FA_PROJECT}_USER, FA_${FA_PROJECT}_PASS. Don’t worry, the values will be provided by us!:

    • FA_ORG: The name of the organization.

    • FA_PROJECT: The name of the continuous hacking project.

    • FA_${FA_PROJECT}_USER: Name of the user from our Container Registry.

    • FA_${FA_PROJECT}_PASS: The password of the user.

      For example, in Gitlab, and assuming FA_ORG=FLUIDATTACKS and FA_PROJECT=BWAPP, the environment of the pipeline would look like this:

      Gitlab CI environment variables
  2. Add a job to run Asserts. For example, in Gitlab, you would add these commands to your .gitlab-ci.yml:

    asserts in gitlab
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    fluidasserts-static:
      script:
        - export STAGE="${FA_PROJECT}_static"
        - docker login fluid-docker.jfrog.io
            -u "$FA_BWAPP_USER"
            -p "$FA_BWAPP_PASS"
        - docker pull fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
        - docker run
            -e USER="$FA_BWAPP_USER"
            -e PASS="$FA_BWAPP_PASS"
            -e FA_STRICT=true
            -v "$PWD":/code
            fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
        - docker logout fluid-docker.jfrog.io
    
    fluidasserts-dynamic:
        - export STAGE="${FA_PROJECT}_dynamic"
        - docker login fluid-docker.jfrog.io
            -u "$FA_BWAPP_USER"
            -p "$FA_BWAPP_PASS"
        - docker pull fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
        - docker run
            -e USER="$FA_BWAPP_USER"
            -e PASS="$FA_BWAPP_PASS"
            -e FA_STRICT=true
            fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
        - docker logout fluid-docker.jfrog.io
    
  3. Now your pipeline will break if any vulnerability is found to be open, wether it is in the source code or in the production/staging environment. In order to not break the build, but still run the tests, set the FA_STRICT variable above to false.

CI Stages

OK, I’m in. But in what stage should I test my app with Asserts ? There are at least three good moments to perform closing testing:

  1. After deploying to the production environment

  2. After deploying to a staging or ephemeral environment

  3. Even after every single commit!

Post-production

Just as before, we log in to the artifacts repository, pull the custom image and run it with Docker. This time, however, note that the job is run only in the master branch and in one of the latest stages, namely post-deploy. The source code of this branch is linked to to the container in the /code folder since it is already set up to test this particular folder.

post-deploy
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
fluidasserts-static:
  stage: post-deploy
  script:
    - export STAGE="${FA_PROJECT}_static"
    - docker login fluid-docker.jfrog.io
        -u "$FA_BWAPP_USER"
        -p "$FA_BWAPP_PASS"
    - docker pull fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker run
        -e USER="$FA_BWAPP_USER"
        -e PASS="$FA_BWAPP_PASS"
        -e FA_STRICT=true
        -v "$PWD":/code
        fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker logout fluid-docker.jfrog.io
  only:
    - master

fluidasserts-dynamic:
  stage: post-deploy
    - export STAGE="${FA_PROJECT}_dynamic"
    - docker login fluid-docker.jfrog.io
        -u "$FA_BWAPP_USER"
        -p "$FA_BWAPP_PASS"
    - docker pull fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker run
        -e USER="$FA_BWAPP_USER"
        -e PASS="$FA_BWAPP_PASS"
        -e FA_STRICT=true
        fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker logout fluid-docker.jfrog.io
  only:
    - master

Post-ephemeral

But wait! We could catch bugs before deploying to production. If you use ephemeral environments, you can also perform closings testing in those:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
fluidasserts-static:
  stage: test
  script:
    - export STAGE="${FA_PROJECT}_static"
    - docker login fluid-docker.jfrog.io
        -u "$FA_BWAPP_USER"
        -p "$FA_BWAPP_PASS"
    - docker pull fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker run
        -e USER="$FA_BWAPP_USER"
        -e PASS="$FA_BWAPP_PASS"
        -e FA_STRICT=true
        -v "$PWD":/code
        fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker logout fluid-docker.jfrog.io
  except:
    - master

fluidasserts-dynamic:
  stage: test
    - export STAGE="${FA_PROJECT}_dynamic"
    - docker login fluid-docker.jfrog.io
        -u "$FA_BWAPP_USER"
        -p "$FA_BWAPP_PASS"
    - docker pull fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker run
        -e USER="$FA_BWAPP_USER"
        -e PASS="$FA_BWAPP_PASS"
        -e FA_STRICT=true
        fluid-docker.jfrog.io/"$FA_ORG":"$STAGE"
    - docker logout fluid-docker.jfrog.io
  except:
    - master

In contrast to the post-deploy job above, this one runs on the development branches, during the test stage. Otherwise, everything else is the same, just like staging environments mirror production environments.

Pre-commit

As a developer you might be thinking “why wait until all other CI stages are finished if I just want to test whether my last commit fixed the security hole?” You could just run Asserts in your development machine, but sometimes tiny details (like dependencies versions) might cause the testing to pass in your machine but fail continuous integration. Remember that at this point during the development, there is no environment available for testing, hence you can only run static tests against the source code.

In that case you might run the Dockerized incarnation of Asserts as a pre-commit hook:

pre-commit
1
2
3
4
5
- id: asserts-docker
  name: Running Asserts on the code
  description: Run Asserts to perform SAST
  entry: -v /path/to/your/code/:/code fluidattacks/asserts:latest /code/asserts.sh
  language: docker_image

This particular configuration is for the pre-commit tool, but can be adapted for similar tools like overcommit. The use of such tools is convenient for the developer, as tests can be quickly run in their machine with every commit:

Pre-commit test passed
Pre-commit test failed

The same tests can also be run in CI time (for example, in a lint stage) to ensure that nothing is broken, even if the developer forgot to run it. Just:

1
pre-commit run --all-files

somewhere in your CI script.

Talk to our experts and start solving your vulnerabilities now!




Number is valid Number is not valid

Please select an option





Service status - Terms of Use