[php][mysql] content management beveiligen

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • The Flying Dutchman
  • Registratie: Mei 2000
  • Laatst online: 18-06 10:22
Ik ben een website aan het bouwen die beheerd zal worden door iemand anders. Degene die de website zal beheren kent geen html en gebruik van een ftp programma is ook vrijwel uitgesloten. Dus ik ben bezig met een content management systeem dat volledig vanaf de website te beheren is. De mogelijkheden van het systeem zijn:
  • het aanmaken van nieuwe pagina's
  • het veranderen van de inhoud van een pagina
  • het verwijderen van pagina's
Nu is mijn probleem: hoe beveilig ik dit op een goede manier? De mogelijkheden die ik op de server heb zijn de volgende:
  • als ik op mijn account inlog, dan kan ik de rechten op directory's wijzigen, maar vanuit php is dit onmogelijk (het is een windows server), rechten op bestanden wijzigen is in het geheel onmogelijk
Wat is nu de beste structuur voor het maken van die website? De volgende mogelijkheden zie ik voor ogen:
  1. ik maak een subdirectory die voor iedereen toegankelijk is, daarin worden de nieuwe pagina's aangemaakt
  2. ik stop de pagina in een database en ik maak dus geen bestand aan voor die pagina
  3. als het eerste voorstel, echter ik controleer de inhoud van de pagina met wat er in de database staat
    • voordeel: gebruikers krijgen geen verkeerde pagina te zien
    • nadeel: de boel is nog steeds toegankelijk
    • nadeel: erg lelijk naar mijn idee
Eigenlijk valt de eerste methode voor mij al af, je loopt namelijk de kans dat een kwaadwillend iemand content op de website laat zien en dat is uiteraard niet de bedoeling. De 3e methode lijkt me ook niet een erg verstandige keuze. Blijft alleen de 2e methode nog over. Maar hoe zit het met de nadelen van deze methode? Zijn er nog andere mogelijkheden die ik over het hoofd zie? Ik hoop dat hier mensen zijn die iets zinnigs hierover kunnen zeggen.

Uiteraard heb ik gezocht op GoT over content management systemen, maar ik kon niet iets vinden wat hier op leek. Verder hoop ik dat ik het juiste forum heb gekozen, daarover was ik zelf ook nog niet helemaal uit ;).

The Flying Dutchman


Acties:
  • 0 Henk 'm!

  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 02-07 23:14

Gerco

Professional Newbie

Het "nadeel" wat je noemt voor de tweede methode is op te lossen door iets als IISRewrite te gebruiken. Daarmee kun je URLs maken in de vorm http://www.domein.nl/bla voor de pagina "bla". Bestanden gaan aanmaken lijkt me een heel erg slecht idee, vooral op security gebied en alleen optie 2 lijkt me levensvatbaar.

[ Voor 8% gewijzigd door Gerco op 05-09-2006 13:34 ]

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


Acties:
  • 0 Henk 'm!

  • sariel
  • Registratie: Mei 2004
  • Laatst online: 22-05-2024
Eeuhm.....er zijn tientallen opensource gratis CMS applicaties. Waarom zelf bouwen, als er al zat mensen zijn die er een voor je hebben gemaakt?

http://www.opensourcecms.com

MODx, Joomla/Mambo, e107 en WebGUI zijn allemaal zeer goede CMS'en die makkelijk te beheren zijn, en authenticatie ingebouwd hebben.

Copy.com


Acties:
  • 0 Henk 'm!

  • The Flying Dutchman
  • Registratie: Mei 2000
  • Laatst online: 18-06 10:22
Gerco schreef op dinsdag 05 september 2006 @ 13:34:
Het "nadeel" wat je noemt voor de tweede methode is op te lossen door iets als IISRewrite te gebruiken. Daarmee kun je URLs maken in de vorm http://www.domein.nl/bla voor de pagina "bla". Bestanden gaan aanmaken lijkt me een heel erg slecht idee, vooral op security gebied en alleen optie 2 lijkt me levensvatbaar.
Bedankt voor deze tip! De server waarop ik werk heeft ISAPI_rewrite. Daar ga ik eens even mee aan de slag. Ik wist niet dat zoiets bestond.

The Flying Dutchman


Acties:
  • 0 Henk 'm!

  • FragFrog
  • Registratie: September 2001
  • Laatst online: 04-07 15:12
Mocht je Apache draaien IPV IIS kun je mod_rewrite gebruiken. Zelf ook gedaan voor een paar CMS'en die ik geschreven heb, wellicht wat handige code:

PHP:
1
2
3
/* .htaccess rewrite:*/
RewriteEngine on
RewriteRule !^(favicon\.ico|templates/) index.php [L]


PHP:
1
2
3
4
/* PUT URI INTO $params ARRAY */
global $params;
$params[0] = '/';
$params = array_map('checkVar', array_slice(explode("/",strtolower(rtrim($_SERVER["REDIRECT_URL"],"/"))),1));


checkVar doet trouwens wat meuk als addslashes en html_entities om te zorgen dat alle variabelen direct veilig binnen komen :)

Overigens, ik ben samen met iemand anders een jaar geleden begonnen met het schrijven van het CMS voor www.cleopatra-groningen.nl, is nog steeds niet helemaal af en we hebben er al enorm veel tijd in geinvesteerd. CMS'en zijn leuk om te maken, maar als je het goed wilt doen echt -veel- werk. Het is echt veel makkelijker iets te gebruiken wat iemand anders gemaakt heeft - ik zou je serieus willen aanraden eerst een standaard pakket te pakken :)

[ Voor 3% gewijzigd door FragFrog op 05-09-2006 14:39 ]

[ Site ] [ twitch ] [ jijbuis ]


Acties:
  • 0 Henk 'm!

  • Cavorka
  • Registratie: April 2003
  • Laatst online: 27-03-2018

Cavorka

Internet Entrepreneur

Kost gelukkig maar $199...

Gratis equivalenten van ModRewrite onder Apache voor IIS zijn zeer schaars, en voor zover ik heb ondervonden een hel om te installeren. Dit omdat er dus in IIS niets vergelijkbaars is ingebouwd als ModRewrite, wat (het ontbreken ervan dus) naar mijn mening redelijk achterlijk is.

the-blueprints.com - The largest free blueprint collection on the internet: 50000+ drawings.


Acties:
  • 0 Henk 'm!

  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 02-07 23:14

Gerco

Professional Newbie

@Cavorka:

Dat is m.i. inderdaad achtelijk, vandaar dat de meeste ASP/IIS hosters het tegenwoordig ook standaard erbij aanbieden.

offtopic:
Het ontbreken ervan is simpelweg onderdeel van het businessmodel voor closed-source software, maak het zo kaal mogelijk en reken goddeloze bedragen voor de "uitbreidingen" om het compleet te maken. Op die manier kun je kunstmatig een leuke markt creëren, waar er eigenlijk geen is.

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


Acties:
  • 0 Henk 'm!

  • pietje63
  • Registratie: Juli 2001
  • Laatst online: 04-07 10:08

pietje63

RTFM

Om even terug ontopic te komen: ik snap echt niet wat al jouw beveiligingsproblemen zijn.. Een beetje cms schrijft sowieso niet de hele pagina's weg,maar slechts een stuk content.

Als je een directory /admin/ maakt en deze met htaccess beveiligt en hier alle admin php in zet dan is dit in principe al beveiligd.

Ik heb in mijn cms wel alles gewoon in een database staan, inclusief 2 kolommen met een rechtenlevel; eentje voor bekijken en eentje voor wijzigen. Dit gelinkt aan een login tabel en wat goede php pagina's die overal de rechten controleren is volgens mij een vrij standaard basis.

De grootste Nederlandstalige database met informatie over computers met zoekfunctie!!


Acties:
  • 0 Henk 'm!

  • The Flying Dutchman
  • Registratie: Mei 2000
  • Laatst online: 18-06 10:22
Het management content gedeelte is grotendeels al af. Natuurlijk is het mogelijk om alle 'includes' en 'admin' pagina's in een andere directory te zetten die niet schrijfbaar is. Dan zijn die iig in orde. Maar als je nieuwe pagina's aanmaakt, dan heb je nog steeds dat de content daarvan door iedereen te wijzigen is (om de pagina te kunnen maken moet de directory writetable zijn, en de nieuwe pagina die je maakt is dat ook).

Met wat kleine aanpassingen heb ik het nu als volgt gedaan:
mbv ISAPI_Rewrite wordt een url omgezet, bijvoorbeeld www.domein.nl/gewenstepagina.php wordt www.domein.nl/content.php?filename=gewenstepagina.php

In content.php wordt de inhoud van de pagina uit de database getrokken en geparsed door de parser die ik heb geschreven. Het werkt nu prima, het enige probleem waar ik nu nog een oplossing voor zoek is bestaande pagina's (die niet gewijzigd mogen worden). Bijvoorbeeld:

www.domein.nl/bestaandepagina.php wordt www.domein.nl/content.php?filename=bestaandepagina.php

Dit is niet de bedoeling. Mogelijke oplossing is om ook de inhoud van pagina's die niet gewijzigd mogen worden in de database te zetten, maar mooier zou zijn als de rewrite rule deze url gewoon niet rewrite. Dus nog maar eventjes verder zoeken ;).

Ik ben in ieder geval al een stuk verder, bedankt voor alle reacties!

The Flying Dutchman


Acties:
  • 0 Henk 'm!

  • PowerFlower
  • Registratie: Juni 2001
  • Laatst online: 28-06 20:12

PowerFlower

être diable et jouer fleur

Uhm... eigenlijk weet ik niet waar ik moet beginnen om behulpzaam te zijn, zoals FragFrog al zei, het maken van een CMS kost heel veel tijd. Als het níet heel veel tijd kost is er meestal iets grondig mis met de basisarchitectuur. Om dat te voorkomen, moet je je daar dus echt in verdiepen, en al doende - nu je hier mee bezig bent - is daar misschien wel het juiste moment voor: je begint nu een eerste glimp van de problemen te zien. En misschien nog een vermakelijk voorbeeld van het soort dingen dat fout kan gaan met een zelfgebouwd CMS waar nét niet grondig genoeg over nagedacht is: "The Spider of Doom" (ook bekend als "Google killed my CMS") :)

Acties:
  • 0 Henk 'm!

  • mrFoce
  • Registratie: Augustus 2004
  • Laatst online: 03-07 19:36
sariel schreef op dinsdag 05 september 2006 @ 13:39:
Eeuhm.....er zijn tientallen opensource gratis CMS applicaties. Waarom zelf bouwen, als er al zat mensen zijn die er een voor je hebben gemaakt?

http://www.opensourcecms.com

MODx, Joomla/Mambo, e107 en WebGUI zijn allemaal zeer goede CMS'en die makkelijk te beheren zijn, en authenticatie ingebouwd hebben.
Tjah, waarom een nieuwe game programmeren. Er zijn al zat games uit 8)7
Soms wil je gewoon zelf iets schrijven. Dat heeft zeker niet alleen maar nadelen als je dat denkt, bijvoorbeeld minder kans op exploits (aangezien je site uniek is, wordt je site niet gehackt met bekende exploits voor de versie die je gebruikt) etc

Dus, een reply als: Waarom zou je zelf een CMS schrijven is een beetje onzinning.

Acties:
  • 0 Henk 'm!

  • The Flying Dutchman
  • Registratie: Mei 2000
  • Laatst online: 18-06 10:22
PowerFlower schreef op dinsdag 05 september 2006 @ 17:57:
Uhm... eigenlijk weet ik niet waar ik moet beginnen om behulpzaam te zijn, zoals FragFrog al zei, het maken van een CMS kost heel veel tijd. Als het níet heel veel tijd kost is er meestal iets grondig mis met de basisarchitectuur. Om dat te voorkomen, moet je je daar dus echt in verdiepen, en al doende - nu je hier mee bezig bent - is daar misschien wel het juiste moment voor: je begint nu een eerste glimp van de problemen te zien. En misschien nog een vermakelijk voorbeeld van het soort dingen dat fout kan gaan met een zelfgebouwd CMS waar nét niet grondig genoeg over nagedacht is: "The Spider of Doom" (ook bekend als "Google killed my CMS") :)
Ehm... ik ben hier al langer mee bezig dan menigeen hier denkt ;).
Daarnaast zijn de mogelijkheden van deze CMS heel beperkt. Pagina's toevoegen, pagina's verwijderen, menustructuur wijzigen, pagina inhoud wijzigen, oude versies van pagina inhoud terughalen, het werkt allemaal prima. Het enige punt waar ik op vastliep was een goede structuur om de pagina's netjes op te slaan. Die heb ik nu, dus is het probleem nu opgelost.

The Flying Dutchman


Acties:
  • 0 Henk 'm!

  • PowerFlower
  • Registratie: Juni 2001
  • Laatst online: 28-06 20:12

PowerFlower

être diable et jouer fleur

oKIeh schreef op dinsdag 05 september 2006 @ 18:14:
[...]
Ehm... ik ben hier al langer mee bezig dan menigeen hier denkt ;).
Daarnaast zijn de mogelijkheden van deze CMS heel beperkt. Pagina's toevoegen, pagina's verwijderen, menustructuur wijzigen, pagina inhoud wijzigen, oude versies van pagina inhoud terughalen, het werkt allemaal prima. Het enige punt waar ik op vastliep was een goede structuur om de pagina's netjes op te slaan. Die heb ik nu, dus is het probleem nu opgelost.
Stukje al gelezen? Ik begrijp prima dat je er al langer mee bezig bent, alleen wijst je vraag, en de manier waarop je die stelt, enigszins op nogal wat potentiële problemen met je CMS: je moet niet eerst de functies bouwen, en daarna de security "toevoegen", maar denken vanuit de security, en van daaruit de functies bouwen. Iets waar zelfs grote/bekende bedrijven mee in de problemen gekomen zijn, herhaaldelijk (Microsoft wordt er vaak om uitgekafferd), en wat je alleen voorkomt door het conceptueel goed door te denken.

Het stukje is daar natuurlijk een hilarisch voorbeeld van - tuurlijk, dat CMS werkte ook prima, het werd alleen leeggespiderd door Google; het was niet eens een ev0l h4x0r. Als jóu zoiets gebeurt vermoed ik dat je het een stuk minder grappig vind :P Daarom was mijn hint, dit is een uitstekend moment om eens te gaan kijken naar de basis van de concepten (en daar is vrij veel online over te vinden) :)

[ Voor 5% gewijzigd door PowerFlower op 05-09-2006 18:28 ]


Acties:
  • 0 Henk 'm!

  • The Flying Dutchman
  • Registratie: Mei 2000
  • Laatst online: 18-06 10:22
Ik heb het stukje gelezen. Ik begrijp daarnaast ook dat de mijn vraag doet overkomen alsof ik niet weet waar ik mee bezig ben. Naar mijn idee valt dat wel wat mee en is het systeem dat ik nu ontworpen heb voor de toepassing waarvoor ik het gebruik veilig genoeg.

Het enige punt waar ik nog mee zat was hoe sla ik de pagina's op een veilige manier op? Het veilig bewerken, aanmaken en verwijderen van pagina's is al helemaal uitgedacht. Het opslaan van een pagina, was mij duidelijk dat de veiligste manier is om dat gewoon in een database te doen en vervolgens die data eruit trekken. Het enige nadeel dat ik daarbij zag heb ik uitgelegd (zie mijn openingspost) en vandaar vroeg ik me af of ik mogelijkheden over het hoofd had gezien.

The Flying Dutchman


Acties:
  • 0 Henk 'm!

  • lgeraeds
  • Registratie: Augustus 2006
  • Laatst online: 26-05 11:26
Ik heb ook mijn eigen cms, ik heb toen gekeken of ik HTML pagina's direct wou gaan bewerken of gewoon alleen een index.php maken waar in ik aan de hand van variabelen alles uit de database lees.

Ik heb voor de laatste gekozen, PHP met een MySQL database.
Dit is gewoon de meest veilige methode denk ik zelf dan...

Acties:
  • 0 Henk 'm!

  • FragFrog
  • Registratie: September 2001
  • Laatst online: 04-07 15:12
gideon82 schreef op dinsdag 05 september 2006 @ 18:00:
Tjah, waarom een nieuwe game programmeren. Er zijn al zat games uit 8)7
Je vergelijking klopt niet. Die zou moeten zijn: waarom zelf een game-engine schrijven, er zijn al zat game-enginges!

En het leuke is: er zijn enorm veel games die gebruik maken van iemand anders' game engine ;)

Een goed CMS regelt het aanmaken, beheren en weergeven van gegevens. Met de layout en content zelf hoort het niets van doen te hebben. De TS zocht een manier om gegevens veilig op te slaan, dit is prima iets wat een standaard CMS goed kan.

En ja, een goede reden om geen default CMS te gebruiken is security trough obscurity. Ons vorig CMS was Typo3 en is offline gehaald nadat het herhaaldelijk gehacked werd. Echter, een echt uitgebreid CMS heeft zoveel dingen waar je aan moet denken security-wise dat voor een beetje hacker het geen enkel probleem is gaten te vinden. Tenzij je security altijd in je achterhoofd hebt zitten bij alles wat je code loop je altijd risico. Vaak is het dan beter toch maar voor een bekend CMS te gaan. Om maar wat te noemen, heeft de TS al gedacht aan XSS, SQL injecties, JS exploits, packet sniffers (verstuur je wachtwoorden als plain tekst?), etc?

Maargoed, I'll stop being offtopic here now :+

[ Site ] [ twitch ] [ jijbuis ]


Acties:
  • 0 Henk 'm!

  • The Flying Dutchman
  • Registratie: Mei 2000
  • Laatst online: 18-06 10:22
We zijn inderdaad enigzins offtopic bezig, maar het is natuurlijk ook aardig om te kijken waar je allemaal op zou moeten letten bij een goede CMS.

In dit geval heb ik veel aandacht besteed aan SQL injections. Alles wat ingevoerd wordt, wordt zowel met JS als met PHP gecontroleerd en elke keer als je een beveiligde pagina bezoekt of schrijft naar de database wordt er gecontroleerd of je ingelogd bent.

Op dit moment stuur ik wel wachtwoorden in plain text over het internet. Ik heb wel overwogen om dit nog te veranderen, maar het leek me voor deze specifieke opdracht enigzins overdreven. Wachtwoorden van gebruikers worden gehashed in de database opgeslagen. Ik overweeg nog om een salt toe te voegen. Hoewel je dan eigenlijk ook gewoon wachtwoorden encrypted over internet zou moeten sturen (het heeft weinig zin om een schakel in je ketting nog sterker te maken als je een andere zwakke schakel hebt).

The Flying Dutchman


  • FragFrog
  • Registratie: September 2001
  • Laatst online: 04-07 15:12
Met JS controleren heeft totaal geen nut aangezien dat client-side gaat (security NOOIT clientside laten plaatsvinden ;)), wat je wel goed met JS kan doen is het wachtwoord encrypten voordat je't verstuurd. Als je met cookies werkt geldt daarvoor hetzelfde. Desnoods server-side weer decrypten, als je inlog systeem goed centraal opgezet is moet dit niet al teveel werk zijn :)

SQL injecties kun je trouwens het allerbeste voorkomen door gebruik te maken van zgn parametrized queries (kwam ik een jaar geleden dankzij GoT achter nadat een website van mij gehacked was ;)), alhoewel dit wel vereist dat je al je queries weer opnieuw mag gaan schrijven, dus of je daar zin in hebt.. MySQLescapestring doet't natuurlijk ook gewoon :)

[ Site ] [ twitch ] [ jijbuis ]


  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 02-07 23:14

Gerco

Professional Newbie

FragFrog schreef op donderdag 07 september 2006 @ 04:51:
Met JS controleren heeft totaal geen nut aangezien dat client-side gaat (security NOOIT clientside laten plaatsvinden
Hij zegt dat de controle zowel serverside als clientside plaatsvind. Dat heeft wel degelijk nut aangezien je dan nutteloze roundtrips voorkomt en je een betere gebruikerservaring kan creëren. Je moet controles nooit alleen clientside doen, dat betekent niet meteen dat clientside controle waardeloos is en dus nooit zou moeten gebeuren.

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


Anoniem: 80305

Misschien dat je eens iets moet proberen als CMS Mundo, te vinden via http://www.hotwebscripts.com

Het systeem is gratis, en makkelijk te begrijpen voor de meestte leken (en dan doel ik dus op de webmaster, niet de developer)

  • FragFrog
  • Registratie: September 2001
  • Laatst online: 04-07 15:12
Gerco schreef op donderdag 07 september 2006 @ 08:42:
Hij zegt dat de controle zowel serverside als clientside plaatsvind. Dat heeft wel degelijk nut aangezien je dan nutteloze roundtrips voorkomt en je een betere gebruikerservaring kan creëren. Je moet controles nooit alleen clientside doen, dat betekent niet meteen dat clientside controle waardeloos is en dus nooit zou moeten gebeuren.
Roundtrips kun je ook voorkomen door gebruik te maken van AJAX, in mijn opinie is het client-side laten controleren haast altijd een nodeloze security-risk omdat het je een vals gevoel van veiligheid geeft - het stukje van PowerFlower is daarvoor nog wel het mooiste voorbeeld.

Daarnaast, wat wou je controleren? Je content (en dan vooral links etc) pas je aan -voordat- je die naar de client stuurt, als je het goed doet krijgt die nooit links te zien waar'ie niet op mag klikken. Username en wachtwoord zou je kunnen laten controleren voor verzenden, maar de enige manier om dat te doen is een hash meesturen die elke hacker met wat geduld kan kraken - MD5 en zelfs SHA1 zijn niet meer zo veilig als wel eens gedacht werd. Wellicht zie ik hier nog een nuttige toepassing over het hoofd, maar voor zover ik weet is client side controleren nauwelijks de moeite waard :)

[ Site ] [ twitch ] [ jijbuis ]


  • MBV
  • Registratie: Februari 2002
  • Laatst online: 01-07 16:10

MBV

Ik kan me voorstellen dat een hacker zoiets heeft van "Ja dag, ik ga er geen dag computertijd aan besteden, deze is niet leuk meer. Volgende slachtoffer..." als je MD5/SHA1 gebruikt in Javascript. Beveiliging is nooit absoluut, altijd relatief.
En waarom moet je er ajax bij halen om een formuliertje te versturen? Is toch een beetje boel onnodige complexiteit toevoegen voor iets wat veel simpeler kan?
Pagina: 1