fredrik: Ok, låter bra.
Brimba: Jag menar inte att så fort man kör med SSL så är allt säkert. Vad jag frågade var om det var den bästa (enda?) lösningen för att förhindra just sniffning.
Diskussioner kring det Swesecure tar upp
38 svar · 1 692 visningar · startad av Erik Juhlin · sida 2 av 2
Frågan, av Erik Juhlin
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
Läs frågan i sin helhet →Pace:
Om du kan koda PHP, VB, VBScript eller liknande så finns det oftast metoder för att göra postningar mot sidor.
I VB finns objektet XMLHTTP där man även kan ange POST-parametrar.
Sen gör du bara en applikation som loopar igenom ordlistan och stoppar så fort den får den får ett annorlunda svar.
Pace skrev:
Finns det program för detta måntro?
Vad är det du vill kontrollera?
Dictionary attacks? I så fall brukar man som attackerar först ta reda på ett användarnamn och sedan kan man bygga sitt program att läsa av resultatet allt eftersom man postar in olika lösenord, det är nog inte aktuellt att försöka gissa både användarnamn och lösenord.
Men om du menar mot sql-injection så kan du testa detta själv relativt enkelt. Sedan vet du säkert hur din kod bakom ser ut och vet kanske även då hur du hanterar inparametrar.
Men beskriv gärna mer i detalj vad det är du vill prova.
Läs gärna vår artikel om sql-injection
http://www.swesecure.com/?ID=dc6ea60a-12ae-4e7e-9e9c-59489ccafa90&IID=29a58b01-ca79-4877-b924-4f5da18d4a2a
Erik Juhlin skrev:
Brimba: Jag menar inte att så fort man kör med SSL så är allt säkert. Vad jag frågade var om det var den bästa (enda?) lösningen för att förhindra just sniffning.
Ahh, då förstår jag!
Jo eftersom värdet av sessionsnyckeln skickas i headern är det svårt att göra så mycket annat.
Hur är det med SSL när man skickar saker i querystringen. Går det att sniffa det eller är det lika dolt? (förutom att man ser det ganska tydligt i webbläsaren)
POST/GET krypters, men det är ändå generellt sett ett dåligt ställe att placera känslig information på.
Umm, what?
Jag menar inte att jag vill dölja saker för användaren. Jag vill dölja saker för utomstånde snortare.
Jo, men som utomstående får man kanske även räkna webbserveradministratören som läser loggarna? Det är stor risk att iaf querystrings sparas i webbloggar. Det var mer en generell upplysning.
Men det skall inte gå att sniffa querystrings om du kör SSL.
Erik Juhlin skrev:
Pace:
Om du kan koda PHP, VB, VBScript eller liknande så finns det oftast metoder för att göra postningar mot sidor.I VB finns objektet XMLHTTP där man även kan ange POST-parametrar.
Sen gör du bara en applikation som loopar igenom ordlistan och stoppar så fort den får den får ett annorlunda svar.
Jo, det var det jag undrade med "Är det bara att göra en klient som kör http-post återupprepade gånger och analyserar resultatet?"
Brimba skrev:
Vad är det du vill kontrollera?
Trodde jag skrev det ganska tydligt:
"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."
Alltså ett webbformulär för inloggning där jag vill köra dictionary attacks. Men jag ska testa att göra ett litet .net-program som försöker penetrera mina sidor, får se ifall jag har någon timme över någon gång. :e
SQL-injection har jag känt till länge och är bland det första jag brukar kontrollera, liksom farlig <html>-taggning, lägga in diverse text i querystrings m.m.
Pace: Jag läste nog inte tillräckligt nog. Sorry!
Egentligen så är väl XSS inte farligt förrens man kan spara det så att en annan användare får upp det. Är det bara en själv det påverkar så spelar det ingen roll. Visst, man kan sätta cookies. Men det kan man göra ändå. Lite krångligare bara.
Egentligen så är väl XSS inte farligt förrens man kan spara det så att en annan användare får upp det.
I vilket avseende tänker du då?
Med XSS så luras ju (oftast) dina användare att skicka ifrån sig värdet i cookien?
Jo, men då gäller det att den farliga koden ligger lagrad så att ett offer kan visa upp den.
Är den inte lagrad utan bara visar sig genom en querystring så kan hackern bara manipulera sina egna cookies. Vilket han kan ändå även om det är lite krångligare.
Man ska väl försöka skydda sig mot det också, men det är ju främst där en hacker kan lagra data som någon annan sen visar. Som i t.ex. forum.
Kom att tänka på det. Har inte wF ett XSS säkerhetshål i.o.m. "Mina filer"?
http://member.webforum.nu/Erik Juhlin/cookie.html
Erik Juhlin skrev:
Kom att tänka på det. Har inte wF ett XSS säkerhetshål i.o.m. "Mina filer"?
http://member.webforum.nu/Erik Juhlin/cookie.html
Jo det verkar uppenbarligen så.
Ja, helt klart är det så, eftersom jag postar som "Brimba" nu, fast det egentligen är jag "Fredrik" som skriver :)
Oops. Jag provade själv i Mozilla, men jag fick aldrig till det riktigt. Vet inte om det berodde på att user agenten skiljde sig...
Oops, mina filer funktionen inaktiverades snabbt där. :)
Tack för hjälpen Erik!
Angående sessionskapning, igen...
Smågammal tråd detta men jag tyckte den var passande så jag bygger vidare i den. Jobbar i ett projekt där användare registrerar sig med personuppgifter, samt loggar in med sina användare för att genomföra köp och dylikt. Implementerar de flesta säkerhetsrutiner som beskrivits i denna tråd. Utöver det tänkte jag mig följande uppbyggnad:
SSL är ju onödigt att använda för hela sajten ur prestandasynpunkt. Därmed är det uteslutet att använda SSL på varje sida som användaren besöker efter inloggning (som är samma sidor som de man besöker utan inloggning med enda skillnaden att man är inloggad) och skydda användarens session från kapning. Men om man lägger in en kontroll av lösenordet för användaren (över SSL) vid varje "känslig" operation, t.ex. ett köp eller när användaren vill visa sina personuppgifter, så finns det väl helt enkelt inte längre intresse av att genomföra sessionskapning? Det "farligaste" attackeraren kan göra efter kapningen är ju att logga ut den riktiga användaren, allt annat krävs det ju lösenord för, t.o.m. för att se personuppgifterna för användaren!
Finns det några nackdelar med denna metod? Utöver att användarna måste uppge sitt lösenord oftare (men det tvivlar jag att de har något emot).