Variabele in logfile

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

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/

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

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.

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

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.

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

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