Repository: https://github.com/kbadinger/cherry-picker

IMPORTANT: This is a historical codebase from 2006-2007 that is NO LONGER MAINTAINED and contains known security vulnerabilities. It is preserved for educational and historical purposes only.

This codebase was developed in 2006-2007 using practices and libraries that were acceptable at the time but are now considered insecure. DO NOT use this code in production environments without significant security hardening.

Recommendation: If modernizing, replace all dependencies with current versions:

• iText → iText 8.x or Apache PDFBox
• JFreeChart → JFreeChart 1.5.x+
• MS JDBC Driver → microsoft-mssql-jdbc 12.x+
• Java → OpenJDK 21 LTS

Original Code (sanitized for archive):

// CpCharting.java (line 125-130) and CpForecasting.java (line 153-167)
Connection connection = DriverManager.getConnection(
    "jdbc:microsoft:sqlserver://localhost:1433;databasename=cp",
    "sa", "password"  // ⚠️ Hardcoded in original
);

Issues:

• Database credentials in source code
• No encryption or secure storage
• Visible in version control history
• Anyone with code access has database access

Modern Solution:

// Use environment variables or secure secret management
String dbUrl = System.getenv("DB_URL");
String dbUser = System.getenv("DB_USER");
String dbPassword = System.getenv("DB_PASSWORD");

// Or use AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, etc.

Vulnerable Code:

// CpForecasting.java (lines 146-150)
String searchUserQuery = "select ... " +
    "where type_key = 'maxCleanPrice' and " +
    "trandate >= convert(datetime, '" + d1 + "') and " +  // ⚠️ Direct string concatenation
    "trandate <= convert(datetime, '" + d2 + "')";

Issues:

• Date parameters (d1, d2) from command-line arguments concatenated directly
• No input validation or sanitization
• Vulnerable to SQL injection if attacker controls arguments

Attack Vector:

java CpForecasting "'; DROP TABLE cp_processed_results; --" "10/25/05"

Modern Solution:

// Use PreparedStatement with parameterized queries
String query = "select ... where trandate >= ? and trandate <= ?";
PreparedStatement ps = connection.prepareStatement(query);
ps.setDate(1, parseDate(d1));
ps.setDate(2, parseDate(d2));
ResultSet rs = ps.executeQuery();

Issues:

• No validation of command-line arguments
• No bounds checking on data from database
• No sanitization of user-provided strings
• Assumes all inputs are well-formed

Example:

// CpCharting.java (line 600)
if (args.length > 0)
    cp.defaultName = args[0];  // ⚠️ No validation

Attack Vector:

java CpCharting "../../../etc/passwd"  # Path traversal
java CpCharting "../../important_file" # Overwrite system files

Modern Solution:

if (args.length > 0) {
    String filename = args[0];
    // Validate filename: alphanumeric and underscore only
    if (!filename.matches("^[a-zA-Z0-9_]+$")) {
        throw new IllegalArgumentException("Invalid filename");
    }
    // Ensure output directory is safe
    Path outputPath = Paths.get(OUTPUT_DIR, filename).normalize();
    if (!outputPath.startsWith(Paths.get(OUTPUT_DIR))) {
        throw new SecurityException("Path traversal detected");
    }
    cp.defaultName = filename;
}

Issues:

// CpCharting.java (line 188)
fileName = new File("c:\\" + filepre + Integer.toString(doccount) + ".pdf");

• Hardcoded paths
• No path traversal protection
• No permission checking
• Direct file creation in system directory

Risks:

• Could overwrite system files
• No protection against symlink attacks
• Directory traversal possible

Issues:

• System connects to database with hardcoded credentials
• No user authentication
• No role-based access control
• Anyone who can run the Java program has full database access

Modern Solution:

• Implement authentication (username/password, OAuth, etc.)
• Use principle of least privilege (read-only vs read-write)
• Implement audit logging
• Use database connection pooling with credential rotation

Issues:

• Database connection uses unencrypted TCP (port 1433)
• No SSL/TLS for data in transit
• No encryption for data at rest
• Sensitive financial data transmitted in cleartext

Modern Solution:

String dbUrl = "jdbc:microsoft:sqlserver://localhost:1433;" +
               "databasename=cp;" +
               "encrypt=true;" +  // Enable SSL/TLS
               "trustServerCertificate=false;" +
               "hostNameInCertificate=*.database.windows.net";

Issues:

catch (Exception e) {
    System.out.println(e.toString());  // ⚠️ Prints stack trace with sensitive info
}

• Exception messages may leak sensitive information
• Stack traces printed to stdout (could be logged/exposed)
• No distinction between expected errors and security issues
• No rate limiting or circuit breakers

Risks:

• Information disclosure (database structure, paths, etc.)
• No alerting on security-relevant errors
• Makes debugging attacks easier for attackers

Issues:

• Manual classpath management
• JAR files committed to repository (not included in this archive)
• No dependency verification or checksums
• No Software Bill of Materials (SBOM)

Modern Solution:

• Use Maven/Gradle with dependency verification
• Implement dependency scanning (Snyk, Dependabot)
• Generate SBOM
• Use artifact signing

Issues:

• No audit trail of database operations
• No monitoring of failed authentication attempts
• No alerting on anomalous behavior
• Limited visibility into system operations

Modern Solution:

• Implement comprehensive logging (SLF4J, Log4j2)
• Send logs to SIEM system
• Monitor for suspicious patterns
• Implement rate limiting and anomaly detection

The following security practices were either not established in 2006 or not implemented in this codebase:

• ❌ No security testing (SAST/DAST)
• ❌ No code signing
• ❌ No security headers (not applicable to CLI app)
• ❌ No principle of least privilege
• ❌ No defense in depth
• ❌ No secure development lifecycle
• ❌ No threat modeling
• ❌ No security code review
• ❌ No penetration testing
• ❌ No incident response plan

Overall Risk: CRITICAL - Do not use in production

If you want to modernize this codebase for actual use, address these security issues:

• Update all dependencies to latest stable versions
• Replace Java 1.4/1.5 with modern Java (21 LTS)
• Remove all hardcoded credentials
• Implement parameterized queries throughout
• Add input validation for all external inputs
• Enable SSL/TLS for database connections
• Implement proper error handling without info leakage

• Add authentication and authorization
• Implement audit logging
• Add secure file operations with path validation
• Encrypt sensitive data at rest
• Add rate limiting and circuit breakers
• Implement dependency scanning
• Add unit tests with security test cases

• Implement SIEM integration
• Add monitoring and alerting
• Create threat model
• Perform security code review
• Conduct penetration testing
• Implement secrets management (Vault, etc.)
• Add SBOM generation

• Code signing
• Bug bounty program
• Security training for developers
• Regular security audits
• Implement DevSecOps pipeline

⚠️ This is a historical archive that is no longer maintained.

If you discover a security vulnerability in this code:

1. DO NOT open a public GitHub issue (this code is already known to be insecure)
2. DO NOT attempt to exploit vulnerabilities in any production systems
3. DO document the issue for educational purposes
4. DO consider writing a blog post or academic paper about historical security practices

Note: Since this is unmaintained historical code, vulnerabilities will not be patched. The entire codebase is published with full knowledge of its security limitations.

This codebase serves as an excellent example of:

• Hardcoding credentials
• String concatenation in SQL queries
• Using outdated dependencies
• Ignoring input validation
• Insufficient error handling
• No security testing

• Security practices of 2006 era
• Evolution of Java security
• How financial software security has improved
• Why modern frameworks and practices matter

• Secure Coding: Show before/after examples
• Threat Modeling: Analyze attack vectors in legacy code
• Risk Assessment: Evaluate real-world historical system
• Modernization: Practice refactoring insecure code

• OWASP Top 10
• CWE Top 25 Software Weaknesses
• NIST Secure Software Development Framework

• Static Analysis: SonarQube, Checkmarx, Veracode
• Dependency Scanning: Snyk, Dependabot, OWASP Dependency-Check
• Secrets Management: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault
• Security Testing: OWASP ZAP, Burp Suite

This software is provided "AS IS" with no security guarantees whatsoever. By using this code, you acknowledge:

• You understand it contains known security vulnerabilities
• You will NOT use it for actual trading or production purposes
• You accept full responsibility for any security incidents
• The author bears no liability for damages arising from use of this code
• You will not hold the author responsible for any data breaches or losses

USE AT YOUR OWN RISK

Last Updated: 2025 (for historical archive publication) Status: Unmaintained - Known vulnerable - Educational purposes only Security Posture: ❌ CRITICAL - Do not use in production