Onveilig paginasysteem?

Saven schreef op zaterdag 17 juli 2010 @ 01:33:
Het is toch aan de hoster om te zorgen dat die user niet buiten zijn eigen folders kan? Anders zou ik ook voor mezelf bij andere users in kunnen breken.. Lijkt me niet helemaal de bedoeling

Saven schreef op zaterdag 17 juli 2010 @ 01:24:
Goeienacht Even een korte vraag eigenlijk.
Ben bezig voor een klant met een kleine website, en heb daarvoor een heel simpel paginasysteempje gemaakt /index.php?p=xxxx je kent het wel

Saven schreef op zaterdag 17 juli 2010 @ 02:20:
user input vertrouwen deed ik eigenlijk al niet alleen ik was niet helemaal op de hoogte van die unicode dingen, en vond (en vind nog steeds) dat de hoster zn user zaakjes maar op orde moet hebben

Saven schreef op zaterdag 17 juli 2010 @ 02:23:
[...]

ej sorry man wist niet dat je boos werd
maareh simpel en dient zn doel. het is zoiets simpels als dit, of statische html pagina's maken.

[ Voor 11% gewijzigd door mcDavid op 17-07-2010 02:31 ]

Saven schreef op zaterdag 17 juli 2010 @ 02:20:
Ja is lang verhaal maar het is geen webhostingboer ofzo, tis een bedrijf die zn klanten host en normaal zelf websites voor die klanten verzorgt. Dus die waren niet zo happig op het feit dat een of ander kereltje even php komt dumpen op hun server

freakingme schreef op zaterdag 17 juli 2010 @ 12:35:
Daarnaast is het tegenwoordig bestpractice als je de ?> in php bestanden weglaat.

freakingme schreef op zaterdag 17 juli 2010 @ 12:35:
Als we dan toch bezig zijn include, include_once, require en require_once zijn statements en geen functions. Verder denk ik dat je in deze context include of require wil gebruiken ipv include_once. Daarnaast is het tegenwoordig bestpractice als je de ?> in php bestanden weglaat.

Saven schreef op zaterdag 17 juli 2010 @ 02:29:
Nee snap ik. Ik ben zelf wel redelijk op de hoogte met dat soort dingen hoor Ik vind het alleen nog steeds niet mijn probleem als de hoster zn userrechten niet goed heeft geregeld

kevinkrs schreef op zaterdag 17 juli 2010 @ 12:56:
[...]

Hoezo weglaat?
Zover ik weet moet je php ook gewoon afsluiten...

kevinkrs schreef op zaterdag 17 juli 2010 @ 12:56:
[...]

Hoezo weglaat?
Zover ik weet moet je php ook gewoon afsluiten...

Gomez12 schreef op zaterdag 17 juli 2010 @ 13:07:
waarom zou je bijv nog een mysql-connectie afsluiten dan

offtopic:
Omdat persistente connecties (soms) sneller zijn

Verwijderd schreef op zaterdag 17 juli 2010 @ 13:09:
Je script is zeker wel veilig, ik bedoel het is beter als je alle mogelijke waardes van je GET in een array zou stoppen en vervolgens zou controleren of die erin zit.

Maar het is iniedergeval niet zo dat bijvoorbeeld iemand anders zijn PHP pagina vanaf het internet in joun website kan "include" en vervolgens alle variable kan uitlezen doordat file_exists alleen true reageert als het bestand lokaal staat en niet extern.

NMe schreef op zaterdag 17 juli 2010 @ 13:11:
De ?> weglaten wordt inderdaad door Zend aangeraden maar ik voel me daar zelf ook niet zo happy bij. Ik zorg wel dat ik geen witregels achter mijn ?> heb staan. Los daarvan: het is dus inderdaad best practice volgens "de authoriteiten".

1
2
3
4
5
6
7
8
9

if(array_key_exists($_GET['p'])){

switch($_GET['p']){
 case "bla1":
 case "bla2":
 default:
  die ( "go away!");
}
}

[ Voor 3% gewijzigd door Webgnome op 17-07-2010 18:30 ]

Ik vraag me eigenlijk af waarom je niet gewoon een framework gaat gebruiken in plaats van zelf iets in elkaar probeert te prutsen?

Sebazzz schreef op zaterdag 17 juli 2010 @ 18:35:
[...]
Waarom is een compleet framework nodig als de gebruiker alleen statische HTML pagina's bij elkaar wilt voegen? De TS wil gewoon dat in een vaste pagina de juiste content in zijn div/table en title tags worden gezet. Een include is dan voldoende en een compleet framework is dan niet nodig imo.

Webgnome schreef op zaterdag 17 juli 2010 @ 18:28:
Maar ik vind het eigenlijk zowiezo ranzig om via een $_GET['p'] te bepalen wat je include. Je moet een vast model hebben waarin de $_GET bepaald wat je uit de database moet trekken indirect (bijvoorbeeld $_GET['contenttype'] icm een $_GET['id'] ) content type bepaalt dan hoe je je view opbouwt ( welke classes je moet laden en dergelijke en welke php files je nodig hebt hiervoor) en het ID nadat je het gecontroleerd hebt met op zijn minst is_numeric (...) bepaald welk item je uit de db trekt.

_{nu is alleen op is_numeric checken natuurlijk ook niet voldoende helemaal veilig maar ik hoop dat je het idee door krijgt. Vertrouw NOOIT op spul dat je via $_GET/$_POST of welk ander user generated content binnen krijgt.}

1

$sSql = 'SELECT content FROM page WHERE id='.(int)$_GET['id'].' LIMIT 1';

1

$sSql = 'SELECT content FROM page WHERE id='.((int)$_GET['id'] >0 ? (int)$_GET['id'] : 1).' LIMIT 1';

[ Voor 95% gewijzigd door Webgnome op 17-07-2010 23:26 ]

Webgnome schreef op zaterdag 17 juli 2010 @ 22:18:
Over is_numeric en sql Ik weet niet of dit nog helemaal klopt trouwens.

krvabo schreef op zaterdag 17 juli 2010 @ 21:24:

Waarom is controleren op is_numeric niet helemaal veilig?

PHP:

1	$sSql = 'SELECT content FROM page WHERE id='.(int)$_GET['id'].' LIMIT 1';

Volstrekte veilig. Dat je in principe ook een 0 als id naar je database kunt gooien maakt het niet minder veilig, hooguit kun je eens een lege resultset krijgen. Maargoed, dat is ook wel af te vangen

[ Voor 20% gewijzigd door MorosMyrddin op 18-07-2010 15:54 ]

YopY schreef op maandag 19 juli 2010 @ 09:15:
Mja, het kunnen aanpassen van een ID om een andere pagina te kunnen kijken lijkt mij niet een heel erg groot probleem voor simpele sites met losse pagina's. Het wordt echter een ander probleem als je ook bijvoorbeeld je beheerspagina's een ID meegeeft, of als je privéinformatie van mensen op zo'n pagina zet (en het beveiligt met 'er zijn geen links naartoe op openbare pagina's').

krvabo schreef op zaterdag 17 juli 2010 @ 21:24:
[...]

PHP:

1	$sSql = 'SELECT content FROM page WHERE id='.(int)$_GET['id'].' LIMIT 1';

Volstrekte veilig. Dat je in principe ook een 0 als id naar je database kunt gooien maakt het niet minder veilig, hooguit kun je eens een lege resultset krijgen. Maargoed, dat is ook wel af te vangen

1
2

$sSql = sprintf( 'SELECT content FROM page WHERE id = %d LIMIT 1',
                 $_GET['id']);

1
2

$sSql = sprintf( 'SELECT content FROM page WHERE id = %d LIMIT 1',
                 (int)$_GET['id'] >0 ? (int)$_GET['id'] : 1);

LuCarD schreef op maandag 19 juli 2010 @ 10:50:
Persoonlijk ben ik een voorstander van sprintf.

Dat is niet het probleem van het kunnen aanpassen van het ID, maar een probleem van de autorisatie op de pagina's

YopY schreef op maandag 19 juli 2010 @ 11:47:
[...]
Inderdaad. Wat ik probeer te zeggen: Beter om dit soort dingen te voorkomen dan om er later nog een keer achter te komen dat je systeem eigenlijk in eerste instantie niet goed was / is.

Verwijderd schreef op zaterdag 17 juli 2010 @ 13:09:
Je script is zeker wel veilig, ik bedoel het is beter als je alle mogelijke waardes van je GET in een array zou stoppen en vervolgens zou controleren of die erin zit.

Maar het is iniedergeval niet zo dat bijvoorbeeld iemand anders zijn PHP pagina vanaf het internet in joun website kan "include" en vervolgens alle variable kan uitlezen doordat file_exists alleen true reageert als het bestand lokaal staat en niet extern.

Alex) schreef op maandag 19 juli 2010 @ 16:56:
[...]

Je bent sarcastisch, toch? TOCH?

NMe schreef op maandag 19 juli 2010 @ 17:31:
[...]

Alle webservers hebben allow_url_fopen toch zeker uit staan?!?!?!?!