Skydda sig ifrån SQL Injections (Lätta sättet?)

[KQ]

Hej! Jag har undersökt lite om SQL Injection då jag råkade ut för detta själv. Så jag har läst på lite i ämnet, men har fått lite funderingar och tänkte se om ni vet hur man bäst gör.

 

Vad jag förstår så ska man alltid då man skickar något fält till SQL satsen ersätta ' med ''

 

Så har jag lärt mig och min sida gör så över allt. Fast vad jag inte visste var att man även skulle ersätta även dessa:

 

"select"

"drop"

";"

"--"

"insert"

"delete"

"xp_"

 

Vad händer om jag har data på min sida där jag faktiskt vill posta text som den här ovan? Texten "Drop down beautiful" blir ju om jag ersätter alla "drop" med "" " down beautiful". Finns det inte något vettigt sätt att fixa detta? Ett sätt som jag ser framför mig är att jag ersätter tecken ovan med egenpåhittade andra ord och sedan konverterar tillbaka när datan skall hämtas ut. Men finns det inget bättre sätt, där den datan som står i databasen är faktiskt den datan som jag vill visa på sidorna?

 

[Anjuna Moon]

Fast vad jag inte visste var att man även skulle ersätta även dessa:

Nja, detta behöver du bara göra om du skickar queries i klartext (såsom selects och inserts) till databasen, vilket du absolut inte skall göra. Det absolut första steget i att undvika injections är att enbart använda sig av lagrade procedurer och parametrisering. Om du trots allt insisterar på att använda klartext-frågor så är det ett absolut minimum att du åtminstone använder parametrisering

 

Ett par enkla parametriseringexempel hittar du här:

http://patrikc.wordpress.com/2009/05/13/parameteriserade-fragor/

 

Lite mer om injections

http://patrikc.wordpress.com/2009/05/13/sql-injection/

 

Båda sidor är direktlänkade från den gamla eminenta sajten Swesecure. Läs med fördel igenom hela deras webbsäkerhets-sektion, även om den har ett par år på nacken. De flesta principer som tas upp används fortfarande i olika grad.

http://www.swesecure.com/?ID=dc6ea60a-12ae-4e7e-9e9c-59489ccafa90&CP=

 

[Micke_skane]

Finns det inte något vettigt sätt att fixa detta?

Det finns en uppsjö av varianter för att skydda sig mot SQL-injections men några grundprinciper jag tycker du ska använda är:

 

- Lägg in värdena i varainbler och kontrollera att dem verkligen är vad dem förmodas vara, t ex att ett talvärde enbart är av taltyp.

- När du väl ska köra en sql-frågan så använd parametrar för värdena.

 

Lite läsbart/vägledning:

http://www.w3schools.com/ADO/ado_ref_command.asp

http://www.w3schools.com/ADO/met_comm_createparameter.asp

 

[KQ]

Tack för dina länkar och tips. Har suttit här i någon timme nu och sugit in informationen. Har även plockat upp lite nytt som jag inte visste om, exempelvis Server.HtmlEncode()) kommandot. Jag har alltid gjort arbetet manuellt då jag behövt få det presenterat på de sättet.

 

Fast något som jag tycker verkar klurigt är just stycket om parameteriserade frågor. Jag har tittat på exemplet och fattar de till viss del men inte allt. Du har inget enklare kodstycke som du kan visa?

 

Mina SQL satser brukar se ut så här:

 

 

SELECT password from users where username ='"&fixatecken(Request.form("username"))&"'"

 

Funktionen Fixatecken tar bort ' och ersätter med ''.

 

Sedan tittar jag på password i recordsettet som kommer om de matchar Request.Form("password").

 

En sök sats brukar jag skriva så här:

 

SELECT fält1, fält2 from table where fält1 like '%"&Request.Querystring("sök")&"%'"

 

 

Kan jag på något sätt få mina enklare SQL satser säkra utan att behöva ta till parameteriserade frågor?

 

 

 

[KQ]

Hej och tack för dina råd.

 

- Lägg in värdena i varainbler och kontrollera att dem verkligen är vad dem förmodas vara, t ex att ett talvärde enbart är av taltyp.

 

Hur validerar jag textfält? Det är där problemet är för mig tror jag. Siffervärde är inga problem med säg exempelvis att någon skall söka efter något. Då kommer en querystring i stil med Request.querystring("sok") att innehålla vad som helst. Det räcker ju att jag missar säkra en enda sida på siten så får jag den hackad igen.

 

Har du något tips hur jag bör göra när de är sådan input? Förutom att begränsa hur många tecken som de får söka på.

 

[Cluster]

Kan jag på något sätt få mina enklare SQL satser säkra utan att behöva ta till parameteriserade frågor?

Tycker helt klart att du skall se till att ändå ta för vana att bara jobba med parametriserade frågor.

Förr eller senare så kommer du annars riskera att omedvetet öppna upp dig för injections den vägen.

Naturligtvis skall du även överväga att jobba med stored procedures.

 

/Cluster

----------------------------------------------

Any fool can use a computer. Many do.

-----[ http://eforum.kicks-ass.net ]------

 

[Anjuna Moon]

Kan jag på något sätt få mina enklare SQL satser säkra utan att behöva ta till parameteriserade frågor?

Svaret är som tidigare NEJ, Du kan replace:a bort SQL-statements i evighet och det finns ändå sätt att sabotera.

 

Jag drar mig till minnes en så enkel metod, men ack så skadlig, att hacka sig in på stora sql-servrar. Altt som krävdes var att webbservern hade detaljerad error-info påslagen. Sedan räckte det med en injection som överhuvudtaget inte gjorde något i sqlserver, utan enbart fick queryn att trigga ett ADO-felmeddelande som slängde ur sig uppgifter som gjorde intrånget till en lek.

 

Simpla metoder som många glömmer bort är att se till att det användarkonto som serversidorna använder sig av mot databasen bara har läsrättigheter (om sajten enbart använder databasen för läsning förstås)

 

Jag citerar dig igen, med ytterligare en tanke som svar

Kan jag på något sätt få mina enklare SQL satser säkra utan att behöva ta till parameteriserade frågor?

Om du bryr dig så lite om säkerhet att du inte orkar lägga lite tid på det, fundera då på syftet av att du ställde frågan från början.

 

Hur viktig är säkerheten för dig? Är den inte vital och det handlar om en liten sajt med enkel användarinloggning för att titta på bilder av humlor, tja, då kan man ju fuska förstås. Ingen skada skedd om humle-bilderna byts ut mot kopulerande getingar.

Men är saker som andras personliga uppgifter och material (vars integritet du skyddar enligt ett avtal) eller än mer känsliga saker såsom våra ärade pengar, ja då bör du tänka lite till.

 

[Micke_skane]

Har du något tips hur jag bör göra när de är sådan input?

Syftet med ett sökfält är ju att man ska kunna söka på vad man vill så säkerheten ang just vilka ord man söker på får göras genom själva tekniken/tillvägagångssättet man skapar sina sql-frågor.

Låååååångsökt variant är kanske om man kan kontrollera visa ord och i vilken ordning dem Inte får vara i.(Inget jag själv gjort någon gång.)

 

Men se tidigare svar!

 

[KQ]

Tack för din hjälp.

 

Jag kommer få skriva om stora delar av siten men det blir bättre i slutändan, då allt är parametriserat för hoppningsvis. Jag kommer nog inte skriva om SQL satserna på de sidor där inte SQL satsen kan påverkas av besökaren, men där det är en querystring eller form involverad på något sätt så får jag nog tänka om lite.

 

 

 

[KQ]

Stort tack för ditt förtydligande och påpekande av hur viktiga parametriserat är för säkerheten.

 

En sista sak som jag grubblat lite på. Om jag går över till parametriserade frågor, måste jag även i de fallet använda mig av replace av "skadliga tecken" eller kan jag låta de vara helt oberörda?

 

 

 

[KQ]

Med andra ord, parametriserat är nyckeln här :-)

 

Tack Micke! Jag ska sätta igång och skriva om sidorna.

 

[Anjuna Moon]

Om jag går över till parametriserade frågor, måste jag även i de fallet använda mig av replace av "skadliga tecken" eller kan jag låta de vara helt oberörda?

Nej, du behöver inte skriva om något här. ADO-objekten ser med denna metodik till att varje parameter är just enbart en parameter och inget annat.

 

[KQ]

Ok, toppen. Tack för förtydligandet.

 

Nu ska jag sätta igång arbetet med att skriva lite ny kod

 

Ha de gott och tack igen!