owasp-amass / amass

In-depth attack surface mapping and asset discovery
https://owasp.org/www-project-amass/
Other
12.05k stars 1.88k forks source link

Clarification on ini file credentials format #734

Closed mzpqnxow closed 2 years ago

mzpqnxow commented 3 years ago

Hey @caffix and friends,

I had a question about the ini file and how credentials can be stored as well as how you recommend they should be stored- meaning, what is supported, and what is recommended as the "best-practice". This isn't a request for doing it differently, I just want to ensure I'm doing it in the best way possible as I'm using a Jinja2 template to generate an Amass.ini file (which I'm happy to contribute later if it's useful to anyone)

As I understand it (and based on the example here) for source where only a single credentials is available, the following format should be used:

[data_sources.HackerTarget]
# Optional TTL overrides default TTL
ttl = 86400
[data_sources.HackerTarget.Credentials]
apikey = THE_API_KEY

For a source where multiple sets of credentials are available, the following format should be used:

[data_sources.HackerTarget]
# Optional TTL
ttl = 86400

[data_sources.HackerTarget.account1]
apikey = API_KEY_LITERAL_1

[data_sources.HackerTarget.account2]
apikey = API_KEY_LITERAL_2

In the case of multiple credentials for a source, the name of the section is arbitrary and can be anything so long as each are different. For example, the following is functionally equivalent to the previous example:

[data_sources.HackerTarget]
# Optional TTL
ttl = 86400

[data_sources.HackerTarget.account_derp]
apikey = API_KEY_LITERAL_1

[data_sources.HackerTarget.account_huhu]
apikey = API_KEY_LITERAL_2

The only thing about this that makes my OCD twitch is the fact that the keyword "Credential" is not present in the multiple credential set format. That's also what made me want to confirm that this is the correct way to set these values as I'm not sure whether the example ini file is 100% up to date, and I know some enhancements were made to the multiple credential features over the past months

One specific question for you- is there any reason to not use the multi-credential format when there is only a single set of credentials? For example, I would prefer to use the following, as opposed to the first "short-hand" style example at the top, even though only one credential is available in this example:

[data_sources.HackerTarget]
# Optional TTL
ttl = 86400

[data_sources.HackerTarget.account1]
apikey = API_KEY_LITERAL_1

Anyway, if you can confirm I'm not misunderstanding, that'd be swell. What I can offer you in exchange for that (if you're interested) is:

  1. Clarification in the existing documentation, if helpful or necessary
  2. A jinja2 ini file, for those who may want to create Amass ini files from Python. You may wonder why anyone would want to do that- in my case, I have several projects that use these data sources and keep all of the credentials (and a bunch of other parameters) in a YaML file, which is used mostly by my Python application stack, but also by a few other tools (e.g. masscan, massdns, Amass, etc) so it's useful to have it all in one place, and to use templates to generate/regenerate configuration files when something is changed, removed or added

Thanks, sorry for the bother- there's of course no rush on this request and as always I appreciate your assistance

Another-Anonymous-Person commented 2 years ago

Hello, I would also like to be clear about this, since although they closed the issue they did not answer what would be the best way to configure the .ini file.

Thanks and best regards.