Under possible attacks, there are attacks on the php file themselves. Some php viruses, (injecktor and variations) scan the visible directory tree for php and/or html files, then inject code (such as spam-ware to generate fraudulent page hits) into otherwise harmless and useful .php scripts. One way to block this is by using open_basedir to restrict the visible file system directories to directory tree(s) which do NOT contain any .php scripts. (see doc page "Description of core php.ini directives" Note under open_basedir to tighten open_basedir scope from /www/ which would contain .php scripts to /www/tmp/ which would protect any scripts in /www/ from modification.) If the php.ini is outside the open_basedir tree, than a malware php script has no way to alter the core web site files, even if it were succesfully uploaded via ftp or other mechanism. The damage done by the spam-ware may seem trivial, but as browsers and virus programs eventually recognize the spam-ware the web site becomes effectively completely blocked and un-browsable.
Cazul 1: numai fișierele publice sunt servite clientului
Instalat ca un binar CGI
[edit] Last updated: Fri, 24 May 2013
Instalat ca un binar CGI
[edit] Last updated: Fri, 24 May 2013
Atacuri posibile
Utilizarea PHP în calitate de binar CGI este o opțiune pentru cazurile când dintr-un anume motiv nu se dorește integrarea PHP în calitate de modul în serverul software (precum Apache), sau PHP se va utiliza cu diferite tipuri de învelișuri CGI pentru a crea medii securizate cu ajutorul chroot și setuid pentru scripturi. Această variantă implică de obicei instalarea binarului PHP executabil în directorul cgi-bin al serverului web. Îndrumarul CERT » CA-96.11 nu recomandă plasarea oricărui tip de interpretor de acest gen în directorul cgi-bin. Chiar dacă binarul PHP poate fi folosit ca un interpretor de sine stătător, PHP a fost conceput în așa fel, încât să prevină atacuri, pe care o asemenea variantă de utilizare le face posibilă:
- Accesarea fișierelor din sistem: http://my.host/cgi-bin/php?/etc/passwd Informația din URL de după semnul de întrebare (?) este transmisă interpretorului în calitate de argumente în linia de comandă de către interfața CGI. De obicei interpretoarele deschid și execută fișierul specificat ca prim argument în linia de comandă. Când este apelat ca un binar CGI, PHP refuză să interpreteze argumentele din linia de comandă.
- Accesarea oricărui document web de pe server: http://my.host/cgi-bin/php/secret/doc.html Informațiile introduse în URL după denumirea binarului PHP, /secret/doc.html sunt de obicei utilizate pentru a specifica denumirea și calea către fișierul care trebuie deschis de către interpretorul CGI. De obicei directivele din configurația unui server web (Apache: Action) sunt folosite pentru a redirecționa interpelările către documente ca http://my.host/secret/script.php către interpretorul PHP. În acest caz, serverul web verifică mai întâi permisiunile de acces către directorul /secret, și după aceea creează interpelarea de redirecționare către http://my.host/cgi-bin/php/secret/script.php. Cu regret, dacă interpelarea este inițial scrisă în această formă, serverul web nu efectuează nici o verificare de acces către fișierul /secret/script.php, ci numai către fișierul /cgi-bin/php. În acest fel, orice utilizator care poate accesa fișierul /cgi-bin/php, poate accesa și orice document protejat de pe serverul web. În PHP, directivele de configurare în timpul rulării cgi.force_redirect, doc_root și user_dir pot fi utilizate pentru a preveni acest atac, dacă arborele de documente de pe server conține directoare cu acces restricționat. Observați mai jos explicații detaliate despre diferite combinații.
add a note
User Contributed Notes
Atacuri posibile - [1 notes]
bill1 at nospam dot windhome dot com ¶
1 year ago