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!

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.

Beror på vad du menar med script. Ett javascript som körs på användarens dator använder förmodligen samma session.

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. :)

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"

Hmm, ja, då jäklar gör man det svårt för hackarn... Så kanske jag gör. Bra grej!

Är hursomhelst inte helt säkert. Var uppe tidigare här i nån tråd. Däremot enormt frustrerande för användaren.

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…

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.

Ja, nog är det browsern som skickar den (jag är inte särskilt insatt i hur HTTP funkar rent praktiskt), men om en angripare vet att du kollar och förväntar dig att rätt REFERER kommer med (jag kan inte tänka mig att den försvinner i brandväggen eftersom den är en del av requesten, men som sagt, inte mitt område). Angripare struntar nog ofta i att skicka någon REFERER men såvitt jag förstår skickar i alla fall webläsarna den.

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)

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.

XSS attacker är alltid tråkiga men generellt sätt så kan en attackerare göra precis allt som en vanlig användare kan, med undantag för CAPTCHA eller något som kräver dens lösenord. Givetvis kan även captcha knäckas, men det försvårar nämnvärt.

Men då du bygger sidan från grunden skulle jag lägga mycket prioritet på att inte tillåta javascript från användare. Generellt sätt kan man tvinga (framförallt) IE att köra javascript på en rad sätt och även större communities (playahead, snyggast, anstalten m.fl.) har visat sig vara sårbara på en eller flera punkter där.

Skrev för övrigt en artikel om samma ämne och hur man som programmerare för ett community kan skydda sig för A List Apart, adress http://www.alistapart.com/articles/secureyourcode och http://www.alistapart.com/articles/secureyourcode2

Mycket av det om står ska en webmaster redan veta men med lite tur kan de flesta lära sig något nytt. Vid intresse kan ni med fördel kolla in diskussionen som följde då det kom upp flertalet bra poänger där.

Mvh/ Niklas

Tack folk!

Det där med att skriva in sitt lösenord är kanske grejen. Jag ska fundera på vad det har för innebörder.

Bivald, xss är faktiskt inte problemet i detta fall, det är jag väl skyddad emot, detta gäller ju externa länkar - där personer skriver en länk i forumet "kolla min fina bild" - sedan har de ett javascript på SIN site, så nu blandar du ihop problematiken lite.

Men jag ska ändå titta på dina länkar imorrn, det finns säkert något matnyttigt ändå.

Du kanske kan använda tekniken jag beskriver i min lilla text på http://www.netrogenic.com/public/linkprotection/
Om du modifierar tillvägagångssättet lite dvs.

Referer går enkelt att tabort för "sekretessskäl".

Men alternativet man kan göra istället är att skapa en "egen" referer. dvs. mer eller mindre addera lite data (token) per http request i en cookie. Denna jämförs sedan med den som sparades på serversidan. Det negativa med detta är att det tar en del kraft.

Rekommenderar ej att använda IP-adress eller user-agent då dessa kan förändras genom att vissa ISP:er vill spara bandbredd(proxy servrar som cachar vanliga http requests el dyl. har inte riktigt koll på proceduren) och därmed skicka andra ip-adresser respektive user-agents. Vet inte riktigt hur vanligt detta är men det förekommer.

För dom som inte använder ett liknande verktyg så rekommenderar jag firefox tillägget "Tamper Data" vilket gör att ni kan testa era webbapplikationer enkelt.