PS: Man bør være varsom og ikke kjøre disse verktøyene verken mot sider som eksisterer i produksjon eller på testmiljøer, så sant det ikke er avtalt på forhånd.
1. OWASP ZAP
OWASP ZAP er en Open-Souce og gratis sikkerhetsskanner for webapplikasjoner. Den er veldig enkel å bruke ved at man bare limer inn URL’en og klikker «attack». Du kan laste ned og installere skanneren her: https://www.zaproxy.org/
Eller du kan skanne koden din fra GitHub: https://github.com/zaproxy/zaproxy
OWASP ZAP kan kjøres i fire ulike angrepsmoduser:
- Safe Mode – lar deg ikke gjøre noe som er potensielt farlig.
- Protected Mode – lar deg simulere potensielt farlige sårbarheter. Brukeren kan bare utføre skadelige handlinger på nettadresser som er nevnt i omfanget.
- Standard Mode – brukeren kan gjøre alt som er relevant.
- ATTACK Mode – vil aggressivt prøve å angripe nye nettadresser så snart de er oppdaget.
Som et eksempel kjørte vi på ‘Standard Mode’. Klikk på ‘Automated Scan’. Lim inn url’en og klikk på ‘Attack’.
Etter skanning er utført får du en rapport som vises på ‘Alerts’ fanen. Figur 3 viser at url’en er sårbar for SQL-injeksjoner på GET metode.
Ved å klikke på GET metode på figur 3 man får mer detaljert rapport. Blant annet hva slags database, hvordan man kan utføre SQL-injeksjon og osv.
2. SQLmap
SQLmap – automatic SQL injection and database take over tool. Du kan finne prosjektet på GitHub: https://github.com/sqlmapproject/sqlmap
Man kan også laste ned og installere (Unix/Linux eller Windows eller Mac) fra: http://sqlmap.org/. Beklageligvis kjører SQLmap kun som kommandolinje programmet.
Figur 4 viser hvordan man kjøre SQLmap for å angrep en vanlig GET parameter.
Figur 5 er rapporten eller status på angrep mot den GET parameter.
Figur 6 vises alle data i ‘users’ tabellen ved bruk av:
sqlmap -u «http://192.168.56.106/peruggia/index.php?action=comment&pic_id=1» -T users -D peruggia -dump
Noen nyttige kommandoer:
3. Hvordan kan man forebygge SQL-injeksjoner med defensive løsninger?
Det er ingen enkel løsning på dette og det innebærer vanligvis å bruke forskjellige forsvarsteknikker samtidig. Hovedproblemet bak en SQL-injeksjon er hvordan ‘user input’ kan samhandle med den faktiske syntaksen til SQL, på kodenivå, er SQL-setninger vanligvis konstruert fra tekststrenger.
Man må ha ‘zero-trust’.
3.1. Forsvar på kodenivå
3.1.1. Input validation
‘Input validation’ er prosessen med å godta eller avvise input basert på innholdet. Kun gyldig ‘input’ (i henhold til våre regler) godtas og behandles av applikasjonen vår. Validering må skje på serversiden. Validering følger to hovedtilnærminger:
- Hviteliste.
- Svarteliste. – IKKE ANBEFALT (https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#whitelisting-vs-blacklisting)
3.1.2. Parametrized queries
Inndataene blir aldri sendt til databasen som en streng, men den blir i stedet sterilisert og lagret i separate parametere.
https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html
3.1.3. Character encoding and escaping
Bruke spesifikke ‘character encoding and escaping’ teknikker slik at aktivering av tegn for SQL-injeksjon ikke sendes til databasen. Her er vi mer opptatt av ‘sanitizing the output’ data slik at SQL-setninger blir fratatt farlige tegn.
https://owasp-top-10-proactive-controls-2018.readthedocs.io/en/latest/c4-encode-escape-data.html
3.1.4. Secure coding practices
I de fleste tilfeller ligger roten til alle applikasjonssikkerhetsproblemene i design- og utviklingsfasen. Team har en tendens til å fokusere bare i de funksjonelle aspektene ved applikasjonen og ikke i sikkerhetsaspektene. Å ta tak i sikkerhetsproblemer i design- og utviklingsfasen krever mye mindre innsats.
‘The OWASP SAMM Framework’ – er et åpent rammeverk for å hjelpe organisasjoner med å formulere og implementere en strategi for programvaresikkerhet som er skreddersydd til de spesifikke risikoene organisasjonen står overfor.
Nedenfor lister vi opp noen gode fremgangsmåter som kan hjelpe til med å produsere sikrere kode mot SQL-injeksjoner.
Introduser flere ‘abstraction layers’.
‘Abstraction layers’ betyr forskjellige logiske komponenter, hver enkelt utviklet for å samhandle med applikasjonslogikken din. Eksempler på ‘application layers’ er ‘the presentation layer’, som inkluderer de mer grafiske og interaktive aspektene ved applikasjonen, og ‘the data access layer’ er designet for å samhandle med data separat fra kjerneapplikasjonslogikken. Å skille lag i et program forbedrer sikkerheten, da flytting fra ett lag til et annet er underlagt flere kontroller og gjør bruk av sikkerhetstiltak mye mer lineær og praktisk.
Administrere sensitive data på en sikker måte.
Lagring av passord med en ‘Secure Hashing Algorithm (SHA)’. Maskering av data ved å bare vise deler av dataene til applikasjonen mens de originale dataene holdes uendret.
Lagrede prosedyrer.
Lagrede prosedyrer er spesifikke instruksjoner som er lagret i selve databasen og som det er mulig å bruke strengere tilgangskontroll på. Du kan endre tilgangstillatelsene for instruksjonene i den, og gi mindre privilegium enn programmet til kommandoene som kjøres. Dette betyr å håndheve prinsippet om ‘least privilege’.
3.2. Forsvar på plattformnivå
3.2.1. Brannmurlogikk på applikasjonsnivå
Filtrering av forespørsler rettet mot applikasjonskomponenter på samme måte som en tradisjonell brannmur ville gjort. Noen eksempler på dette konseptet:
Web application firewalls (WAFs)
- Software-based WAFs
- Appliance-based WAFs
Applikasjon intrusion detection systems. WAF kan brukes som IDS (Intrusion Detection Systems) på applikasjonsnivå for å identifisere nettangrep generelt og gi varslingsfunksjonaliteter. Måten dette fungerer på er å bruke WAF i passiv modus slik at den kan vurdere applikasjonsforespørselen og sende varsler hvis det blir funnet mistenkelige forespørsler.
Database brannmurer. En proxy-server plassert mellom applikasjonen og database som inspiserer spørsmålene som sendes til den.
3.2.2. Sikkerhetsmekanismer for databaseserver
- Beskytte databasedataene. Bruke kryptografi på de lagrede dataene.
- Beskytte databaseserveren
- ‘Patching’.
- Håndheving ‘the least privilege’ prinsipp. Sørge for at databaseprogrammer kjøres på et lavt privilegienivå når det gjelder lesing, skriving og utføring.
- Håndheving ‘authentication and monitoring controls’. Dette inkluderer å sikre at passord ikke er svake ved å håndheve en sterk passordpolicy, deaktivere standardkontoer og aktivere logging.
3.2.3. Andre sikkerhetstiltak
Her er noen andre mulige justeringer som kan gi ytterligere beskyttelse mot SQL-injeksjoner.
Reducing information disclosure. Å begrense informasjonen hackere har tilgang til kan effektivt redusere angrepspotensialet og dermed minimere risikoen for at applikasjonen din blir kompromittert.
- Viser ikke feilmeldinger.
- Forhindrer Google-hacking.
Sikker ‘deployment’ av serveren. Det er bedre å ‘deploy’ applikasjonens webserver og databaseserveren på forskjellige maskiner.
Nettverkstilgangskontroll. NAC innebærer bare å tillate utvalgte ‘hosts’ å koble til bestemte servere og tjenester.
Konklusjon
Vi har gjennomgått noen forsvarsmekanismer som er nyttige for å beskytte deg mot SQL-injeksjonsangrep. Det finnes ingen enkel løsning mot SQL-injeksjoner, men en kombinasjon av beste praksis på kodenivå og på plattformnivå vil gi deg god beskyttelse.
Guide: Slik utfører du sikkerhetstesting gjennom utviklingsløpet
Vil du lære mer om sikkerhet og sikkerhetstesting? I denne guiden gjennomgår sikkerhetsekspert Even Lysen hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.