Att hitta sårbarheter i kod och beroenden

Sårbarheter (på svenska: sårbarhet, i plural sårbarheter) är inte bara “hacker grejer”. Det är ställen där systemet gör mer än du avsåg - läser en annan användares order, kör SQL du inte skrev, litar på en header. Att hitta dem tidigt är billigare än att läsa om dem i en incidentrapport.

Börja med en karta, inte en skanner

Innan du kör verktyg: rita hur data rör sig. Vem är användaren? Var sitter autentiseringen? Vilka fält kommer från webben, från en fil, från en modell?

Tre frågor räcker för en första pass:

1. Vad är det värsta som kan hända om den här indatan är lögn?
2. Vem ska få se den här raden?
3. Vilka hemligheter ligger i processen just nu?

Skriv det på en sida. Sen letar du. Annars drunknar du i false positives.

De vanliga hålen syns i koden

OWASP Top 10 är inte en checklista att bocka av blint, men den pekar på rätt rum. Här är tre jag ser ofta i webbappar.

SQL-injektion - du limmar ihop frågan i stället för att parametrisera.

// Sårbart
const rows = await db.query(
  `SELECT * FROM orders WHERE id = ${req.query.id}`,
);

// Hållbart
const rows = await db.query("SELECT * FROM orders WHERE id = $1", [
  req.query.id,
]);

XSS - du litar på att text är text.

// Sårbart
<article dangerouslySetInnerHTML={{ __html: kommentar.body }} />

// Hållbart: rendera som text, eller rensa med ett bibliotek du förstår
<article>{kommentar.body}</article>

IDOR - du kollar att användaren är inloggad, men inte att det är hens resurs.

const order = await orders.findById(id);
if (order.userId !== session.userId) throw forbidden();

En sårbarhet är ofta en saknad rad, inte en smart exploit.

Låt maskinen leta i beroenden

Din kod är en del. Paketen är resten. En föråldrad log4j-historia lärde oss det dyrt. Kör audit i CI, inte bara på din laptop.

npm audit --json
pip-audit
dotnet list package --vulnerable --include-transitive
osv-scanner -r .

När något flaggas: läs advisoryn. Inte alla CVE:er träffar er konfiguration. Uppdatera med avsikt, inte panik. Pinna versioner så ni vet vad ni kör.

Granska som en otrevlig kollega

Kodgranskning med säkerhetsglasögon:

• Var hamnar req.body och req.headers?
• Loggas tokens, personuppgifter, sessionskakor?
• Finns rate limit på login, sök och filuppladdning?
• Kan en MCP-klient eller en webhook trigga samma väg utan samma auth?

# Snabbt spår i en JS/TS-kodbas
rg -n "dangerouslySetInnerHTML|innerHTML|eval\\(|exec\\(|child_process" src
rg -n "SELECT .*\\$\\{|query\\(`" src

Det ersätter inte ett pentest. Det fångar det pinsamma innan det blir offentligt.

Får du ens leta?

Skanna bara system du äger, eller där du har skriftligt uppdrag. Att “hitta sårbarheter” på någon annans sajt utan tillstånd är inte nyfikenhet - det kan vara olagligt. Intern jakt: ja. Bug bounty enligt reglerna: ja. Slumpmässig portskanning mot en kund: nej.

Gör det till vana

En sårbarhet du hittar i april och glömmer i maj kommer tillbaka. Lägg in:

• automatisk audit i pipelinen
• en kvart på retro: “vilken ny yta öppnade den här featuren?”
• beroendeuppdateringar som egna PR:er, inte gömda i feature-branch

Att jaga sårbarheter är inte paranoia. Det är samma hantverk som att skriva tester: du antar att något går sönder, och du vill hellre att det är du som ser det först.