Eftersom att swesecure-tråden blev lite för OT så skriver jag en ny tråd.
Går det att flytta OT-inläggen därifrån hit så vore det schysst. :)
Minförsta fråga är i alla fall:
På sidan skrivs det att man ska blockera sidan efter ett visst antal felaktiga försök.
Ska man då blockera den för alla användare? Och hur länge hade ni tänkt då?
Jag har haft lite huvudbry om hur man ska blockera en specifik person. Känns som att alternativen är:
1. Blockera användaren i databasen. Betyder dock att när den som försöker logga in och får meddelandet "du har blivit blockerad" så vet han att användaren finns. Vilket ju inte känns särskilt bra.
2. Blockera helt IP-nummer. Lite osmidigt när flera på samma företag/skola/liknande använder inloggningen och alla blir blockerade om en skriver fel. Finns också risk för sabotage genom att skriva fel lösenord om och om igen. Dessutom kan man väl få nytt IP-nummer med DHCP (även om det väl är osmidigt för hackern).
3. Blockera för alla. Känns inte aktuellt i det här fallet. Samma nackdelar som i alternativ 2, fast gånger fem.
4. Blockera med hjälp av cookie. Säkert? :e
Blockeringen som görs anser jag inte vara per användare. Precis som du då skriver så avslöjar man då att ett visst användarnamn finns, vilket är mindre bra.
Blockaden gäller istället för inloggningssidan.
Blockeringen som görs drar alltså igång först efter att många på rad felaktiga inloggningsförsök har gjorts under en kort tid. Detta påvisar i så fall att det garanterat är en attack igång.
Blocken kan göras på 2 olika sätt, men gäller alltså bara för själva inloggningen. Redan inloggade användare berörs alltså inte.
1. Blockeringen görs för alla. Befintliga användare kommer säkert att bli lite småsura, men borde ändå värdera att sajten skyddar deras information och lösenord.
2. Blockeringen görs bara på användarens IP alternativt IP + UserAgent. Detta blir ju då en något mer unik lösning som medför att många vanliga användare fortfarande kan logga in.
Om användare dock sitter bakom samma brandvägg och har samma UserAgent drabbas de ändå, men borde ändå ha förståelse.
Problemet med detta är bara att ett intelligent program kan ändra sin UserAgent och eventuellt IP / request för att lura inloggningsscriptet. Fast...det är i så fall ett väldigt sofistikerat program. Men om då request.sen fortsätter efter en första IP-block, kan ju istället hela sajtens inloggning blockeras.
Om syftet med attacken är att få fram lösenord är detta ett effektivt skydd. Om däremot attackeraren utnyttjar ovanstående script för att stänga ner sajten är vi istället inne på "Denial of Service"-attacker, något som är dessto svårare att skydda sig mot. Just vad en DOS-attack innebär kan du läsa om här.
Om en attack görs regelbundet tycker jag att du skall kontakta abuseavdelningen för ISP:n som har det IPnummret samt eventuellt spärra IPnummret i brandväggen. (Kan dock medföra vissa konsekvenser om det är en skola/bibliotek osv).
Men har du några bra förslag på vilken ratio man ska ha för att det ska vara effektivt, men fortfarande användarvänligt.
Alltså antal försök innan block, inom vilken tidsrymd ska försöken varit och hur lång tid ska man blockera?
Och sen när det gäller DoS attacker så är det väl något brandväggen ska blockera..?
Nästa fråga som vi var inne på tidigare.
Hur enkelt är det att kapa en ASP-session?
Jag har alltid trott att den var kopplad till ett visst IP-nummer vilket skulle innebära att sniffaren skulle vara tvungen att sitta bakom samma IP-nummer för att ha användning av en uppsnortad cookie.
Är inte sessionen kopplad till IP-numret? Eller är det så att man kan fejka IP-nummer?
Alltså antal försök innan block, inom vilken tidsrymd ska försöken varit och hur lång tid ska man blockera?
Det man normalt kan göra är att returnera samma felmeddelande, oavsett om användaren finns eller inte och oavsett om bara lösenordet är fel eller om han så har försökt 100 gånger.
På det viset kan han aldrig med en datorstyrd attack urskilja om användaren finns eller ej, och han upptäcker heller ej om användaren är avstängd eller ej. Det som han däremot märker är om lösenordet blir rätt.
Jag tycker det är lämpligt att ha olika nivåer för hur man blockerar. Hur dessa nivåer lämpar sig beror helt på vilken typ av tjänst du bygger.
Exempel på en nivå kan vara att blockera användaren från att inloggning (oavsett om han matar in rätt eller ej) efter exempelvis tre misslyckade inloggningsförsök. Så oavsett om det fjärde är rätt så ger man tillbaka ett misslyckat resultat. Användaren är sedan blockerad i 2-3 minuter. Om han sedan efter dessa 2-3 minuter utför ytterligare 3 misslyckade försök blockeras han helt och måste kontakta systemadministratören för siten för att bli upplåst. Information om detta kan finnas i hjälpfilen, men vid själva inloggningen skall resultatet av inloggningen aldrig visas för användaren.
Testade själv nu att kapa en session och det var faktiskt löjligt enkelt.
Några problem med XSS har vi inte i de lösningarna vi gör. Däremot så är det väl inte särskilt svårt att sniffa trafiken och då fånga upp kakan som skickas i varje anrop..?
Och hur fejkar man sitt IP-nummer? Tycker det låter konstigt om man kan göra det. Då spelar det ju ingen roll hur mycket man spärrar IP-nummer i brandväggar eller skickar mail till internetleverantörer om hackningsförsök...
Sen en fråga om det här med Brute Force inloggning. Ni säger att hackern inte vet hur en lyckad inloggning ser ut och att man ska försöka få det att för en maskin se ut som en misslyckad inloggning.
Är inte en hacker så smart att den går efter den felaktiga HTML-koden och försöker tills den är något annat..?
Ska man då hålla på och slänga ut lite slumptal, datum och annat för att det ska skilja sig? Känns som att det ändå går att komma runt. Och vet man hur en lyckad inloggning ser ut så faller ju hela grejen...
Då attackeraren oftast inte vet hur resultatet av en lyckad inloggning ser ut, utan bara resultatet av en felaktig sådan, kan vi lägga till vårt felmeddelande som bortmarkerad kod även vid en lyckad inloggning. Då luras programmet att tro att inloggningen var misslyckad i samtliga fall.
Dvs. hackern vet kanske bara hur den misslyckade inloggningen ser ut. Det kan tex. vara strängen "Invalid Username or password". Ett sätt för hackerns program att avgöra om inloggningen var lyckar eller inte är då att söka efter just denna strängen. Alltså om strängen hittas = misslyckat försök. Om man nu lägger till denna strängen även vid en lyckad inloggning (som bortmarkerad kod tex), så kommer hackerns program fortfarande att tro att försöket var misslyckat.
Det räcker kanske ändå inte i alla fall, då hackerns program kanske räknare byte eller annat också för att avgöra hur det gick.
Det finns inget direkt facit att gå efter i sådana här lägen, men en kombination av de punkter vi tar upp i artiklen försvårar i alla fall försöket betydligt.
Okej, men mitt förslag om att slänga in lite slumptal och annat kan då vara vettigt så storlek och annat blir annorlunda..?
Så ASP-sessioner är inte kopplade till IP-nummer och även om de hade gjort det så hade det inte spelat någon roll eftersom att man kan fejka IP-nummer. Enda sättet att skydda sig mot kapning av sessioner är alltså att köra SSL rakt igenom?
Ja, helt rätt. Om attackeraren använder sig av just storleken på svaret för att avgöra en misslyckad inloggning så hjälper det.
Enda sättet att skydda sig mot kapning av sessioner är alltså att köra SSL rakt igenom?
Nej. SSL skyddar faktiskt ingenting mot XSS-attacker. SSL skyddar bara den data som skickas från din webbläsare till servern.
Vid en XSS-attack hämtas ju bara ett värde upp från klienten, sen tar attackeraren detta värde och ändrar det på sin klient. Alltså inte i kommunikationen till servern.
Bästa sättet att skydda sig är att se över sin kod och kontrollera all in-data från tex. formulär, querystrings m.m.
Har förresten lagt upp en artikel till om HTTP-only cookies som kan användas för att skydda sig mot XSS. Du hittar den här
Några problem med XSS har vi inte i de lösningarna vi gör. Däremot så är det väl inte särskilt svårt att sniffa trafiken och då fånga upp kakan som skickas i varje anrop..?
Det är alltså det sista som är problemet och där ska det väl till SSL för att man inte ska kunna sniffa trafiken och fånga upp cookies?
Ok, jag trodde du menade gällande "vanlig" XSS, dvs. när man utnyttjar indata på en sida.
När det gäller SSL så är det säkrare, men inte helt säkert ändå.
Så länge dina användare surfar på din säkra sida (utan några anrop(bilder/css/osv) till en vanlig HTTP så är allt lugnt.
Men om ett anrop sedan görs till en vanlig HTTP-adress, så kommer värdet att skickas okrypterat och kan således "sniffas" upp.
En attackerare skulle då kunna lura till sig värdet ändå.
Jo, men säg att man ställer in på webbservern att sidorna endast är tillgängliga via SSL. Har ju sina nackdelar. Krävande för servern att hålla på och kryptera alla bilder och grejer och lite osmidigt för användarna att de måste skriva in https för att komma rätt.
Men det skulle väl lösa problemet med sniffning?
1. Var hittar jag en ordlista som kan användas för attack?
2. Var hittar jag ett program som kan utföra attacker?
3. Hur skapar jag fejkade sessions/cookies?
En fördel är om programmet är knutet till localhost så att det inte går att använda förutom på sin egen dator.
För det första så är chansen att en hacker skulle genomföra och lyckas med en snifferattack tillsammans med SSL väldigt väldigt liten. Först måste den hitta en användare som surfar till din sajt via SSL och loggar in. All trafik är ju sedan säker. Hackern måste sedan vänta och hoppas på att din användare surfar till en osäkersida, tex. https://www.mysite.com/page.html, utan att först ha loggat ut. Nu får hackern snabbt se till att själv svara på anropet och returnera ett falskt svar i form av en HTML-sida som gör ett anrop till en vanlig HTTP-resurs på din server. Först då kan värdet av cookien läsas.
Så, uppmana dina användare att alltid "logga ut" innan de surfar vidare, samt se till att din domän inte svarar på vanlig HTTP.
Hur gör man det då? Finns det andra sätt att hindra sniffning?
Det är inget fel på SSL, vad jag menar är att man kan minimera riskerna. Att använda SSL är jättebra och om du har skyddat dig mot XSS på de sätt som du känner till så har du förmodligen kommit väldigt långt. Men vad jag menade med att man inte bara skall lite på ett skydd är exempelvis att en brandvägg inte skyddar mot XSS, och lika lite skyddar SSL mot dåliga internrutiner. Någon kanske lämar sin dator igång över helgen. Väl där är även SQL-EM igång och städerskan kan utan problem hämta alla användares lösenord eller hemligheter. Men nu är det inte det vi skall diskutera, men det är inte heller helt oviktigt att ha bra säkerhetsrutiner internt på företaget.
Pace skrev:
Nu vill jag testa min egen säkerhet.
1. Var hittar jag en ordlista som kan användas för attack?
2. Var hittar jag ett program som kan utföra attacker?
3. Hur skapar jag fejkade sessions/cookies?
En fördel är om programmet är knutet till localhost så att det inte går att använda förutom på sin egen dator.
2. Enklast är nog att skriva ett eget eller utföra attackerna själv. Jag tror inte det finns något program som täcker alla behov och alla attacker som går att göra.
Tack för länkarna, ska titta närmare på det senare i dag.
Brimba skrev:
2. Enklast är nog att skriva ett eget eller utföra attackerna själv. Jag tror inte det finns något program som täcker alla behov och alla attacker som går att göra.
I mitt fall rör det sig om <form>ulär med method="post", ett fält för användarnamn och ett för lösenord.
Finns det program för detta måntro? Och hur skriver man ett eget? Är det bara att göra en klient som kör http-post återupprepade gånger och analyserar resultatet?
263 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
