Glem zero-days et øjeblik - SQL-injections er stadig et væsentligt problem her i 2017

Der er flere af de samme sårbarheder på OWASP’s top-10 liste over web-app-trusler for 2017, som også var der i 2007.

Reddit/programming er blevet opmærksom på et indlæg hos HPE skrevet af Alan Zeichick, analytiker hos Camden Associates.

Indlægget bærer titlen 'The OWASP Top 10 is killing me, and killing you!', og det handler om den top-10-liste over kritiske web-sårbarheder, som Open Web Application Security Project (OWASP) sætter sammen med års mellemrum.

Listen bliver blandt andet til via branche-input. Der står mere om tilblivelsesprocessen her.

OWASP er kort fortalt en community-drevet organisation, der, som navnet antyder, arbejder med at forbedre sikkerheden i software. Det sker blandt andet i form af flere guides med best practices, der frit kan læses på organisationens hjemmeside.

For øjeblikket er en 2017-liste ved at blive til. Den ligger her i release candidate 2.(PDF) Release candidate vil sige, det endnu er et udkast.

Zeichick hæfter sig i den forbindelse ved, at adskillige web-app-sårbarheder på udkastet til 2017-listen også var at finde på listen fra 2007.

Følgende fire sårbarheder stod således både på listen fra 2007 og 2017:

»There is no acceptable excuse«

Alan Zeichick peger i den forbindelse på, at de fleste udviklere nok grundlæggende ved, at en web-app selvfølgelig skal kodes, så den eksempelvis ikke er sårbar overfor SQL-injections (Injection Flaws). Men alligevel sker det altså igen og igen - også her i 2017 - at systemer bliver kompromitteret via netop injections.

»There is no acceptable excuse for injection. I've heard developers offer one excuse: 'My tools should detect injection'. No, no, no. It's not the job of the tools - whether an IDE or a security scan run as code is checked into a repository—to ensure that developers don't make stupid mistakes,« skriver Alan Zeichick i indlægget og fortsætter:

»Failing to validate inputs and all data submitted by client-side webpages is a stupid mistake. It's tedious, but it must be done—and frankly, managers must be stricter about enforcing the detection of injection by coders and testers.«

OWASP har en guide til, hvordan generelle injections og SQL-injections kan forhindres her og her.

Senere i indlægget peger Alan Zeichick på, at det ikke giver nogen mening, når organisationer på den ene side bekymrer sig om eksempelvis zero-day-exploits, mens de på den anden side ikke har sikret sig mod banale injection-angreb.

»There's no point installing a sophisticated alarm system in your car if you fail to lock the door or leave the windows rolled down with the key in the cup holder,« som Zeichick skriver.

Slutteligt har Zeichick nogle råd til ledere i forhold til at lukke ned for eksempelvis SQL-injection-sårbarheder.

»Create a culture of writing and deploying secure code,« lyder et af rådene, hvilket nok er lettere sagt end gjort

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kristian Rastrup

Alt hvad der kræver et bevidst manuelt skridt (her: husk at validere input) er dømt til at fejle for sådan er mennesker bygget. At sige at folk bare skal være grundigere er en grundlæggende manglende forståelse for hvordan den menneskelige hjerne virker. Så selvfølgelig skal det ind i ens værktøjssamling på linje med andre ting som også går galt hvis overlagt til mennesker som garbage collection og pointer aritmetik.

  • 0
  • 0
Simon Mikkelsen

Jeg hører igen at man skal huske at validere og sanere input. Den tilgang forstår jeg ikke.

Validering og sanering udelukkende for at forebygge SQL-injections introducerer unødig logik til applikationen og begrænsinger til brugeren. Når det kommer til beskrivelser og andre brødtekster, kan man alligevel ikke løse problemet og er nød til at escape korrekt. Men værre endnu: Holde styr på hvilke variable der skal håndteres hvordan.

Alle databasedrivers (jeg kender til) har en variant af prepared statements. Her adskiller man SQL og data, og indsætter en markør i SQL hvor data skal være. Så sørger driveren for at escape korrekt.

Der bør kun være én regel for at undgå SQL-injection: Altid brug prepared statements! Altid, altid, altid.

Så kan du kigge ét sted i koden og se at det er lavet korrekt. Man gør det altid på samme måde - ikke noget med at holde styr på om den her nu er escapet. Man kommer ikke til at fjerne en validering eller gøre den sårbar senere.

Folk skal have lov til at kalde deres barn: Indsæt reference til Bobby Tables fra XKCD, som V2s anti SQL-injection afviste.

Hvorfor man snakker validering og sanering er mig en gåde, når der er en så nem løsning, der efter min mening også er den mest korrekte.

  • 11
  • 0
Ivo Santos

Citat: »Create a culture of writing and deploying secure code,«

Den sætning burde også være henvendt til alle medlemmer af en virksomhedernes bestyrelse. Så hvis en leder siger at en opgave kræver ekstra 3 måneder fordi at udviklerne skal have tid til at kode på en sikker måde, så bør direktøren sige okay, så må det tage ekstra 3 måneder.

  • 3
  • 0
Torben Mogensen Blogger

Helt enig. Hvis man "saniterer" input, risikerer man at folk med navne som O'Toole eller Þorbjörn afvises eller smadres til ukendelighed. I enhver datastruktur, hvor brugerindtastet data og kode kombineres, skal disse adskilles. Enten ved at bruge markører i de strings, der angiver koden (i stil med formattering i printf-sætninger i C) eller med at koden ikke indkodes som en string, men som en datastruktur, hvor brugerdata er særskilte felter, som derfor aldrig fortolkes som kode. Den sidste løsning er den bedste, da man statisk kan checke typen af datastrukturen, hvilket er svært med kode, der er indkodet i en string.

  • 3
  • 0
Jesper S. Møller

Alt hvad der kræver et bevidst manuelt skridt (her: husk at validere input) er dømt til at fejle for sådan er mennesker bygget.

Ja, mennesker begår fejl, men kodereview er faktisk et meget effektivt redskab netop til dette formål. Og man kan sagtens automatisere at f.eks. ikke samme udvikler, som har skrevet koden må merge den til master (eller hvad man nu bruger).

Så selvfølgelig skal det ind i ens værktøjssamling på linje med andre ting som også går galt hvis overlagt til mennesker som garbage collection og pointer aritmetik.

Det er selvfølgelig altid en god idé at tool'e up hvor man kan, MEN der er grænser for hvad man kan sikre sig med ad den vej. Helt stringent er man jo nødt til at forholde sig til alle strengtyper, der går ind og ud af systemet, holde dem separat og tjekke alle operationer. Ja, man kommer langt med ORM'er og Linq, og automatisk output encoding i templatesprog mv. (og det er en god ting!) men tools kan ikke gå hele vejen, f.eks. i spørgsmål som "må denne bruger læse denne oplysning".

  • 3
  • 0
Allan Thisgaard

Der bør kun være én regel for at undgå SQL-injection: Altid brug prepared statements! Altid, altid, altid.

Fuldstændig enig, kunne ikke have sagt det bedre selv. Med prepared statements kan det ikke gå galt. Seriøst.

Ahhh ja! Little Bobby Tables! :) :) It never gets old... Som det er tilfældet med mange andre gode XKCD striber.

**School: **Hi, this is your son's school. We're having some computer trouble. **Mom: **Oh, dear -- Did he break something? **School: **In a way. Did you really name your son Robert'); DR0P TABLE Students;--? **Mom: **Oh. Yes. Little Bobby Tables we call him. **School: **Well, we've lost this year's student records. I hope you're happy. **Mom: **And I hope you've learned to sanitize your database inputs.

Striben ligger her -> https://imgs.xkcd.com/comics/exploits_of_a_mom.png

*Barnets navn udløser en SQL injection da det indføres i skolens database - hele det table med de studerende i slettes - fuld forklaring her

Version2 tillader ikke at man skriver DRXP TABLES (hvor X er et O som Ole - men DR0P TABLES er bare fjong, great work!!*

  • 1
  • 0
Log ind eller Opret konto for at kommentere