cv-site/docs/HACK-CHALLENGE.md

Try to Hack Me! 🎯

Challenge Site: https://juan.andres.morenorub.io/ Status: ACTIVE Difficulty: ⭐⭐⭐ (Medium to Hard)

---

🎮 Welcome, Security Researcher!

This CV portfolio site is intentionally opening its doors to security researchers, ethical hackers, and curious developers. I believe the best way to prove security isn't through claims, but through real-world testing.

Why This Challenge?

As a developer who values security, I've implemented defense-in-depth protection across this application. Rather than just documenting these controls, I'm inviting you to test them yourself.

This is a showcase of:

• Production-grade security implementation
• Real-world attack prevention
• Transparent security practices
• Confidence in my code

Your mission (if you choose to accept it): Find vulnerabilities, bypass security controls, or break the application in creative ways.

---

🎯 Challenge Categories

Category 1: Browser-Only Challenge ⭐⭐⭐

Objective: Submit a contact form message using anything except a web browser.

What's Protected:

• The contact form at /api/contact ONLY accepts browser requests
• All automation tools are blocked: curl, wget, Postman, HTTPie, Python requests, etc.

Your Goal:

• Successfully submit a contact form using curl, Postman, or any HTTP client
• OR bypass browser-only validation with a crafted request

Difficulty: Hard

Why This Matters: Browser-only access prevents 95%+ of automated attacks. Can you join the 5% who bypass it?

Hints:

• What headers does a browser send that curl doesn't?
• Can you perfectly impersonate a browser?
• Is there a race condition in the validation?

---

Category 2: Rate Limit Bypass ⭐⭐

Objective: Exceed the rate limits without getting blocked.

What's Protected:

• Contact form: 5 requests per hour per IP
• PDF export: 3 requests per minute per IP

Your Goal:

• Submit more than 5 contact forms in 1 hour from a single IP
• Generate more than 3 PDFs in 1 minute from a single IP
• OR find a way to reset the rate limiter

Difficulty: Medium

Why This Matters: Rate limiting prevents spam and resource exhaustion. Can you find the loophole?

Hints:

• How does the server identify your IP?
• Can you make the server think you're multiple clients?
• Is the rate limiter stateless or stateful?

---

Category 3: Injection Challenge ⭐⭐⭐

Objective: Execute code or commands on the server.

What's Protected:

• Email header injection prevention
• XSS protection (HTML escaping)
• Command injection prevention (no shell commands)
• SQL injection (N/A - no database)

Your Goal:

• Inject email headers (Bcc, Cc, Content-Type)
• Execute JavaScript via XSS
• Run shell commands via command injection
• OR find any other injection vulnerability

Difficulty: Hard

Why This Matters: Injection attacks are the #1 web security threat. Can you find a gap in our input validation?

Hints:

• What characters are allowed in each field?
• How is user input sanitized?
• Are there any differences between client and server validation?

---

Category 4: Bot Detection Bypass ⭐⭐

Objective: Submit a contact form as a bot without getting detected.

What's Protected:

• Honeypot field (hidden from humans, visible to bots)
• Timing validation (must take at least 2 seconds)
• Server-side timestamp verification

Your Goal:

• Submit a form with the honeypot filled (bot behavior)
• Submit a form in less than 2 seconds
• OR bypass timing validation without waiting

Difficulty: Medium

Why This Matters: Bot detection prevents spam and automated abuse. Are you smarter than the bot detector?

Hints:

• Where is the timestamp set?
• Can you manipulate the timestamp?
• Is there a way to predict valid honeypot values?

---

Category 5: CSRF Challenge ⭐⭐⭐

Objective: Submit a valid CSRF-protected request from an external site.

What's Protected:

• CSRF tokens (32-byte cryptographically secure)
• Token expiration (24 hours)
• Constant-time comparison (timing attack resistant)

Your Goal:

• Submit a contact form without a valid CSRF token
• Reuse an expired CSRF token
• Predict or forge a CSRF token
• OR exploit a timing attack in token comparison

Difficulty: Hard

Why This Matters: CSRF allows attackers to perform actions on behalf of users. Can you break the token system?

Hints:

• How are tokens generated?
• Where are tokens stored?
• Are tokens predictable or brute-forceable?

---

Category 6: Denial of Service ⭐

Objective: Make the site unavailable to legitimate users.

What's Protected:

• Rate limiting (5 contact forms/hour, 3 PDFs/minute)
• Origin validation (prevents external hotlinking)
• Resource limits (request timeouts, connection limits)

Your Goal:

• Exhaust server resources (CPU, memory, connections)
• Trigger a crash or panic
• Make the site unresponsive to legitimate users
• OR find a resource leak

Difficulty: Easy to Medium

Why This Matters: DoS attacks can take down services. How robust is this application?

Hints:

• Which endpoints are most resource-intensive?
• Are there any unbounded operations?
• Can you trigger a memory leak?

---

🏆 Bonus Challenges

Bonus 1: Data Extraction ⭐⭐⭐

Objective: Extract sensitive data from the server.

Examples:

• Environment variables
• Server file paths
• Configuration details
• Email addresses or contact form submissions

Difficulty: Hard

---

Bonus 2: Privilege Escalation ⭐⭐⭐⭐

Objective: Gain unauthorized access or elevated privileges.

Examples:

• Access admin endpoints (if they exist)
• Modify application configuration
• Execute arbitrary code
• Read/write files outside the web root

Difficulty: Very Hard

---

Bonus 3: Creative Attack ⭐-⭐⭐⭐⭐

Objective: Surprise me with something I didn't think of!

Examples:

• Novel attack vectors
• Chained exploits
• Social engineering combined with technical attacks
• Zero-day vulnerabilities in dependencies

Difficulty: Variable

Why This Matters: The best vulnerabilities are the ones nobody thought to test for.

---

📋 Rules of Engagement

✅ What's Allowed

• Automated scanning - Use OWASP ZAP, Burp Suite, Nikto, etc.
• Fuzzing - Test all inputs with unexpected data
• Load testing - Test rate limits and resource exhaustion
• Source code review - The code is open source
• Social engineering - Email me attack vectors (no actual exploitation)
• Creative thinking - Try anything not explicitly forbidden

❌ What's NOT Allowed

• Physical attacks - Don't attack the server infrastructure
• Social engineering end users - Don't phish my site visitors
• Destructive attacks - Don't delete data or destroy the site
• Third-party attacks - Don't attack my hosting provider or CDN
• Illegal activity - Follow all applicable laws
• Spam - Don't send actual spam through the contact form

🤝 Good Faith

This challenge operates on good faith:

• Test the security controls, not the infrastructure
• Report findings before exploiting them maliciously
• Don't cause harm to the site or its visitors
• Respect the responsible disclosure process

If you're unsure if something is allowed, ask first!

---

🎁 What You Get

Recognition

Hall of Fame: Valid findings will be acknowledged in the project repository (with your permission).

Categories:

• 🥇 Critical Findings - Remote code execution, data breaches, authentication bypass
• 🥈 High Severity - CSRF bypass, XSS, injection attacks, sensitive data exposure
• 🥉 Medium Severity - Rate limit bypass, DoS vulnerabilities, information disclosure
• 📝 Low Severity / Informational - Security improvements, best practice violations

What Qualifies as a Valid Finding?

Valid:

• ✅ Actual security vulnerabilities (reproducible)
• ✅ Bypasses of implemented security controls
• ✅ Data leakage or information disclosure
• ✅ Denial of Service (reproducible, not infrastructure-level)
• ✅ Novel attack vectors I haven't considered

Invalid:

• ❌ Already documented behavior (see SECURITY.md)
• ❌ Out-of-scope findings (e.g., GitHub account security)
• ❌ Social engineering without technical component
• ❌ Attacks on infrastructure (hosting provider, DNS, etc.)
• ❌ Features, not bugs (e.g., "site allows long names")

---

📧 Responsible Disclosure

Found something? Here's how to report it:

1. Document Your Finding

Include:

• Description - What did you find?
• Impact - What can an attacker do with this?
• Reproduction Steps - How can I reproduce it?
• Proof of Concept - curl commands, screenshots, code samples
• Suggested Fix - (Optional) How should this be fixed?

2. Send Your Report

Email: Create issue on GitHub

Subject: [SECURITY] Brief description of finding

Please DO NOT:

• ❌ Publicly disclose the vulnerability before I've had a chance to fix it
• ❌ Exploit the vulnerability for personal gain
• ❌ Share the vulnerability with others before resolution

3. What Happens Next?

Response Time:

• Initial Response: Within 48 hours
• Triage: Within 1 week
• Fix: Varies by severity (1 day to 1 month)
• Public Disclosure: After fix is deployed (coordinated with you)

Severity Timelines:

• 🔴 Critical: 24-48 hours
• 🟠 High: 1 week
• 🟡 Medium: 2 weeks
• 🟢 Low: 1 month

4. Recognition

If you'd like to be acknowledged:

• Hall of Fame entry in repository
• Thank you in release notes
• Social media shoutout (with your permission)

Privacy: You can choose to remain anonymous!

---

🛡️ What You're Up Against

Security Layers Implemented

┌────────────────────────────────────────┐
│  Layer 1: Browser-Only Access          │
│  Blocks: curl, Postman, automation     │
└────────────────────────────────────────┘
                   ▼
┌────────────────────────────────────────┐
│  Layer 2: CSRF Protection               │
│  32-byte cryptographic tokens           │
└────────────────────────────────────────┘
                   ▼
┌────────────────────────────────────────┐
│  Layer 3: Rate Limiting                 │
│  5 forms/hour, 3 PDFs/minute            │
└────────────────────────────────────────┘
                   ▼
┌────────────────────────────────────────┐
│  Layer 4: Bot Detection                 │
│  Honeypot + Timing validation           │
└────────────────────────────────────────┘
                   ▼
┌────────────────────────────────────────┐
│  Layer 5: Input Validation              │
│  Email injection, XSS, injection tests  │
└────────────────────────────────────────┘
                   ▼
┌────────────────────────────────────────┐
│  Layer 6: Security Logging              │
│  All events tracked in structured JSON  │
└────────────────────────────────────────┘

Known Protections

You'll have to bypass:

• Origin/Referer validation
• X-Requested-With header checks
• User-Agent validation
• CSRF token generation & validation
• Rate limiting (per-IP tracking)
• Honeypot field detection
• Timing validation (2-second minimum)
• Email header injection prevention
• HTML escaping (XSS protection)
• Input length limits
• Character whitelist validation

See SECURITY.md for full details on security controls.

---

💡 Hints & Tips

Getting Started

1. Review the source code: GitHub Repository
2. Read the security documentation: SECURITY.md
3. Inspect the contact form: View source of the form
4. Try basic attacks: XSS, SQL injection, command injection
5. Use automated tools: OWASP ZAP, Burp Suite, Nikto

Testing Endpoints

Primary Targets:

• GET / - Main page
• POST /api/contact - Contact form (heavily protected)
• GET /export/pdf?lang=en - PDF generation (rate limited)
• POST /toggle/* - Preference toggles
• POST /switch-language - Language switcher

Common Attack Patterns

XSS:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>

Email Header Injection:

test@test.com\nBcc: attacker@evil.com
test@test.com\r\nContent-Type: text/html

Command Injection:

data; ls -la
data | cat /etc/passwd
data`whoami`

SQL Injection (N/A but try it):

' OR 1=1 --
Robert'; DROP TABLE users; --

Advanced Techniques

• Race conditions - Submit multiple requests simultaneously
• Unicode tricks - Use Unicode characters to bypass validation
• Encoding bypasses - Try URL encoding, double encoding, hex encoding
• Header manipulation - Craft custom headers to bypass validation
• Timing attacks - Measure response times to leak information

---

🏅 Hall of Fame

Status: No vulnerabilities reported yet!

Be the first to find a valid security issue and get recognized here.

---

Past Findings

This section will be updated as vulnerabilities are found and fixed.

Format:

[Date] [Severity] [Reporter] - Description

Example:

2025-11-30 | HIGH | @researcher | CSRF bypass via race condition

---

📊 Challenge Statistics

Current Stats:

• Total Attempts: Not tracked (privacy-respecting)
• Valid Findings: 0
• Invalid Reports: 0
• Average Time to First Finding: N/A

Most Tested:

• Contact form submission
• Rate limit bypass attempts
• Browser-only access bypass

Least Tested:

• Creative/novel attack vectors
• Chained exploits
• Social engineering components

---

🤔 FAQ

Q: Is this a real production site?

A: Yes! This is my actual CV portfolio site. It's production-ready and serves real traffic.

Q: Will you actually fix vulnerabilities I find?

A: Absolutely! Valid findings will be prioritized and fixed according to severity.

Q: Can I use automated tools?

A: Yes! OWASP ZAP, Burp Suite, Nikto, and other scanners are welcome.

Q: What if I accidentally break something?

A: Don't panic! Just report it immediately. The site has backups and graceful error handling.

Q: Can I test in production?

A: Yes, but please be responsible. Don't spam, don't DoS, and don't cause harm to legitimate users.

Q: Is there a monetary reward?

A: No cash bounty (this is a personal project), but you'll get recognition and my eternal gratitude!

Q: Can I stay anonymous?

A: Absolutely! You can report anonymously and choose whether to be acknowledged publicly.

Q: How do I know you won't use my finding maliciously?

A: This is a personal CV site with no sensitive data. The worst case is someone sends me spam emails. I'm committed to transparent, ethical security practices.

Q: What if I find something in a dependency, not your code?

A: Still valid! Report it, and I'll coordinate disclosure with the upstream project.

Q: Can I write a blog post about my findings?

A: Yes! But please wait until after the fix is deployed. Coordinated disclosure protects everyone.

---

🎓 Learning Resources

New to security testing? Here are some resources to get started:

Beginner

• OWASP Top 10
• PortSwigger Web Security Academy
• HackerOne 101

Intermediate

• OWASP Testing Guide
• Bug Bounty Bootcamp
• Web Application Hacker's Handbook

Advanced

• Advanced Penetration Testing
• The Tangled Web
• Real-World Bug Hunting

Tools

• OWASP ZAP - Free web app scanner
• Burp Suite - Professional testing toolkit
• Nikto - Web server scanner
• SQLMap - SQL injection testing

---

🚀 Ready to Hack?

Target: https://juan.andres.morenorub.io/

Source Code: https://github.com/juanatsap/cv-site

Documentation: SECURITY.md

Report Findings: GitHub Security Advisory

---

Good luck, and happy hacking! 🎯

Remember:

• Be ethical
• Be responsible
• Be creative
• Have fun!

---

Last Updated: 2025-11-30 Challenge Status: ACTIVE Next Review: 2026-03-01

P.S. - If you manage to bypass the browser-only access using curl, I'll be genuinely impressed. That one's tough. 😉