Testing ZAP Proxy

[Kaso]

Hey!

I am testing ZAP Proxy against an assortion of (stateful) testbed applications aimed at web application security scanners.

I would like to know which of the two docker-compose, A or B shown below, offers the optimal configuration for the application. Both files were generated by machine learning models (ChatGPT and Claude, respectively). I tested one of the testbed applications, specifically XSS, with Docker Compose A, and it worked. A screenshot of the Docker Compose A results is attached. My doubt arises because, in Docker Compose A, no database is defined. Since the testbed applications are stateful, the AI told me that the applications store data. Therefore, is Docker Compose B the best option to test ZAP Proxy?

-----------------------------------

|  docker-compose  A |

------------------------------------

services:

  archery-xss:

    build: .

    ports:

      - "3000:3000"

    command: gunicorn -b 0.0.0.0:3000 app:app

    restart: unless-stopped

    # Volumen opcional para desarrollo

    # - ./templates:/home/appuser/app/templates

------------------------------------

|  docker-compose  B |

------------------------------------

services:

  # ==========================================

  # APLICACIÓN 1 - Ejemplo con autenticación

  # ==========================================

  app_vulnerable_1:

    build:

      context: ./apps/app1

      dockerfile: Dockerfile

    container_name: archery_app1

    hostname: app1

    networks:

      testbed_network:

        ipv4_address: 172.20.0.10

    ports:

      - "8001:8000"

    environment:

      - APP_NAME=VulnerableApp1

      - DEBUG=false

      - SECRET_KEY=change_this_secret_key_123

      - DATABASE_URL=postgresql://app1user:app1pass@postgres_app1:5432/app1db

      - REDIS_URL=redis://redis_shared:6379/0

    volumes:

      - app1_data:/var/lib/app1/data

      - app1_logs:/var/log/app1

      - ./config/app1.conf:/etc/app1/config.conf:ro

    depends_on:

      postgres_app1:

        condition: service_healthy

      redis_shared:

        condition: service_healthy

    restart: unless-stopped

    deploy:

      resources:

        limits:

          cpus: '0.5'

          memory: 512M

        reservations:

          cpus: '0.25'

          memory: 256M

    logging:

      driver: "json-file"

      options:

        max-size: "10m"

        max-file: "3"

    healthcheck:

      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]

      interval: 30s

      timeout: 10s

      retries: 3

      start_period: 40s

Warm Regards,

Kattia.

[psiinon]

Hiya Kattia,

I wouldnt trust LLMs with this level of detail tbh :D

It looks like each of the test apps are well documented and easy to run, just look at the instructions on:

• https://github.com/google/security-testbeds/tree/main/archery_range/sqli#readme
• https://github.com/google/security-testbeds/tree/main/archery_range/xss#readme
• https://github.com/google/security-testbeds/tree/main/archery_range/xxe#readme

No need to define a db, it looks like the setup instructions handle everything for you.

Cheers,

Simon

[Kaso]

Thank you Simon. So, the docker-compose A is enough to run the xss testbed.

Just out of curiosity, is there an AI app we can trust with this level of detail?

[psiinon]

Does it work as it is supposed to? :)

Try running it locally, run the ZAP spider against it and then the XSS rule.

If it doesnt find any XSS's then theres probably a problem.

I dont know all of the AI varients well enough .. but LLMs, no, I dont trust them with details.

LLMs are token prediction engines.

They get things mostly right most of the time, but they are not good with details.

Always validate that what they are telling you is correct.

Cheers,

Simon