# Secure System Development Lab 4 - DAST

**Team Members:**
* Daniyar Cherekbashev ([e-mail])
* Gleb Statkevich ([e-mail])
* Daria Kalashnikova ([e-mail])

## Task 1 - Theory
1. Explain:
* What is DAST?
**A:** DAST (Dynamic Application Security Testing) is a testing process with purpose to find weaknesses and vulnerabilities in the software in a runtime. It is test the security of web applications by simulating attacks from the point of view of a malicious hacker.
* How does dynamic security testing work?
**A:** Dynamic security testing = sending malicious requests to application + monitoring responses. This process can help identify vulnerabilities, that could be exploited by attackers. By identifying these vulnerabilities, developers can take steps to protect their applications from potential attacks.
* Explain how a context can be useful in DAST.
**A:** Context can be used by a scanner to access deep features of an application. Essentially, a scanner does not have comprehensive information about available APIs and their endpoints. It also doesn't have auth data for certain functions etc. For example, if there is a web application, the context may contain info about hidden pages (admin dashboard for example) and authentication information. The scanner will be able to interact with the app not only as a foreign user, but also as a user with valid access.
* How is an authenticated scan different from an unauthenticated scan?
**A:** Unauthenticated scan allows to assess the security of software from the point of view of a foreign user. This user have no special rights/accesses. In other words, if we have a website, the scanner will act like visitor. On the other hand, an authenticated scan acts like a legitimate user with certain permissions. The scanner may detect if the user has obtained more privileges than they should have. Additionally, an authenticated scanner will analyze APIs that are available only for authenticated users (for example, we may have some service API for dev parties that are accessible only with token)
* What are the advantages of the DAST methodology?
**A:**
- allows to assess the entire software without access to the source code. This is useful in cases where external software that do not have access to the sources is used.
- it also allows to find logical errors in the code that would be difficult to detect using static scanning methods (for example, sensitive data in the DB that is leaked during runtime).
- the most significant advantage is its precision. If the scanner is able to detect an exploit, than it is likely that there is real vulnerability that could be exploited. This makes easier to prioritize and fix found vulnerabilities.
* Are there any downsides to the DAST methodology?
**A:**
- it is expensive tool that requires a running environment with highly realistic data and minimum number of assumptions.
- it also can face different types of protection, which can prevent DAST from finding vulnerabilities. This is because the protection may filter out the payload due to some factors. If an attacker is able to bypass protection, the vulnerability can be exploited later.
- it is difficult to quickly locate the root cause of the weakness, as we only have access to the payload and output.

2. List and explain the main criteria when choosing a DAST tool.
**A:**
- **Easy-to-Use.** Consider user-friendly interface and how easy it is to configure and run scans. A user-friendly tool can save time during the testing process.
- **Report format.** If it’s not comprehensive and understandable, it will be useless
- **Coverage.** range of vulnerabilities the tool can detect for common vulnerabilities, accuracy and quality of scanning, their maintainenace. The scanner should be aware of recent techniques used by attackers to be able to detect weaknesses.
- **Cost.** Consider the total cost of using the DAST tool, including any licensing fees, maintenance costs, and any additional features/services. Ensure that tool fits your budget constraints.

3. 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.
**A:** DAST should be used after auto-tests and static analysis tools. Since DAST is expensive, it takes a lot time to run and process project, so there is no need to run DAST if the weaknesses can be found statically. Running DAST might find the same weaknesses, but it would just waste time and computational resources on something that has already been identified.
4. What is Fuzzing? What is/are the key(s) difference between Fuzzing and common DAST?
**A:** Fuzzing is technique used to find weaknesses in the runtime of software by generating a large number of different inputs. They are designed (by special tools) to cause the software to crash, DoS, or other failures cases. Fuzzing can help to identify issues with memory management/leaks, incorrect calculations, identify problems with multithreading and other synchronization issues.
5. List and describe the different type of Fuzzers you know.
**A:**
- Application fuzzing - is a technique that involves testing an application's API (for example REST) with high frequency and large inputs of different types
- Protocol fuzzig identify vulnerabilities in the processing of a protocol. The main purpose is to prevent protocol requests from being misinterpreted as commands and executed on the server.
- File format fuzzing - send corrupted files (with incorrect attributes), files that contain dangerous parts, and more
## Task 2 - Deploy the vulnerable web app
For this lab, we'll be using Juice Shop + StackHawk

Create helm chart with `helm create juice-shop`

Then, modify `values.yaml` to use juice-shop container and port 3000

image:
  repository: bkimminich/juice-shop
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"

service:
  type: ClusterIP
  port: 3000

Install the chart with `helm install juice-shop --namespace juice-shop --create-namespace .`

Verify installation:
We also need to configure port forwarding with `kubectl --namespace juice-shop port-forward svc/juice-shop 8047:3000`:

Now, we can add deployment job as the part of Gitlab CI.

Repo for deployment

We need to save the kube config file as base64 string in the environment variables in Gitlab

Deploy job:

stages:
  - deploy

variables:
  CHART_NAME: juice-shop

deploy_job:
  stage: deploy
  image:
    name: alpine/helm:latest
    entrypoint: [""]
  script:
    - mkdir -p ~/.kube/
    - echo $KUBE_CONFIG | base64 -d > ~/.kube/config
    - chmod 600 ~/.kube/config
    - helm upgrade ${CHART_NAME} --install --values=./values.yaml --create-namespace --namespace ${CHART_NAME} .

## Task 3 - Dynamic Analysis
1. StackHawk is not able to resolve docker: alias so we have to determine and put internal docker address in host
<span style="color: green;">stackhawk.yml</span>

    app:
      applicationId: 480a55d0-3cc1-4835-b508-3cb6964666e1
      env: Development
      host: http://172.18.0.4:3000

      openApiConf:
        filePath: swagger.yml
      autoPolicy: true
      autoInputVectors: true

Add HAWK_API_ID and HAWK_API_SECRET env variables:
Add job in <span style="color: green;">.gitlab-ci.yml</span>

    dast_job:
      stage: scan-dast
      tags:
        - docker
      script:
        - docker run -d -e API_KEY="hawk.${HAWK_API_ID}.${HAWK_API_SECRET}" -e NO_COLOR=true --name stackhawk --entrypoint "/bin/sleep" --user root --rm stackhawk/hawkscan infinity    
        - docker exec stackhawk "/bin/mkdir" -p /hawk
        - docker cp ./swagger.yml stackhawk:/hawk/
        - docker cp ./stackhawk.yml stackhawk:/hawk/
        - docker exec -t stackhawk "/zap/hawk" scan

Unathenticated scan result:


2. Added form-based authentication method, for email and password I took some pre-built juice-shop credentials from https://github.com/juice-shop/juice-shop/blob/master/data/static/users.yml to not take one more step for registration

      antiCsrfParam: csrfToken
      authentication:
        cookieAuthorization:
          cookieNames:
            - JSESSIONID
        loggedInIndicator: "HTTP.*2[0-9][0-9]\\s*O[kK](\\s*)|HTTP.*3[0-9][0-9].*"
        loggedOutIndicator: "HTTP.*4[0-9][0-9](\\s*)Unauthorized.*"
        usernamePassword:
          type: FORM
          loginPagePath: /#/login
          loginPath: /#/login
          usernameField: email
          passwordField: password
          scanUsername: ${AUTH_EMAIL}
          scanPassword: ${AUTH_PASSWORD}
          otherParams:
            - name: rememberMe-input
              val: "true"
          testPath:
            path: /profile
            success: ".*2[0-9]{2}.*"
            requestMethod: GET

Authenticated scan result:
Compared to unauthenticated scan, it found 18 more paths available paths

4. In a custom context, I excluded some paths to see how it will be reflected in the scan results. For that, I added to `stackhawk.yml`

     excludePaths:
        - "/assets"
        - "/b2b"

Assets should be definitely unnecessary in the scan, while b2b path may contain some order information.
Job result:
Scan took a little bit less time compared to the full authenticated one and found 3 less path routes, however, findings remained the same.
6. OpenAPI specification for juice-shop is located at [swagger.yml](https://github.com/juice-shop/juice-shop/blob/master/swagger.yml) of the juice-shop project and was used by default while StackHawk app creation.