Database Resource Exhaustion (Denial of Service) [HIGH]

[AkramBitar]

Database Resource Exhaustion (Denial of Service)

Severity: HIGH

Threat: Compromised node, malicious insider, buggy code, or supply chain attack floods database with requests until system crashes.

Example: Hacked participant node sends 10,000 token requests per second. Database accepts all until it runs out of resources and crashes the entire network.

[AkramBitar]

Database Resource Exhaustion - Primarily Analysis and Solution Proposal

Issue

Database Resource Exhaustion (Denial of Service) - Severity: HIGH

Compromised node floods database with 10,000 requests/second. Without limits, database accepts all until crash.

1. Parameters to Address Issue

Parameter	Purpose	Recommended	How It Helps
maxOpenConns	Cap concurrent connections	50	Limits total connections, prevents connection exhaustion
maxIdleConns	Idle connections in pool	10	Efficient connection reuse without waste
maxIdleTime	Idle connection lifetime	1 hour	Recycles stale connections
statementTimeout	Kill long queries	30 seconds	Prevents runaway queries from blocking database

How this solves the issue: Even if attacker sends 10,000 requests/second, only 50 can connect simultaneously, and each query is killed after 30 seconds. Database stays responsive.

2. Current vs Needed

Parameter	Current	Needed
maxOpenConns	0 (unlimited)	50
maxIdleConns	2	10
maxIdleTime	1 minute	1 hour
statementTimeout	Not set	30 seconds

3. Current Defaults (Applied When Not in Config)

FSC: fabric-smart-client/.../common/config.go:18-20

const (
    DefaultMaxIdleConns = 2           // Applied if not configured
    DefaultMaxIdleTime  = time.Minute // Applied if not configured
)

FSC: fabric-smart-client/.../postgres/config.go:50-55

if o.MaxIdleConns == nil {
    o.MaxIdleConns = CopyPtr(DefaultMaxIdleConns) // = 2
}
if o.MaxIdleTime == nil {
    o.MaxIdleTime = CopyPtr(DefaultMaxIdleTime)   // = 1 minute
}
// MaxOpenConns: No default (0 = unlimited)
// StatementTimeout: Missing completely

4. What's Missing

• maxOpenConns: No default (unlimited connections)
• maxIdleConns: Too low (2 vs needed 10)
• maxIdleTime: Too short (1 min vs needed 1 hour)
• statementTimeout: Completely missing

5. Question

Where should we add safe defaults?

• FSC (benefits all projects)
• Token SDK (Token SDK-specific)

[AkramBitar]

After discussion with the team:

1. The default DB parameters (maxOpenConns, maxIdleConns, and maxIdleTime) are configurable and should be set by the database administrator.
2. Regarding the statementTimeout parameter, we need to check with FSC whether this parameter is generic and can be configured at the PostgreSQL level, or if it must be defined at the FTS level.

@mbrandenburger could you please share your thoughts on the statementTimeout parameter and whether you think it should be configured at the FSC level or at the FTS level?

[AkramBitar]

See PR #1781, this seems to be duplicate of this issue (setting the query timeout)

[AkramBitar]

See discussion with @adecaro in PR #1781.

The Token SDK must respect the provided context timeout and cancellation.

If the context reaches its deadline or is canceled, any ongoing query must be interrupted as soon as possible and return the appropriate context error.

The SDK must use context-aware database operations and ensure no query continues running after the context has expired or been canceled. Database-side query limits and timeouts are expected to be configured by the DB administrator and application developer.

This issue will be addressed under: PR #1781