Virtuaalserver

Tõlkida koos – http://shiflett.org/articles/shared-hosting

Tere tulemast teise väljaanne Turvalisuse Nurgas. See kuu, ma olen valinud teema, mis on probleemiks paljude jaoks on PHP arendajad, jagatud hosting. Läbi minu kaasamine PHPCommunity.org projekt, minu panused erinevate meililistide ja hoides silma peal PHP blogid ja uudiste saidid, ma olen näinud selle teema üles kasvanud erinevate kehastuste. Mõned inimesed on mures, varjates oma andmebaasi juurdepääsu volikirja, mõned on mures safe_mode on lubatud või keelatud, ja teised lihtsalt tahan teada, mida nad peaksid muretsema, kui midagi.

Tulemusena, olen otsustanud, et lahendada neid probleeme nii palju üksikasju kui võimalik, nii, et teil on parem arusaamine ja tunnustust jagatud hosting julgeoleku riske. Pärast lugemist see artikkel, võite otsustada, kas seal on midagi, et sa olla mures.

VIRTUAALSERVER

Kuna tulek HTTP/1.1 ja nõutavad Host päis, jagatud hosting on muutunud väga populaarseks. Ilma et see päis puudub otsene viis, web klient tuvastada domeeni. See muudab TCP/IP connection to host kindlaks määratud domeeni, ja see, kui ta saadab oma taotluse, mis võib olla sama lihtne kui järgmised:

  1. GET /path/to/script.php HTTP/1.0

Pane tähele, et URL esitatud taotlus ei sisalda domeeni nimi. Sest see on tarbetu, eeldades, et ainult üks domeen on kätte eelkõige server. HTTP/1.1, Vastuvõtva muutub nõutav päis, nii lihtne taotlus peab olema esitatud järgmiselt:

  1. GET /path/to/script.php HTTP/1.1
  2. Host: example.org

Selle vormingu puhul, ühe web server server paljudes valdkondades, sest klient tuleb tuvastada domeeni. Selle tulemusena hosting ettevõte, mahutab palju domeene ühele server, ja see ei ole vajalik olla eraldi avalik IP iga domeeni jaoks. Selle tulemuseks palju rohkem odav hosting ja innustas tohutu kasvu web ise. Muidugi, see on liikumapanev jõud alguses PHP vastu samuti.

Negatiivne jagatud hosting on, et see võtab mõned turvalisuse riskid, mida ei ole olemas spetsiaalne server keskkonnas. Mõned riskid on maandatud, mida PHP safe_mode direktiivi, kuid see ei ole lahendamiseks algpõhjuse kõige julgeoleku riskid, ja mõistmiseni, et neid riske on vaja mõista, mida safe_mode teeb ja ei tee. Kuna see, ma alustan, kehtestades mõned unikaalsed riskid jagatud hosting.

FAILISÜSTEEMI TURVALISUS

Tõeline multi-kasutaja operatsioonisüsteemi, näiteks Linux on ehitatud täiesti turvaline lähenemine kasutaja õigused. Kui loote uue faili, saate määrata kindla õigused selle faili. See on saavutatud andes iga faili nii kasutaja ja grupi omandiõigus, samuti komplekt privileegid kolme gruppi inimesi:

  • Kasutaja
  • Grupp
  • Muud

Privileegid, et teil on võimalik määrata iga kategooria kasutaja hulka lugeda, kirjutada ja ellu viia (seal on mõned detailid, kuid need ei puutu asjasse, et praegune arutelu). Selle selgitamiseks edasi, kaaluge järgmist faili noteerimiseks:

  1. -rw-r--r-- 1 chris shiflett 4321 May 21 12:34 security-corner

See fail, security-corner, kuulub kasutajale chris ja grupi shiflett. Õigused on määratletud -rw-r–r–, ja see võib olla jagatud juhtiv sidekriipsu (märkides tavaline fail) ning kolme rühma õigused:

  • rw- (lugeda, kirjutada, no täita)
  • r-- (lugeda, no kirjutada, no täita)
  • r-- (lugeda, no kirjutada, no täita)

Need kolmed load vastavad otseselt kolme rühma kasutajaid: kasutaja (chris), group (shiflett), ja muud.

Linuxi kasutajad on ilmselt tuttavad need õigused ja kuidas muuta neid käske, nagu chown ja chmod. Põhjalikum selgitus failisüsteemi turvalisus, lugeda Linux Turvalisuse Kuidas: Faili ja Faili Süsteemi Turvalisuse.

Kui kasutaja jagatud vastuvõtva, see on ebatõenäoline, et te olete lugenud juurdepääs palju faile väljaspool oma kodu kataloogi. Te kindlasti ei tohiks võimalik sirvida kataloogi või dokumendi juur teiste kasutajad. Siiski, lihtsa PHP skripti, see võib olla võimalik.

SIRVIMINE PHP

Selle arutelu eeldame, et veebiserver on Apache ja, et see töötab, sest mitte nobody. Selleks, Apache, et olla suuteline teenima oma veebilehe sisu, et sisu peab olema loetav mitte nobody. See sisaldab pilte, HTML-faile, ja PHP skriptid. Seega, kui keegi võiks saada samasugused õigused nagu nobody serveris, nad vähemalt on juurdepääs kõigile veebi sisu, isegi kui on võetud ettevaatusabinõud, et vältida juurdepääsu mis tahes muu kasutaja.

Kui Apache täidab oma PHP skriptid, see muidugi teeb seda nobody. Kombineeri seda koos Failid ja failisüsteem SecurityPHP rikkalikku komplekti failisüsteemi funktsioonid, ja siis tuleb hakata mõistma, et riski. Teha riski selgem, ma olen kirjutanud väga lihtne failisüsteemi sirvija PHP (Vt Kandmise 1). See skript väljundid praegune seadistus safe_mode direktiivi (informeerimise eesmärgil) ja võimaldab teil sirvida kohaliku failisüsteemi. See on näide tüüpi skripti ründaja võiks kirjutada, kuigi mitmed lisaseadmed oleks tõenäoliselt lisanud teha pahatahtliku tegevuse mugavam.

Lisamise 1:

  1. <?php
  2.  
  3. echo "<pre>\n";
  4.  
  5. if (ini_get('safe_mode')) {
  6.     echo "[safe_mode enabled]\n\n";
  7. } else {
  8.     echo "[safe_mode disabled]\n\n";
  9. }
  10.  
  11. if (isset($_GET['dir'])) {
  12.     ls($_GET['dir']);
  13. } elseif (isset($_GET['file'])) {
  14.     cat($_GET['file']);
  15. } else {
  16.     ls('/');
  17. }
  18.  
  19. echo "</pre>\n";
  20.  
  21. function ls($dir)
  22. {
  23.     $handle = dir($dir);
  24.     while ($filename = $handle->read()) {
  25.         $size = filesize("$dir$filename");
  26.  
  27.         if (is_dir("$dir$filename")) {
  28.             if (is_readable("$dir$filename")) {
  29.                 $line = str_pad($size, 15);
  30.                 $line .= "<a href="{$_SERVER['PHP_SELF']}?dir=$dir$filename/">$filename/</a>";
  31.             } else {
  32.                 $line = str_pad($size, 15);
  33.                 $line .= "$filename/";
  34.             }
  35.         } else {
  36.             if (is_readable("$dir$filename")) {
  37.                 $line = str_pad($size, 15);
  38.                 $line .= "<a href="{$_SERVER['PHP_SELF']}?file=$dir$filename">$filename</a>";
  39.             } else {
  40.                 $line = str_pad($size, 15);
  41.                 $line .= $filename;
  42.             }
  43.         }
  44.  
  45.         echo "$line\n";
  46.     }
  47.  
  48.     $handle->close();
  49. }
  50.  
  51. function cat($file)
  52. {
  53.     $contents = file_get_content($file);
  54.     echo htmlentities($content, ENT_QUOTES, 'UTF-8');
  55. }
  56.  
  57. ?>

Üks esimesi kohti ründaja võiksite lühidalt on /etc/passwd. See saavutatakse kas sirvimise seal root kataloogi (kus skript hakkab) või külastades URL-i otse (helistades skripti ?file=/etc/passwd).

See annab ründaja kasutajate nimekirja ja nende kodukataloogid. Teine fail huvi võib olla httpd.conf. Eeldades, et iga kasutaja home kataloog on kataloog nimega public_html vastava dokumendi juured, ründaja saab sirvida teise kasutaja veebisisu, helistades skripti ?dir=/home/kannatanu/public_html/.

Julgeoleku-teadlik kasutaja tõenäoliselt hoida tundliku konfiguratsiooni faile ja nagu kuskil väljaspool dokumendi juur. Näiteks, võib-olla andmebaasi kasutajanimi ja parool salvestatakse faili nimega db.kasvata ja lisatud koodi, mis sarnaneb järgmisele:

  1. <?php
  2.  
  3. include '../inc/db.inc';
  4.  
  5. ?>

See on tark, kuid kahjuks ründaja saab veel vaadata seda faili helistades browse.php skripti ?file=/home/victim/inc/db.inc. Miks see tingimata tööd? Eest hõlmavad kõne, et olla edukas, Apache peab lugenud failile juurdepääs. Seega, see skript peab olema ka juurdepääs. Lisaks, kuna kasutaja sisselogimismandaati, on sageli samad, andmebaasi juurdepääsu volikirja, see meetod võib ründajal lubada vähenda konto serveris (ja käivitada täiendavaid rünnakute ohustatud kontod).

Seal on ka võimaliku ründaja, et kasutada selle sama skripti pääseda kellegi seansi andmeid. Lihtsalt sirvimiseks /tmp kataloogi (?dir=/tmp/), siis on võimalik lugeda kõiki istungil, et on seal ladustatud. Mõned täiustused skripti, see võiks olla isegi lihtsam vaatamiseks ja/või muutmiseks seansi andmeid need failid. Ründaja võiks külastada oma rakendus ja seejärel muutke seotud istungil anda administraatori juurdepääsu rajada profiili informatsiooni, või midagi sarnast. Ja, sest ründaja võib sirvida allikas, et oma rakendusi, see ei ole isegi vaja mõistatama. Ründaja teab täpselt, mida sessiooni muutujad rakenduste kasutamiseks.

Muidugi, see on palju turvalisem, et salvestada sessiooni andmed oma andmebaasi, kuid me oleme just näinud, kuidas ründaja võib saada ligipääsu, et hästi. Kui safe_mode direktiiv aitab vältida nende rünnakuid.

KONFIGURATSIOONI DIREKTIIVID

Kui safe_mode direktiivi on spetsiaalselt projekteeritud, et püüda leevendada mõned neist virtuaalserver muresid. Kui te tegelikkuses töötab skripti Kandmise 1 oma serverisse, saad proovida, mis võimaldab safe_mode ja jälgida, kui palju vähem tõhus skripti muutub.

When safe_mode is enabled, PHP kontrollib, kas omanik skripti hukatakse sobib, et faili avamisel. Seega, PHP skripti, mille omanikuks te ei saa avada faile, mis ei kuulu sulle. Oma PHP skriptid on tegelikult rohkem piiratud kui teil on alates shell, kui safe_mode on lubatud, sest siis on teil tõenäoliselt loe juurdepääsu failidele, mida ei ole konkreetselt kuulub teile. See range kontroll võib olla lõdvestunud mõnevõrra võimaldades safe_mode_gid. Käesoleva direktiivi lõdvestab kontroll rühma asemel kasutaja.

Sest safe_mode võib põhjustada probleeme kasutajatele, kes on õigustatud põhjusel, et pääsete failide juurde kuulub teise kasutaja poolt, seal on mõned muud direktiivid, mis võimaldavad veelgi suuremat paindlikkust. Kui safe_mode_include_dir direktiiv võib määrata ühe või mitu kataloogid, kust kasutajad saavad lisada faile, olenemata omandivormist. Ma kutsun teid üles lugeda http://php.net/features.safe-mode rohkem infot.

Sarnane PHP direktiivi on open_basedir. Käesolev direktiiv võimaldab piirata kõik PHP skriptid, et ainult saaks faile avada jooksul kataloogid käesolevas direktiivis kindlaks määratud, sõltumata sellest, kas safe_mode is enabled.

MÖÖDA SAFE_MODE

Muidugi, safe_mode ainult kaitseb inimesi, kasutades PHP pääseda muul viisil piiratud andmed. See ei tee midagi, et kaitsta teid keegi oma jagatud server, kes kirjutab sama programmi teises keeles. Näiteks, miks peaks Perli interpretaator huvita, mida on php.ini? Käsitsi sätestab:

See on arhitektuuriliselt vale püüda lahendada see probleem PHP tasandil, kuid kuna alternatiivide veebi server ja OS-i tasandil ei ole väga realistlik, paljud inimesed, eriti interneti-teenuse pakkuja, kasutada safe mode nüüd.

Kaaluge järgmist CGI skript kirjutatud Bash:

  1. #!/bin/bash
  2.  
  3. echo "Content-Type: text/plain"
  4. echo ""
  5. cat /etc/passwd

See on väljund sisu /etc/passwd nii kaua, kui Apache on võimalik lugeda, et faili. Nii et me oleme tagasi sama dilemma ees. Kui ründaja ei saa kasutada skripti Kandmise 1 sirvida filesystem when safe_mode is enabled, seda ei saa välistada sarnaseid skriptid kirjutatud muus keeles.

MIDA SAAB TEHA?

Sa ilmselt teadsid, et jagatud host oli vähem turvaline kui ettenähtu ammu enne, kui see artikkel. Õnneks, seal on mõned lahendused mõned probleemid, mis ma esitasin, kuid mitte kõik. Põhimõtteliselt on olemas kaks peamist samme, et soovite teha ühine vastuvõtva:

  • Hoidke kõiki tundlikke andmeid, näiteks seansi andmeid, mis on andmebaasi salvestatud.
  • Hoia oma andmebaasi juurdepääsu volikirja, mis on ohutu.

Kuidas sa hoida oma andmebaasi juurdepääsu volikirja ohutu? Kui teine kasutaja võib potentsiaalselt on juurdepääs mis tahes faili, et me kättesaadavaks teha, Apache, tundub, et pole kuhugi peita. Minu lemmik lahendus sellele probleemile on üks, mis on kirjeldatud PHP Kokaraamat, David Sklar ja Adam Trachtenberg.

Lähenemisviis on kasutada keskkonna muutujad salvestada tundlikke andmeid (näiteks oma andmebaasi juurdepääsu volikirjad). Koos Apache, saate kasutada SetEnv käesoleva direktiivi:

  1. SetEnv DB_USER "myuser"
  2. SetEnv DB_PASS "mypass"

Määrata, kui palju keskkond, muutujad, kui teil on vaja kasutada seda süntaksit ja salvestada see eraldi faili, mis ei ole loetav Apache (nii, et seda ei saa lugeda kasutades tehnikaid kirjeldatud varem). Selles httpd.conf, võite lisada selle faili järgmiselt:

  1. Include "/path/to/secret-stuff"

Muidugi, sa tahad, et hoida neid lisada avaldusi jooksul iga kasutaja VirtualHost plokk, muidu kõik kasutajad saavad kasutada samu andmeid.

Sest Apache on tavaliselt alustas juure on võimalik lisada selle faili, kui ta loeb selle konfiguratsiooni. Sest iga laps protsessi käsitlemise taotluse jookseb nagu keegi, see ei pääse enam seda faili otse, nii, et teised kasutajad ei saa kasutada seda teavet tark skripte.

Kui need keskkonnamuutujad on sätestatud, saab neid kasutada $_SERVER superglobal massiivi. Näiteks:

  1. <?php
  2.  
  3. mysql_connect('localhost', $_SERVER['DB_USER'], $_SERVER['DB_PASS']);
  4.  
  5. ?>

Kuna see teave on salvestatud $_SERVER, siis on vaja hoolitseda, et see massiiv ei ole väljund igal oma skripte. Näiteks kõne phpinfo() näitab kõike alates $_SERVER, nii et sa peaksid tagama, et teil ei ole avalik skriptid, et täita seda funktsiooni.

KUNI JÄRGMISE KORRANI…

Loodetavasti sa nüüd aru, mõned riske koos virtuaalserver ja võib võtta mõned meetmed, et leevendada neid. Samas safe_mode on tore funktsioon, seal on ainult nii palju aidata võib see anda selles osas. See peaks olema selge, et need riskid on tegelikult sõltumatu PHP, ja see on põhjus, miks muud meetmed, mis on vajalikud.

Nagu alati, ma armastan kuulda teie enda lahendusi nende probleemidele. Kuni järgmise kuu jooksul, on ohutu.

 

Tagasi esilehele

Leave a Reply

Your email address will not be published. Required fields are marked *