Formulär

Hej,
Hur förhindrar man att någon annan domän eller sida postar data till en php-sida som tar emot data från ett formulär som är i min webb?

Ta sidan (i den här webben) där man kan posta och skapa en ny tråd. Finns det något som förhindrar mig från att skapa ett motsvarande formulär i min webbsida och från den posta in i webbforum.nu? Förutsatt att jag simulerar alla fält inklusive gömda.

Tack på förhand...

PS: Jag är inte intresserad av HTTP_REFERER. Jag har ett hum om hur jag ska göra men vill veta hur man normalt löser problemet.

Det är normalt inget problem då det ligger lite i sin natur att det inte går att posta från andra servrar. Dels beroende på att det inte längre är den lokala webbservern som exekverar skriptet och därmed ingen filaccess och dels för att MySQL inte tillåter anslutningar utifrån.

Har du problem med detta så är det dags att se över komfigurationen. Kontrollera att du endast tillåter mysql-användare att ansluta via localhost.

test

test

Hej Kjell,
Jag tror inte att jag har kunnat förklara problemet så bra för ditt svar berör inte problemet, ursäkta. Jag ska förtydliga mig.

Inlägget innan (test) är gjord av mig, via ett formulär där jag har kopierat och klistrat in nödvändiga inputfält från sidan "newreply.php" till en egen sida. Via den här sidan, som ligger på min webbserver, skrivit in "test" som rubrik och "test" som brödtext och klickat på knappen "Skicka svar". Formuläret postar sidan nu till "http://www.webforum.nu/newreply.php" som accepterar indata utan problem och lägger den externa formulärets data in i webbforums databas.

Kan man inte förhindra detta? Det vill säga, sidan "newreply.php" accepterar bara indata från sidor som har sina "rötter" i webbforum.nu och neka "post" från "främmande formulär".

Hoppas att jag har kunnat förklara problemet bättre...
Vänligast

I ditt script kan du kolla om $_SERVER['SERVER_ADDR'] är rätt ip eller om $_SERVER["HTTP_HOST"] stämmer överens med din adress.

Nej, man kan inte förhindra det eftersom det inte är skriptet som postar, utan det är besökarens webbläsare.

$_SERVER['SERVER_ADDR'] finns inte och $_SERVER['HTTP_HOST'] är irrelevant.

Du verkar ha förstått problemet. Det är riktig, $_SERVER['SERVER_ADDR'] och $_SERVER['HTTP_HOST'] är irrelevanta för jag har inget PHP som postar något. Det är webbläsaren som postar.

Jag uppskattar svaret men hoppas att någon ska komma med ett förslag till lösning.

Filen http://www.webforum.nu/newreply.php har ju till uppgift att posta inlägg på wF från besökare och kan inte riktigt förstå varför man vill förhindra detta?

Kan du ge ett konkret exempel på ett fall där det skulle innebära ett problem för dig. Jag misstänker att eventuella problem kan förebyggas med andra åtgärder.
Det skulle i.o.f.s. vara möjligt att först försöka kontrollera vilken sida besökaren kommer ifrån innan man godkänner postning i exempelvis newreply.php.
I vissa fall kan det dock ställa till med problem om man t.ex. får en länk via e-post och dyligt.

Hej igen,
Exempel i WF's fall:
1. Jag skulle kunna skapa en webb kallad, säg masterForum.se. Via den här webben kan jag låta mina besökare ställa frågor om utveckling. När denne klickar på knappen "posta inlägg" så skulle min formulär kunna posta "frågan" till alla utvecklarforum såsom webforum.nu, phpportalen.net, phpsidan.nu, etc.
Med lite finurligt DHTML-programmering skulle jag dessutom kunna läsa av sidorna (skrapa data) och eventuella svar och plocka in dessa och presentera svaren på masterForum.se.

<!-- Nu kanske några protesterar om att man inte kan göra det...det går. Jag fick idén för ett par år sedan och testade genom att "skrapa" data från en känd filmsajt ;-). Jag lät min dator skrapa av information om > 20.000 filmer över en natt. På så sätt fick jag information om titel, handling, skådisar, genre samt bild på "fodralet" (liten och stor). På så sätt skulle jag kunna starta en filmsajt, CD-sajt eller liknande utan att lägga in informationen i databasen själv. Man kan säga att jag replikerade databas-tabellen via http. //-->

2. Det som finns i punkt 1, är kanske inget man vill förhindra men man skulle kunna "skanna" databasen genom att posta till inloggningssidan. Användarnamnen är ju kända, så man kan låta ett DHTML-skript testa olika lösenord och posta det till inloggningssidan. Om det är rätt lösenord så kommer man ju till ett speciellt sida och när det är fel så kommer man till en annan.

Nu kanske exemplet är extrem och skulle kräva lång tid för eventuella skanningar. Men det finns andra områden där man skulle kunna skanna databas till min fördel och server tillhandahållarens nackdel.

Du nämner att man skulle kunna kontrollera vilken sida besökaren kommer ifrån innan man godkänner postning. Betyder det HTTP_REFERER? Den är som du vet osäker och inte bra lösning. Men du kanske tänkte på något annat !?

I mitt fall vill förhindra post från främmande formulär för att bl a förhindra skanning. Jag vill heller inte ha "skräp" i databasen.

Det är enkelt att kolla vilken sidan man kommer ifrån och använder det själv på en av mina sidor.

Jag använder, som så många andra, en include-fil som innheåller exempelvis databas-kopplingen osv. I den har jag också en kod som håller koll på:
$_SERVER['HTTP_HOST']
$_SERVER['SCRIPT_NAME']
$_SERVER['QUERY_STRING']

Dessa värden använder jag för att skicka en besökare tilbaka till sidan man tidigare befann sig på om man väljer att logga in mitt i allt.
Tillsammans kan dessa få ett värde som ser ut så här

[url]www.webforum.nu/newreply.php?action=newreply&threadid=120566[/url]

som du sedan kan använda för att kontrollera. I ditt fall räcker det antagligen med att ha koll på $_SERVER['HTTP_HOST'] men du kan inte använda den globala variabeln direkt och jämföra med utan får skapa en egen där du tilldelar värdet.
$min_host = $_SERVER['HTTP_HOST'];
Namnet på variabeln bör inte vara känd för då kan man ju skicka med den också. Alternativt sparar du den i besökarens session.

Men som nämnts tidigare, nackdelen är att man inte kan posta genom att direkt gå till den aktuella sidan, via favoriter, e-post eller liknande.

[r]
Funderar lite och i ditt fall måste du nog använda dig av sessions. Jag presenterar ju mina på forumlärssidan i hidden-fält och det är ju inte så praktiskt i ditt fall.

Lägg det i en session
$_SESSION['host'] = $_SERVER['HTTP_HOST'];
Existerar den inte eller inte stämmer med din host så får man inte posta.
I newreply.php skulle man exempelvis kontrollera det med

if (isset($_SESSION['host']) AND $_SESSION['host'] == $_SERVER['HTTP_HOST'])
	// Ok
} else {
	// Ej ok
}

Ska man nu vara ärlig så skulle man ju i.of.s. kunna anropa en sida i en dold frame och på så sätt sätta en session som faktiskt kommer från den riktiga webbplatsen.

Jag går nog tillbaka till min första idé och det är att vi tänker fel här och problemet måste angripas på ett annat plan.
Så länge det är en webbläsare som agerar så gör våra filer exakt vad vi kodat dem att göra och jag ser egentligen inget problem med det.
Begränsningen av vad man får göra och inte får göra styrs av dessa filer och däri måste också kontrollen göras.

I ditt fall är du orolig över skanning av databasen efter lösenord. I vBulletin 3, som wF ska uppgraderas till, tillåter man endast ett X antal inloggningsförsök och sedan blir sidan oåtkomlig i X antal minuter, allt beroende på vilka inställningar som valts.

Kort och gott, man får helt enkelt koda sina egna skript så dessa sätter de gränser och säkerhet man vill uppnå. Det verkar ju också vara det mest logiska.

tydal skrev:

Nej, man kan inte förhindra det eftersom det inte är skriptet som postar, utan det är besökarens webbläsare.

$_SERVER['SERVER_ADDR'] finns inte och $_SERVER['HTTP_HOST'] är irrelevant.

Nu kollade jag visserligen bara snabbt men ta du dig en titt längst ned här: https://www.qimen.net/info.php så ser du att SERVER_ADDR finns visst. Men jag erkänner att jag tänkte lite fel nu (satt och jobba med lite ett cronjobb innan och då använde jag bl.a. dessa).

Men annars finns ju $_SERVER['HTTP_REFERER']...

Inget är säkert, men...

I ditt fall är du orolig över skanning av databasen efter lösenord.

Faktiskt så är jag inte orolig för skanning av databasen därför att servern svarar inte genom att slussa klienten till två olika sidor. Den inloggning som jag ska programmera är en variant av CHAP-login (Challenge-Handshake Authentication Protocol).

Du känner säkert till detta protokoll men för de som inte gör det följer nedan en beskrivning av hur jag hade tänkt att det ska gå till.

Först bör jag nog avslöja att alla sidor som skall vara skyddade finns i ett lösenordsskyddad folder.

Detaljerat:
1. Användare kommer till inloggningssida, där han får ange användarnamn och lösenord.
2. Vid "submit" skickas från formuläret bara användarnamnet till servern som i sin tur gör en sökning i databasen efter användare med emottaget användarnamn och får reda på användarens lösenord.
3. Servern använder användarens lösenord som nyckel när denne krypterar lösenordet till det skyddade foldern och svarar klienten med en krypterad massa.
4. Klienten tar emot krypterade massan och försöker dekryptera det genom den inmatade lösenordet (identisk algoritm som serverns). Om dekrypteringen lyckas, slussar klient-skriptet sig själv vidare till det skyddade foldern och anger automatiskt användarnamn och lösenord till den skyddade foldern (som är helt annan än användarens anvNamn och lösenord.).
5. Sista men det viktigaste steget. Lösenordet till det skyddade foldern ändras med helt slupmässiga tecken som är säg 12 tecken lång. Och andra som loggat in tidigare påverkas inte av lösenordsändringen (genrell regel som råder på webbservrar). Observera, lösenordet ändras efter att användaren kommit in i foldern och aldrig innan. Om användaren anger ett felaktig lösenord så ändras inte lösenordet.

Som rubriken avslöjar, så är inget säkert. Även CHAP-login har säkert sina brister men jag tror att det gör det svårare att "hacka" in. Dessutom, som du märker så skickas inte användarens lösenord alls till servern. Lösenordet till det skyddade foldern skickas till klienten men i krypterad form och är dessutom "engångsnyckel".

Men vid steg tre måste jag veta att formuläret och indata (förfrågningen) inte kommer ifrån en främmande formulär.

Min oro är något helt annat...och jag anser att det är befogat. Så pass att jag inte ens vågar avslöja varför. (Usch vad dramatiskt det blev :-)

Qimen skrev:

Men annars finns ju $_SERVER['HTTP_REFERER']...

HTTP_REFERER är praktiskt för saker som bekvämlighet för besökaren men sämre om man vill använda det av säkerhetsskäl eftersom det är klienten som ger servern informationen och inte tvärt om. Klienten är inget alternativ när man vill uppnå hög säkerhet.

hbi99 skrev:

2. Vid "submit" skickas från formuläret bara användarnamnet till servern som i sin tur gör en sökning i databasen efter användare med emottaget användarnamn och får reda på användarens lösenord.

Är inte det en miss med tanke på den säkerhet du vill uppnå? Nu vet jag inte all bakomliggande kod men tycker nog att detta ser ut som en flaskhals i säkerhetssystemet. Det är väl inget som hindrar att du jämte användarnamnet samtidigt jämför lösenordet innan du använder den som nyckel i nästa steg, alternativt har en 3:e nyckel som genereras och skickas tillbaka till klienten. Jag förmodar att du kör SSL så inget skickas i klartext.

Använder man en vanlig webbläsare och serverns filer så kan man förmodligen alltid simulera ett förutbestämt senario med en klient och främmande server. Lösningen ligger troligen i att försöka koda bort eventuellt upprepade försök eller vad det nu må vara i ditt fall. Någon form av mönster brukar det ju röra sig om vi hackningsförsök och det är nog där du får koncentrera koden.

Bäst är förmodligen att skippa åtkomst via webbläsare och använda en helt egen klientvara men det kanske är att överdriva en aning.

Jag tror att "Qimen" missade det men jag skrev redan i mitt första inlägg att jag inte är intresserad av HTTP_REFERER.

Jag anser inte att det kommer att bli en flaskhals eftersom det är egenligen inte så mycket mer (om inte mindre) än vid vanlig loggin system. Dessutom efterföljande förfrågningar är smidigare i jämförelse med vad som är "standard". Vidare så "distribuerar" jag arbetet till klienterna. M a o, så skickar jag data i XML format och och XSL-mallar så klienterna får själva rendera presentationen.

Varför använda SSL (onödig i det här fallet iaf)? Användarnamnet kommer att vara publik/känt. Dessutom SSL, om något, skapar flaskhals i sig eftersom förfrågningarna tar längre tid då allt måste krypteras/dekrypteras av båda noderna. Säkerheten ligger i att inte skicka användarens lösenord över nätet. Krypterad eller okrypterad så är det säkerhetsrisk att skicka den över nätet.

Egentligen så eliminerar CHAP-login upprepade försök, vid steg fem. Lösenordet till den skyddade foldern ändras hela tiden så spelar det ingen roll att man hackar in med upprepningsmetoden, det är meningslöst.

En distribuerad klient-mjukvara...den tanken har jag sållat bort. Fördelen med webbläsare är att alla datorer har en. Nackdelen med en distribuerad program är att klienterna måste tanka ner och installera den. Om jag dessutom uppdaterar den måste den distribueras igen. Dessa egenskaper vill jag inte ha. (Banker använder webläsare i sina lösningar...om det är ok för de så är det ok för mig)

Du skulle kunna använda dig av någon form av kontrollvärde i ett dolt fält i formuläret. Detta värde ska ändras kontinuerligt för att det ska bli svårt att replikera. Ex. så kan ditt kontrollvärde bestå av en md5-hash på aktuell tidpunkt (avrundning till närmsta 5-minuters intervall är nog lämpligt) kombinerat med ett hemligt salt. Hashen kontrollerar du sedan på sidan som tar emot inloggningsuppgifterna. Stämmer den inte så får man logga in på nytt. Visst kommer en del "riktiga" inloggningar få göras om för att vi ex. har passerat nästa 5-minutersintervall, och visst går det fortfarande att logga in (fast då måste man kontrollera md5-hashen med jämna mellanrum) remote. Men det försvårar ju iaf...

Skulle det inte fungera med sessions om du varje gång man går in på lösenordssidan genererar en slumpmässigkod säg 10tecken lång som sparas i sessions och i ett formulärfält.
Varje gång man laddar om login in sidan ska detta värde ändras.
Dessutom kan du på samma sätt slumpa namnet på forumlärfältet vilket borde göra det svårt att ansluta utifrån