Acties via url veilig?
Ik zit met een vraag, is het veilig om acties uit te voeren via de url op een beveiligde pagina.
Dus stel ik wil een pagina aanpassen dan staat er in de url index.php&action=save-content&id=1. Als de gebruiker dan nu een 2 bij id invult dan wijzigt er een andere pagina, wat niet zo erg is wan het zijn zijn eigen pagina's. Maar als de gebruiker bezig is en halverwege per ongeluk op f5 drukt wordt dit ook meteen opgeslagen.
Zo zijn er natuurlijk meer voorbeelden, maar het gaat er om of dit veilig is en gebruikelijk??
Alvast bedankt
GET - het verkrijgen van data van de server
POST - het verzenden van data naar de server
Als je deze vuistregel gebruikt zal je dus updates en inserts altijd via post requests doen. Ook is een post beter omdat je dan geen limiet hebt aan het aantal karakters dat je kunt versturen, wat bij get wel zo is. Het probleem van een veranderd id in de url ben je bij post ook kwijt. Kwaadwillende kunnen het zonder veel probleem nog steeds doen, maar per ongeluk zal het niet gebeuren.
GET requests behoren gebruikt te worden om data op te halen / verkrijgen (to GET). POST requests zijn bedoeld om data te manipuleren. Opslaan acties behoor je eigenlijk dus niet te doen via een GET request, maar via een POST request met een formulier.
Ik wil niet voor elke actie een apart php document ik doe dit liever op de pagina pages.php. Hierin heb ik dan een switch waarin in de afhandeling's documenten worden geinclude. Zo is het nog wel overzichtelijk maar heb ik wel alle documenten bij elkaar in een pagina.
Maar ik kan dus beter een hidden field gebruiken??
Tim Slootweg op 11/12/2012 13:02:13:
index.php&action=save-content&id=1.
Wat de twee heren hierboven zeggen klopt en kun je aanhouden. En om je snel uit te leggen waarom insert's, update's en delete's onveilig zijn via GET is als voglt.
Nu wijzig je de content van je id 1, maar als ik nu kwaad wil doen, zet ik daar bij id gewoon 2, 3, 4, etc neer om een ander record te wijzigen.
Dus kan er heel makkelijk verkeerde gegevens gewijzigd worden, escapes en 'invoerveiligheid' zijn dan niet van toepassing, want ik blijf een int (cijfer) geven alleen niet het id wat de bedoeling was.
Alleen kom je als je op een pagina link klikt op de de pagina pages.php&action=view&id=1, nu haal ik gegevens op dus dit is goed. Op de view pagina staat boven de pagina een menu met de acties die je kunt uitvoeren. Als ik dan bijvoorbeeld de content ga wijzigen opent er een dialog met het formulier(tiny mce). Als ik dan op submit druk verstuur ik het formulier met method post. Maar als ik dan $_GET gebruik heb je nog steeds de id van pages.php&action=view&id=1 en deze is dan alsnog aan te passen. Zelfs als ik dit op het php gedeelte heb.
Dus kortom ik loop alleen even vast met de id...
Toevoeging op 11/12/2012 13:44:32:
Ja had het laatste bericht niet gezien, maar zo moet het dan wel werken.
Je hebt het over een beveiligde pagina. Ik weet niet exact hoe je dit gedaan hebt, maar stel... ik log in en vervolgens krijg ik dan een overzicht te zien van items die ik kan verwijderen. Allemaal prima. Echter, realiseer je wel dat ik als ik niet ben ingelogd nog steeds diezelfde url's kan aanroepen. Je zult dus voorafgaand aan iedere verwijder actie moeten controleren of de betreffende persoon is ingelogd.
Als je het heel uitgebreid wilt doen kunt je werken met een user class met rechten, maar dit is nu goed.
Toevoeging op 11/12/2012 14:47:24:
De beheer pagina is wel een aparte pagina.
Tim Slootweg op 11/12/2012 14:45:39:
Hij kan ze wel aanroepen maar dan krijgt hij of zij de inlog pagina te zien.
Oké, dan kan een kwaadwillende in ieder geval niks verwijderen. Lijkt me prima.
Een Admin panneel valt of staat bij een deftig inlog systeem.
Daarbij kunnen leden een "rol" krijgen (bv. "moderator", "contributor", "admin").
Een stuk content (bv. een bericht) krijgt altijd een auteur mee.
Bij het aanpassen of verwijderen moet je dus eerst controleren of de gebruiker rechten heeft om dit te verwijderen/aanpassen.
bv.
Een admin heeft alle rechten.
Een moderator mag alle pagina's aanpassen.
Een contributor mag enkel de eigen posts aanpassen.
Dus, dit alles hoor je te controleren.
Maar hoe zit dat dan met de navigatie van bijna alle sites? Als ik bijvoorbeeld www.domeinnaam.nl/home heb dan is home of een map, of een bestand, waarbij de extentie is weggewerkt met mod rewrite of het is gewoon een get variabele die geen vraagteken of engelse "and" teken bevat omdat deze is ge mod rewrite.
Veel sites gebruiken dus GET variabelen om de gebruiker te navigeren naar een pagina, en dan is het vaak al de bedoeling dat de gebruiker die GET variabele zelf typt achter de domeinnaam.
Het is dus niet van de server.
Maar als je een menu met links op een pagina zet, en je klikt op een link die verwijst naar bijvoorbeeld www.domeinnaam.nl?page=home
Dan komt die GET ook niet van de server.
Facebookpagina's zijn een voorbeeld...
Gewijzigd op 11/12/2012 15:46:07 door Mark Hogeveen
Kijk eens naar de url van deze pagina hier.
We zitten hier op en topic met id=88101
mod rewrite herschrijft dat dus in iets wat "mooier" is.
Ja dit klopt bij mij is er alleen admin recht op dit momen. En hoe noem je het dan als er iemand is die wel alle pagina's mag aanpasen maar niet mag verwijren bijv.
@harry,
Volgens mij staan alle bestande op een server, dus haal je met $_get gewoon iets van de server
Gewijzigd op 11/12/2012 15:55:31 door Tim S