Hej allihop,

Jag håller på att utveckla en hemsida åt ett företag med diverse dynamiska funktioner. Den ligger nu utan bilder på en utvecklar-IIS. Jag skulle vilja att ni försökte hacka er in på inloggningen (eller på sidan i allmänhet), som nås på en länk på förstasidan, och även inloggningen till Projektstatus.

Jag hoppas att ni gör som riktiga hackers, och påvisar var bristerna finns istället för att förstöra allt om ni lyckas få tillgång. Givetvis har jag backuper, men fler kan försöka om inte någon tar ner hela sidan.

Det vore bra om ni skrev ett inlägg både när ni har försökt och misslyckats och när ni har försökt och lyckats. Om (när?) ni lyckas, vore det bra om ni beskev detaljerat hur det gick till, och om ni vet någon möjlig lösnings på säkerhetshålet.

Adressen är: (tog bort URL efter genomfört test)

Tack för att ni tar det med ansvar, och lycka till!

Verkar vara fel adress...?

/Johan

Kommer du inte åt den? Jag testade nyss från en dator som inte är i det lokala nätverket (alltså via internet), och det fungerar fint. IIS-servern är inte speciellt hårdvarumässigt snabb, så du kanske inte väntade länge nog? Testa annars att lägga till default.aspx: (tog bort URL efter genomfört test). Låt mig veta om det fortfarande inte fungerar.

Jag hoppas att det fungerar utifrån? Någon som har försökt? Förslag på förbättringar?

Jag kommer inte åt den på någon av länkarna.

Hej Jonas!

Jag har inte lagt mer än två tre minuter, men kan se två problem direkt.

1) Du tycks konkatenera ihop SQL-frågan som verifierar inloggningen ungefär såhär (pseudokod, C#):
<code>
mySqlQuery = "SELECT UserID FROM Users WHERE UserName =" + txtUserName.txt;
</code>

Det öppnar för s.k. SQL injection-attacker. Använd istället parametriserade SQL-frågor, kanske via lagrade procedurer. Se t.ex. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp för mer info (länken SQL injection).

2) Du har satt customErrors Mode till Off i web.config. Detta leder till att mycket ingående felmeddelanden visas om nåt går snett, t.ex. om man gör ett första, halvdant försök med SQL injection. Felmeddelandet kan ge utmärkt ledning till hur man ska modifiera sitt hack-försök för att lyckas bättre... Sätt istället detta till On eller RemoteOnly. Se också till att hantera alla undantagsfel med try/catch-block. Mer info finns t.ex. i kommentaren i web.config vid customErrors-sektionen.

mvh
/Jonas Ö

Är det tänkt att denna:

http://gondor.no-ip.com/trytohack/products.aspx

ska va lösenskyddad?
inklusive dom andra sidorna company osv?

/B

<b>Bertil Rundquist,</b>

Nej, den ska inte vara lösenordsskyddad. Det är endast Projektstatus och Administratörsinloggningen som ska vara det.

<b>Jonas Österlöf,</b>

Jag kanske har fått det här om bakfoten, men Stored Procedures är väl bara för SQL-server? Kräver det inte som namnet antyder att man har en lagrad procedur på servern? Iochmed att jag kör med Accessdatabas och JET.OleDB.4.0-drivrutinerna så kan jag väl inte använda SP?

custumError=Off hade jag på för att jag ville se om någon tog sig in då. Senare tänkte jag sätta defaultRedirect till en felsida som verkligen inte visar någon konkret information. Behövs det verkligen try/catch-block om man alltid redirectar till en felsida? Vad fyller de då för funktion? Hur ser du på säkerheten efter inloggningen? Behöver den vara lika skarp?

<b>Per Persson,</b>

Jag kan inte förstå varför inte du kommer åt sidan. Väntar du tillräckligt länge? IIS:en är som sakt inget att skryta med, så det kan ta en stund. Får du 404-fel, eller vad händer? Det är konstigt iochmed att andra kommer åt sidan.


Tack för responsen!

Om du läser Jonas Österlefs inlägg igen så ser du att han pratar om att du ska använda parameteriserad frågor (kan inte stava det där); titta på http://www.swesecure.com/?ID=dc6ea60a-12ae-4e7e-9e9c-59489ccafa90&IID=29a58b01-ca79-4877-b924-4f5da18d4a2a så ser du

JAg kommer inte heller åt någon av adresserna, får 404-fel.

/Johan

Nu kom jag fram med IE, men inte med Firefox.

Jag får ofta följande fel:
<info>
Serverfel i tillämpningsprogrammet /trytohack.
Det gick inte att hitta resursen.
Beskrivning: HTTP 404. Resursen som du letar efter (eller ett av resursens beroenden) kan ha tagits bort, namnet kan ha ändrats, eller också är den inte tillgänglig för tillfället. Kontrollera att stavningen i URL:n nedan är korrekt.

Begärd URL: /trytohack/trytohack/index.aspx

Versionsinformation: Microsoft .NET Framework-version:1.1.4322.2032; ASP.NET-version:1.1.4322.2032
</info>

Nu insåg jag vad det beror på. I din kod har du en backslash före trytohack:
<code>
<IFRAME SRC="\trytohack/index.aspx"
</code>
Byt ut det mot en vanligt framåtslash:
<code>
<IFRAME SRC="/trytohack/index.aspx"
</code>
Samma problem återfinns på många ställen i index-sidan.

Om du vill undvika att administratören blir frustrerad bör du undvika att i bilden med texten ha med tecken som kan förväxlas, t.ex. litet L och stort I. Även O kan vara lämpligt att undvika då det kan missuppfattas som en nolla.

Lagrade procedurer är inte en förutsättning för parameteriserade SQL-frågor.
Om du kollar här http://aspnet101.com/aspnet101/tutorials.aspx?id=1 så hittar du info om hur du skriver parameteriserade SQL-frågor även för OleDB (t.ex. Access).

Du bör ALLTID hantera ALLA fel som kan uppstå i din applikation, inte bara av säkerhetsskäl. Ohanterade fel riskerar alltid att krascha din applikation och att äta upp resurser, oavsett om det gäller databasuppslag eller annat.

Om t.ex. databasuppslaget för att verifiera en användare genererar ett fel (pga en bugg, eller hackning, eller serverfel eller...) så lämnas förmodligen din databaskoppling (OleDB-connection) öppen. Om felet upprepas kan du mycket snabbt få slut på resurser, särskilt med en måttligt robust databas som Access.

Detta kan dessutom utnyttjas av en illvillig person för att enkelt sänka servern, genom att medvetet generera en mängd fel efter varandra. Om du bäddar in uppslaget i ett try/catch-block och ser till att stänga din db-connection i ett finally-block, så slipper du båda problemen.


Om du sätter errorMode till RemoteOnly så kommer utförliga felmeddelanden bara att visas om du jobbar direkt från webbservern. Det kanske i o f s inte hjälper dig om du t.ex. jobbar direkt mot ett webbhotell?

mvh
/Jonas

<b>Per Persson och övriga som har fått 404-fel,</b>

Jag hade totalt glömt bort detta. Jag gjorde trytohack utifrån en version av den riktiga sidan som inte var standardiserad, alltså fungerar den inte i något annat än IE egentligen. Eftersom jag nu på den riktiga sidan har standardiserat den, så att den fungerar även i FireFox, tänkte jag inte på detta när jag väl publicerade trytohack.

Jag glömde bort att skriva detta, så det hela var mitt fel. Jag kan säga det nu: Ni bör använda IE när ni testar denna sida. :)

Angående ditt förslag till byte av teckensnitt, håller jag med. CAPTCHA-koden konverterade jag för hand från C# till VB, eftersom den fanns i C# på http://www.swesecure.com. Det står en hel del om säkerhet där, och jag trodde därför att de hade tänkt igenom vilket teckensnitt som var bäst för att inte kunna avkodas. Det försämrar alltså inte själva CAPTCHA-funktionen att ersätta det nuvarande teckensnittet med ett annat?

<b>Jonas Österlöf,</b>

Jag har konkatenerat SQL-strängar så som du skrev:

   Dim strSQL as String = "SELECT FLD_COUNTER_ID FROM TBL_Login WHERE FLD_Username = '" & strUserName & "' AND ...

Behöver jag ändra detta överallt på hela sidan, eller räcker det att det finns parameteteriserade SQL-strängar just på inloggningen?

Jag ska försöka lägga till try/catch-block på alla OleDB-operationer. Är det på andra ställen som det kan vara bra att använda detta? Hur vet jag vilka ställen som jag KAN använda try/catch-block?

Jag jobbar inte direkt mot ett webbhotell, men eftersom jag ville se om ni tog er in om jag visade er felmeddelandena lät jag dessa vara kvar. Jag är medveten om att det är säkrast att skicka användaren till en generell felsida om denne stöter på ett sådant fel.



<b>Tack för er hjälp!</b>

Överallt där du tar emot användarinput och bygger SQL-queries utifrån inputen riskerar du SQL injection-attacker. Du behöver inte ens ha en textruta för inputen, man behöver bara vara en aningen mer avancerad crackare för att mecka med värden i querysträngar eller t.om. viewstaten.

Man ska i o f s inte överdriva säkerheten. Säkerheten ska stå i proportion till risken och hur stor skadan kan bli.

Om du litar hundra på att din inloggning inte kan hackas och på att de som är inloggade aldrig aldrig aldrig skulle göra nåt dumt, så kanske du kan nöja dig med att säkra de databasuppslag man kommer åt innan/under inloggning.

Man kan också uppnå liknande trygghet genom att escapa bort riskabla tecken. Info om den metoden fanns i nån av artiklarna jag hänvisade till tidigare.

Å andra sidan är det inte särskilt krångligt att använda parameteriserade SQL-frågor och koden blir oftast läsbarare.

När det gäller try/catch-block så kan du använda det precis överallt! :-) God felhantering är en central del av all god programmering.

Utöver specifik felhantering på metod-nivå kan man skapa en global hanterare som tar hand om alla fel de mer specifika hanterarna missar. Den ambitiöse kan med bara några rader extra se till att utförliga felmeddelanden skrivs till serverloggen och/eller e-postas till admin, medan användaren får ett mer "vänligt" felmeddelande.

Om du googlar efter "asp.net error handling" får du massor av träffar. Här är en bra (VB):
http://www.15seconds.com/issue/030102.htm

MVH
/Jonas

Okej, tack för hjälpen, allihop!

Det blir snart bonusmedlemskap här vill jag lova!

Vore bra om ni tog bort min URL ur era inlägg, även om det kanske inte spelar så jättestor roll.