# DevSecOps Lab 5

Ilya Kolomin [e-mail]
Kirill Ivanov [e-mail]
Anatoliy Baskakov [e-mail]

Team number 4, **Webgoat app**
## Task 1 - Theory

1. Explain:
* what is DAST?
* Dynamic application security testing. Unlike SAST, which is performed on the source code, DAST is performed on a running application.
* How does dynamic security testing work?
* Multiple approaches are used to try to cause error within a running application. For example, incorrect data is passed to a running app, e.g. an SQL-injection.
* What are the advantages of the DAST methodology?
* It can find issues which cannot be deduced from the source code. For example, misconfiguration, authentication problems.
* Are there any downsides to the DAST methodology?
* DAST will not find vulnerabilities or problem in code which unless that chunk of code is run during while application is being tested.
2. List and explain the main criteria when choosing a DAST tool.
* ***Coverage***: A DAST tool should cover all use cases of the app. The more vulnerabilities a tool can find the better, however, if a tool meets the requirements for you apps, this stops being the main criteria
* ***False results rate***: We expect a tool to have a low false positives (otherwise reports will be ignored) and false negatives rate.
* ***Report utilities***: It should generate detailed reports.
* ***Support***: A DAST tool should be actively maintained and have good integration with other tools
* ***Efficiency***: How fast a scan is performed
4. According to the “Shift Everywhere” paradigm, Security tools in CI/CD should be used where they can bring maximum benefit. Based on this, give and explain at what stage(s) of the development process dynamic analysis can be introduced.
* DAST tools are introduced to the "Right" stage of the development process, as opposed to SAST tools which are usually run to the "Left".
5. What is Fuzzing? What is/are the key(s) difference between Fuzzing and common DAST?
* Fuzzing is a vulnerability and coding errors detceting method. It sends lots of random inputs in attempt to cause errors or crashes. In such case, fuzzers also may help to find the root cause.
* While DAST is about elaborate analyzis and search, fuzzing is a low-effort approach

6. List and describe the different type of Fuzzers you know
* There are two different types of fuzzers
* ***Behaviour-based***: given some kind of specification on how an app should work, it randomly probes different inputs to see that the app actually does what is expected. There is a close resemblance with property-based testing.
* ***Coverage-based***: an attempt to cover as much cases as possible. Instead analyzing expected behaviour, we try to cover a wide range of inputs, and, should an app crash on any, there is a high chance of an issue present.

## Task 2 - Deploy the vulnerable web app

First we build an app with Maven, then we create an image with the app and finally we deploy it to our cluster. All of this is accomplished with the following three *gitlab-ci* jobs:

build-maven:
  stage: build
  image: maven:latest
  script:
    - mvn package -DskipTests=true
  artifacts:
    paths:
      - target

build-image:
  stage: build
  image: docker:latest
  needs: [build-maven]
  before_script:
    - docker login -u securelabs -p "$docker_hub_access_token" docker.io
  script:
    - docker build --pull -t "securelabs/ssd:lab5" .
    - docker push "securelabs/ssd:lab5"

kube_cluster:
  stage: deploy
  needs: [build-image]
  image:
    name: alpine/helm:3.10.2
    entrypoint: ['']
  variables:
    KUBECONFIG: $CI_PROJECT_DIR/kube_config
  script:
    - echo "$KUBE_CONFIG" > kube_config
    - helm package helm
    - helm upgrade helm helm-* --install

Note: 'target' directory, created as the result of *build-maven* job, was too large, so it was necessary to increase the default artifact size

When ssh-ing to the cluster:


## Task 3 - Dynamic Analysis with StackHawk

1. Here is our configuation file for the hawk scan

# -- stackhawk configuration for WebGoat test --
app:
  # -- An applicationId obtained from the StackHawk platform. --
  applicationId: d82a19b5-51b4-4f56-bccb-c982067386df # (required)
  # -- The environment for the applicationId defined in the StackHawk platform. --
  env: Test # (required)
  # -- The url of your application to scan --
  host: http://${WEBGOAT_ADDRESS}:8080 # (required)
  excludePaths:
    - "/WebGoat/logout"
  sessionTokens:
    - JSESSIONID
  openApiConf:
      filePath: api-docs.json


# -- Customized Configuration for GraphQL/SOAP/OpenAPI, add here --
  autoPolicy: true
  autoInputVectors: true
  # Configuration Docs: https://docs.stackhawk.com/hawkscan/configuration/

# -- If Authenticated Scanning is needed, add here --
  # Authenticated Scanning Docs: https://docs.stackhawk.com/hawkscan/authenticated-scanning.html
  # Authenticated Scanning Repo: https://github.com/kaakaww/scan-configuration/tree/main/Authentication

# -- Help Section --
  # Docs: https://docs.stackhawk.com/
  # Contact Support: [e-mail]
  authentication:
    # Paths that HawkScan checks to see if it is still logged in during the scan
    loggedInIndicator: "\\QLogout\\E"
    loggedOutIndicator: "\\QSign in\\E"
    # Auth(N) HTTP Form
    usernamePassword:
      type: FORM
      loginPagePath: /WebGoat/login # Your login form path
      loginPath: /WebGoat/login # Your login form path
      usernameField: username # Field name for the account username/email
      passwordField: password # Field name for the password
      scanUsername: ${ZAP_AUTH_PASSWORD} # Inject variable at runtime or place your username here
      scanPassword: ${ZAP_AUTH_USERNAME} # Inject variable at runtime or place your password here  

    cookieAuthorization:
      cookieNames:
        - JSESSIONID

    # (REQUIRED) Add your Auth(Z) here. Either Cookie or Token
    #
    #A path that can only be seen when successfully logged in. HawkScan will check this path to see if log in was successfull
    testPath:
      path: "/WebGoat/start.mvc"
      fail: ".*302.*" # if redirect detected then fail
      requestMethod: GET
hawk:
  spider:
    ajax: true
    ajaxBrowser: CHROME
    seedPaths: ["/WebGoat/start.mvc#lesson/WebGoatIntroduction.lesson", "/WebGoat/start.mvc"]

2. We use form-based authentication, which could be seen on 34-41 lines.
3. We decided to exclude the `/WebGoat/logout` path in order to stay logged in for the entire scan. Moreover, because of poor performance of built-in crawler, we decided to generate and provide OpenAPI file for this scan. Now the scanner considers much more paths and do not have to re-login after each test on `/WebGoat/logout` page, which does not provide any interesting results for us.

Brief result:

## Task 4 - Dynamic Analysis with ZAP

1. Integrate ZAP Scanner in your pipeline to perform a baseline scan against your application.
To launch the scan we use `ictu/zap2docker-weekly`. Job for launching is

zap-full:
  stage: test
  allow_failure: true
  image:
    name: ictu/zap2docker-weekly
    entrypoint: [""]
  artifacts:
    name: zap-full-scan-report
    paths:
      - "${ZAP_REPORT_FOLDER}"
    when: always
  script:
      - mkdir ${ZAP_REPORT_FOLDER}
      - >
        /zap/zap-full-scan.py -j -a -m 20
        -t http://${WEBGOAT_ADDRESS}/WebGoat
        --hook=/zap/auth_hook.py
        -r ${ZAP_REPORT_FOLDER_ARG}/webgoat-zap-report-$(date -Iseconds)-full.html
        -J ${ZAP_REPORT_FOLDER_ARG}/webgoat-zap-report-$(date -Iseconds)-full.json
        -z "auth.password="${ZAP_AUTH_PASSWORD}"
            auth.username="${ZAP_AUTH_USERNAME}"
            auth.password_field=\"exampleInputPassword1\"
            auth.username_field=\"exampleInputEmail1\"
            auth.submit_field=\"/html/body/section/section/section/form/button\"
            auth.loginurl=http://${WEBGOAT_ADDRESS}/WebGoat/login"

2. Integrate ZAP Scanner in your pipeline to perform an authenticated full scan of your application.

You can already see parameters for authentication (starting with `auth.`) in the previous step.
Authentication is performed successfully, as you can see here:

3. Modify the last scan to use a specific context that you’ll detail.

We have installed ZAP Desktop and created a context for later use in CI


Also we've manually added exclusion of `logout` just in case.

Then we've exported the context file, added to repo, and included in scan process.


4. Change the scan method to run an API scan using one of the following API method(REST/OpenAPI/Swagger, SOAP). Analyse the new results and share your understandings.

zap-api:
  stage: test
  allow_failure: true
  image:
    name: ictu/zap2docker-weekly
    entrypoint: [""]
  artifacts:
    name: zap-api-scan-report
    paths:
      - "${ZAP_REPORT_FOLDER}"
    when: always
  script:
      - mkdir ${ZAP_REPORT_FOLDER}
      - >
        /zap/zap-api-scan.py -j -a -m 20
        -t http://${WEBGOAT_ADDRESS}/WebGoat/v3/api-docs
        -f openapi
        --hook=/zap/auth_hook.py
        -r ${ZAP_REPORT_FOLDER_ARG}/webgoat-zap-report-$(date -Iseconds)-api.html
        -J ${ZAP_REPORT_FOLDER_ARG}/webgoat-zap-report-$(date -Iseconds)-api.json
        -z "auth.password="${ZAP_AUTH_PASSWORD}"
            auth.username="${ZAP_AUTH_USERNAME}"
            auth.password_field=\"exampleInputPassword1\"
            auth.username_field=\"exampleInputEmail1\"
            auth.submit_field=\"/html/body/section/section/section/form/button\"
            auth.loginurl=http://${WEBGOAT_ADDRESS}/WebGoat/login"

It finds significantly more URLs to scan and vulnerabilities, since apparently it cannot find the needed endpoints by itself/by crawling. Probably it happens because it does not have a good API.

Without provided API definition:
With:

Results:


## Task 5 - Tools Comparison

1. Provide a comparative analysis of the results obtained in task 3 and task 4 based on the following criterias:

* Amount of vulnerabilities
* Zap found significantly more vulnerabilities compared to the hawk (~3000 vs ~100). However, most zap's issues are related to returning error code (~2800), which hawk just do not report. What is more important, zap found more attack sources (source code disclosure, for instance)
* 
* Also, it found more compromised API end-points for different issues (31 vs 12 for SQL injection, for instance)
* Integrations
* Both tools perform well with integrating into GitLab CI and provide convinient docker image with guide for configuring.
* Reporting
* Both tools provide good reporting with detailed evidence. However, hawk also shows useful information on the issue, including description, and prevention mechanism.
* 
* Scan speed
* 7 minutes (zap) vs 3 minutes (hawk)
* Scan quality
* As mentioned earlier, zap considers more vulnarabilities and have better tests, that helps us to find more insecure end-points.
* Authentication
* Form based authentication is easily configured on both tools.
* However, hawk provides more control over the logged state by default via mandatory specifying checks and session cookie token.
* License
* Both tools are free for non-commerical use.
2. Based on your comparison, which tool are you more eager to adopt in your environment? Explain why?

Despite the lowered speed and unpleasant report, we believe, that Zap is still could be considred as preferrable tool for DAST, because of its scan quality.