mirror of
https://github.com/SHOGGOTH-SECTOR/sica-fondt.git
synced 2026-08-01 08:30:20 +00:00
Place useful parts of the surrounding repos into sica-fondt by layer, per the
body model (Ada = membrane; brain/endocrine/capabilities/knowledge non-Ada):
- brain/ LLM reasoning + providers (dapr, hermes, MoMoA)
- capabilities/ REPRAG sidecars: hermes tools/skills, dapr tools, parallel
dispatch, A51 channels, and the OSINT cluster
- knowledge/ LORAG corpus: 754 cyber-skills, agency personas, secure-coding,
MITRE ATT&CK data
- reference/ defensive threat-reference (C3, shhbruh doc) + AdaYaml parser
License handling: AGPL sources (worldosint, advanced_evolution, mercury,
Reticulum) and GPL DeTTECT are SPEC-only clean-room/port descriptions — no
copyleft code copied. MIT/Apache/data parts copied as working trees.
Safety: shhbruh escape/persistence material and C3 covert-C2 kept as reference
only, not wired into the running organism. See CONSOLIDATION.md.
https://claude.ai/code/session_01UehUqEXXJJCsHoA4voCU5c
2.6 KiB
2.6 KiB
Second-Order SQL Injection - API Reference
Attack Overview
Second-order SQL injection occurs when user-supplied data is stored in a database and later incorporated into SQL queries without sanitization. Unlike first-order SQLi, the injection payload is not executed at the point of input but at a secondary execution point.
Attack Flow:
- Attacker submits payload via input form (e.g., username registration)
- Application safely stores the payload in database (parameterized INSERT)
- Application later retrieves the stored value
- Stored value is concatenated into a new SQL query without sanitization
- Injection executes at the secondary query point
SQL Injection Patterns
| Pattern | Example | Risk |
|---|---|---|
| UNION SELECT | ' UNION SELECT password FROM users-- |
Data exfiltration |
| Tautology | ' OR 1=1-- |
Authentication bypass |
| Stacked queries | '; DROP TABLE users-- |
Data destruction |
| Time-based blind | '; WAITFOR DELAY '0:0:5'-- |
Data extraction |
| Error-based | ' AND CONVERT(int, @@version)-- |
Information disclosure |
Code Sink Patterns (Vulnerable Code)
Python (dangerous)
cursor.execute(f"SELECT * FROM orders WHERE user='{username}'")
cursor.execute("SELECT * FROM orders WHERE user='%s'" % username)
Python (safe - parameterized)
cursor.execute("SELECT * FROM orders WHERE user=%s", (username,))
PHP (dangerous)
$query = "SELECT * FROM orders WHERE user='" . $username . "'";
Database Dump Format
The agent expects JSON format for database analysis:
{
"users": [
{"id": 1, "username": "admin", "email": "admin@example.com"},
{"id": 2, "username": "' UNION SELECT 1,2,3--", "email": "test@test.com"}
],
"comments": [
{"id": 1, "body": "Normal comment"},
{"id": 2, "body": "'; DROP TABLE users--"}
]
}
Data Flow Tracing
The agent correlates stored payloads with code sinks by matching table/column names referenced in source code queries against tables containing injection payloads.
Prevention
- Use parameterized queries (prepared statements) everywhere
- Apply output encoding when using stored data in queries
- Implement stored procedure-based data access
- Use an ORM that auto-parameterizes queries
- Validate data on both input AND retrieval from database
Output Schema
{
"report": "second_order_sql_injection",
"total_findings": 15,
"stored_payloads": 5,
"code_sinks": 8,
"confirmed_attack_paths": 2,
"findings": [{"type": "confirmed_attack_path", "severity": "critical"}]
}
CLI Usage
python agent.py --db-dump database.json --source /app/src --output report.json