Säkerheten på webbplatser är viktig, men har inte helt klart för mig hur man skyddar sig i alla lägen.

Om jag har en gästbok, så lagras innehållet i en databas. Vilka åtgärder behöver jag göra för att skydda databasen, eller behövs inget göras i det fallet?

Är det överallt där besökaren kan skriva in något som det är en fara för databasen?

Är alla databaser lika "känsliga"?

Jag håller på med en sida som är helt uppbyggd från en databas, när jag ska in i admindelen så knappar jag in ett användarnamn och ett lösenord, lösenordet går igenom en "lösenordsgenerator" så att lösenordet omvandlas till ett väldigt stort tal istället för en text. Är detta säkert för dessa sql-injections

Är det alltid databasen som är utsatt eller kan man fördärva filer?


några funderingar

/Tomas

Se till att databasen ligger i en mapp som inte är tillgänglig från internet.

Även om databasen ligger i en mapp som inte är tillgänglig från internet, så matas väl samma värden in i databasen och det är väl det som fördärvar den, om jag nu har fattat rätt.

/Tomas

Hej,

vi har lagt ut en sida som tar upp olika ämnen om säkerhet. Där kan du bland annat läsa om hur du skyddar dig mot SQL-Injections, Cross-Site Scripting m.m.

Sidan har även en "Testa dina kunskaper"-del inom just webbsäkerhet.

Du hittar den på:

www.swesecure.com

/Fredrik

>Jag håller på med en sida som är helt uppbyggd från en databas, när jag ska in i admindelen så knappar jag in ett användarnamn och ett lösenord, lösenordet går igenom en "lösenordsgenerator" så att lösenordet omvandlas till ett väldigt stort tal istället för en text. Är detta säkert för dessa sql-injections

Om du knappar in användarnamnet och lösenordet finns alltid risk att någon sniffar det du matar in, men det kan ändå vara en godtagbar risk, men det kan ändå vara värt att känna till.

Angående att du omvandlar lösenordet till ett stort tal? Vad menar du med det?
Ett krypterat lösenord är alltid ett krypterat lösenord och det brukar gå att forcera på ett eller annat sätt, det är bara svårighetsgraden som avgör. Om du har byggt en egel krypteringsalgoritm så tycker jag att du skall byta till en mer pålitlig och som är framtagen under andra lång tid av forskare på just krypteringsalgoritmer.

Om du menar att du i någon kaka sparar lösenordet för att validera användaren tycker jag att du skall sluta med det också. Efter att användaren är validerad finns det ingen anlendning att spara lösenord eller liknande i någon kaka.

Om du nu vill ha automatiskt inlogg och känner att du verkligen måste spara användarnamn och lösenord i kakan så tycker jag att du istället kan spara en länk till lösenordet i kakan.
Exempelvis kanske du sparar ett guid som pekar på den rad där du har lösenordet till användaren.

Men förklara gärna lite mer vad du menar så kan jag ge lite fler tips.

/Patrik - www.swesecure.com

Ska kolla på er hemsida

Vad jag menar att kryptera lösenordet är att detta måste väl skydda mot dessa sql-injections där man manipulerar sql-satsen. Det ger som du säger inget säkert skydd mot att knäcka lösenordet.

Vet du om det finns risk för sql-injections i tex en gästbok, där allt lagras i databasen?

/Tomas

Överallt där man sparar data som användaren har matat in finns ju risk för sql-injections. Det bästa är att ta för vana att alltid validera input, det kan vara bra ibland ändå för andra saker än motverka sql-injections :-)

>Vad jag menar att kryptera lösenordet är att detta måste väl skydda mot dessa sql-injections där man manipulerar sql-satsen.

Då antar jag att du gör exempelvis såhär?

username = encrypt(request.form("username"))
password = encrypt(request.form("password"))

SQLStmt = "select id from users where username='" & username & "' and password='" & password & "'"

Där encrypt hashar det som kommer in från formuläret.
Ja det borde ju helt klart fungera om du gör så, men det beror helt på hur din krypteringsmetod ser ut och vilka tecken den kan returnera, men om det alltid blir ett tal så bör det vara ok.

/Patrik - www.swesecure.com

<Överallt där man sparar data som användaren har matat in finns ju risk för sql-injections. Det bästa är att ta för vana att alltid validera input, det kan vara bra ibland ändå för andra saker än motverka sql-injections :-)>

Ska man då skapa en funktion i ASP som kollar upp alla tecken som skrivs in där det går att skriva in för en användare.
Prestanda mässigt tar det inte enormt mycket kraft att göra så?
Hur skulle en sådan funktion vara bäst utformad för att undvika säkerhets risker. Det finns färdiga script till allt möjligt, men jag har hittat väldigt lite script-exempel när det gäller säkerhet och skydd av webbplatser

/Tomas

Om du vill skydda dina inmatningar kan du använda parametiserade frågor genom ado.

Här kan du se ett exempel. http://support.microsoft.com/default.aspx?scid=kb;EN-US;300488

Du skall alltid jobba mot att godkänna sådant de får göra och neka allt annat, istället för tvärtom att neka till det de inte skall få göra.

/Patrik - www.swesecure.com

Tja, ska man mata in t.ex. ett datum så kan man ju ha en automatisk datumväljare, sätta en maxgräns på längden på ett input-fält, validera med javascript på klienten (med t.ex. regexp) för att undvika att felaktig data matas in. Fast det är väl mest för att upplysa användaren om felaktig input.

En illasinnad användare kan ju gå förbi såna kontroller på klienten. Då kan man ju dessutom kontrollera på serversidan. Såna oerhörda mängder data matar man väl inte in på en sida så att det blir prestandamässigt ohållbart. Leta på reguljära uttryck, det kan vara rätt kraftfullt att använda sig av.

I datumexemplet kan man ju verifiera att datumet endast innehåller siffror och bindestreck, samt är ett visst antal tecken långt. Ofta är det ju som sagt bra att verifiera data ändå, så att det är korrekt datum, e-postadress eller vad det nu kan tänkas vara. Min erfarenhet är att går det att mata in fel, så matar användaren in fel ;-)

Gällande "input" är det ju även mycket viktigt att skydda sig mot HTML-kod och javascript, särskilt om du har användare som är påloggade med sessions. I annat fall kan någon kapa dina användares sessioner och på så vis bli inloggade i deras namn eller skriva otrevliga script som dina besökare råkar ut för.

Denna teknik kallas Cross-Site Scripting och kan läsas mer om här:
http://www.swesecure.com/?ID=dc6ea60a-12ae-4e7e-9e9c-59489ccafa90&IID=436d5180-8909-4aa2-baee-7c8f925d6eab

/Fredrik

Kan man använda parametiserade frågor genom ado om man har Access och mySQL?

/Tomas

1. Textfält är känsliga för apostroftecknet (') och de ska man oftast ersätta med dubbla sådana...
2. Siffror i SQL skrivs i en fråga ex. "WHERE number = 12345". Om man inte kontrollerat att det verkligen bara är siffror kan man i ett textfält skriva t.ex. "12345 Or field=field".
3. Datum ska bara vara datum, inga ogiltliga tecken får förekomma...
4. Även om du har en lista med valida inmatningar är det inget att lita på, användare kan gå förbi dem och alla andra client-side valideringar så det absolut viktigaste är att validera all data på serversidan...

För att göra en text valid för databasen kan man ersätta ' med dubbla sådana med tex Replace("'", "''").
Datum och siffror kan man kontrollera om de är valida med IsDate och IsNumeric.
Ska man kontrollera andra fält kan man använda Regular Expressions...

Mvh,
Thomas

Kan man använda parametiserade frågor genom ado om man har Access och mySQL?


Har för mig att du kan använda "Stored Procedures" from version 5 av mySql.

Med access så kan du skapa "Frågor" och sedan anropa dem. Se:
<http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q200/1/90.asp&NoWebContent=1>

Vill du inte skapa frågor kan du även skriva din sql-sträng som:
Select * From table where id = ?
och sedan lägga till parametern med:
cmd.parameters(0) = 152

/Fredrik

>För att göra en text valid för databasen kan man ersätta ' med dubbla sådana med tex Replace("'", "''").

Det är dock inte ett helt optimalt alternativ.
Tänk dig att administratören för databasen heter admin,
sedan loggar någon in med admin'-- detta ersätts till admin''-- och allt ser jättebra ut, men i själva databasen blir det ju fortfarande admin'-- och du kanske tror att det är ofarligt då.
Men tänk dig att du har en sida där du byter lösenord eller på något annat sätt använder dig av strängen.
exempelvis

Dim username = replace("admin'--","'","''")
Dim oldPassword = "password"
Dim newPassword = "123"
set rs = conn.execute("select username from users where username='" & username & "' and password='" & password & "' ")
if not rs.eof then
sql = "update users set password='" & newPassword & "' where username='" & rs("username") & "'"
end if

Den slutgiltiga sqlfrågan kommer bli såhär:
sql = "update users set password='123' where username='admin'-- "

och som du säkert ser så kommer den alltså att byta lösenordet på admin och inte den egentliga användaren.


/Patrik - www.swesecure.com

Det är jag väl medveten om, men man ska köra all text som ska in i databasen genom replace...
Även om den kommer ut från databasen och vänder in igen samtidigt...
Läs "hacked by bacher13" så ser du vad jag skrev bland det sista där...

Men det är en tolkningsfråga det som jag skrev, självklart menar jag att man ska kontrollera allt som ska in i databasen...

Dock i ditt exempel finns det ingen användning av att ta ut username från databasen eftersom du redan har ett korrekt användarnamn i variabeln username...

Det är bara att använda den variabeln...
Och din SQL fråga behöver bara räkna antalet träffar och retunera hur många användare som heter "admin'--".

Mvh,
Thomas

Mitt exempel är ett exempel på hur det kan gå, inte att det inte går att göra någonting åt.

Var hittar jag "hacked by bacher13"?


/Patrik - www.swesecure.com

Hacked by Basher13: [Hacked by basher13]

Självklart var det ett exempel, och ett bra exempel på varför man ska ersätta data som tas ut ur databasen för att sedan användas i en annan fråga...

Mvh,
Thomas