[PHP] Readfile("test.php") parsed niet als php.

[remco_k]

Ik heb een betrekkelijk simpel probleem denk ik, alleen niet simpel genoeg wat ik op kan lossen.
Met m'n php-skills (ahum) open ik met readfile een php file, waarvan de output naar de kijker word geschreven.

Tot gisteren heeft dit jaren prima gewerkt. Echter, m'n webhoster heeft ergens met z'n poten aangezeten (upgrade php ofzo, of instellingen veranderd) waardoor dit ineens niet meer werkt.

Even een concreet geisoleerd voorbeeld:

readfiletest.php:

PHP:

<?php
error_reporting(E_ALL);
echo "readfile:<br>";
if (readfile("readfiletest2.php")==FALSE) echo "readfile failed"; 
?>

readfiletest2.php:

PHP:

<?php
echo "Dit werkte ooit!<br>";
sleep(1000);
?>

Het starten van readfiletest.php werkte voorheen dus prima en de output was:

readfile:
Dit werkte ooit!

Maar sinds vandaag:

readfile:

Nog wat info:
- Php versie 4.3.9
- Ik krijg geen foutmeldingen
- De PHP code in readfiletest2.php word geheel niet geparsed, als ik daar b.v. een sleep in doe, duurt het uitvoeren van readfiletest.php niet langer.
- Zelfde geprobeerd met file_get_contents, zelfde probleem.
- De documentatie van readfile zegt niet specifiek iets over het wel of niet parsen van php code. (lijkt me ook meer iets voor de server).
- Als ik readfiletest2.php rechtstreeks start, is de output zoals verwacht "Dit werkte ooit!"
- Als ik readfiletest2.php leegmaak en wat kale tekst erin zet, word dat door readfile goed getoond.

Iemand suggesties wat te doen om dit werkend te krijgen?

[AtleX]

Waarom gebruik je readfile() en niet gewoon include() wat juist hiervoor bedoeld is?

[Joen]

Je moet include() gebruiken ipv readfile().
Readfile leest alleen de inhoud van een bestand en wordt nu gezien als HTML door dat je code met ene < begint en met een > eindigd.
Als je in de broncode van de output kijkt zie je daar ook precies je script staan.

Edit:
Spuit 11, maar wel uitgebreider en (hopelijk) duidelijker antwoord.

Info van de PHP manual (www.php.net/functienaam):
http://nl.php.net/readfile
http://nl.php.net/include

[ Voor 27% gewijzigd door Joen op 28-05-2008 16:55 ]

[--MeAngry--]

Eh? Voor zoiets heb je toch include() en require() ?
Readfile() hoort alleen maar het bestand te openen, en uit te lezen in een variabele. Vervolgens moet je er zelf nog iets mee doen. Als dat voorheen niet zo was had je hoster juist iets verkeerd staan.

[remco_k]

AtleX schreef op woensdag 28 mei 2008 @ 16:52:
Waarom gebruik je readfile() en niet gewoon include() wat juist hiervoor bedoeld is?

Include doet inderdaad wat ik bedoel. Gelukkig is dat geen nieuws voor mij.
Wat ik alleen vergeet te melden is dat ik parameters mee wil geven aan de php file.
En dat lukt niet met include, wel met readfile. Uh, lukte wel met readfile.

Ik weet dat je ook kan includen op deze manier:

PHP:

include "http://www.domeintje.nl/bla/readfiletest2.php?parameter=1";

Maar dat geeft bij mij sinds vandaag deze error:

Warning: main(http://www.domeintje.nl/bla/readfiletest2.php): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found

... iets wat voorheen trouwens ook prima werkte. Dus als jullie daar een oplossing voor hebben, dan houd ik me aanbevolen.

Bijkomend voordeel van de readfile methode was dat het php script in een compleet geisoleerde omgeving draaide (geen "last" van andermans variabelen of dubbele declaraties). En dat wilde ik ook omdat ik vanuit een CMS op deze manier externe php scripts aanroep waarvan sommige functies declareren die ook al in het CMS zijn gedeclareerd en dus voor problemen zorgen in het geval van include. Readfile lostte dat mooi op, met include heb ik die problemen weer, maar daar valt nog wel overheen te stappen.
De php scripts die ik weer wil geven in het CMS zijn dus geen onderdeel van het CMS maar extern erbij geprogged. Ik zou die natuurlijk allemaal zo kunnen aanpassen dat ik geen conflicten meer heb met declaraties enzo, maar dan blijft het parameter probleem nog bestaan.
Die parameters kan ik niet 'weghalen' omdat dezelfde php scripts ook via andere wegen met parameters aan worden geroepen.

Joen schreef op woensdag 28 mei 2008 @ 16:53:
Als je in de broncode van de output kijkt zie je daar ook precies je script staan.

Dat gebeurd juist niet, dat is het vreemde eraan. (staat ook in de TS trouwens)

--MeAngry-- schreef op woensdag 28 mei 2008 @ 16:53:
Readfile() hoort alleen maar het bestand te openen, en uit te lezen in een variabele. Vervolgens moet je er zelf nog iets mee doen. Als dat voorheen niet zo was had je hoster juist iets verkeerd staan.

Readfile poept de inhoud juist meteen naar de console, zonder tussenkomst van een variabele.

[martijnve]

Je hoeft met include geen parameters mee te geven:

index.php

PHP:

$a = "test"
include 'includetest.php';

includetest.php

PHP:

echo $a;

laat "test" zien!

Dat met die "isolatie" is een bekend php probleem omdat php geen namespaces heeft.

Het blijft een smerige hack, maar als je zo wilt blijven werken als je eerst deed moet je het resultaat van die readfile echo'en.

Dat het eerst weergegeven werdt was imho erg raar en niet zoals het hoort te werken.

edit:
kijk anders ook hier even naar:
http://www.bin-co.com/php/scripts/load/

[ Voor 52% gewijzigd door martijnve op 28-05-2008 17:47 ]

[Icekiller2k6]

martijnve schreef op woensdag 28 mei 2008 @ 17:41:
Je hoeft met include geen parameters mee te geven:

index.php

PHP:

$a = "test"
include 'includetest.php';

includetest.php

PHP:

echo $a;

laat "test" zien!

Dat met die "isolatie" is een bekend php probleem omdat php geen namespaces heeft.

ik denk dat hij dit bedoelt

main.php

PHP:

<?php

echo "he het getal is 5 * 6 =";
include "hulp.php?getal=5";
?>

hulp.php

PHP:

<?php
$getal=$_GET['getal'];
$bewerking=500*6*5*$getal;

echo $bewerking;
?>

edit:


net getest.. als je bovenstaande voorbeeld hebt met een include dan kent hij gewoon $getal.. dus kun je gewoon in uw redfile2 $getal gebruiken zonder $_GET etc..

[ Voor 23% gewijzigd door Icekiller2k6 op 28-05-2008 17:52 ]

[remco_k]

martijnve schreef op woensdag 28 mei 2008 @ 17:41:
Je hoeft met include geen parameters mee te geven:

I know, maar ik wil juist parameters meegeven omdat dezelfde php scripts ook vanuit andere hoeken (dan het CMS) worden gestart.

Ondertussen heb ik denk ik de oplossing voor het wel meegeven van parameters gevonden:
[code=php]
$_GET['parameter'] = 'paramvalue';
[/code=php]
En dat in het php script weer lezen met

PHP:

$_GET['parameter'];

Neem niet weg dat ik het maar raar vind dat readfile ineens niet meer doet wat hij jarenlang wel deed.

Edit:
@hierboven, dat dus, had het precies ook zelf gevonden.
Include met single quotes zou te mooi zijn om waar te zijn maar werkt eveneens niet.

[ Voor 10% gewijzigd door remco_k op 28-05-2008 17:50 ]

[Icekiller2k6]

main.php

PHP:

<?php

$value=66;

include "index.php";

?>

index.php

PHP:

<?php

$getal=$value*5;

echo $getal;



?>

werkt dus gewoon

[ Voor 4% gewijzigd door Icekiller2k6 op 28-05-2008 17:54 ]

[remco_k]

Met bovenstaande suggesties lukt het allemaal wel. Maar ik heb wel een hoop problemen met variabelen die dubbel gebruikt worden.

Zo gebruikt het CMS een variabele $mode maar m'n php scripts ook (voor een ander doel). En zo zijn er nog wel een heel aantal voorbeelden te noemen.
Als ik 1 van m'n php scripts dan vanuit het CMS include, dan werkt dat CMS ineens niet meer goed want de CMS code die na die include komt, heeft ineens een andere waarde in $mode staan (en datzelfde probleem met meer variabelen.).
Het zelfde probleem heb ik met de $_GET variabele, ook daar gebruik ik vaak dezelfde namen voor parameters dan het CMS hetgeen ook weer tot problemen leid voor de CMS code na de include.

Dat is precies de reden waarom ik zo blij was met de readfile methode...
Ik kan natuurlijk de php scripts allemaal aan gaan zitten passen, of voor de include alle dubbele gebruikte variabelen even onthouden en na de include weer terugzetten.
Dat is erg veel werk, en wellicht foutgevoelig. (en vooral lelijk en niet failsafe voor de toekomst).
Dit moet toch veel makkelijker kunnen?

Als je in PHP nou eens een aparte scope of namespace zou kunnen defineren...

[Verwijderd]

Als je nou gewoon goed had leren programmeren had je dit probleem ook niet gehad. Ik weet niet wat je ooit met readfile hebt gedaan, maar evaluatie van PHP code kan er niet mee. Je plukt nu gewoon de vruchten van je rare manier van aanpakken uit het verleden.

[MueR]

remco_k schreef op woensdag 28 mei 2008 @ 16:50:
- Php versie 4.3.9

About fucking time ook dat die hoster 'met zn poten ergens aan zit'. PHP4 is al een jaar dood. Niet om het een of ander hoor, maar dit soort programmeergepruts maakt mij wensen dat PHP niet zo'n toegankelijke taal was. Al die idioten die de moeite niet nemen om zich op de hoogte te stellen van security of zelfs basale dingen als hoe een functie werkt, maar vervolgens wel klagen dat hun script uit 2003 niet meer werkt op een hedendaagse webserver waar een hoop legacy rotzooi die voor security holes zorgen zijn dichtgetimmerd.

remco_k schreef op donderdag 29 mei 2008 @ 07:51:
Als je in PHP nou eens een aparte scope of namespace zou kunnen defineren...

PHP 5.3 en PHP6 ondersteunen dit, duurt niet lang meer.

[ Voor 67% gewijzigd door MueR op 29-05-2008 08:57 ]

[curry684]

Verwijderd schreef op donderdag 29 mei 2008 @ 07:54:
Als je nou gewoon goed had leren programmeren had je dit probleem ook niet gehad. Ik weet niet wat je ooit met readfile hebt gedaan, maar evaluatie van PHP code kan er niet mee. Je plukt nu gewoon de vruchten van je rare manier van aanpakken uit het verleden.

Tuurlijk wel, daar heb je toch eval voor!

* curry684 rent

[Janoz]

De reden dat het vroeger wel werkte komt omdat je het via de webserver aan het opvragen was. Readfile gedroeg zich als het ware als een browser. Je las niet het bestand van de schijf af, maar je vroeg via de netwerk interface of de webserver een bepaalde url wilde genereren.

Dat een hoster de http manier van opvragen uitzet is behoorlijk logisch. Wanneer deze optie aan staat kan door de vele pruts 'cms' implementaties (includen middels een get parameter) elke willekeurige code worden uitgevoerd op de server.

Verder met cheatah

[jan-marten]

Ben je niet gewoon op zoek naar highlight?
Hm, nee dus. Include/require dan maar.

[ Voor 15% gewijzigd door jan-marten op 29-05-2008 12:09 . Reden: Lezen is ook een vak ]

[remco_k]

Janoz schreef op donderdag 29 mei 2008 @ 09:02:
De reden dat het vroeger wel werkte komt omdat je het via de webserver aan het opvragen was. Readfile gedroeg zich als het ware als een browser. Je las niet het bestand van de schijf af, maar je vroeg via de netwerk interface of de webserver een bepaalde url wilde genereren.

En met jouw verklaring begrijp ik nu inderdaad dat het volkomen logisch is dat readfile de lokaal geopende php file niet parsed maar gewoon als plain text behandeld.
Voorheen deed ik dit inderdaad via de netwerk interface (http:// .... )
Dat het niet (meer) werkte begreep ik niet, nu wel.

Even dacht ik dat eval(file_get_contents ( "file.php")); (als vervanger van de readfile() methode) me zou helpen met een geisoleerde omgeving, maar dat blijkt niet zo te zijn, het werkte wel prima overigens, maar ik schoot er niets mee op, dus een include is dan een veel beter idee.

Ik heb er dus toch maar voor gekozen om de scripts aan te passen en ervoor te zorgen dat ze geen variabelen gebruiken die het CMS ook gebruikt.
Ze worden nu met include() aangeroepen en met $_GET zet ik de parameters.
De scripts kunnen ook nog gewoon van buiten het cms aan worden geroepen met parameters in de url. En dat was het doel!
Thx voor het meedenken.

[ Voor 8% gewijzigd door remco_k op 29-05-2008 12:50 ]

[Tsunameh]

Icekiller2k6 schreef op woensdag 28 mei 2008 @ 17:46:
[...]


ik denk dat hij dit bedoelt

main.php

PHP:

<?php

echo "he het getal is 5 * 6 =";
include "hulp.php?getal=5";
?>

hulp.php

PHP:

<?php
$getal=$_GET['getal'];
$bewerking=500*6*5*$getal;

echo $bewerking;
?>

edit:


net getest.. als je bovenstaande voorbeeld hebt met een include dan kent hij gewoon $getal.. dus kun je gewoon in uw redfile2 $getal gebruiken zonder $_GET etc..

Dit zal nooit werken:

PHP:

include("file.php?var=value");

Dan zoekt PHP namelijk naar een bestand genaamd file.php?var=value, je kan 't beter zo doen:

PHP:

$var = "value";
include("file.php");

_{sorry als dit een dubbel of onzinnige post is}

[Icekiller2k6]

Tsunameh schreef op donderdag 29 mei 2008 @ 12:56:
[...]


Dit zal nooit werken:

PHP:

include("file.php?var=value");

Dan zoekt PHP namelijk naar een bestand genaamd file.php?var=value, je kan 't beter zo doen:

PHP:

$var = "value";
include("file.php");

_{sorry als dit een dubbel of onzinnige post is}

ik weet dat dat niet werkt , die post was voor uit te leggen wat HIJ (topicstarter) bedoelde

[Janoz]

remco_k schreef op donderdag 29 mei 2008 @ 12:49:
Ik heb er dus toch maar voor gekozen om de scripts aan te passen en ervoor te zorgen dat ze geen variabelen gebruiken die het CMS ook gebruikt.
Ze worden nu met include() aangeroepen en met $_GET zet ik de parameters.
De scripts kunnen ook nog gewoon van buiten het cms aan worden geroepen met parameters in de url. En dat was het doel!
Thx voor het meedenken.

Lees je in in scopes en het gebruik van functies danwel classes. Je moet er voor zorgen dat je de scope van je variabelen zo klein mogelijk houdt. Dat is oa wat cheatah bedoeld met goed programmeren.

[Tsunameh]

Icekiller2k6 schreef op donderdag 29 mei 2008 @ 13:05:
[...]


ik weet dat dat niet werkt , die post was voor uit te leggen wat HIJ (topicstarter) bedoelde

oh, my bad, dan las ik daar over heen

[remco_k]

Janoz schreef op donderdag 29 mei 2008 @ 13:54:
[...]


Lees je in in scopes en het gebruik van functies danwel classes. Je moet er voor zorgen dat je de scope van je variabelen zo klein mogelijk houdt. Dat is oa wat cheatah bedoeld met goed programmeren.

Dat inlezen is niet nodig, is bekende theorie.
Ik zit alleen met een kant en klaar CMS wat ik niet zelf gemaakt heb (hooguit wat aanpassingen erop aangebracht) en wat simpele recht toe recht aan PHP scripts die ik lang geleden een keer tussendoor in elkaar heb geflanst, toen dat CMS er nog niet was.
PHP is totaal mijn vakgebied niet vandaar ook mijn 'php-skills (ahum)' verwijzing in de TS en vandaar ook de klasse loze scripts. Om nou dat CMS zelf op de schop te gooien gaat me weer wat ver.

Misschien tijd om die home-brew PHP scripts eens helemaal te herzien naar een wat nettere structuur. Momenteel even geen idee hoe ik in PHP met classes kan werken (functies gelukkig wel). Ik zal daar eens induiken.
Edit:
Da's een snelle, makkelijk te doen die classes in PHP.

[ Voor 8% gewijzigd door remco_k op 29-05-2008 14:51 ]

[Janoz]

remco_k schreef op donderdag 29 mei 2008 @ 14:48:
Dat inlezen is niet nodig, is bekende theorie.

Als de complete theorie mbt de scopes (en daarmee bedoel ik niet alleen het hoe, maar ook het waarom) bekende theorie was geweest dan had je dit probleem niet gehad, los van hoe het CMS geimplementeerd was ...

[remco_k]

Janoz schreef op donderdag 29 mei 2008 @ 15:12:
[...]


Als de complete theorie mbt de scopes (en daarmee bedoel ik niet alleen het hoe, maar ook het waarom) bekende theorie was geweest dan had je dit probleem niet gehad, los van hoe het CMS geimplementeerd was ...

Inmiddels bijna 10 jaar C++ (Borland en wat .NET (en nog veel meer maar dat doet er even niet toe)) ervaring in het bedrijfsleven, daarvoor nog eens 10 jaar in de hobby. Dus ga mij niet zitten vertellen dat ik de theorie achter classes en scopes niet snap want dan zou ik nu echt de grootste problemen op het werk hebben.
Ik ben gewoon geen PHP ster - probeer daar gewoon wat te rommellen wat dat betreft heeft Cheatah gelijk.
Dat ik toen die implementatie in de PHP scripts niet goed gedaan heb wil zeggen dat ik er te laks mee omging en de bekende makkelijkste weg nam. Ik was allang blij dat het ding deed wat ik wilde.
... en daarna blijft het liggen, en liggen en liggen totdat er ineens iets niet meer werkt en dat was gisteren.

[Janoz]

Maar als je het hoe en waarom begrijpt van scopes, waarom is je globale scope dan helemaal vol geplempt met variabelen? Zeker voor iemand met zoveel c++ ervaring lijkt het me niet zo'n probleem om php onder de knie te krijgen. Syntax lijkt op elkaar en je kunt een redelijk vergelijkbare structuur gebruiken.

Kortom, het verbaast me gewoon.

[remco_k]

Janoz schreef op donderdag 29 mei 2008 @ 16:42:
Maar als je het hoe en waarom begrijpt van scopes, waarom is je globale scope dan helemaal vol geplempt met variabelen?

remco_k schreef op donderdag 29 mei 2008 @ 15:45:
...dat ik er te laks mee omging en de bekende makkelijkste weg nam. ...

Daarom. Vandaag de dag veel meer ervaring met PHP, nog steeds n00b wat mij betreft. Maar als ik nu iets nieuws zou maken zou dat wel wat netter gaan ja.

[curry684]

remco_k schreef op donderdag 29 mei 2008 @ 12:49:
[...]

Even dacht ik dat eval(file_get_contents ( "file.php")); (als vervanger van de readfile() methode)

Dude.... als mensen ergens een clown-smiley bij zetten bedoelen ze "DIT DUS ABSOLUUT NIET DOEN"

[MueR]

Leer jezelf meteen 2 dingen aan:
- eval() is evil
- als curry684 iets zegt, gevolgd door een *curry684 rent., negeer het.

[remco_k]

curry684 schreef op donderdag 29 mei 2008 @ 16:50:
[...]

Dude.... als mensen ergens een clown-smiley bij zetten bedoelen ze "DIT DUS ABSOLUUT NIET DOEN"

I know Je moet alleen alles een keer hebben geprobeerd in je leven.
Eval is zo lelijk als de nacht...

Edit:
@hierboven, Evil dus.

[ Voor 5% gewijzigd door remco_k op 29-05-2008 16:52 ]

[Janoz]

MueR schreef op donderdag 29 mei 2008 @ 16:50:
Leer jezelf meteen 2 dingen aan:
- eval() is evil
- als curry684 iets zegt, gevolgd door een *curry684 rent., negeer het.Zwaai met een knuppel in de hoop hem nog net te raken.

[Voutloos]

Dan nog verbaast het me gewoon. Met je ervaring moest (ja, niet kon) je dit gewoon zien aankomen.

edit:
Welke graftak zorgt er nou weer voor een 2e pagina

[ Voor 25% gewijzigd door Voutloos op 29-05-2008 16:54 ]

[curry684]

Wat een vijandigheid

Eval is een mooie functie. Voor 0.1% van de gevallen waar ie voor ingezet wordt.

[remco_k]

Zijn we nou klaar met remco_k bashen?
Ik hem m'n portie wel gehad nou hoor.

[ Voor 31% gewijzigd door remco_k op 29-05-2008 16:54 ]

[Voutloos]

curry684 schreef op donderdag 29 mei 2008 @ 16:53:
Eval is een mooie functie. Voor 0.1% van de gevallen waar ie voor ingezet wordt.

Optimistische schatting. Met 1 cijfer achter de komma aan significantie kom je imo op 0.0% uit.

remco_k schreef op donderdag 29 mei 2008 @ 16:54:
Zijn we nou klaar met remco_k bashen?
Ik hem m'n portie wel gehad nou hoor.

Ik heb nog wel wat ideetjes. Je hebt toch niet register_globals uit?
Hint: zeg: Neuh joh, uiteraard staat dat aan!

[ Voor 35% gewijzigd door Voutloos op 29-05-2008 17:01 ]

[MueR]

remco_k schreef op donderdag 29 mei 2008 @ 16:54:
Zijn we nou klaar met remco_k bashen?

* MueR kijkt Janoz aan

Mag het? Mag het?

[ Voor 59% gewijzigd door MueR op 29-05-2008 16:57 ]

[remco_k]

Voutloos schreef op donderdag 29 mei 2008 @ 16:55:
Ik heb nog wel wat ideetjes. Je hebt toch niet register_globals uit?

Neuh joh, uiteraard staat dat aan!
@hieronder:
Nee
Ik zeg alleen lief wat je vraagt.
In het echt heb ik geen idee wat het is of doet.

En zo zullen er nog wel 10-tallen dingen in PHP zijn die mij in dit topic voor aap gaan zetten.

[ Voor 32% gewijzigd door remco_k op 29-05-2008 17:08 ]

[Voutloos]

Hmz, nu weet ik niet of je dat meent.

edit:

O, dan wordt het tijd dat je het uitzoekt, want het aan hebben jankt om security problemen, zeker als je deze 'feature' onbewust gebruikt.

[ Voor 69% gewijzigd door Voutloos op 29-05-2008 17:13 ]

[MueR]

[remco_k]

Voutloos schreef op donderdag 29 mei 2008 @ 17:03:
Hmz, nu weet ik niet of je dat meent.

edit:

O, dan wordt het tijd dat je het uitzoekt, want het aan hebben jankt om security problemen, zeker als je deze 'feature' onbewust gebruikt.

Onbewust is het zeker aangezien hij default server breed aanstaat bij de webhoster.
Ik heb 'm uitgezet middels de .htaccess file in de root van de website:

http://www.domeintje.nl/.htaccess
...
php_flag register_globals off
...

Daarna even hele CMS nagelopen en uiteindelijk 1 script wat niet meer wilde werken.
Was een script wat een form naar zichzelf postte en de variabelen niet met $_POST weer teruglas. (wat prima werkt als register_globals aan staat).
Dat erbij gebakken en die werkte ook weer.

Thx!

Edit:
Ik heb even gezocht naar een soort guide die aangeeft welke stappen belangrijk zijn om veilig te programmeren in PHP. Iemand een linkje naar zoiets? (Waar theoretisch dus ook gesproken word over de register_globals setting).

[ Voor 13% gewijzigd door remco_k op 30-05-2008 16:49 ]

[Icekiller2k6]

remco_k schreef op vrijdag 30 mei 2008 @ 16:39:
[...]

Onbewust is het zeker aangezien hij default server breed aanstaat bij de webhoster.
Ik heb 'm uitgezet middels de .htaccess file in de root van de website:

[...]

Daarna even hele CMS nagelopen en uiteindelijk 1 script wat niet meer wilde werken.
Was een script wat een form naar zichzelf postte en de variabelen niet met $_POST weer teruglas. (wat prima werkt als register_globals aan staat).
Dat erbij gebakken en die werkte ook weer.

Thx!

Edit:
Ik heb even gezocht naar een soort guide die aangeeft welke stappen belangrijk zijn om veilig te programmeren in PHP. Iemand een linkje naar zoiets? (Waar theoretisch dus ook gesproken word over de register_globals setting).

phpfreakz zal er wel hebben..
paar goede regels als je iets met mysql doet altijd mysql_real_string_escape

als je input van de user verwerkt en niet wilt dat je 200x een javascript in propt doe dan htmlentities

sla passes nooit op zonder een md5 op te doen (minstens..)
niets 'belangrijks' meegeven via de url
als je met includes werkt NOOIT index.php?page=hoi.txt
en dan include($_GET['page']); aangezien ik dan ook toffe dingen kan doen die niet horen..
(vb extern script ophalen die bepaalde files van u 'plain' weergeven)

[Voutloos]

Je geeft wel een aantal leuke cases aan waar veel security problemen zitten, maar

ls je iets met mysql doet altijd mysql_real_string_escape

is zeker _niet_ waar. Gebruik die functie altijd voor de string variabelen in je query, vandaar de naam. Voor ints kan je bijv. beter naar int casten, want anders is er toch echt een injection mogelijkheid.

[Icekiller2k6]

Voutloos schreef op vrijdag 30 mei 2008 @ 17:06:
Je geeft wel een aantal leuke cases aan waar veel security problemen zitten, maar
[...]
is zeker _niet_ waar. Gebruik die functie altijd voor de string variabelen in je query, vandaar de naam. Voor ints kan je bijv. beter naar int casten, want anders is er toch echt een injection mogelijkheid.

inderdaad is dan ook maar een korte summary van mogelijkheden die je sowieso moet doen

[remco_k]

Icekiller2k6 schreef op vrijdag 30 mei 2008 @ 17:01:
[...]
met mysql doet altijd mysql_real_string_escape

als je input van de user verwerkt en niet wilt dat je 200x een javascript in propt doe dan htmlentities

sla passes nooit op zonder een md5 op te doen (minstens..)
niets 'belangrijks' meegeven via de url
als je met includes werkt NOOIT index.php?page=hoi.txt
en dan include($_GET['page']); aangezien ik dan ook toffe dingen kan doen die niet horen..
(vb extern script ophalen die bepaalde files van u 'plain' weergeven)

Dit zijn gelukkig allemaal wel bekende dingen.
mysql_real_string_escape gebeurd uiteraard bij eventuele strings in een query die op een of andere manier user input kunnen bevatten en als ik een nummer of id mee wil geven aan een query check ik die altijd met de is_numeric() functie.

Edit:
En een mooi documentje gevonden met de gevaren van PHP:
http://www.phpfreakz.nl/artikelen.php?aid=74&page=1

[ Voor 6% gewijzigd door remco_k op 30-05-2008 19:50 ]

[Verwijderd]

Achja, het gelul van phpfreakz.nl. Als je halve waarheden, onwaarheden en brakke scripts wilt vinden moet je daar kijken.

$ find . -type f -name "*.php" | wc -l
376
$ find . -type f -name "*.php" | xargs grep -l "\$_GET" | wc -l
1
$ find . -type f -name "*.php" | xargs grep -l "mysql_" | wc -l
1

Als je begrijpt wat ik hiermee wil zeggen, ben je al een stuk beter op weg. Spuug bijvoorbeeld $_GET en de mysql_* functies niet overal door je code, maar wrap alles netjes in bruikbare classes, zodat je veel meer controle hebt over wat waar vandaan komt, en hoe je het benadert.

[Cartman!]

remco_k schreef op vrijdag 30 mei 2008 @ 19:30:
[...]
als ik een nummer of id mee wil geven aan een query check ik die altijd met de is_numeric() functie.

is_numeric is niet zo veilig als je denkt, lees de manual maar : http://nl2.php.net/is_numeric

[remco_k]

Cartman! schreef op vrijdag 30 mei 2008 @ 21:27:
[...]


is_numeric is niet zo veilig als je denkt, lees de manual maar : http://nl2.php.net/is_numeric

Zoals ik dacht en denk dat het werkt;
Ik gebruik is_numeric() puur om SQL injection te voorkomen. Het lijk me dat dat prima kan?
Als is_numeric() FALSE teruggeeft, dan voer ik de SQL code geheel niet uit, als is_numeric() TRUE teruggeeft dan wel. Ik weet dan in ieder geval zeker dat er -een- getal in de variabele staat. Welke, geen idee, maar daarmee kan dan ook geen SQL injection gedaan worden.
Of zie ik iets over het hoofd?

[curry684]

ctype_digit is stukken zuiverder.

Qua security hoef je maar 1 regel te onthouden en die op iedere regel code toe te passen die je schrijft:

NEVER - TRUST - INPUT

[remco_k]

@eensch met hierboven.

Op 't werk benoemen we dat doel (en nog wat andere doelen) met de volgende zin:
Hufterproof maken.

Heb dat nu ook gedeeltelijk toegepast op de PHP scripts en ga er nog even mee verder.

[Joolee]

http://www.phpfreakz.nl/artikelen.php?aid=106 raad ik altijd aan aan mensen. Voor mijzelf is het al een hele tijd geleden dat ik hem heb doorgelezen maar volgens mij stonden er wel goede dingen in.

Kun je trouwens niet gewoon een functie maken waarin je die 'modules' include? Dan gebruiken ze ook een eigen scope (of er moet ergens $GLOBALS gebruikt worden)
Quick en dirty oplossing toch?