mirror of
https://github.com/danielmiessler/SecLists.git
synced 2025-05-27 16:36:30 -04:00
105 lines
6.2 KiB
Markdown
105 lines
6.2 KiB
Markdown
> [!CAUTION]
|
|
> Uploading complete data breaches to Seclists is not allowed. You may only upload the passwords obtained from a data breach as long as you do **not** upload any PII (Personally Identifiable Information) that could link those passwords back to any specific user.
|
|
|
|
## Contributing
|
|
|
|
If you have any ideas for things we should include, please use ONE of the following methods to submit them:
|
|
|
|
* Create a pull request
|
|
* Create an issue in the project (with links, and we'll parse and incorporate them)
|
|
|
|
Significant effort SHOULD be made to give attribution for these lists whenever possible, and if you are a list owner or know who the original author/curator is, please let us know so we can give proper credit.
|
|
|
|
## Folder naming scheme
|
|
|
|
Folders should be named with the train case scheme, for example `File-System`.
|
|
|
|
## Conventional Commits
|
|
|
|
All commits related to contributions to seclists are encouraged to use the [Conventional-Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) syntax
|
|
|
|
> The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.
|
|
>
|
|
> The commit message should be structured as follows:
|
|
```xml
|
|
<type>[optional scope]: <description>
|
|
|
|
[optional body]
|
|
|
|
[optional footer(s)]
|
|
```
|
|
|
|
For example:
|
|
```
|
|
feat(wordlist): Added "raft" wordlists by Google
|
|
```
|
|
|
|
Below is a flowchart which should assist you in selecting the best conventional-commits syntax for the commit messages of the contributions you wish to make.
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
start(You made a commit) --> f1
|
|
f1{Does it affect a wordlist?}
|
|
f1 --> |YES| q1A{Did you upload a\ncompletely new\nwordlist?}
|
|
|
|
q1A --> |YES| q1A_opt1(Use the syntax:\nfeat(wordlist): Added "WORDLIST_NAME_HERE" by AUTHOR_NAME_HERE)
|
|
q1A --> |NO| q1B{Did you add\ncompletely new\ncontent to an existing\nwordlist?}
|
|
|
|
q1B --> |YES| q1B_opt1(Use the syntax:\nfeat(wordlist): Added _____ to "WORDLIST_NAME_HERE")
|
|
q1B --> |NO| q1C{Did you fix an error/\nmistake/oversight in an\nexisting wordlist?}
|
|
|
|
q1C --> |YES| q1C_end(Use the syntax:fix(wordlist): Fixed _____ in "WORDLIST_NAME_HERE"\nfix(wordlist): Removed _____ from "WORDLIST_NAME_HERE")
|
|
q1C --> |NO| q1D{Did you perform a big operation\nwich affects all wordlists \nin a minor way?\nFor example: \n- Moving all wordlists from one \ndirectory to a new one\n- Changing the line-endings of\nall wordlists}
|
|
|
|
q1D --> |YES| q1D_end(Use the syntax:\nchore(wordlist): _____\n\nFor example:\n\nchore(wordlist): Moved all file-extension wordlists to /Fuzzing/File-Extensions/)
|
|
q1D --> |NO| support1(Ask a project-maintainer which commit type you should use)
|
|
|
|
f1 --> |NO| f2{Does if affect a\nREADME file?}
|
|
|
|
f2 --> |YES| q2A{Did you create a new\nREADME file?}
|
|
|
|
q2A --> |YES| q2A_end(Use the syntax:\nfeat(docs): Created documentation for ______)
|
|
q2A --> |NO| q2B{Did you fix a typo?\nDid you improve the\nphrasing of a README?}
|
|
|
|
q2B --> |YES| q2B_end(Use the syntax:\nchore(docs): Fixed typo for _____ docs\nchore(docs): Improved phrasing in ____ docs)
|
|
q2B --> |NO| q2C{Did you add new \ncontent to an existing\nREADME?}
|
|
|
|
q2C --> |YES| q2C_end(Use the syntax:\nfeat(docs): Added documentation for ______)
|
|
q2C --> |NO| q2D{Did you fix incorrect\ninformation in a \nREADME?}
|
|
|
|
q2D --> |YES| q2D_end(Use the syntax:\nfix(docs): Corrected _____\n\nFor example:\nfix(docs): Corrected author name for the raft.txt wordlist)
|
|
q2D --> |NO| support2(Ask a project-maintainer which commit type you should use)
|
|
|
|
|
|
f2 --> |NO| q3A{Does it affect the CICD\npipelines? (github actions)}
|
|
|
|
q3A --> |YES| q3B{Did you create a\ncompletely new\nautomation?}
|
|
q3A --> |NO| support3(Ask a project-maintainer which commit type you should use)
|
|
|
|
q3B --> |YES| q3B_end(Use the syntax:\nfeat(cicd): Created ______)
|
|
q3B --> |NO| q3C{Did you fix an error or \nfix a vulnerability in an \nexisting automation?}
|
|
|
|
q3C --> |YES| q3C_end(Use the syntax:\nfix(cicd): Fixed ______ in "AUTOMATION_NAME_HERE"\n\nFor example:\nfix(cicd): Fixed permissions error in "trickest-wordlist auto-updater")
|
|
q3C --> |NO| q3D{Did you add \na new feature \nto an existing \nautomation?}
|
|
|
|
q3D --> |YES| q3D_end(Use the syntax:\nfeat(cicd): Added _____ to "AUTOMATION_NAME_HERE"\n\nFor example:\nfeat(cicd): Added a file size checker to "dangerous_wordlist_checker.sh")
|
|
q3D --> |NO| q3E{Did you:\n- Fix a typo\n- Move a file\n- Add a code coment}
|
|
|
|
q3E --> |YES| q3E_end(Use the syntax:\nchore(cicd): Fixed typo in "AUTOMATION_NAME_HERE"\nchore(cicd): Moved ______\nchode(cicd): Added code comment to "AUTOMATION_NAME_HERE")
|
|
q3E --> |NO| support4(Ask a project-maintainer which commit type you should use)
|
|
```
|
|
|
|
## READMEs
|
|
|
|
If you are uploading a brand-new wordlist into SecLists, an entry must be added to the containing folder's `README.md`. If the folder does not already have a `README.md` file, you may create one.
|
|
|
|
These are the general guidelines for writing READMEs in SecLists:
|
|
1. Use the filename of the wordlist as the title. This will help other people more easily locate which entries in the README correspond to the wordlist you've uploaded.
|
|
2. If the wordlist is very purpose-specific, consider adding a `Use for:` text, right below the entry title. For example:
|
|
> ## vulnerability-scan_j2ee-websites_WEB-INF.txt
|
|
> Use for: Discovering sensitive J2EE files, allowing for exploitation of an LFI.
|
|
|
|
3. Always include a link to the source of the wordlist: `Source: example.com/the-great-wordlist`
|
|
4. If the author shared the wordlist through a blogpost, include a link to it: `Reference: example.com/how-i-hacked-xyz-with-a-wordlist`. This will help SecLists users more easily understand the practical applications of the wordlists you've uploaded.
|
|
|
|
You can use the README in the folder [Web-Content](Discovery/Web-Content) as a general reference.
|