solokit 0.1.1__py3-none-any.whl

solokit/templates/security_spec.md

@@ -0,0 +1,287 @@
+# Security Task: [Name]
+
+<!--
+TEMPLATE INSTRUCTIONS:
+- Replace [Name] with a concise description of the security task
+- Be specific about the vulnerability or security improvement
+- Include threat model and attack scenarios
+- Document all security controls and validations
+- Remove these instructions before finalizing the spec
+-->
+
+## Security Issue
+
+<!-- Describe the security concern, vulnerability, or improvement in detail -->
+
+Describe the security concern, vulnerability, or improvement.
+
+**Example:**
+> SQL injection vulnerability in the user search endpoint (`/api/users/search`). The search query parameter is directly concatenated into the SQL query without proper sanitization or parameterization, allowing attackers to execute arbitrary SQL commands and potentially access or modify sensitive user data.
+
+## Severity
+
+<!--
+Choose one severity level based on exploitability and impact:
+- Critical: Active exploit possible, high impact (data breach, system compromise)
+- High: Likely exploit, significant impact (privilege escalation, data exposure)
+- Medium: Possible exploit, moderate impact (information disclosure, DoS)
+- Low: Difficult exploit, minor impact (security hardening, best practices)
+-->
+
+- [x] Critical - Active exploit possible
+- [ ] High - Significant security risk
+- [ ] Medium - Moderate security concern
+- [ ] Low - Minor security improvement
+
+**Impact Assessment:**
+- **Confidentiality:** High (full database access possible)
+- **Integrity:** High (data modification possible)
+- **Availability:** Medium (DoS via resource-intensive queries)
+- **CVSS Score:** 9.1 (Critical)
+
+## Affected Components
+
+<!-- List all components, systems, or data affected by this security issue -->
+
+- API Endpoint: `GET /api/users/search?q=[query]`
+- Backend Service: `src/services/UserSearchService.ts`
+- Database: `users` table (contains PII: names, emails, phone numbers)
+- Affected Versions: v2.0.0 - v2.4.2
+- First Introduced: v2.0.0 (commit abc123f)
+
+## Threat Model
+
+### Assets at Risk
+- User database containing 1.2M user records
+- Personal Identifiable Information (PII): names, emails, phone numbers, addresses
+- Authentication credentials (hashed passwords)
+- Session tokens
+
+### Threat Actors
+- **External Attackers:** Opportunistic attackers scanning for SQL injection vulnerabilities
+- **Malicious Insiders:** Users with legitimate API access attempting privilege escalation
+- **Automated Bots:** Scripts scanning for common vulnerabilities
+
+### Attack Scenarios
+
+**Scenario 1: Data Exfiltration**
+```
+GET /api/users/search?q=admin' UNION SELECT id,email,password FROM users--
+```
+Attacker retrieves entire user database including hashed passwords.
+
+**Scenario 2: Privilege Escalation**
+```
+GET /api/users/search?q=test'; UPDATE users SET role='admin' WHERE id=1337;--
+```
+Attacker elevates their own account to admin role.
+
+**Scenario 3: Data Destruction**
+```
+GET /api/users/search?q='; DROP TABLE users;--
+```
+Attacker destroys user data (DoS attack).
+
+## Attack Vector
+
+<!-- Detailed description of how the vulnerability could be exploited -->
+
+**Example:**
+> The vulnerability exists in the `searchUsers()` method which constructs SQL queries using string concatenation:
+
+```typescript
+// VULNERABLE CODE in src/services/UserSearchService.ts:42-48
+async searchUsers(query: string): Promise<User[]> {
+  // Direct string concatenation - UNSAFE!
+  const sql = `SELECT * FROM users WHERE name LIKE '%${query}%' OR email LIKE '%${query}%'`;
+
+  const results = await this.db.query(sql);
+  return results.rows;
+}
+```
+
+**Exploitation Steps:**
+1. Attacker crafts malicious SQL payload in the `q` parameter
+2. Backend concatenates user input directly into SQL query
+3. Database executes the malicious SQL command
+4. Attacker receives unauthorized data or modifies the database
+
+**Proof of Concept:**
+```bash
+# List all users (bypassing pagination/filtering)
+curl "https://api.example.com/api/users/search?q=admin' OR '1'='1"
+
+# Extract password hashes
+curl "https://api.example.com/api/users/search?q=x' UNION SELECT id,email,password FROM users--"
+```
+
+## Mitigation Strategy
+
+<!-- Detailed approach to fix or mitigate the security issue -->
+
+**Primary Fix: Use Parameterized Queries**
+
+Replace string concatenation with parameterized queries:
+
+```typescript
+// SECURE CODE in src/services/UserSearchService.ts:42-51
+async searchUsers(query: string): Promise<User[]> {
+  // Parameterized query - SAFE!
+  const sql = `
+    SELECT id, name, email, created_at
+    FROM users
+    WHERE name LIKE $1 OR email LIKE $2
+    LIMIT 100
+  `;
+
+  const searchPattern = `%${query}%`;
+  const results = await this.db.query(sql, [searchPattern, searchPattern]);
+  return results.rows;
+}
+```
+
+**Defense in Depth Measures:**
+
+1. **Input Validation:**
+```typescript
+// Add input validation
+function validateSearchQuery(query: string): string {
+  // Max length
+  if (query.length > 100) {
+    throw new ValidationError('Search query too long');
+  }
+
+  // Allowed characters only
+  if (!/^[a-zA-Z0-9\s@.-]+$/.test(query)) {
+    throw new ValidationError('Invalid characters in search query');
+  }
+
+  return query;
+}
+```
+
+2. **Database Permissions:**
+   - Create read-only database user for search queries
+   - Revoke DELETE, UPDATE, DROP permissions
+
+3. **Rate Limiting:**
+   - Limit search requests to 10/minute per user
+   - Implement exponential backoff for repeated failures
+
+4. **Logging & Monitoring:**
+   - Log all search queries for audit trail
+   - Alert on suspicious query patterns (UNION, --, etc.)
+
+## Implementation Plan
+
+1. **Immediate:** Apply hotfix to parameterize queries (2 hours)
+2. **Short-term:** Add input validation (4 hours)
+3. **Medium-term:** Implement rate limiting (1 session)
+4. **Long-term:** Database permission hardening (1 session)
+
+## Security Testing
+
+<!-- Comprehensive security testing checklist -->
+
+### Automated Security Testing
+- [ ] SAST (Static Analysis): Run Semgrep/SonarQube to detect SQL injection patterns
+- [ ] DAST (Dynamic Analysis): Run OWASP ZAP against search endpoint
+- [ ] Dependency scan: Check for vulnerable database driver versions
+- [ ] Regression test: Verify fix prevents all known attack vectors
+
+### Manual Security Testing
+- [ ] Penetration test: Attempt SQL injection with various payloads
+- [ ] Authentication bypass test: Verify no privilege escalation possible
+- [ ] Data exfiltration test: Confirm only authorized data accessible
+- [ ] DoS test: Verify rate limiting prevents resource exhaustion
+
+### Test Cases
+```typescript
+describe('User Search Security', () => {
+  it('prevents SQL injection via UNION', async () => {
+    const maliciousQuery = "admin' UNION SELECT password FROM users--";
+    const results = await searchUsers(maliciousQuery);
+    // Should return no results or safe results, not passwords
+    expect(results.every(r => !r.password)).toBe(true);
+  });
+
+  it('prevents SQL injection via comment', async () => {
+    const maliciousQuery = "admin'--";
+    await expect(searchUsers(maliciousQuery)).not.toThrow();
+  });
+
+  it('rejects queries with excessive length', async () => {
+    const longQuery = 'a'.repeat(1000);
+    await expect(searchUsers(longQuery)).rejects.toThrow(ValidationError);
+  });
+});
+```
+
+## Compliance
+
+<!-- Regulatory and standards compliance -->
+
+- [ ] **OWASP Top 10:** Addresses A03:2021 - Injection
+- [ ] **CWE-89:** SQL Injection prevention implemented
+- [ ] **PCI DSS 6.5.1:** Input validation for SQL injection
+- [ ] **GDPR Article 32:** Appropriate security measures for personal data
+- [ ] **SOC 2:** Security controls documented and tested
+- [ ] **Security best practices:** Parameterized queries, principle of least privilege
+
+## Pre-Deployment Requirements
+
+<!-- Gates that must pass before deploying the fix -->
+
+- [ ] Security scan passes with 0 critical/high vulnerabilities
+- [ ] All security tests pass (automated + manual)
+- [ ] Code review by security team completed and approved
+- [ ] Penetration test confirms vulnerability is fixed
+- [ ] No new vulnerabilities introduced by the fix
+- [ ] Documentation updated with security notes
+- [ ] Incident response runbook updated
+
+## Acceptance Criteria
+
+<!-- Specific criteria that must be met -->
+
+- [ ] SQL injection vulnerability is completely fixed
+- [ ] All attack scenarios from threat model are mitigated
+- [ ] Security tests pass (100% of test cases)
+- [ ] No regression in functionality (search still works)
+- [ ] No regression in security posture (no new vulnerabilities)
+- [ ] Security review approved by security team
+- [ ] Performance impact < 10ms (parameterized queries are fast)
+- [ ] Logging/monitoring captures suspicious activity
+- [ ] Incident response plan updated (if critical)
+
+## Post-Deployment
+
+<!-- Actions to take after deploying the fix -->
+
+- [ ] Monitor logs for attack attempts
+- [ ] Review security alerts for 7 days post-deployment
+- [ ] Conduct follow-up penetration test after 30 days
+- [ ] Update security training materials with lessons learned
+- [ ] Share findings with development team (blameless postmortem)
+
+## Dependencies
+
+<!-- Any dependencies on other security work or tools -->
+
+- Security scanning tools: Semgrep, OWASP ZAP
+- Database with parameterized query support (PostgreSQL 12+)
+- Rate limiting infrastructure (Redis)
+- Logging/monitoring system (Datadog/Splunk)
+
+## Estimated Effort
+
+2 sessions
+
+<!--
+Breakdown:
+- Immediate hotfix: 0.25 sessions
+- Input validation: 0.5 sessions
+- Rate limiting: 0.5 sessions
+- Security testing: 0.5 sessions
+- Database hardening: 0.25 sessions
+-->