mirror of
https://github.com/0x5t4l1n/hunting.git
synced 2026-05-26 11:35:51 +00:00
Add XML injection, prompt injection, enhanced open redirect payloads, and contribution guidelines
Co-authored-by: Stalin-143 <161853795+Stalin-143@users.noreply.github.com>
This commit is contained in:
copilot-swe-agent[bot]
+259
@@ -0,0 +1,259 @@
|
||||
# 🤝 Contributing to Hunting-
|
||||
|
||||
Thank you for your interest in contributing to this security testing repository! We welcome contributions that help make this resource more comprehensive and valuable for the security community.
|
||||
|
||||
## 📋 Table of Contents
|
||||
|
||||
- [Code of Conduct](#code-of-conduct)
|
||||
- [How Can I Contribute?](#how-can-i-contribute)
|
||||
- [Contribution Guidelines](#contribution-guidelines)
|
||||
- [Adding New Payloads](#adding-new-payloads)
|
||||
- [Creating New Categories](#creating-new-categories)
|
||||
- [Submission Process](#submission-process)
|
||||
- [Quality Standards](#quality-standards)
|
||||
|
||||
## 🤝 Code of Conduct
|
||||
|
||||
### Our Standards
|
||||
|
||||
- **Be Ethical**: All contributions must be for legitimate security testing purposes
|
||||
- **Be Respectful**: Treat all contributors with respect and professionalism
|
||||
- **Be Legal**: Only contribute content that is legal and ethical
|
||||
- **Be Helpful**: Focus on educational value and practical security testing
|
||||
- **Be Accurate**: Ensure all payloads and techniques are properly documented
|
||||
|
||||
### Prohibited Content
|
||||
|
||||
Do NOT contribute:
|
||||
- Illegal or malicious content
|
||||
- Personal information or credentials from unauthorized sources
|
||||
- Exploits for 0-day vulnerabilities before responsible disclosure
|
||||
- Content that encourages illegal activities
|
||||
- Plagiarized content without proper attribution
|
||||
|
||||
## 💡 How Can I Contribute?
|
||||
|
||||
### Types of Contributions
|
||||
|
||||
1. **New Payloads**: Add new security testing payloads to existing categories
|
||||
2. **New Categories**: Propose and create new vulnerability categories
|
||||
3. **Documentation**: Improve README files and explanations
|
||||
4. **Bug Fixes**: Correct errors in existing payloads or documentation
|
||||
5. **Organization**: Improve structure and organization of content
|
||||
6. **Examples**: Add real-world examples and use cases
|
||||
|
||||
## 📝 Contribution Guidelines
|
||||
|
||||
### General Rules
|
||||
|
||||
1. **Quality Over Quantity**: Focus on well-tested, effective payloads
|
||||
2. **Clear Documentation**: Each payload should be clearly explained
|
||||
3. **Proper Attribution**: Credit original sources when applicable
|
||||
4. **Educational Focus**: Include context about when and how to use payloads
|
||||
5. **Organized Structure**: Follow the existing repository structure
|
||||
6. **Legal Compliance**: Ensure all content complies with applicable laws
|
||||
|
||||
### Content Requirements
|
||||
|
||||
- **Relevance**: Content must be relevant to security testing
|
||||
- **Accuracy**: Payloads should be tested and verified when possible
|
||||
- **Clarity**: Use clear, descriptive naming and organization
|
||||
- **Context**: Provide background information about attack vectors
|
||||
- **Safety**: Include warnings about potential impacts
|
||||
|
||||
## 🎯 Adding New Payloads
|
||||
|
||||
### Step-by-Step Process
|
||||
|
||||
1. **Identify the Category**: Determine which existing category fits your payload
|
||||
2. **Check for Duplicates**: Ensure the payload doesn't already exist
|
||||
3. **Format Properly**: Follow the formatting style of existing payloads
|
||||
4. **Add Context**: Include comments explaining complex payloads when needed
|
||||
5. **Test if Possible**: Verify payloads work in authorized testing environments
|
||||
|
||||
### Payload Format
|
||||
|
||||
```
|
||||
## Section Name
|
||||
payload_1
|
||||
payload_2
|
||||
payload_3
|
||||
|
||||
## Another Section
|
||||
payload_with_description
|
||||
# Comment explaining complex payload
|
||||
another_payload
|
||||
```
|
||||
|
||||
### Example Addition
|
||||
|
||||
```
|
||||
## DOM-Based XSS
|
||||
<img src=x onerror=alert(document.domain)>
|
||||
<svg/onload=alert(1)>
|
||||
javascript:alert(document.cookie)
|
||||
```
|
||||
|
||||
## 📁 Creating New Categories
|
||||
|
||||
### When to Create a New Category
|
||||
|
||||
Create a new category when:
|
||||
- The vulnerability type doesn't fit existing categories
|
||||
- There's substantial content (15+ unique payloads)
|
||||
- The category represents a distinct attack vector
|
||||
- It provides significant educational value
|
||||
|
||||
### New Category Structure
|
||||
|
||||
```
|
||||
New-Category/
|
||||
├── README.md
|
||||
└── new-category-payloads.txt
|
||||
```
|
||||
|
||||
### README.md Template
|
||||
|
||||
```markdown
|
||||
# Category Name
|
||||
|
||||
## Description
|
||||
Brief description of the vulnerability type.
|
||||
|
||||
## Common Attack Vectors
|
||||
- Vector 1
|
||||
- Vector 2
|
||||
- Vector 3
|
||||
|
||||
## Testing Approach
|
||||
How to test for this vulnerability.
|
||||
|
||||
## Payloads
|
||||
See `category-payloads.txt` for comprehensive list.
|
||||
```
|
||||
|
||||
## 🔄 Submission Process
|
||||
|
||||
### Step 1: Fork the Repository
|
||||
|
||||
```bash
|
||||
# Fork on GitHub, then clone your fork
|
||||
git clone https://github.com/YOUR-USERNAME/Hunting-.git
|
||||
cd Hunting-
|
||||
```
|
||||
|
||||
### Step 2: Create a Branch
|
||||
|
||||
```bash
|
||||
# Create a descriptive branch name
|
||||
git checkout -b add-xss-payloads
|
||||
# or
|
||||
git checkout -b new-category-api-injection
|
||||
```
|
||||
|
||||
### Step 3: Make Your Changes
|
||||
|
||||
- Add your payloads or create new files
|
||||
- Follow the existing structure and format
|
||||
- Update the main README.md if adding a new category
|
||||
- Test your changes locally
|
||||
|
||||
### Step 4: Commit Your Changes
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Add new XSS payloads for DOM manipulation"
|
||||
# Use clear, descriptive commit messages
|
||||
```
|
||||
|
||||
### Step 5: Push and Create Pull Request
|
||||
|
||||
```bash
|
||||
git push origin add-xss-payloads
|
||||
```
|
||||
|
||||
Then create a Pull Request on GitHub with:
|
||||
- **Clear Title**: Describe what you're adding
|
||||
- **Description**: Explain the changes and why they're valuable
|
||||
- **Testing**: Mention if you've tested the payloads
|
||||
- **References**: Link to any relevant sources or documentation
|
||||
|
||||
## ✅ Quality Standards
|
||||
|
||||
### Before Submitting
|
||||
|
||||
- [ ] Payloads are properly formatted
|
||||
- [ ] No duplicates exist
|
||||
- [ ] Documentation is clear and accurate
|
||||
- [ ] Follows existing structure and conventions
|
||||
- [ ] Commit messages are descriptive
|
||||
- [ ] No personal or sensitive information included
|
||||
- [ ] Content is legal and ethical
|
||||
- [ ] Proper attribution provided when applicable
|
||||
|
||||
### Review Process
|
||||
|
||||
1. **Initial Review**: Maintainers will review your PR
|
||||
2. **Feedback**: You may receive requests for changes
|
||||
3. **Updates**: Make requested changes if needed
|
||||
4. **Approval**: Once approved, your PR will be merged
|
||||
5. **Recognition**: Contributors will be acknowledged
|
||||
|
||||
## 📚 Resources
|
||||
|
||||
### Helpful Links
|
||||
|
||||
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
|
||||
- [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
|
||||
- [Bug Bounty Platforms](https://www.bugcrowd.com/)
|
||||
- [Responsible Disclosure Guidelines](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)
|
||||
|
||||
### Testing Environments
|
||||
|
||||
Always test in authorized environments:
|
||||
- Personal lab environments
|
||||
- Authorized CTF platforms
|
||||
- Bug bounty programs with explicit scope
|
||||
- Open-source test applications (DVWA, WebGoat, etc.)
|
||||
|
||||
## 🎓 Learning and Growth
|
||||
|
||||
### For New Contributors
|
||||
|
||||
- Start small with simple payload additions
|
||||
- Review existing content to understand the format
|
||||
- Ask questions if you're unsure about anything
|
||||
- Learn from feedback on your pull requests
|
||||
|
||||
### Best Practices
|
||||
|
||||
- **Stay Updated**: Keep up with latest security research
|
||||
- **Be Thorough**: Research payloads before contributing
|
||||
- **Collaborate**: Engage with other contributors
|
||||
- **Improve**: Continuously enhance your contributions
|
||||
|
||||
## 📧 Contact
|
||||
|
||||
### Questions or Suggestions?
|
||||
|
||||
- **Issues**: Open a GitHub issue for discussions
|
||||
- **Pull Requests**: For direct contributions
|
||||
- **Security Concerns**: Report responsibly if you find issues
|
||||
|
||||
## 🙏 Recognition
|
||||
|
||||
All contributors will be recognized for their valuable contributions to the security community. Thank you for helping make this resource better!
|
||||
|
||||
## ⚖️ Legal Reminder
|
||||
|
||||
By contributing to this repository, you confirm that:
|
||||
- Your contributions are original or properly attributed
|
||||
- You have the right to share this content
|
||||
- Your contributions comply with the repository's disclaimer
|
||||
- You understand the ethical and legal implications
|
||||
|
||||
---
|
||||
|
||||
**Happy Contributing! Let's build a better, more secure web together! 🚀**
|
||||
|
||||
*For legal disclaimers and terms of use, please see [DISCLAIMER.md](./DISCLAIMER.md)*
|
||||
Reference in New Issue
Block a user