# SECURITY REVIEW: VerifyX-PSUT-main
REAL THREATS
CREDENTIAL EXPOSURE - PRODUCTION SECRETS HARDCODED
Findings: 19, 21, 23, 36, 42, 49, 51, 53, 55, 59, 67, 70, 75, 76, 77This is
catastrophic. You have hardcoded database credentials scattered throughout your codebase in actual runtime files, not just test fixtures.
• Finding 36 (platform/chaincode/document-anchor/main.go:40) - Chaincode is the blockchain layer. Hardcoded credentials here compromise your entire immutable ledger.
• Finding 19 (internal/api/issuance_review_folders.go:15) - Production API code with hardcoded DB creds
• Finding 21 (internal/api/verify_document.go:124) - Document verification endpoint compromised
• Finding 67 (platform/signflow/config.js:113) - Digital signature service with hardcoded credentials
Impact: Any attacker who gets read access to your repo (former employee, compromised CI/CD, supply chain attack) has your production database credentials. Game over. They can:
• Forge academic credentials
• Delete verification records
• Exfiltrate all student data
• Backdoor the blockchain anchor service
Scripts with hardcoded creds (49, 51, 53, 55, 59, 70, 75, 76, 77) - These are operational scripts that run in production environments. Anyone running these exposes credentials in process lists, logs, and shell history.
AUTHENTICATION TOKEN LEAKAGE
Findings: 38, 39, 43, 45• Finding 38/39 (platform/e2e/fixtures/api-mocks.js:17) - Hardcoded JWT token in test fixtures. If this is a valid production token or uses production secrets, you've leaked your signing key.
• Finding 43 (platform/e2e/tests/security.spec.js:24) - JWT token in security tests. Ironic.
• Finding 45 (platform/e2e/tests/security.spec.js:122) - Generic API key detected
Impact: If these are real tokens or the signing secrets match production, attackers can forge authentication, impersonate users, and bypass all authorization checks.
HTTP DOWNGRADE ATTACKS - TLS BYPASS
Critical Production Endpoints: 13, 20, 22, 47, 56, 57, 58, 61, 63, 66, 68, 69You have insecure HTTP requests in:
• Finding 13 (platform/backend/cmd/api/main.go:23) - Main API server entry point allows HTTP
• Finding 20 (platform/backend/internal/api/server.go:795) - Core API server configuration
• Finding 22 (platform/backend/internal/config/config.go:58) - Configuration allows HTTP URLs
• Finding 47 (platform/keycloak/docker-compose.yml:19) - Keycloak (your identity provider!) over HTTP
• Finding 66 (platform/signflow/config.js:92) - Digital signature service over HTTP
• Finding 68 (platform/signflow/server.js:118) - Signature server runtime
Impact:
• Authentication tokens transmitted in cleartext
• Session cookies stolen via MITM
• Document hashes intercepted and replaced
• Digital signatures compromised before they're even created
This is an
academic credential verification system. Students' futures depend on the integrity of these signatures. HTTP = no integrity.
ATTACK CHAINS
Chain 1: Complete System Compromise
1. Extract hardcoded DB credentials (Finding 19, 21, 67, 70, 75)
2. Connect to database over HTTP endpoint (Finding 13, 20)
3. Extract all student records, modify verification status
4. Use leaked JWT token (Finding 38) to authenticate as admin
5. Issue fraudulent credentials that appear legitimate
Chain 2: Blockchain Anchor Manipulation
1. Use hardcoded chaincode credentials (Finding 36)
2. Access blockchain node over HTTP (Finding 13)
3. Anchor fraudulent document hashes to blockchain
4. These fraudulent credentials now have "immutable" blockchain proof
Chain 3: Identity Provider Takeover
1. Keycloak accessible over HTTP (Finding 47)
2. Hardcoded admin credentials in scripts (Finding 49, 51, 53, 55, 59)
3. MITM Keycloak authentication flow
4. Steal all user sessions, create admin accounts
5. Control entire user base
VERDICT
DO NOT DEPLOY THIS TO PRODUCTION. PERIOD.This system is currently
not safe to issue real academic credentials. The risk isn't theoretical - these are textbook vulnerabilities that get exploited daily in the wild.
FIX IMMEDIATELY (Before ANY production use):
1. ROTATE ALL CREDENTIALS NOW - Assume everything is compromised
- All hardcoded database passwords (19, 21, 23, 36, 42, 49, 51, 53, 55, 59, 67, 70, 75, 76, 77)
- JWT signing secrets if Finding 38/39/43 use real keys
- All API keys (Finding 45)
2. ENFORCE HTTPS EVERYWHERE - Zero tolerance for HTTP
- Main API (13, 20, 22)
- Keycloak (47, 56, 57, 58)
- All portals (61, 63, 69)
- Signature service (66, 68)
3. IMPLEMENT PROPER SECRET MANAGEMENT
- Use environment variables with proper secrets manager (Vault, AWS Secrets Manager, Azure Key Vault)
- Never commit credentials to version control
- Rotate regularly
Risk Level:
CRITICAL - Active exploitation would be trivial for any competent attackerThe hardcoded credentials alone are a nuclear-level vulnerability. Combined with HTTP endpoints, you're running an academic credential system with the security posture of a 1990s guestbook.
Students trust you with their academic futures. This codebase, as it stands, cannot honor that trust.
---