FAQ |
Kalender |
![]() |
#1 | |||
|
||||
Mycket flitig postare
|
Okej, nu har vi gjort ett experiment på mitt community och även testat mot andra med att lura in en medlem på en länk till en extern sida - som mha javascript skickar postdata tillbaka till communityt (där användaren fortfarande är inloggad) och utför instruktioner som användaren inte är med på.
Exempel på detta är att man t.ex. kan lura in en person till en sida som gör att han ofrivilligt skickar ett PM till admin där han förklarar att han vill bli bannad - alternativt att man till och med utför en avregistrering av användaren. Mer än så behöver jag inte berätta, ni som vet vad det är hänger redan med till fullo. Jag har googlat runt på olika lösningar, och en som i 99% av fallen anses som en lösning duger inte riktigt för mig. Det folk brukar föreslå som lösning är att lägga in ett hemligt ( = slumpat) id i formuläret som måste finnas med då postdatan tas emot. Detta gör det lite svårare för "hackern" då han måste gräva fram detta id för att kunna skicka sin postdata. Men en sak han faktiskt kan göra är ju att först av allt öppna ursprungsformuläret - gräva fram detta id, sedan skicka sin postdata. Så att säga - allt som är tillgängligt för användaren är tillgängligt för hackern, eftersom han kan ladda vilken sida han vill. Jag använder den lösningen idag, så hackern har det lite klurigt, men informationen finns tillgänglig i ursprungsformuläret, så han kan gräva fram det mha lite regexpskills. Det jag helst vill göra är ju att bara ta emot postdata från min egna domän, men hur gör jag det? Jag har fått för mig att vbulletin gör så (efter lite googlande), men jag förstår inte hur de får fram den informationen. Postdatan kommer ju från mottagaren oavsett om han gör det manuellt eller om det är hackat. Så vad är det jag kan läsa av som identifierar hackern? Tack för svar! |
|||
![]() |
![]() |
![]() |
#2 | |||
|
||||
Mycket flitig postare
|
Går det inte att editera inlägg här?
Aja, jag tror jag har en lösning... Min lösning med id var baserat på att det inte slumpas vid varje sidladdning, utan att det är kopplat till användarid och lite sånt. Det uppdateras vid varje inloggning. Men om man ser till att nyckeln genereras vid varje sidladdning, och sätts i sessionen för användaren så kan man nog garantera att ingen annan får det. Om man med script anropar sidan med urspringsformuläret så generaras en ny nyckel som då inte är samma som den som redan är satt i användarens session, då borde det nog bli kört. |
|||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Supermoderator
|
Beror på vad du menar med script. Ett javascript som körs på användarens dator använder förmodligen samma session.
__________________
Jonny Zetterström se.linkedin.com/in/jonnyz | bjz.se | sajthotellet.com | kalsongkungen.se | zretail.se | zetterstromnetworks.se | webbhotellsguide.se | ekonominyheter24.se | nyamobiltelefoner.se | gapskratt.se | antivirusguiden.se | jonny.nu |
||
![]() |
![]() |
![]() |
#4 | |||
|
||||
Mycket flitig postare
|
ja, det använder samma session.
För att uppdatera lite igen så har jag dragit slutsatsen att det inte går att bli helt 100% säker med denna metod. Jag hoppas att det går på något annat sätt, men jag litar inte riktigt på det. Allt som användaren kan komma åt manuellt är ju också åtkomligt för javascriptet, eftersom de ur serverns perspektiv inte skiljer sig från varandra. Jag har gett upp hoppet för en vattentät lösning. Det som gäller är att försöka jävlas så mycket det bara går med hackern. Jag har iaf enligt uppgift ett säkrare community än både phpbb och vbulletin, kanske får det räcka. ![]() |
|||
![]() |
![]() |
![]() |
#5 | ||
|
|||
Supermoderator
|
För värre saker som att avregistrera sig skulle du kunna bygga en captcha-funktion också. "Är du säker på att du vill avsluta ditt konto? Mata in koden nedan"
__________________
Jonny Zetterström se.linkedin.com/in/jonnyz | bjz.se | sajthotellet.com | kalsongkungen.se | zretail.se | zetterstromnetworks.se | webbhotellsguide.se | ekonominyheter24.se | nyamobiltelefoner.se | gapskratt.se | antivirusguiden.se | jonny.nu |
||
![]() |
![]() |
![]() |
#6 | |||
|
||||
Mycket flitig postare
|
Hmm, ja, då jäklar gör man det svårt för hackarn... Så kanske jag gör. Bra grej!
|
|||
![]() |
![]() |
![]() |
#7 | |||
|
||||
Mycket flitig postare
|
Citat:
Däremot kan det förstås vara bra att ha en "Är du säker"-sida (eventuellt med nytt slumpat koll-id). Då måste ju "förövaren" åtminstone skicka en request, vänta på svaret, bearbeta och skicka en request till - blir ju i alla fall lite jobbigare. Det borde åtminstone sätta stopp för de flesta spambottar som försöker spamma ner med länkar etc. totoo: Varför är det så himla viktigt? Har du haft problem med attacker? Klagomål? Annars behöver man ju inte anstränga sig så oändligt. Det blir ALDRIG helt säkert i alla fall. (automatiska captcha-knäckare finns det också – som dessutom är träffsäkrare än människor!) I ditt fall verkar det som du syftar på någon enveten angripare som riktar in sig på just ditt forum och det är ju ganska ovanligt. Intressant säkerhetshål för övrigt. Du kanske kan använda HTTP_REFERER för att ytterligare försvåra. Är väl heller inte helt säkert… |
|||
![]() |
![]() |
![]() |
#8 | |||
|
||||
Mycket flitig postare
|
Halloj.
Generellt så är jag väldigt noga med det jag gör, detta till stor del pga bakgrund i spelindustrin och c++, så det är väldigt mycket i webbvärlden som ger mig smärre hjärtattacker. Det hela är en lång historia, men i alla fall så arbetar jag med ett community som kommer öppnas under nästa år och vi har lagt mycket tid och pengar på att konstruera detta och har som målsättning att slå väldigt väldigt hårt. Vi ska ligga i alla fall 10 i topp på svenska communities i användarantal efter ett halvår, helst ett kvartal. Hur som helst så sätter jag den tekniska ribban så högt som jag bara kan, för jag vill inte att något litet bagatellhål ska sabotera det kanske mest potentiella projektet jag någonsin arbetar med, så det är där skon klämmer. Men just nu har jag i alla fall för tillfället lagt detta problem på hyllan. Jag genererar ett id som måste finnas med när postdatan skickas. Om hackern vet vilken sida besökaren ska gå till för att t.ex. hitta sina inställningar så kan han gå dit, sno nyckeln och skicka den med sin postdata, men nu går det inte längre att bara skicka postdata rakt till mottagaren utan idt i alla fall, bara det hjälper ju jättemycket. Om jag sedan kommer bli angripen eller inte vet jag inte, men jag vill arbeta i förebyggande syfte så mycket som det bara går, jag vill inte lösa problemet efter att medlemmar mailar å gnäller över att deras profilsidor är raderade. Jag vet inte om jag kan använda REFERER till något, för det är väl browsen själv som skickar denna? Och vad jag vet kan både browser och brandvägg se till att dett aldrig kommer fram, då blir det klurigt. Men den kanske hjälper någorlunda iaf. |
|||
![]() |
![]() |
![]() |
#9 | |||
|
||||
Mycket flitig postare
|
Citat:
Kanske du ska fundera på att kräva användarnamn och lösenord över https med alla requester som gör något dramatiskt. (jag vet inte hur du sköter inloggningen i övrigt men kräver man lösenord med samma request så borde det väl vara svårt att komma runt sålänge användarna inte är korkade nog att själva skriva in sin lösen på bluffsidan) |
|||
![]() |
![]() |
![]() |
#10 | ||
|
|||
Medlem
|
Ett komplement till att använda form eller sessions id vore att be användaren ange sitt lösenord
när han vill ändra något drastiskt, till exempel radera sitt konto. |
||
![]() |
![]() |
Svara |
|
|