mboost-dp1
Microsoft Corporation
Huh? Hvorfor bekymrer de sig så meget om felterne? Hvis man har lyst til at skrive Robert'); DROP TABLE Students;-- som fornavn, hvorfor så ikke? Eller mere relevant, hvis jeg har lyst til at skrive det i en kommentar på newz? Så skal den da ikke komme at sige næh nej, du må ikke skrive SQL i en browser!
Princippet er MEGET simpelt: Benyt "parameterized SQL queries" til ALT data, man ikke kan stole på. That's it.
Et skridt bedre: Hav KUN SQL i et database abstraktionslag. Så er det nemt lige at kigge igennem, om en eller anden slambert har gjort noget dumt. Det bliver lidt mere kompliceret for store applikationer, men der kan princippet også benyttes.
Så kan man lave et værktøj som tjekker om man indsætter variabler i SQL på anden måde end med "parameterized SQL queries", hvis man vil automatisere kontrollen.
Princippet er MEGET simpelt: Benyt "parameterized SQL queries" til ALT data, man ikke kan stole på. That's it.
Et skridt bedre: Hav KUN SQL i et database abstraktionslag. Så er det nemt lige at kigge igennem, om en eller anden slambert har gjort noget dumt. Det bliver lidt mere kompliceret for store applikationer, men der kan princippet også benyttes.
Så kan man lave et værktøj som tjekker om man indsætter variabler i SQL på anden måde end med "parameterized SQL queries", hvis man vil automatisere kontrollen.
Lidt om "parameterized SQL queries": http://en.wikipedia.org/wiki/SQL_injection#Using_P...
Jeg snakker ikke om hvorvidt der er et behov. Jeg undrer mig over måden de løser det på. SQL-injections løses ved at kigge på SQL'en, ikke ved at kigge på indtastningsfelterne.
Det er der mange grunde til. Fx. er det ikke sikkert at data fra et indtastningsfelt bliver til SQL. Men det er heller ikke sikkert at alt usikkert data til SQL'en kommer fra et indtastningsfelt.
Det er der mange grunde til. Fx. er det ikke sikkert at data fra et indtastningsfelt bliver til SQL. Men det er heller ikke sikkert at alt usikkert data til SQL'en kommer fra et indtastningsfelt.
#4 Helt enig
I øvrigt, HP Scrawler, som åbenbart er et automatiseret program som sender SQL i indtastningsfelter, hvordan kan det analysere webapplikationens svar og vurdere om SQL'en blev sendt eller ej? Umuligt ... men hvis man ejer sitet, kan man selvfølgelig undersøge om ens tabeller er væk bagefter. Meget videnskabelig fremgangsmåde.
I øvrigt, HP Scrawler, som åbenbart er et automatiseret program som sender SQL i indtastningsfelter, hvordan kan det analysere webapplikationens svar og vurdere om SQL'en blev sendt eller ej? Umuligt ... men hvis man ejer sitet, kan man selvfølgelig undersøge om ens tabeller er væk bagefter. Meget videnskabelig fremgangsmåde.
#4
bare fordi det først er kommet nu, betyder jo ikke behovet først er kommet nu.
Der findes da flere ældre løsninger hvor man ikke har tænkt på dette, og som har en enorm mængde kode at kigge igennem.
Vil du så ikke give mig ret i at dette er da en smuk måde at give et finger pej, på om der er problemer med de 1000 gamle sites der overhoved ikke ligner hinanden, både design og kodemæssigt ?
bare fordi det først er kommet nu, betyder jo ikke behovet først er kommet nu.
Der findes da flere ældre løsninger hvor man ikke har tænkt på dette, og som har en enorm mængde kode at kigge igennem.
Vil du så ikke give mig ret i at dette er da en smuk måde at give et finger pej, på om der er problemer med de 1000 gamle sites der overhoved ikke ligner hinanden, både design og kodemæssigt ?
4 skrev:Det er der mange grunde til. Fx. er det ikke sikkert at data fra et indtastningsfelt bliver til SQL. Men det er heller ikke sikkert at alt usikkert data til SQL'en kommer fra et indtastningsfelt.
God pointe. Hvorfor tjekkes kun form data? Cookies f.eks. er lige så usikre og kan også sagtens bruges til SQL injection.
9 skrev:#1
hørt !
og lige et lille link til den reference du har lavet :)
Og præcis denne strip er også på HP Scrawler linket i artiklen :)
7 skrev:bare fordi det først er kommet nu, betyder jo ikke behovet først er kommet nu.
Ingen siger at behovet er nyt. Behovet er vel næsten lige så gammel som SQL.
7 skrev:Der findes da flere ældre løsninger hvor man ikke har tænkt på dette, og som har en enorm mængde kode at kigge igennem.
Så skal man kigge på SQL'en, ikke indtastningsfelterne.
7 skrev:Vil du så ikke give mig ret i at dette er da en smuk måde at give et finger pej
Nej.
Metoden kan godt afsløre nogle ting, men jeg er bange for at den giver falsk tryghed, og opfordrer til at lave sine rettelser et forkert sted.
#1 Når man laver et nyt website i Visual Studio, er web.configen som standart sat op til ikke at modtage HTML i text felterne, dette er faktisk en meget god idé, især fordi det er lige så let at slå fra.
Jeg syntes det er en godidé at få folk til at tænke lidt over hvordan de filtrerer deres incoming queries.
Jeg syntes det er en godidé at få folk til at tænke lidt over hvordan de filtrerer deres incoming queries.
#11
selvfølgelig skal man kigge på sql'en, eller den måde man tjekker det på.
Men derfor er det stadig rart med nogle tools, der først giver et overblik, og hurtigt giver et overblik over hvor der er fejl, som man så self kan rette.
og nej, ikke altid sql koden man skal kigge på.
Godt være man kan parameterized i php, .net, og andre sprog, men der findes stadig sites som bruger gammel asp.
Så derfor er jeg da som udvikler glad, for hurtigt at kunne tjekke sites igennem, og se hvad der er størt og mest åbenlyse huller i :D
selvfølgelig skal man kigge på sql'en, eller den måde man tjekker det på.
Men derfor er det stadig rart med nogle tools, der først giver et overblik, og hurtigt giver et overblik over hvor der er fejl, som man så self kan rette.
og nej, ikke altid sql koden man skal kigge på.
Godt være man kan parameterized i php, .net, og andre sprog, men der findes stadig sites som bruger gammel asp.
Så derfor er jeg da som udvikler glad, for hurtigt at kunne tjekke sites igennem, og se hvad der er størt og mest åbenlyse huller i :D
14 skrev:Men derfor er det stadig rart med nogle tools, der først giver et overblik, og hurtigt giver et overblik over hvor der er fejl, som man så self kan rette.
Bare man husker at det IKKE er en liste over hvor der er fejl, det er kun en slags stikprøve.
Husker man det? Eller tænker man at nu har et smart værktøj tjekket at der ikke er nogen SQL injection fejl?
14 skrev:og nej, ikke altid sql koden man skal kigge på.
Godt være man kan parameterized i php, .net, og andre sprog, men der findes stadig sites som bruger gammel asp.
Uanset hvilket programmeringssprog (eller scriptsprog) man benytter, er det da stadig SQL'en man skal kigge på. Hvis systemet ikke understøtter den ene teknik, må man benytte en anden.
Kun database-abstraktionen skal vide noget som helst om SQL. Ergo er det der, man løser SQL-problemer.
14 skrev:Så derfor er jeg da som udvikler glad, for hurtigt at kunne tjekke sites igennem, og se hvad der er størt og mest åbenlyse huller i :D
Nemlig, det er højest det, det kan bruges til.
#11
Det argument kan jo bruges mod langt de fleste former for test, da langt de færreste tests (læs ingen) med 100% sikkerhed kan udelukke fejl.
Så løsningen er slet ikke at teste da det giver en falsk tryghed?
Give me a break!
Jeg synes det er en god løsning fordi:
1. Hvis du er den perfekte udvikler har du ikke brug for det så hvorfor være imod?
2. Hvis du er en dygtig udvikler kan det måske hjælpe en gang imellem. Og du er under alle omstændigheder ikke dum nok til at tro at disse løsninger giver komplet beskyttelse.
3. Hvis du er en dårlig udvikler kan løsningerne i det mindste fange det mest idiotiske ting.
Win, win win. Hvorfor være negativ?
Det argument kan jo bruges mod langt de fleste former for test, da langt de færreste tests (læs ingen) med 100% sikkerhed kan udelukke fejl.
Så løsningen er slet ikke at teste da det giver en falsk tryghed?
Give me a break!
Jeg synes det er en god løsning fordi:
1. Hvis du er den perfekte udvikler har du ikke brug for det så hvorfor være imod?
2. Hvis du er en dygtig udvikler kan det måske hjælpe en gang imellem. Og du er under alle omstændigheder ikke dum nok til at tro at disse løsninger giver komplet beskyttelse.
3. Hvis du er en dårlig udvikler kan løsningerne i det mindste fange det mest idiotiske ting.
Win, win win. Hvorfor være negativ?
16 skrev:Det argument kan jo bruges mod langt de fleste former for test, da langt de færreste tests (læs ingen) med 100% sikkerhed kan udelukke fejl.
En god test er tilstrækkelig tæt på 100% dækkende.
Denne test kigger et helt forkert sted, og vil derfor overse hele områder fuldstændigt. Den leder efter symptomer, når man kan kigge direkte på problemet.
16 skrev:Win, win win. Hvorfor være negativ?
Fordi man "winner" meget mere ved at gøre det ordentligt i stedet.
#17
Du modsiger dig selv.
Og samtidigt siger du
Altså hvis man gør det ordenligt, har man jo slet ikke brug for en test.
Eller indrømmer du bare man aldrig kan gøre det godt nok og derfor har brug for test systemer, og derfor også de programmer der tales om i denne tråd.
Du modsiger dig selv.
En god test er tilstrækkelig tæt på 100% dækkende.
Og samtidigt siger du
Fordi man "winner" meget mere ved at gøre det ordentligt i stedet.
Altså hvis man gør det ordenligt, har man jo slet ikke brug for en test.
Eller indrømmer du bare man aldrig kan gøre det godt nok og derfor har brug for test systemer, og derfor også de programmer der tales om i denne tråd.
Rigtig store sites har typisk flere "generationer" af kode, som muligvis også kører op imod flere forskellige DA lag og det ældste kode gør måske slet ikke, men udfører SQL mere direkte op imod databasen.
Der kan være forskellige årsager til at man ikke nødvendigvis bare koder det hele om til nyeste generation, herunder at det kan være meget tidskrævende (og dermed dyrt) og at man risikerer at introducere andre fejl (ikke nødvendigvis sikkerhedsrelaterede) i forb. med en omskrivning (if it ain't broken, don't fix it).
I sådanne tilfælde kan problemstillingen være noget mere kompleks. Et scanningstool kan muligvis afdække problemer i gamle generationer kode og hvis det ikke er noget der videreudvikles på kan et fix af evt. huller være tilstrækkeligt.
Parameteriserede queries kommer man langt med og der er ikke rigtig nogen undskyldning for at lade være, men det er dog heller ikke den hellige gral. Specielt dynamisk opbyggede queries kan meget nemt være sårbare hvis ikke man tænker sig om også selvom man heri benytter parametrer til al data.
Det er ikke helt usædvanligt at man kan støde på noget ala:
Eller et andet eksempel, som ofte forekommer på sider indeholdende entries med checkboxe (lige præcis ID IN er i visse databaser besværlig at håndtere med parametrer):
Hvis ikke vedkommende har tænkt sig om og udført korrekt inputvalidering, så har man i ovenstående introduceret et hul. Nu er disse basale eksempler, men dynamisk opbyggede søgestatements kan ofte blive meget komplekse da der skal tages højde for en masse brugervalg og det kan nemt resultere i at der sniger sig en fejl ind pga. manglende input validering - især hvis man forventer at man er ude over alt hvad der hedder SQL injections blot fordi man anvender parametrer til data.
Der kan være forskellige årsager til at man ikke nødvendigvis bare koder det hele om til nyeste generation, herunder at det kan være meget tidskrævende (og dermed dyrt) og at man risikerer at introducere andre fejl (ikke nødvendigvis sikkerhedsrelaterede) i forb. med en omskrivning (if it ain't broken, don't fix it).
I sådanne tilfælde kan problemstillingen være noget mere kompleks. Et scanningstool kan muligvis afdække problemer i gamle generationer kode og hvis det ikke er noget der videreudvikles på kan et fix af evt. huller være tilstrækkeligt.
Parameteriserede queries kommer man langt med og der er ikke rigtig nogen undskyldning for at lade være, men det er dog heller ikke den hellige gral. Specielt dynamisk opbyggede queries kan meget nemt være sårbare hvis ikke man tænker sig om også selvom man heri benytter parametrer til al data.
Det er ikke helt usædvanligt at man kan støde på noget ala:
"SELECT id, name FROM user WHERE age > @age ORDER BY " + SortValue + " ASC"
url: /listusers?sortvalue=name
Eller et andet eksempel, som ofte forekommer på sider indeholdende entries med checkboxe (lige præcis ID IN er i visse databaser besværlig at håndtere med parametrer):
"SELECT id, name FROM user WHERE ID IN (" + IDList + ")"
postdata: 12,34,56,68
Hvis ikke vedkommende har tænkt sig om og udført korrekt inputvalidering, så har man i ovenstående introduceret et hul. Nu er disse basale eksempler, men dynamisk opbyggede søgestatements kan ofte blive meget komplekse da der skal tages højde for en masse brugervalg og det kan nemt resultere i at der sniger sig en fejl ind pga. manglende input validering - især hvis man forventer at man er ude over alt hvad der hedder SQL injections blot fordi man anvender parametrer til data.
Sjovt at se at der faktisk opstår SQL-injections når ASP.NET's database tool, ADO.NET , har haft parameterizert queries siden dag 1.
Dumme udviklere kan vist ødelægge enhvert forsøg på at undgå SQL injections, så jeg tvivler på at flere råd kan hjælpe dem med noget som helst.
Desuden så bør man også sanitisere sit input, f.eks. et felt hvor du angiver alder bør der jo ikke acceptere andet end tal.
At lave valgmuligheder, og lade brugerens eget input være til det minimale hjælper også meget.
Sund fornuft løser 99% af alle problemer , folk er bare dumme -- og derfor opstår der sikkerdsfejl.
Dumme udviklere kan vist ødelægge enhvert forsøg på at undgå SQL injections, så jeg tvivler på at flere råd kan hjælpe dem med noget som helst.
Desuden så bør man også sanitisere sit input, f.eks. et felt hvor du angiver alder bør der jo ikke acceptere andet end tal.
At lave valgmuligheder, og lade brugerens eget input være til det minimale hjælper også meget.
Sund fornuft løser 99% af alle problemer , folk er bare dumme -- og derfor opstår der sikkerdsfejl.
Efter et nærmere kig lader til at være mere relateret til klassisk ASP, hvor størstedelen af udviklerne slet ikke er klar over de kan bruge param-queries.
I klassisk asp er det nærmest defacto IKKE at have nogen form for beskyttelse, f.eks. Odder kommune, www.odder.dk kan SQL injectes og med en shutdown kommando kan du slukke for sql-serveren hos det firma der kører siden.
Og dermed lukke deres egen side + andre hostede sider ned :p
Fantastisk , er det ikke? ;-)
I klassisk asp er det nærmest defacto IKKE at have nogen form for beskyttelse, f.eks. Odder kommune, www.odder.dk kan SQL injectes og med en shutdown kommando kan du slukke for sql-serveren hos det firma der kører siden.
Og dermed lukke deres egen side + andre hostede sider ned :p
Fantastisk , er det ikke? ;-)
#17
Så bliver der ikke lavet mange (om nogen) gode tests.
Det er i praksis umuligt at lave en 100% test eller en tæt på 100% test af komplekst software.
Der er flere kombinationer at teste end der er atomer i universet.
En god test er tilstrækkelig tæt på 100% dækkende.
Så bliver der ikke lavet mange (om nogen) gode tests.
Det er i praksis umuligt at lave en 100% test eller en tæt på 100% test af komplekst software.
Der er flere kombinationer at teste end der er atomer i universet.
18 skrev:Fordi man "winner" meget mere ved at gøre det ordentligt i stedet.
Altså hvis man gør det ordenligt, har man jo slet ikke brug for en test.
TESTE ordentligt. Dvs. lede efter SQL-injection problemer i SQL-koden, ikke tage en stik-prøve og se om man tilfældigvis kan generere en fejl.
23 skrev:Input felter ender op i SQL i stort set alle apps.
Brug af info fra cookies er langt mere sjælden.
Men ja - data kan komme hvor som helst fra.
Det er også nogenlunde fint, hvis data går nærmest direkte fra bruger til database. Men hvis du har forretningslogik imellem, som jonglerer med data, så kommer du nemt til kigge på den forkerte side af logikken, og måske løse problemet samme sted.
Og hvis ikke der er nogen forretningslogik imellem, så er det alligevel et ret simpelt projekt man har gang i, og så burde koden være overskuelig, men okay. :)
25 skrev:Så bliver der ikke lavet mange (om nogen) gode tests.
Det er i praksis umuligt at lave en 100% test eller en tæt på 100% test af komplekst software.
Mjah, det er har du egentlig ret i, der fik jeg formuleret mig dårligt.
Det jeg TÆNKTE (men ikke fik skrevet) var 100% af det man tænker på at teste.
Hvis jeg vil teste samtlige tekst-felter for SQL-injection, så er det en test man godt kan ramme 100%. (I store apps vil man dog nok overse et eller andet, men tæt på 100%.)
Men det betyder jo ikke at man tester 100% af SQL-koden. Hvis man tror det SÅ har man falsk tryghed. Og det er sådan jeg tolker denne nyhed: Man kontrollerer maskinelt for fejl i SQL-koden, ved at lege med input-felterne.
#24: En af årsagerne til at klassisk ASP er specielt sårbar skyldes at understøttelsen af parameteriserede queries heri er rimelig dårlig (specielt sammenlignet med ADO.NET). Det kan løses med et abstraktionslag, men det hører vist desværre til sjældenhederne at det sker. Der er en tilbøjelighed til at man gør det der er lettest og i klassisk ASP er det letteste desværre også det mest usikre.
#26: Husker jeg ikke helt forkert så kan det lade sig gøre med "WHERE ID IN (@id1, @id2, @id3)" i MSSQL hvilket så kræver at parametrene tilføjes med en løkke i koden der løber arrayet igennem. Men det er lidt mere bøvlet af den grund og derfor gøres det typisk ikke sådan, vi har da også selv valgt modellen hvor ID IN problematikken håndteres af DA laget som så automatisk sikrer validering af inputtet istedet, men det kræver at man har et lag ovenpå ADO.NET for at man kan sikre at det sker i alle tilfælde.
#30: Det ville jo være den "nemme" løsning :)
Men i en afdeling med flere ansatte, hvor folk kan være på forskellige niveauer bliver det lidt mere komplekst. Er der tale om så stor en virksomhed at man har en decideret test-afdeling, så bliver fejl forhåbentlig fanget her, men rigtig mange virksomheder der arbejder med webudvikling er ikke så store at man har denne luksus og path til production er dermed rimelig kort. Oftest sker der det at det er den samme udvikler der tester koden, som har skrevet den.
Så er vi så ude i at tale noget seriøs kodereview og dermed organisering, hvis man skal have løst dette problem, men det kan også være en tidskrævende og omkostelig affære.
I bund og grund kommer det nok ofte ned til risiko vs økonomi.
#26: Husker jeg ikke helt forkert så kan det lade sig gøre med "WHERE ID IN (@id1, @id2, @id3)" i MSSQL hvilket så kræver at parametrene tilføjes med en løkke i koden der løber arrayet igennem. Men det er lidt mere bøvlet af den grund og derfor gøres det typisk ikke sådan, vi har da også selv valgt modellen hvor ID IN problematikken håndteres af DA laget som så automatisk sikrer validering af inputtet istedet, men det kræver at man har et lag ovenpå ADO.NET for at man kan sikre at det sker i alle tilfælde.
#30: Det ville jo være den "nemme" løsning :)
Men i en afdeling med flere ansatte, hvor folk kan være på forskellige niveauer bliver det lidt mere komplekst. Er der tale om så stor en virksomhed at man har en decideret test-afdeling, så bliver fejl forhåbentlig fanget her, men rigtig mange virksomheder der arbejder med webudvikling er ikke så store at man har denne luksus og path til production er dermed rimelig kort. Oftest sker der det at det er den samme udvikler der tester koden, som har skrevet den.
Så er vi så ude i at tale noget seriøs kodereview og dermed organisering, hvis man skal have løst dette problem, men det kan også være en tidskrævende og omkostelig affære.
I bund og grund kommer det nok ofte ned til risiko vs økonomi.
#30
Og folk kan også bare lære at stave ordentlig, men alligevel findes der stavefejl i bøger, aviser, tidsskrifter osv (og endnu flere på et online forum). Og det på trods af at der findes stavekontrol...
Så længe koden er skrevet af mennesker, vil den indeholde fejl. Længere er den ikke...
Og folk kan også bare lære at stave ordentlig, men alligevel findes der stavefejl i bøger, aviser, tidsskrifter osv (og endnu flere på et online forum). Og det på trods af at der findes stavekontrol...
Så længe koden er skrevet af mennesker, vil den indeholde fejl. Længere er den ikke...
Af ren nysgerrighed, vil der kunne bruges sql injections i dette eksempel:
strSQL = "Select * from viewPages where PagesID = " & sqlPrepare(request.querystring("PagesID"))
Hvor sqlPrepare ser således ud (ASP):
Altså hvor den escaper single quotes fra brugerinput, så de læses som en quote, der indsættes i databasen og ikke en quote der bruges til at stoppe en variabel
strSQL = "Select * from viewPages where PagesID = " & sqlPrepare(request.querystring("PagesID"))
Hvor sqlPrepare ser således ud (ASP):
Function sqlPrepare(strString)
sqlPrepare = Replace(strString,"'","''")
End Function
Altså hvor den escaper single quotes fra brugerinput, så de læses som en quote, der indsættes i databasen og ikke en quote der bruges til at stoppe en variabel
#34 det var et spørgsmål, det ser bare så dumt ud når det flyver ude for enden af en klump kode :P
Men det var også et dårligt eksempel.. jeg koder sådan at jeg altid leder efter id's eller andre int's i select-strings.. men lad os sige en søgemaskine på en side brugte eksemplet:
strSQL = "Select * from viewPages where PagesContent LIKE %" & sqlPrepare(request.form("search")) & "%"
Og så samme funktion som ovenover..
Men det var også et dårligt eksempel.. jeg koder sådan at jeg altid leder efter id's eller andre int's i select-strings.. men lad os sige en søgemaskine på en side brugte eksemplet:
strSQL = "Select * from viewPages where PagesContent LIKE %" & sqlPrepare(request.form("search")) & "%"
Og så samme funktion som ovenover..
#35 okay.. crap :) men bliver det ikke fortolket i urlen og sendt som de egentlige tegn? Synes også at huske at jeg har fået forskellige resultater ved at bruge Server.URLEncode på en streng jeg leder efter, og uden urlencode...?
Et lille eksempel: http://www.karga.dk/skriv.asp?1;%20DROP%20TABLE%20...
Der bliver %20 sendt til koden som et mellemrum
Et lille eksempel: http://www.karga.dk/skriv.asp?1;%20DROP%20TABLE%20...
Der bliver %20 sendt til koden som et mellemrum
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund