[cgi] Waarom cgi-bin beperking

[RolandWitvoet]

Veel providers staan perl (en andere cgi-scripts) alleen toe in de cgi-bin directory, terwijl ze php wel toestaan vanaf elke lokatie. Waarom is dat?

[Eelke Spaak]

Omdat CGI-scripts bepaalde toegangsrechten nodig hebben (execute) om te werken, en PHP-scripts niet, omdat die geïnterpreteerd worden door de PHP-parser.

Edit: Oja, een provider zet dan altijd de execute-rechten op de cgi-bin directory aan .

[ Voor 24% gewijzigd door Eelke Spaak op 03-04-2004 19:54 ]

[Soultaker]

Ik denk dat het een overblijfsel is uit de tijd dat het gros van de pagina's statisch was en er maar een beperkt aantal programma's waren die in cgi-bin geplaatst werden. Dat waren immers uitzonderingen.

Er is geen enkele technische reden waarom je geen executable files in de hoofddirectory zou kunnen plaatsen.

[Eelke Spaak]

Soultaker schreef op 03 april 2004 @ 19:56:
Ik denk dat het een overblijfsel is uit de tijd dat het gros van de pagina's statisch was en er maar een beperkt aantal programma's waren die in cgi-bin geplaatst werden. Dat waren immers uitzonderingen.

Er is geen enkele technische reden waarom je geen executable files in de hoofddirectory zou kunnen plaatsen.

Wel dus: er moeten execute-rechten zijn voor executable files.

[aardbeix15]

Vladimir G. schreef op 03 april 2004 @ 19:57:
[...]

Wel dus: er moeten execute-rechten zijn voor executable files.

exact, en door hiervoor 1 dir af te sprken is het mooi overzichtelijk op welke dirs speciale rechten gezet zijn.

PHP e.d. worden client-side uitgevoerd, cgi/perl server-side, vandaar het verschil.

[TNijpjes]

aardbeix15 schreef op 03 april 2004 @ 19:59:
[...]

exact, en door hiervoor 1 dir af te sprken is het mooi overzichtelijk op welke dirs speciale rechten gezet zijn.

PHP e.d. worden client-side uitgevoerd, cgi/perl server-side, vandaar het verschil.

PHP client side?? Ik geloof dat je altijd nog een PHP phraser op de server nodig hebt om PHP te phrasen naar HTML wat je browser snapt.

PHP heeft als voordeel dat het geen ongecontroleerde programma's c.q. services op de server kan starten en dus beter te beveiligen is.

[Eelke Spaak]

aardbeix15 schreef op 03 april 2004 @ 19:59:
[...]
PHP e.d. worden client-side uitgevoerd, cgi/perl server-side, vandaar het verschil.

Euhm dat is dan ook weer niet helemaal waar . PHP is wel degelijk een server-side taal (net als ASP of cgi-scripts). Het verschil zit erin dat PHP-scripts niet zelf worden uitgevoerd, maar door een parser worden gehaald die ze vervolgens uitvoert. CGI-scripts zijn shell- of batch-scripts of zelfs binary executables die dus wel zelf worden uitgevoerd. Daarom zijn er execute-rechten voor nodig.

[Verwijderd]

php client-side? euuh, dit wordt net als asp, cgi, perl, jsp,... mooi serverside uitgevoerd.
Anders zou je maar even op elke webserver php kunnen draaien .
EDIT: te laat!
(Vladimir slaat de spijker op de kop)

[ Voor 15% gewijzigd door Verwijderd op 03-04-2004 20:05 ]

[RolandWitvoet]

Je kunt gewoon in de apache config file aangeven waar je je scripts neer wilt kunnen zetten. standaard staat dat op cgi-bin/ maar het is net zo simpel om het ook op de andere dirs te zetten. En waar je de scripts ook neer zet, je moet altijd nog zelf de execute rechten zetten.
Op mijn eigen server heb ik dit aangepast, daar mag ik overal scripts neerzetten (dan kun je tenminste mooie url's maken en index.pl scripts gebruiken)
Maar het gros van de providers houdt er aan vast dat je scripts alleen in cgi-bin neetzet. (vaak kun je dat met .htaccess files wel overrulen, maar a) soms vinden ze het niet leuk dat je dat doet en maken ze het ongedaan zodra ze er achter komen b) Ik ben nog geen provider tegengekomen die dat duidelijk maakt in het overzichtje van hun diensten.

Aardbei: php wordt echt serverside uitgevoerd. Om 'voor het overzicht' perl-scripts alleen in cgi-bin toe te staan staat in vreemde verhouding tot php-scripts die wel overal worden toegestaan.

-edit-
Met mod_perl wordt ook perl door een parser gehaald en ik kan ook met php system calls doen. Wat beveiliging betreft zie ik het verschil niet. Misschien dat bugs in perl (niet mod_perl) makkelijker te exploiten zijn dan in php vanwege de parser?

En idd: het is een interpreter. Maar ook perl-scripts worden uitgevoerd door een interpreter, nl perl. Het verschil is dat php een apache module is (net als mod_perl) en perl niet. maar nogmaals, ik zie niet in waarom dat zou verklaren waarom je php wel overal toestaat, maar perl niet.

Het enige verschil dat ik zie is dat als je de execute-rechten vergeet in de cgi-bin directory is dat je dan een server error krijgt terwijl je in de www-directories de source van het script in de browser krijgt. Dat laatste wil je niet, maar dan heb je het script ook nooit uitgevoerd gehad, de kans dat je dat vergeet is extreem klein.

[ Voor 36% gewijzigd door RolandWitvoet op 03-04-2004 20:24 ]

[Zoijar]

CrossMozes schreef op 03 april 2004 @ 20:02:
PHP client side?? Ik geloof dat je altijd nog een PHP phraser op de server nodig

Interpreter heet zoiets, parser is daar alleen een onderdeel van

[Infinitive]

PHP heeft als voordeel dat het geen ongecontroleerde programma's c.q. services op de server kan starten en dus beter te beveiligen is.

PHP draait als module niet veiliger dan een CGI programma. In tegendeel zelfs: php draait in hetzelfde process als de webserver en heeft daardoor dezelfde rechten als de webserver. Bijvoorbeeld leesrechten in files van andere gebruikers. Dit wordt opgelost door de safe-mode te gebruiken, zodat php scripts zelf dit niet zomaar kunnen. Maar als je shell commando's uitvoert vanaf php dan wordt die controle bijvoorbeeld niet gedaan (hoewel bij het starten van de shell wel weer de juiste gebruiker kan worden gekozen). Of wat te denken van een exploits via bugs in php...

CGI programma's kunnen daarentegen wel onder de juiste gebruiker worden uitgevoerd door de juiste rechten aan de cgi-executable te geven.

[Soultaker]

Ik heb het altijd jammer gevonden dat PHP scripts niet gewoon als de gebruiker uitvoeren van wie de scripts zijn, wat zowel om beveiligingsreden als terwille van de functionaliteit (nieuwe bestanden aanmaken in de homedirectory van de gebruiker) veel beter zou zijn. Om dat mogelijk te maken zou de webserver onder de rootuser moeten draaien en dat gebeurt tegenwoordig (terecht) steeds minder.

[igmar]

Soultaker schreef op 03 april 2004 @ 22:03:
Ik heb het altijd jammer gevonden dat PHP scripts niet gewoon als de gebruiker uitvoeren van wie de scripts zijn, wat zowel om beveiligingsreden als terwille van de functionaliteit (nieuwe bestanden aanmaken in de homedirectory van de gebruiker) veel beter zou zijn. Om dat mogelijk te maken zou de webserver onder de rootuser moeten draaien en dat gebeurt tegenwoordig (terecht) steeds minder.

suPHP of mod_suid, ik zie geen problemen.

[Soultaker]

igmar schreef op 04 april 2004 @ 00:42:
suPHP of mod_suid, ik zie geen problemen.

mod_suid werkt dus alleen als Apache als root draait en dat is in verband met mogelijke exploits niet echt aantrekkelijk. Voor zover ik kan zien voert suPHP gewoon de CGI versie van PHP uit en ik zie dan ook niet wat daar de voordelen van zijn ten opzichte van direct CGI scripts gebruiken.

Zelfs als een van beide oplossingen zou werken, blijft het nog steeds wachten op de hosting providers die er daadwerkelijk gebruik van maken.

[muba]

lol PHP client side en dan ook nog database-bewerkingen kunnen uitvoeren wordt de database dan ook maar ff naar de client gedownload? En daarna weer geupload? Zal leuke problemen opleveren:

jantje bezoekt een php-pagina van een forum en veranderd bijvoorbeeld zijn signature. Ondertussen doet Pietje hetzelfde. Jantje upload de database weer (met zijn nieuwe signature) en Pietje doet dat ook (met Jantjes oude signature).

Grote databases download: ook bijzonder leuk voor niet-breedbandgebruikers.

[ Voor 9% gewijzigd door muba op 04-04-2004 14:12 ]

[RolandWitvoet]

Het is absoluut off-topic, maar databases kun je ook client-side gebruiken zonder dat je daarvoor de database-file hoeft te verplaatsen. Je kunt gewoon connecten naar de database. Je scripts doen dat op localhost, maar je kunt ook naar een externe machine connecten (mits die dat toestaat)

[igmar]

Soultaker schreef op 04 april 2004 @ 01:32:
mod_suid werkt dus alleen als Apache als root draait en dat is in verband met mogelijke exploits niet echt aantrekkelijk.

Heb je ooit wel eens de code ingekeken ? De childs blijven ook met mod_suid gewoon als de apache user draaien. De enige reden waarom die recompile nodig is is om te voorkomen dat apache setuid() calls gaat lopen doen.

D'r is wel een extra risico kwa security, maar dat is met alle services zo.

Zelfs als een van beide oplossingen zou werken, blijft het nog steeds wachten op de hosting providers die er daadwerkelijk gebruik van maken.

mod_suid wordt vaker gebruikt als men denkt, ik heb helaas nog steeds geen weg gevonden om netcraft dat te laten zien.

[Creepy]

RolandWitvoet schreef op 05 april 2004 @ 15:51:
Het is absoluut off-topic, maar databases kun je ook client-side gebruiken zonder dat je daarvoor de database-file hoeft te verplaatsen. Je kunt gewoon connecten naar de database. Je scripts doen dat op localhost, maar je kunt ook naar een externe machine connecten (mits die dat toestaat)

Moet je er natuurlijk wel voor zorgen dat alle clients de juiste software (libs, drivers) hiervoor hebben. Niet elke connectie loopt via ODBC

Als "hoster" wil ik enige controle hebben over welke CGI scripts er draaien op een server, aangezien CGI script rechtstreeks worden uitgevoerd zonder verder enige beperking (eventuele rechten beperking of een ge-chroote webserver, maar verder..). Met bijv. PHP in safemode is het één en ander nog uit te schakelen en in te stellen, met CGI heb je hier totaal geen controle op.

Komt daarbij dat een CGI programma maken iets meer moeite kost dan een PHP script, en een groot deel van de web devvers tegenwoordig die moeite niet meer neemt of wil nemen.

[Creepy]

RolandWitvoet schreef op 03 april 2004 @ 20:10:
Het enige verschil dat ik zie is dat als je de execute-rechten vergeet in de cgi-bin directory is dat je dan een server error krijgt terwijl je in de www-directories de source van het script in de browser krijgt. Dat laatste wil je niet, maar dan heb je het script ook nooit uitgevoerd gehad, de kans dat je dat vergeet is extreem klein.

Een PHP script hoeft geen executable rechten te hebben om te worden uitgevoerd. Als de webserver het script kan lezen, kan hij dit prima voeren aan de PHP interpreter.

Overigens heeft het wel of niet hebben van een executable recht in deze context vrij weinig te maken met security. Tenzij je dus gebruikers overal cgi scripts laat maken. Andere gebruikers met shell access kunnen dan ook deze scripts uitvoeren. Lat je dit door een hoster in de cgi-bin zetten dan kan de hoster dit voorkomen.