Just nu i M3-nätverket
Jump to content

hindra oberhöriga, referer


hugoni

Recommended Posts

Hej!

 

Jag undrar om någon har bra tips/lösningar på hur man skyddar ett CGI-script på en server så att ingen annan kan länka till scriptet från sin webbplts och därigenom dra nytta av mitt script. En sådan säkerhetsfix finns i formmailer.pl, men den bygger på HTTP_REFERER och den fungerar dels dåligt och är dessutom osäker.

 

Provade med $ENV{'HTTP_REFERER'} och för vissa fungerar det. En del användares webbläsare skickar inget värde och strängen blir tom, lite trist om scriptet inte kan användas av dessa användare. Att det inte fungerar beror på att vissa webbläsare blokerar den här informationen från att skickas till servern, en del har dessutom brandväggar som stoppar informationen. Till på köpet är det relativt enkelt att "spoofa" en adress och andå få åtkomst av scriptet.

 

Så min fråga lyder hur man kan stoppa sådan här länkning och användning av scriptet. Jag vill att endast sidor inom min webbdomän ska kunna köra scriptet, så fort någon försöker länka sig mot scriptet utifrån min domän nekas tillträde. Hur kan mn lösa detta om inte HTTP_REFERER fungerar idag, alla skriver att det är osäkert och inte fungerar, ja det är bevisat, men hur löser man problemet egentligen?

 

 

Tack på förhand!

\\ hugoni

 

[inlägget ändrat 2004-11-02 11:45:10 av Hugo Nissar]

Link to comment
Share on other sites

Så min fråg lyder hur man kan stoppa sådan här länkning och användning av scriptet.

Det enda säkra sätt du kan få reda på varifrån ett script länkas är just genom att titta på den header som används för att berätta varifrån man kommer och det är referer-headern. Headern finns där för det syftet och det syftet alena, om det finns användare som strippar den så tycker jag de kan få skylla sig själva.

Naturligtvis går det att lura den som helt förlitar sig på referer men så är det alltid.

 

Ett alternativt sätt (vilket inte känns som nåt man skulle vilja göra i en cgi-lösning om man slapp) är att införa ett förenklat sessions-koncept där du sätter en sessions-kaka första gången en användare tittar på din sida utan kakan. Därefter kan du utan problem spåra när användaren var hos dig senast (och om han/hon varit hos dig sen han/hon startade om sin webbläsare) och baserat på det avgöra om det är ok att köra scriptet eller inte.

Men ett filter som är korkat nog att spärra bort referer lär nog spärra bort kakor också.

[inlägget ändrat 2004-11-02 11:53:09 av fhe]

Link to comment
Share on other sites

Så min fråga lyder hur man kan stoppa sådan här länkning och användning av scriptet. Jag vill att endast sidor inom min webbdomän ska kunna köra scriptet, så fort någon försöker länka sig mot scriptet utifrån min domän nekas tillträde. Hur kan mn lösa detta om inte HTTP_REFERER fungerar idag, alla skriver att det är osäkert och inte fungerar, ja det är bevisat, men hur löser man problemet egentligen?
Ett förslag skulle ju vara att lägga ett skript i början av din sida som helt enkelt noterar ip och klockslag. Sedan är det okej för den IP-adressen att köra ditt skript under en viss tidsperiod. Problemet är ju (eftersom jag antar att ditt skript genererar webbinnehåll, att det fortfarande kan missbrukas eftersom det går att hämta innehållet.

 

Du kan också kontrollera så att ingen IP-adress överanvänder skriptet, dvs kan du till exempel max tillåta X antal förfrågningar per dag och IP-adress.

 

Återigen ställer detta till det när det gäller folk som sitter bakom en proxy tex.

 

 

.dune.

----------------------------------------------

- "I find this a nice feature but it is not according to the documentation.

Or is it a BUG?"

- "Let´s call it an accidental feature. :-)"

 

Link to comment
Share on other sites

Hej, tack för svar!

 

Jo jag tyckte också att det var korkat att spärra denna header-information men det är uppenbarligen väldigt vanligt idag. Opera har till och med ett val som möjliggör att användaren stoppar den här informationen. Norton Internet Security blokerar bland annat den här informationen.

 

Jag har kikat på en cookielösning och det är nog sant som du säger. Folk som vet vad de gör när de skyddar sig spärrar även den informationen. Sen finns ju skaran som kör Internet Security m.fl utan vetskap om problemet.

 

Link to comment
Share on other sites

Ja det luriga är att cgi-scriptet presenterar en webbsida och bör kunna användas av alla, hur många gånger som helst men bara från användre på min sida. En perfekt lösning är då HTTP_REFERER, men som sagt. Vet inte hur andra löser problemet, för de måste ju lösas dagligen tycker man.

 

Jag har försökt leka lite med location och JavaScript. Som det ser ut nu så måste cgi-scriptet hur som helst laddas inom mitt ramverk (frames), annars öppnas huvudsidan. En klen tröst då användaren som länkat in sig hur som helst får upp informationen.

 

Link to comment
Share on other sites

Folk som vet vad de gör när de skyddar sig spärrar även den informationen.

Jag skulle nog se det som att "folk som INTE vet vad de gör när de skyddar sig".

Att spärra sessions-kakor är bara korkat, de gör aldrig skada och tillför bara mervärde.

 

Det är svårt att ge bättre förslag på lösningar utan att veta mer om sajten. Om allt är CGI-genererat så är det ju betydligt lättare att hantera. Då skulle du kunna låta ett sessionsid gå på URL:en (och naturligtvis neka sessioner som gått ut).

 

Om du har användare som spärrar referer och sessionskakor så finns det lixom väldigt få generella medel kvar. Är det känslig info får du väl lösa det med vanlig http-inloggning.

Om problemet är att du är rädd för att andra lägger länkar till ditt script på sina sajter så lär de i vart fall inte kunna förfalska referer-adressen (den sätts av klienten, inte av den som länkar) så det skulle förmodligen vara fullt tillräckligt att kolla referer och helt enkelt vägra om den inte är tom eller rätt. Ingen skulle lägga ut en länk till någon annans script om 99% av användarna (eller fler) möttes av ett felmeddelande.

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.



×
×
  • Create New...