🤔 InfoSec Reco DBMS

Salute,

I think today it will be cool to look, together, at how best to approach the security of the database, the queue broker for writing to the database and, of course, partially the frontend part when interacting with the database.

My recommendations are based on experience and what I most often notice, I hope for your practice, it will be useful and you will be able to look more deeply and immediately in the right direction - because this is important when analyzing and it doesn’t matter whether you are an analyst or an engineer, the main thing is to understand the architecture and how it is built. In some points I will note that it is bad and I think you will understand why.

Relational DBMS

• Bad practice: give the application db_owner, sysadmin, or access to the entire schema without restrictions

• Store sensitive data in such a way that direct access to the underlying tables is limited: use views, stored procedures or a service layer

• Place the DBMS in a separate network segment and prohibit direct access from external and semi-public zones

• Bad practice: use plaintext connections or disable certificate verification

• Enable auditing of critical operations: read, change, delete, DDL changes and administrative actions

• Store connection strings, keys and passwords only in an external secret store.

• Use separate accounts for each application and environment, without shared passwords between teams

• Never pass custom JSON directly to query filters without validation and normalization

• Use typed queries, driver APIs, or strictly limited filtering schemes

• When working with arbitrary documents, check that they do not contain operators starting with $ and other dangerous constructions

• Bad practice: skipping $where, $gt, $regex and similar operators without a whitelist

Redis and in-memory cache

• Bind the service only to internal interfaces and do not publish it to the public network

• Bad practice: listen to 0.0.0.0 and leave Redis accessible from outside

• Require authentication and use long random passwords or equivalent authorization mechanism

• Bad practice: leaving FLUSHALL, CONFIG, EVAL, SCRIPT, DEBUG available

• It is a bad practice to issue a full ACL to an application or use one user for all roles.

• Use namespace prefixes for keys to isolate caches, sessions and service data

• Do not store long-lived secrets or sensitive data in Redis without additional protection

Queues and message brokers

• Bad practice: leaving guest or similar factory accounts

• Create separate users for producer, consumer and administrative tasks

• Isolate environments through separate virtual host/namespace/tenant mechanisms, if supported

• Bad practice: mixing dev, test and prod in the same namespace

• The Producer must only have the right to publish in the allowed exchange or topic

• The Consumer should only have read access from allowed queues and should not publish messages.

• Check client and server certificates if the broker is used in a sensitive circuit

• Limit message size and set quotas to reduce the risk of flooding and abuse

JavaScript and frontend

• Do not use dangerous DOM operations with user input: innerHTML, outerHTML, document.write

• Any HTML coming from outside is sanitized before displaying

• Prohibit unsafe redirect mechanisms based on user input without a whitelist

• Use CSP with minimal required sources and without unsafe-inline, where possible

• For inline scripts use nonce or hash approach

• For external libraries and CDN use Subresource Integrity

• Bad practice: loading a library from a CDN without checking integrity

#reco #devsecops #appsec #specialty