Prepare purpleteam CLI for deployment to NPM using `np`

Add releases using github but in the changelog format. Using np

After selecting the version to release, np runs the full release and publish to npm.

np installed globally.

np doesn't allow one to add the latest tag to a pre-release, so next seems the only option. Do this, then:

npm dist-tag add [email protected] latest

Check the files array in package.json to make sure no secrets can be published. Double check what will be published

From project root dir: np (release and publish to npm)

After selecting the version to release, np runs:

Todo: detail what np runs.

logger
mocksse
purpleteam (CLI)

Once published to npm npm install and check the file contents.
Check the Github release Assets archive.

From project root dir: np --no-publish

After selecting the version to release, np runs:

✔ Git
✔ Installing dependencies using npm
✔ Running tests using npm
✔ Bumping version using npm
✔ Pushing tags
✔ Creating release draft on GitHub

Check the Github release Assets archive.

From project root dir: np --no-publish --no-tests

doc
s2-containers

Check the Github release Assets archive.

Get Emissary logs to CLI

Time appears incorrect in outcomes files

Actual Behavior:

hour produced by NowAsFileName returns 05 when it's 17.

Issue exists in all testers that use the NowAsFileName function.

Expected Behavior:

Should return time as according to local

Steps to Reproduce:

During a Test Run this is executed.

Additional Details:

The Date Get methods return values based on the local time, problem is the timezone is set in the container image (in our case to UTC). If we change it, then we change it for everyone that uses the images.

The folloing placed into the docker-compose file fixes it for New Zealand, but then it's wrong for everyone else:

    environment:
      - TZ=Pacific/Auckland

We've decided to leave it as UTC.

Provide ability for Build User to pass flag to disable colour in tester reporting

The enhancement may already be reported! Please search for the enhancement before creating one.

Current Behavior:

colorsEnabled is set to true in app-scanner.

Proposed Behavior:

Provide ability for buildUserConfig Job file to pass through flag for testers to check whether colour should be enabled or dissabled in tester reporting

How It Would Benefit You:

I wouldn't have to see colour symbols in cli logs that are writen to file

Add definitions to purpleteam-doc

Set-up CodeQL as github action for semantic code analysis

Current Behavior:

No CodeQL

Proposed Behavior:

Set-up CodeQL as github action for semantic code analysis across all repos where it makes sense.
Example here: https://github.com/OWASP/NodeGoat/pull/229/files

How It Would Benefit You:

Find bad coding patterns so that they can be fixed.

Convert our usage of child_process spawn to fork in app.parallel.js

This is in the app-scanner. This will probably reduce memory usage as well, which would be great for getting EC2 instance sizes down.

Links to get started:

Test against additional test targets

Will want to put call out for volunteers.

Some origonal thoughts were:

Juice Shop
https://github.com/appsecco/dvna
Find other non node apps
Better still, just recruit commercial clients

CLI Integrations

Current Behavior:

We have a process that runs anywhere. Do we need integrations with the likes of Github, Gitlab, others?

Proposed Behavior:

Integrations

How It Would Benefit You:

Good question?

That's what this issue is about answering.

Resources that may be helpful:

Github apps vs actions https://dev.to/morganrconnolly/comment/13ide

Refactor the naming of the variables like `port` in app.parallel.js in s2ContainersReady

Integration test installing and running purpleteam CLI

As part of ci-cd for the CLI, we should test that purpleteam CLI installs and runs correctly as if it was done so from NPM. We can do this using verdaccio:

Current Behavior:

No integration test for the CLI

Proposed Behavior:

Add integration tests that:

Test the options detailed on the CLI README
- Installs
- Configuratioins
- Runs

Basically we want to be testing things we don't usually test in development... like the actual ilnstallation and verifying that the CLI runs as a Build User would use it.

How It Would Benefit You:

It would provide confidence that the community can install and run purpleteam without errors

How graphql ready are we? What to do to support if not?

The enhancement may already be reported! Please search for the enhancement before creating one.

Current Behavior:

Not sure. Investigate what we need to do to support GraphQL if we don't already

Proposed Behavior:

Implement GraphQL support if it doesn't exist.

Should we do this?
Do we need to do this?

How It Would Benefit You:

Not sure, who actually wants this? Anyone?

Review Selenium security

Secure as much as possible selenium: https://github.com/elgalu/docker-selenium/blob/master/SECURITY.md

Upgrade EC2 AMIs

Add support page

https://docs.github.com/en/github/building-a-strong-community/adding-support-resources-to-your-project

Implement SSL/TLS Scanner

Releases:

Overall

Added documentation around PurpleTeam CLI Log files and the Outcomes archive that the orchestrator sends to the CLI
Updated the definitions

Website

https://gitlab.com/purpleteam-labs/purpleteam-labs-web/-/commit/1574ae51b3a1fbef3c94dfcae5bc4f1573915569

Added

Job file
Log and Outcomes files
FAQ
TLS Scanner set-up doc
Doc around debugging the Tls Tester

Changed

cloud and local architecture diagrams
Casing to match Definitions
Doc around setting up Tls Tester
Formatting improvements to workflow doc
SSLyze to testssl.sh in Third Party sources
Site footer

Issues Created

Useful Resources

Upgrade aws-sdk from v2 to v3

Projects involved:

app-scanner
Example of using the lambda commands with TextDecoder
lambda
At this stage the Nodejs runtimes for lambday only support v2 of the sdk, so one needs to add it as a package dependency

Resources

Used in app-scanner app.parallel

Used in lambda for `cloud`

Use implicit webdriver waits rather than the current explicit

app_scan_steps.js in app-scanner uses explicit waits. We can do better than this. We started changing to implicit in the webDriverFactory.js, but this is currently commented out.

Move hard coded timeouts in app.parallel.js of app-scanner to config

You could probably have a look at this one @ricekot? Get your bearings and propose the change?

Tweak Copyright notices

Actual Behavior:

All the source files that have a Copyright notice at the top refer to purpleteam as the solution.

Also the last two lines of the Copyright are:

// You should have received a copy of the GNU Affero General Public License
// along with purpleteam. If not, see <https://www.gnu.org/licenses/>.

Expected Behavior:

The casing should match that as defined in the definitions

The last two lines of the Copyright should be:

// You should have received a copy of the GNU Affero General Public License
// along with this PurpleTeam project. If not, see <https://www.gnu.org/licenses/>.

Additional Details:

This affects most/all public PurpleTeam projects.

Create API SUT and test

SUT Resources

Mentioned by Nicholas Tolstoshev on #project-zap of OWASP Slack

Mentioned by @ricekot on #project-zap of OWASP Slack

Mentioned by @kingthorin_rm on #project-zap of OWASP Slack

https://owasp.org/www-project-vulnerable-web-applications-directory/

Mentioned by @Kinnaird McQuade on #project-zap of OWASP Slack

local returns 'app tests are running', cloud returns 'initialising job'

Actual Behavior:

In local env the very first response is 'app tests are running'
In cloud env the very first reponse is 'initialising job'

I think this may be because the cloud returns the status faster than local but unsure.

Expected Behavior:

Both local and cloud to be the same

Steps to Reproduce:

Run a test

Review Dockerfile's, are they production ready?

Create Tester reset for "Tester failure:" occurrances

If the orchestrator.js testTeamAttack returns initTesterResponsesForCli due to failedTesterInitialisations.length || !startTesters, for example if a Tester failure: occurred, for example due to:

No tlsScanner resource object being provided in the Job file
- Then the App Tester will be in the state of Tester initialised.
Or perhaps a timeout while waiting for s2 containers to be up (easy to simulate)
- Then the Tls Tester will be in the state of Tester initialised.

This means subsequent calls to orchestrator.js testTeamAttack will return the same internals.initTesterResponsesForCli as last time, and Testers will never change state.

What we need is a reset routine for each Tester

The first place the reset should be invoked from would be within the first option of the current internals.initTesterResponsesForCli = failedTesterInitialisations.length || !startTesters ternary in testTeamAttack of orchestrator.js.
internals.initTesterResponsesForCli = null which is currently in orchestrator.js processTesterFeedbackMessageForCli should be in something like a resetTesters routine of the orchestrator.
The resetTesters routine would also call each model's testerFinished(true)

reset should probably attempt stopping any s2 containers as well as setting status.
Add tests, even if manual

Unclear instructions / failing start

Actual Behavior:

Wanted to try out purpleteam (guide at https://purpleteam-labs.com/doc/local/set-up/)

Cloned https://github.com/purpleteam-labs/purpleteam-orchestrator
npm run dc-build
results in

npm run dc-build                                                    

> [email protected] dc-build /Users/my-user/Develop/purpleteam-orchestrator
> npm run dc-orchestrator-testers build


> [email protected] dc-orchestrator-testers /Users/my-user/Develop/purpleteam-orchestrator
> APP_SCANNER_GROUP_ID=$(id -g) APP_SCANNER_USER_ID=$(id -u) ORCHESTRATOR_GROUP_ID=$(id -g) ORCHESTRATOR_USER_ID=$(id -u) docker-compose -f ./compose/orchestrator-testers-compose.yml "build"

WARNING: The HOST_DIR variable is not set. Defaulting to a blank string.
ERROR: build path /Users/my-user/develop/purpleteam-app-scanner either does not exist, is not accessible, or is not a valid URL.

Mh, okay. Can't see that in instructions, but okay. Cloned https://github.com/purpleteam-labs/purpleteam-app-scanner.
npm run dc-build
now results in

npm run dc-up

> [email protected] dc-up /Users/my-user/Develop/purpleteam-orchestrator
> npm run dc-orchestrator-testers up


> [email protected] dc-orchestrator-testers /Users/my-user/Develop/purpleteam-orchestrator
> APP_SCANNER_GROUP_ID=$(id -g) APP_SCANNER_USER_ID=$(id -u) ORCHESTRATOR_GROUP_ID=$(id -g) ORCHESTRATOR_USER_ID=$(id -u) docker-compose -f ./compose/orchestrator-testers-compose.yml "up"

WARNING: The HOST_DIR variable is not set. Defaulting to a blank string.
Creating network "compose_pt-net" with the default driver
Pulling redis (redis:alpine)...
alpine: Pulling from library/redis
540db60ca938: Pull complete
29712d301e8c: Pull complete
8173c12df40f: Pull complete
a77b7ddf4978: Pull complete
3f34a000c6b3: Pull complete
275dfaedaf41: Pull complete
Digest: sha256:f8f0e809a4281714c33edf86f6da6cc2d4058c8549e44d8c83303c28b3123072
Status: Downloaded newer image for redis:alpine
Creating compose_redis_1 ... done
Creating pt-app-scanner-cont  ... error
Creating pt-orchestrator-cont ... 

Creating pt-orchestrator-cont ... error

ERROR: for pt-orchestrator-cont  Cannot create container for service orchestrator: invalid mount config for type "bind": field Source must not be empty

ERROR: for app-scanner  Cannot create container for service app-scanner: invalid mount config for type "bind": field Source must not be empty

ERROR: for orchestrator  Cannot create container for service orchestrator: invalid mount config for type "bind": field Source must not be empty
ERROR: Encountered errors while bringing up the project.

...

Expected Behavior:

Either something starts without error or guide has clear instructions.

...

Steps to Reproduce:

Seen above.

...

Environment:

Specific purpleteam project and version?
0.1.1 (i guess)
Running locally or in the cloud?
local
Details of your specific System Under Test (SUT)?
didn't come there
Which purpleteam components are running on which Operating System and version?
0.1.1
MacOS 11.4 + Docker 20.10.2
Ubuntu Server 20.04 + Docker 20.10.6
Anything else that will set the stage for us understanding your context?
node v14.17.0

Additional Details:

Checklist

I have read the documentation. (I hope I did not oversee/misunderstand something)

.env file rework

Rework how we handle environment variables in most of our services and CLI, use a .env and dotenv/config for local and provide a .env.example for source control. We use .env files in a few places, but will take this a bit further,

https://medium.com/the-node-js-collection/making-your-node-js-work-everywhere-with-environment-variables-2da8cdf6e786

setup .env files and dotenv/config in as many repos as makes sense. We didn't use dotnev anywhere
Add .env.example files
What happens if dotenv cant find a .env? Then it breaks
Document the parse error (due to incompatible TERM env var) in pt cli and detail what to do commit

Doc changes here (https://github.com/purpleteam-labs/purpleteam) and probably quite a few other places.

dotenv doesn't overload by default environment variables that are already set and by the look of it, can't do it using the pre-load technique (node -r dotenv/config server.js)

Issue

Add option to disable CLI screen

Actual Behavior:

Running (spawning, etc) purpleteam within another process, for example the NPM install locally option causes blessed errors due to the fact that the purpleteam CLI is not running directly within a terminal.

npm start for example.

Example output follows:

Expected Behavior:

No errors

Steps to Reproduce:

Run the CLI from within another process. It must get to the stage where the blessed screen is actually drawn though. So the orchestrator has to be running.

Because the CLI errors when creating the screen, the cli log also fails to be written.

Additional Details:

In order to fix this, the dashboard view should be disabled in the CLI
The purpleteam-build-test-cli project will need some modifications, probably just add an environment variable NO_SCREEN
Update docs:

I think we need to change the transport that ptLogger is inited with to probably Console
Work out a way to swap the dashboard (blessed)
Release changes

Before starting work

link purpleteam dep purpleteam-logger
link purpleteam-build-test-cli dep purpleteam
Using npm list -g --depth 0 before and after linking to see the differences

Before commit/push/PR:

After commit/push/PR:

Publish release
Check release on github and npm (README, etc)
Tell the Slacks and twitter that new release is out
unlink

Re-work orchestrator.js

Re-work orchestrator.js
Re-work orchestrator.js variables like testerModels should be in internals or even better a member of the class

While doing this:

We may as well try and see what happens if we turn the CLI POST retry on again (default 2 retries), will this effect the cloud? Adds complexity for little gain. Currently there isn't really a need, and the time-outs would have to be tweaked quite a bit. Added comments to apiDecoratingAdapter.js
Currently the CLI still subscribes to updates even if Testers were not started, this shouldn't happen
a3dc4fe and daaec32 addresses this

Create Job file schema validator

Readme Tweaks

https://github.com/purpleteam-labs/purpleteam/blob/main/README.md#clone-the-git-repository

also needs to include npm install

With an optional npm link to install the repo as a system command

Probably also add some details to the Run section

Tickets to keep an eye on

Implement purpleteam-server-scanner

Possibly use https://github.com/sullo/nikto as the emissary.

Nikto: (Perl) Tests web servers. GPL which sounds fine used in a SaaS. The AGPL on the other hand means the code must be open. In Docker container: https://github.com/ellerbrock/nikto-docker or https://hub.docker.com/r/frapsoft/nikto/

Handle fatal failures in app.parallel better

We need to look at turning fatal failures into non fatal via retries and other means. Just search for throws and Todo's in app.parallel.js
- If all the s2 Service Discovery Service Instances don't come up within the timeOut (70000 at time of writing) app.parallel getS2ContainerHostNamesWithPorts rejects with new Error 'Timed out while waiting for S2 Service Discovery Service Instances to be available.'. This is currently fatal (app-scanner container hangs), Can we reduce the timeOut to well under the Api Gateway timeout and use our redis publisher to publish a message. Then retry getS2ContainerHostNamesWithPorts up to two more times? This would satisfy the Api Gateway 30 second timeout, provide some feedback to the purpleteam CLI, and almost certainly be successful. The first try on a cold EC2 instance takes longer. Also the s2 Service Discovery Service Instances that are up will remain up after retrys, making subsequent retrys faster. Also if an exception is thrown, which in this case it is, the s2 Service Discovery Service Instances will currently never be brought down. This is also a problem that needs addressing. If the AMI resources is not sufficient for the number of containers requested, then the timeOut will consistenly be hit, there is a comment in getS2ContainerHostNamesWithPorts of app.parallel around this.
  Need to also work out what happens if the Lambda timeouts are hit. Test this by reducing the timeout. Then handle this in the lambdas and in the app-scanner, publishing feedback to the purpleteam CLI
Problems when we kill the CLI before tests are finished due to pollTesterMessages (that hasn't been called on last message) not cleaning up the testerWatcher
Starting a test too soon after a previous one, we'll need better error handling and notification to the build user

Dog food the Orchestrator/Cloud API

Create abilitiy to remove false positives

Start here: https://www.zaproxy.org/faq/how-do-i-handle-a-false-positive/

Improve orchestrator Tester model error handling

Orchestrator Tester models startTester, initTester and plan:

Need to retry if requests to Testers fail. Swap Wreck for got as Wreck doesn't support retry
Provide error handling for failed requests.
- plan already has some, but it'll probably need changing
- initTester should be easy to handle as we can just pass back a "Tester failure:"
- startTester may be a little more work,
  - startTester needs to set isFinished to true and return a "Tester failure:" message, which would also need to be augmented into the combinedInitTesterResponses that the orchestrator returns to the CLI
  - The following could be done, but may not need to be:
  - #warmUpTestSessionMessageChannels should probably also check that it's only acting on Tester models where testerFinished() is true
  - There is also no point in the CLI asking for Tester updates from the orchestrator

May as well swap axios and http-proxy-agent for got and hpagent in app.emissary.js of the app-scanner.

Add tests, even if manual

Rename slave/slaves

slave -> emissary
slaves -> emissaries
Slave -> Emissary
Slaves -> Emissaries

proj	commited	`apply` -> search again	merged	pushed	change-set
doc	✓	-	✓	✓	commit
CLI	✓	-	✓	✓	commit
app-scanner	✓	-	✓	✓	commit
lambda	✓	-	✓	✓	commit
s2-containers	✓	-	✓	✓	commit
orchestrator	✓	-	✓	✓	commit
iac-sut	-	-	-	-	-
logger	-	-	-	-	-
tls-checker	-	-	-	-	-
server-scanner	-	-	-	-	-

System tested
Check badges

Get API scanning ready

https://www.zaproxy.org/faq/how-can-you-use-zap-to-scan-apis/
https://www.zaproxy.org/docs/docker/api-scan/
Review the scanning apis with zap post and decide if and what changes we need to make
Useful link: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
There are some good thoughts in this blog post around API security testing. Some decisions here:
- Get API testing working well with purpleteam, consider ingesting OpenAPI/Swagger file to seed Zap spidering process
- Create IDE plugins that will take a OpenAPI/Swagger contract and test against the code (white box)

Implement Server scanner

We're going to be using Nikto. The majority of the code will be in https://github.com/purpleteam-labs/purpleteam-server-scanner.

This is mostly green fields work. We have the app-scanner and tls-scanner fully implemented to use as a reference for what Testers look like.

The diagram here shows where Testers fit into the architecture.

As with the TLS Tester, this will require on-going maintenance, is the work worth what the Server Tester provides? If not, decide what to do.

Only trust secure TLS certificates in selenium webdriver

This covers Zap self-signed certs and self-signed certs that SUTs may present.

Currently all self-signed certs presented to the webdriver are accepted. Ideally where we want to get to is to not trust any insecure certificates, that is passing false in the following calls in webDriverFactory.js in the app-scanner:

chromeOptions.setAcceptInsecureCerts(true)
firefoxOptions.setAcceptInsecureCerts(true)

In order to do this the following two items need to be done.

Zap

Each Zap instance uses it's own root certificate.

Currently if we have:

chromeOptions.setAcceptInsecureCerts(false)
firefoxOptions.setAcceptInsecureCerts(false)

With the Zap self-signed cert, this will block the selenium browser currently. So what we need to do is:

Get the dynamicaly created Root CA from each Zap instance. The Zap API method coreOtherRootcert should do the trick
create our own browser profile (chrome and firefox) with the zaproxy cert added
Tell selenium to launch the browser based on that profile

These steps should be performed within the routines addressed by the following calls in the Cucumber world:

async initialiseBrowser() {
  await this.sut.initialiseBrowser(this.zap.getPropertiesForBrowser(), this.selenium);
}

SUT

Step 2 and 3 of the above will be similar, but we will need to work out where the best place to source the self-signed customer SUT certificate from. A couple of thoughts:

Passed in the Build User config (Job). This seems a bit smelly
Provided as an environment variable. This would work for both local and cloud

Discussions

I have enabled the Discussions feature. It would be a good place to ask purpleteam-related questions and discuss it in general.

Please be kind and constructive.

This issue can be used for discussing adding new categories and other meta things.

zaproxy needs it's deps (request and friends) updated

This is another you could dive into @ricekot. If and when you do, let me know and I'll dig out as much info as I have. I've done this once before. My fork is here: https://github.com/binarymist/zap-api-nodejs

purpleteam-app-scanner interfaces with Zap via the zap-api-nodejs. The app-scanner is currently pointing at a commit (https://github.com/purpleteam-labs/purpleteam-app-scanner/blob/main/package.json#L88)

Basically we need to update the HTTP library (move away from request as it's now depricated): https://github.com/binarymist/zap-api-nodejs/blob/master/package.json#L28-L29

I'd probably use got again. I moved from request to got in the CLI. Most of the changes were in the apiDecoratingAdapter.js: a705ae8

The zap-api-nodejs is all generated JavaScript, so you need to play a little with Java, not a big deal though. When you get there give me a yell. This not only affects purpleteam-labs but also Zap obviously and all of it's consumers via the Node API @psiinon would also be happy 😄

Update: (2021-02-25) See issue in zaproxy

Creat and deploy website for public documentation

Current Behavior:

Currently public doc:

Source is at: https://github.com/purpleteam-labs/purpleteam-doc
Rendered is at: https://doc.purpleteam-labs.com

Proposed Behavior:

public docs need to have their own website

How It Would Benefit You:

Users wil be able to find information about purpleteam, it'll be user friendly

Additional details

@binarymist has been doing research on this for a couple of years and has a bunch of ideas, requirements and a shortlist of possible platforms to use. Ping @binarymist when starting this. Some of the notes taken have a degree of sensitivity.

As a stop-gap measure we've hosted https://github.com/purpleteam-labs/purpleteam-doc as doc.purpleteam-labs.com
Details here: https://webmasters.stackexchange.com/questions/105899/cloudflare-dns-how-to-setup-a-github-repository-to-a-custom-sub-domain

Cleanup all occurances of domain names and ip addresses and naming of

We could change all occurances of sutIp to hostname, but what would make the most sense is to just combine:
sutIp, sutPort, sutProtocol from the job file into sutUrlOrigin

We should also be using URL:

Add Container Insights to ECS Cluster in iac-sut

purpleteam-labs/purpleteam-iac-sut@e92e5d1

Update Dependencies

SUT

NodeGoat
- Details to set-up NodeGoat
- https://github.com/purpleteam-labs/purpleteam-iac-sut

System

Project

@hapi/good (API here) is deprecated. It doesn't actually do anything other than log process metrics (memory, uptime, load). All other logging is done by the generic hapi logger (server.log, request.log) or purpleteam-logger. good can stay until it no longer works, then we can just remove it along with hapi-good-winston.

Replace instances of JSON.parse with Bourne.parse

Message on #hapi Slack from the BDFL on 2020-07-05:
eran 08:05
@channel hapi v18 will is being soft-deprecated. This means it will only get critical security fixed between now and the end of the year. No other bug fixes or node version updates will be released. It was supposed to be deprecated months ago but was postponed due to the COVID-19 situation. You will start seeing a deprecation message on npm now, and then it will no longer receive any support or security fixed at the end of the year. There is no reason not to upgrade to hapi v19. It is a trivial upgrade from v18
hapijs/hapi#4111

NPM tricks

Publish

Publish and create release notes

Review and make necessary changes to CLI according to Node.js CLI Apps Best Practices

What other Authentication techniques does purpleteam need to support?

Current Behavior:

We have username and password SUT login.

Proposed Behavior:

Research and document which other authentication techniques purpleteam needs to support
Start looking at authentication techniques for APIs with Zap (OAuth flows and how to provide tokens, etc.)
- https://faun.pub/automating-authenticated-api-vulnerability-scanning-with-owasp-zap-eaddba0c2e94
MFA
- https://groups.google.com/g/zaproxy-users/c/Nmydxd67UOc
- OTPs sent to phone
  - We use an online virtual cell phone with API to receive sms and push notification
  - Forwarding of notifications or SMS to email. Script email retrieval
  - @ricekot mentioned on #project-zap: With time-based OTP (TOTP) you can use the secret to generate an OTP and use that for authentication. See ICTU/zap2docker-auth-weekly@44971a8, But the application you're testing would have to support that
WebAuthn which replace passwords
- https://webauthn.guide/
- https://auth0.com/blog/introduction-to-web-authentication/
- Selenium Support
  - https://stackoverflow.com/questions/63477115/selenium-tests-authenticate-with-webauthn
  - SeleniumHQ/selenium#7753
- http://solokeys.com/ mentioned by μSec in InfoSecNZ
Work out a plan to implement
Create issue(s) to implement

How It Would Benefit You:

Build Users would be able to provide authentication details to purpleteam other than username and password so that purpleteam can authenticate with the SUT

Notes:

Zaproxy had a google doc somewhere that listed all it's authentication techniques. Finding where this is documented would be a good place to start
Possibly put a survey out to find out what Devs and their Teams need

Resources

https://secret.club/2021/06/28/windows11-tpms.html

Scratch

Add cloud section to doc site

https://doc.purpleteam-labs.com/

Mask outstanding password values in logs

Current Behavior:

Not all password fields are currently masked in logs

Proposed Behavior:

Mask them all

Keeping in mind future auth types

purpleteam-labs / purpleteam Goto Github PK

purpleteam's People

Contributors

Stargazers

Watchers

Forkers

purpleteam's Issues

Actual Behavior:

Expected Behavior:

Steps to Reproduce:

Additional Details:

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Releases:

Overall

Website

Added

Changed

Issues Created

Useful Resources

Resources

Used in app-scanner app.parallel

Used in lambda for cloud

Actual Behavior:

Expected Behavior:

Additional Details:

SUT Resources

Actual Behavior:

Expected Behavior:

Steps to Reproduce:

Actual Behavior:

Expected Behavior:

Steps to Reproduce:

Environment:

Additional Details:

Checklist

Actual Behavior:

Expected Behavior:

Steps to Reproduce:

Additional Details:

Before starting work

Before commit/push/PR:

After commit/push/PR:

Zap

SUT

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Additional details

SUT

System

Project

Publish

Current Behavior:

Proposed Behavior:

How It Would Benefit You:

Notes:

Resources

Scratch

Current Behavior:

Proposed Behavior:

Recommend Projects

Recommend Topics

Recommend Org

Used in lambda for `cloud`