Onderwerp: PhpSecInfo

Bij het opschonen van een site van me kwam ik deze weer tegen (weet niet of de tests nog relevant zijn) -> http://phpsec.org/projects/phpsecinfo/index.html

PhpSecInfo provides an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.

Bovenstaande lijkt me duidelijk over wat het doet. Probeer het eens zou ik zeggen en misschien kun je er iets mee.
En laat voor de fun eens wat screenshots zien van het uiteindelijke testresultaat van een testserver of zo. Kijken of we kunnen lachen of huilen.

standaard debian 5 php installatie en een directadmin installatie

sommige testen begrijp ik niet goed of werken niet meer goed

CentOS 5.5 install met cPanel. Daar mag nog wat aan gesleuteld worden...
Screenshot is gemaakt met Abduction -> http://tidbits.sydv.net/firefox/extensions/abduction/
Je krijgt er zo een Save Page As Image functie bij en kun je zelf nog de range bepalen. Handig!

Op een van de productieservers. Veel van de notices zijn onzin (e.g. "memory_limit is set to a very high value") en miepen over een temp directory die writable is (joh?!). Daarnaast gaat de test ook voorbij aan maatregelen van gelijke werking die je buiten PHP om treft.

Denk niet dat je een mooi werkbaar systeem hebt voor een shared omgeving als dit script zijn zin krijgt

So much for "The perfect server" setup met Directadmin erop

Een standaard (default installatie hier) directadmin met php5 getest. Dus hierop staan enkele dingen zoals mod_ruid etc aan.

Dingen zoals file upload staan als notice, begrijp de reden maar het moet echt hoger staan in dit geval.

Notice
9 out of 18 (50%)
Pass
9 out of 18 (50%)

Oorspronkelijk geplaatst door Cybafish

Op een van de productieservers. Veel van de notices zijn onzin (e.g. "memory_limit is set to a very high value") en miepen over een temp directory die writable is (joh?!). Daarnaast gaat de test ook voorbij aan maatregelen van gelijke werking die je buiten PHP om treft.

Denk niet dat je een mooi werkbaar systeem hebt voor een shared omgeving als dit script zijn zin krijgt

Kwam ik ook tegen, moet je zelf met een beetje eigen inzicht bekijken.

Oorspronkelijk geplaatst door Cybafish

miepen over een temp directory die writable is (joh?!).

Zou die melding toch niet onderschatten.

Probleem is op zich niet dat /tmp world-readable is, maar dat /tmp door sommigen voor de opslag van de sessiebestanden van meerdere websites gebruikt wordt.

De sessie bestandjes hebben standaard de bestandsnaam "sess_<sessieid>"
Indien andere klanten de bestandsnamen kunnen opvragen (ls /tmp), dan weten ze dus ook de sessienummers die in gebruik zijn, en kunnen deze kapen.
(enige wat nodig is om de sessie van een ander te misbruiken is immers dat je het sessieid kent, deze als cookie in je browser instelt, en de website bezoekt. je hoeft de inhoud van de bestanden zelf niet eens te kennen).

True Max. Daarom iedereen een eigen /tmp en session_safe path geven in de Apache vhost Chroot r0x!
En onder de user draaien zodat de sess_bestanden van de user zijn en niet van Apache;Apache. Zelfs een sticky bit gaat je anders niet tegen diefstal van de inhoud van sessies beschermen.

Allow_url_fopen is ook een vieze depeciated instelling die somige scripts nog gebruiken. Met name om bijvoorbeeld RSS feeds op te halen. CURL it is! Default heb ik deze ook altijd uit staan en bij uitzondering per user open. Probleem is namelijk dat met deze functie vaak ook veel troep binnengehaald wordt.

display_errors en dispose_php (Net zoals Servertokens in Apache die op Prod moeten staan) geven minder snel informatie over de configuratie. Willen klanten deze hebben, kunnen ze phpinfo() en een .htaccess bestand gebruiken en bij voorbeur alleen tijdens development.

Zo zijn er meer zaken te noemen. Het is echt per functie kijken wat je nodig hebt. Zaken als max_upload en max_mem_size kun je snel negeren. Vergeet niet dat het phpSecInfo script ook alweer wat jaren oud is en bijvoorbeeld ver voor de Magento en Framework tijd.

Hm, daar hebben jullie een punt. Anderzijds, het is redelijk vergezocht. Probleem is ook dat als je dit met suPHP voor elkaar wilt krijgen, dat je voor iedereen een eigen php.ini mag aanmaken. Er is wel een workaround zodat je losse php.ini's cumulatief worden geladen en je niet voor iedere wijziging +/- 175 gebruikerseigen php.ini's hoeft aan te passen, maar het blijft alsnog een hele klus.

Daarnaast kun je dan wel voor alle tmp files bombarie gaan maken, want in theorie zou men dus ook de uploads van een ander kunnen onderscheppen, zelfs als deze over SSL binnenkomt. Tweede probleem is dan weer dat de hele site op z'n gat ligt zodra de user over quota is.

Dus ja, wat is wijsheid?

Oorspronkelijk geplaatst door Cybafish

Probleem is ook dat als je dit met suPHP voor elkaar wilt krijgen, dat je voor iedereen een eigen php.ini mag aanmaken. Er is wel een workaround zodat je losse php.ini's cumulatief worden geladen en je niet voor iedere wijziging +/- 175 gebruikerseigen php.ini's hoeft aan te passen, maar het blijft alsnog een hele klus.

Heb zelf ooit een CGI-wrapper geschreven dat simpelweg de home directory van de gebruiker opzoekt, en vervolgens PHP opstart met als command-line optie "-dsession.save_path=/home/$gebruiker/tmp"

Mocht je er wat aan hebben: http://www.je-eigen-domein.nl/yapw.tar.gz

Alleen onder FreeBSD + lighttpd getest, maar kans is groot dat het ook met Linux + Apache werkt.

Daarnaast kun je dan wel voor alle tmp files bombarie gaan maken, want in theorie zou men dus ook de uploads van een ander kunnen onderscheppen, zelfs als deze over SSL binnenkomt.

Als je PHP onder de gebruikersnaam van de klant draait, gaat dat niet zo makkelijk.
De geuploade bestanden komen tijdens het uploaden welliswaar tijdelijk onder de /tmp te staan, maar met permissies waarmee het niet mogelijk is voor andere gebruikers om de INHOUD op te vragen.

Bij sessies is het weten van de BESTANDSNAAM genoeg om de sessie te kapen. Daar zit immers het (geheime) sessienummer in verwerkt.
Met de (random) bestandsnaam van het tijdelijke bestand dat bij file uploads gebruikt wordt kan je weinig stoute dingen doen.

Ja ik volg je redenering. Zal eens kijken of de wrapper soelaas biedt, thanks.

Op wat upload en tmp directories na op mijn eigen webserver met DA:

Notice
6 out of 17 (35.29%)
Pass
11 out of 17 (64.71%)

Kom er ook goed doorheen met wat passes (niet allemaal m.b.t. upload) maar de meeste toch wel goed. Vraag me af in hoeverre je zo'n script nu nog serieus moet nemen zoals Randy ook al aankaart maar het biedt denk ik een goede richtlijn richting een basis opzetje.