DK-CERT: Botnet angriber med SQL-indsætning

Hver gang jeg læser om hvordan man imødegår dette, er opskriften, som i denne artikel:

Applikationen må ikke sende tekststrenge fra brugerinput direkte videre til databasen.

I stedet skal man enten rense input eller kalde stored procedures med parametre i stedet for direkte at udføre SQL-kald.

Det er altså ikke så nemt som det lyder, alt afhængig af hvilke tekst-strenge som er gyldige.
Og selv med stored procedures kan der ske injections.

Hvorfor ikke anvende en generel opskrift, som er uafhængig af hvilke SQL-kald man foretager.
Brug følgende 3 regler:

1. Så længe en bruger ikke er logget ind, anvendes en SQL-konto, som ikke tillader opdateringer.

2. Alle adgangskoder i databasen er krypteret.
Skulle der lykkes at udlæse informationer fra en tabel, vil en evt. adgangskode ikke kunne benyttes.

3. Når en bruger er logget ind med brugernavn/adgangskode, kan anvendes en anden SQL-konto, som giver mulighed for opdatering, hvis det er påkrævet.

Vil da gerne have andres syn på denne fremgangsmåde, specielt hvis du mener at der er et 'hul' i den.

En nemmere måde at beskytte sig på, er, at bruge en model-baseret indkapsling i selve applikationslaget. Dvs. anvend (eller byg selv) et rammesystem der kan levere data til præsentationslaget, men hvor forespørgsler til database m.v. er indkapslet i en klassisk MVC konstellation.

I applikationslaget kan man lave alt den sikkerhed der er nødvendigt, inkl. f.eks. at teste for keywords i felter der ikke bør indeholde SQL kommandoer, gennemtvinge korte feltlængder så der slet ikke er plads til at indsætte kommandoer, gennemtvinge typecheck, og måske endda også analysere det resultat der kommer tilbage fra databasen, for at se om det giver mening i forhold til applikationen (de fleste SQL injection angreb vil f.eks. få cursortypen til at ændre sig).

Det kræver mere kode at komme igang. Indrømmet. Og hvis man ikke har prøvet det før kræver det, at man tager sig tid til at anskaffe et model-rammesystem og læse dokumentationen. Men de findes. Der er mange af dem. Enkelte endda gratis. Og de løser ikke kun dette problem, men rigtig mange andre. For ikke at tale om alt den udviklingstid de kan spare på længere sigt.

- Jesper

Som flere andre har påpeget, beskytter det ikke en brik at anvende Stored Procedures. Jeg mente dog det var en information der var vigtig nok til, at den skulle have en tydelig overskrift (a'la "Stored Procedures beskytter ikke").

Der skal enten anvendes helt andre metoder, eller som minimum prækompilerede SQL sætninger / prepared statements.

- Jesper