Credentialed Scan or Scan With Cookie

[OulipianSummer]

Hey all,

Thanks for making such a great tool!

I was wondering if it is possible to run a scan on a domain with a cookie so that the bot can access pages that are behind a login? I can't find anything in the docs that covers this, but it seems like it would be possible given the stack.

If this doesn't exist yet, I'd be open to working with you to get this feature into the codebase as I would have an immediate use for it.

Please feel free to reach out at andrew@xequals.co.nz with any questions

[G-Rath]

Thanks for reaching out, we agree it's an interesting idea but are not sure how it could be archived in a way that wouldn't be abusable - if you have some ideas, we'd love to hear them

[OulipianSummer]

Hey @G-Rath,

Yeah I guess I hadn't really considered that side of things, but it makes sense considering the intended usage.

Ok, well I've done some thinking about this overnight and I think I've essentially come up with a basic interface for driving this.

We need to verify that the CWAC operator is the same person who owns the website, or, if they don't own the website, they're at least on friendly terms with the person who is.

So we need to be able to verify that the person driving CWAC actually has privileged access to the server codebsae and, once that has been satisfied, that this person ALSO has privileged access to the application layer (via a login, cookie, secret header, or some such device).

What we're really talking about here is a zero trust auth situation. Without knowing who the operator is, we need to know that they have access to certain information that only the operator could own.

So things like PGP or RSA come to mind. Here's what I'm thinking.

• Change the crawl list CSV so that it can support a with_auth field. The values can be 1 or 0 or null (for an empty field, to preserve backwards compatibility)
• Change the config.json interface so it supports a few new fields
  • server_secret: a public URL where CWAC can find a piece of encrypted text that contains a cookie or one-time login URL that can be used for access to the server. This could be implemented by the server maintainer as a plain-text file located at a publicly accessible location. The cipher text would need to be encrypted with something like 4096 bit RSA.
  • encryption_key: this is a local filepath to an encryption key
  • server_auth_type: some sort of enum type describing what to do with the information that CWAC decrypts from the server, something like cookie or url just to keep things simple. The cookie type presents the decrypted token as a cookie to the server, url directs CWAC to visit something like a one-time login URL where CWAC can be given a cookie by the server directly.
  • encryption_method: this could be another enum describing which encryption algorithm to use, values could be pgp or rsa. I'm a little split as to whether this is even required. Maybe in the initial PR we could just focus on one to keep the implementation lean.

I also had the idea of storing cookies in between scans to make things easier for the CWAC user, but I think that would put is back in "possible to abuse" territory. Instead, CWAC should just store the cookie in memory until the scan is done and then the user would need to re-auth on the next scan.

For setup, the CWAC operator would need to generate some encryption keys. Both PGP and RSA would generate asymmetric keys so we'd be working with a concept of both public and private access.

I think the encryption workflow would look like this:

• The operator generates a keypair using whatever method makes sense for them to do so
• Using the private key, the operator encrypts the payload (either a one-time login URL or a session cookie) using whatever method makes sense for them to do so
• The cipher text gets uploaded to a publicly accessible location on the server.
  • Every application is going to have different expectations about what this would look like. I think for ease of implementation it would make sense if CWAC expected a static text file and the server simply served whatever was at that path. Hence, why encrypting the contents of that file matter.
• The operator provides the public encryption key to CWAC in the form of a filepath
• The operator triggers a CWAC scan.
• When CWAC encounters a URL path that requires authentication, it refers to the config file, discovers where to find the cipher text on the server, asks for the contents of that file, checks the config again to find the local filepath to the public key, decrypts the cipher text, and then either stores the cookie in memory (when using the cookie server_auth_type) or visits the one-time login url (when using the url server_auth_type) and then stores the cookie in memory. Future visits to other URL's that also require auth will just reuse the cookie until the scan is over, and then the cookie is erased.

I'm not totally clear on your plugin API for this tool, but I'm wondering if this is a good candidate for implementing as its own standalone extension on par with the other a11y tools you're already using.

Phew, that was a bit, but I think it encompasses the basic premise of a basic zero knowledge auth workflow for the purposes of obtaining proper access to the application layer of a given website. CWAC can then just do what it already does best and scan over a list of URLs looking for accessibility issues.

Some dangling questions:

• How would we enforce the idea of "OK, now you've got your cookie to access the app, now pretty please delete the cipher text on the server"? As an extra precaution, we could limit this entire auth workflow to only function on localhost. It's not ideal (I've still not been able to get CWAC to crawl anything on my localhost reliably, but I assume it's user error), but I think it could limit the potential for abuse. If we are relying on the server being able to provide one-time logins, then this becomes moot because the encrypted payload becomes useless as soon as it is used.
• Which encryption library should we aim for? The reliance on PGP or RSA is pretty much arbitrary given this setup, which is why it seems like it would be nice to have both, but I don't have have any clear concept of what the requirements would be for use in a production system.

I would love your feed back on this.

Me and my team are currently exploring using CWAC for a project for the NZ DOC and we're trying to figure out how far we can leverage this tool for use in future projects where standardized accessibility modeling and reporting are required for launch.

[G-Rath]

There's some interesting ideas in there, but I feel like most (if not all?) are about getting and managing the values securely which I don't think is something the tool itself needs to be responsible for.

I wonder if instead having an environment variable similar to our CHROME_EXTRA_ARGS variable that let you provide a list of arbitrary headers would be sufficient for most use cases

[OulipianSummer]

Ultimately, yes, I think that's all we'd probably need, and the implementation footprint is certainly smaller.

I was initially under the impression that this sort of thing was the abuse vector you were worried about, which is why I tossed together a more comprehensive proposal with all of the auth and decryption workflows. But if this suits, I'd be happy with this.

I wasn't aware that this was an environment variable users could take advantage of. Can Firefox users use the same variable to accomplish the same goal?

[G-Rath]

Cool yeah if you want to explore a PR adding that, we'd be happy to review it - I think it's a great middleground kind of place to start with this feature.

Regarding Firefox, I would imagine it's possible but right now that support is very untested and we've actually been considering removing it for the time being as I believe it's there more to make it easier for those running the tool locally that don't have Chrome than because of any particular advantage like performance or accuracy vs Chrome.

[OulipianSummer]

Hm... That might make it a bit tricky, I've only been able to get Firefox testing set up in the meantime. I'm using NixOS and the Chrome and cromedriver binaries that comes with the CWAC install don't work right off the bat.

I'll probably be submitting a pull that implements nix support as I'm needing to do that anyway, if that's not a huge issue.

But, regardless, yes-- I'll take a look at getting this stood up and engage my team to see if there's any interest in putting some time towards this.

[G-Rath]

fwiw our recommendation these days is to use the Docker image which should be OS agnostic - there's examples of that in #336 and our CI setup

[G-Rath]

we also literally yesterday landed the Chrome upgrade which also changed how we get Chromedriver, which might help too 🤞