Docstoc

MONICA

Document Sample
MONICA Powered By Docstoc
					MONICA
SLIDE 3
1. Introducere
         Astazi, se pare ca in ceea ce priveste softul totul se refera la date: obtinerea lor în baza de date, extragerea din
baza de date, transformarea acestora in informaţii, şi trimiterea lor în altă parte pentru distractie sau profit. Aatacatorii
pot influenţa comenzile SQL pe care le folosim pentru a comunica cu baza noastra de date. Dacă folosim interogări
SQL la controalele de securitate, cum ar fi autentificare, atacatorii ar putea modifica logica acelor interogări pentru a
ocoli securitatea. Ei ar putea modifica interogările pentru a fura, corupe, sau schimba datele. Vor fura chiar de date un
octet la un moment dat dacă au răbdare şi know-how-ul să facă acest lucru.
         Injectarea de cod este exploatarea unui bug care este cauzat de prelucrarea datelor nevalide. Codul de injectare
poate fi folosit de un atacator pentru a introduce (sau "injecta"), cod într-un program de calculator pentru a schimba
cursul de executie. Rezultatele unui atac de injectare de cod pot fi dezastruoase. Datele atacatorului pot fi trisa
inperretatorul si executa executarea comenzi neintenţionate sau accesa date neautorizate.
         Neutralizarea necorespunzătoare de elemente speciale, folosite într-o comandă SQL (numita si injectarea
comenzilor SQL) este o tehnica de injectare cod des folosita care exploateaza o vulnerabilitate de securitate care
apare la nivelul bazei de date a unei aplicatii prin intermediul paginilor web. Vulnerabilitatea este prezenta atunci
când datele introduse de utilizator sunt fie incorect filtrate de caractere de tip escape încorporate în declaraţii SQL sau
datele introduse de utilizator nu sunt tastate normal şi, prin urmare, executate în mod neaşteptat. Este o instanţă a unei
clase mai generale de vulnerabilitati ce pot apărea ori de câte ori un limbaj de programare sau limbaj de scripting este
înglobat în altul. Atacurile SQL injection sunt, de asemenea, cunoscut sub numele de atacuri de inserţie SQL.
         Injectarea SQL se afla pe primul loc in topul “OWASP Top 10 – 2010. The Ten Most Critical Web
Applications Security Risks” sip e locul al 2-lea in “2010 CWE/SANS Top 25 Most Dangerous Software Errors”.
MONICA
SLIDE 4
2. Forme de vulnerabilitate
2.1. Caractere escape filtrate incorect
           Această formă de injecţie SQL apare atunci cand datele introduse de utilizator nu sunt filtrate pentru
caracterele escape şi sunt apoi trecute intr-o interogare SQL. Acest lucru duce la manipularea declaraţiilor efectuate
în baza de date de către utilizatorul final a cererii. Următoarea linie de cod ilustrează aceasta vulnerabilitate: SELECT
* FROM users WHERE name = '" + userName + "';
         Acest cod SQL este conceput pentru a extrage înregistrările cu numele de utilizator specificat din tabelul de
utilizatori. Cu toate acestea, în cazul în care variabila "nume de utilizator" este concepută într-un mod specific de
către un utilizator rău intenţionat, instructiunea SQL poate face mai mult decat autorul codului intentiona. De
exemplu, setarea variabilei "nume de utilizator" ca "or '1'= '1 ';--" sau utilizarea comentariilor pentru a bloca restul
interogarii ( "or '1' = '1' ;/* " ): SELECT * FROM users WHERE name = '' OR '1'='1';
           Dacă acest cod ar fi folosit într-o procedură de autentificare, atunci acest exemplu ar putea fi utilizat pentru
a forta alegerea unui nume de utilizator valid, deoarece evaluarea '1 '= '1' este întotdeauna adevărata.
           Următoarele valori de "nume de utilizator" în situaţia de mai jos ar duce la eliminarea tabelei "utilizatori",
precum şi de selectarea tuturor datelor din tabela "UserInfo" (în esenţă, dezvăluirea de informaţii de la fiecare
utilizator),        folosind           un      API         care          permite        mai         multor         declaraţii:
a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't Aceasta intrare face declaraţia finală SQL, după
cum urmează: SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo
WHERE 't' = 't';
MONICA
SLIDE 5
2.2. Manevrarea incorecta a tipurilor
           Această formă de injecţie SQL are loc atunci când un camp furnizat de utilizator nu este tastat corect sau nu
este verificat pentru constrângeri de tip. Acest lucru ar putea avea loc atunci când un câmp numeric urmează să fie
utilizat într-o declaraţie SQL, dar nici un programator nu controleaza daca datele furnizate la intrare sunt numerice.
De exemplu: SELECT * FROM UserInfo WHERE id = "+ a_variable +"; Este clar din această declaraţie că autorul
intentiona ca a_variable să fie un număr corelat la campul ”id". Cu toate acestea, în cazul în care acesta este de fapt
un şir, atunci utilizatorul poate manipula comanda, ocolind astfel nevoia de caractere de evacuare. De exemplu,
setarea a_variable la 1;DROP TABLE users va şterge tabela "users" din baza de date, deoarece comanda SQL ar fi
devenit, după cum urmează: SELECT * FROM UserInfo WHERE id = 1; utilizatori DROP TABLE;
IOANA
SLIDE 6
2.3. Injectarea oarba SQL
        Injectarea oarba SQL este utilizata atunci când o aplicaţie web este vulnerabil la o injecţie SQL, dar
rezultatele de injectare nu sunt vizibile la atacator. Este posibil ca pagina cu vulnerabilitatea sa nu fie cea care
afişează date, dar va afişa, în mod diferit, în funcţie de rezultatele unei declaraţii injectate SQL solicitate pentru acea
pagină. Acest tip de atac poate dura mult timp, deoarece o nouă declaraţie trebuie să fie creata pentru fiecare bit
recuperat.
Raspunsuri conditionale
        Un tip de injectare oarba a comenzilor SQL forteaza baza de date sa evalueze o declaraţie logică:
                       SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1;
va rezulta într-o pagină normală, în timp ce
                       SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2;
va da probabil un rezultat diferit în cazul în care pagina este vulnerabilă la un SQL injection. O injecţie ca aceasta
poate sugera atacatorului faptul ca o injectare oarba a comenzilor SQL este posibila, lăsând atacatorul să elaboreze
interogari care vor evalua la true sau false, în funcţie de conţinutul altei coloane sau tabel din afara listei de coloane
din interogarea SELECT.
Erori conditionale
        Acest tip de injectare oarba a comenzilor SQL cauzeaza o eroare SQL fortand baza de date sa evalueze o
interogare ce transmite o eroare daca expresia din WHERE este adevarata
                                  SELECT 1/0 FROM users WHERE username='Roger';
Impartirea la 0 va fi evaluate si va rezulta o eroare daca utilizatorul Roger exista.
Intârzieri
Întârzierile sunt un tip de injectare oarba a comenzilor SQL care provoacă executia unei interogari care ar rula intr-o
perioada indelungata de timp. Atacatorul poate măsura apoi timpul necesar pentru ca pagina sa se inacarce pentru a
determina dacă interogarea injectata este adevărata.
IOANA
SLIDE 7
3. Consecinte
Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with
SQL Injection vulnerabilities.
Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect
to a system as another user with no previous knowledge of the password.
Authorization: If authorization information is held in a SQL database, it may be possible to change this information
through the successful exploitation of a SQL Injection vulnerability.
Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete
this information with a SQL Injection attack.
       Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can
cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to
bypass security checks, or to insert additional statements that modify the back-end database, possibly including
execution of system commands.
       SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and
easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an
attempted attack of this kind. This flaw depends on the fact that SQL makes no real distinction between the control
and data planes.
       This weakness typically appears in data-rich applications that save user inputs in a database.

SORIN
SLIDE 8
3. Demo
SIMONA
SLIDE 9
4. Prevenire
        Some tools for automatically finding SQL injection are: HP WebInspect (conducts a full assessment of the
security of a Web site; this tool requires no technical knowledge and runs a full scan, testing for misconfigurations
and vulnerabilities at the application server and Web application layers), IBM Rational AppScan (runs in a similar
manner to WebInspect, crawling the targeted Web site and testing for a large range of potential vulnerabilities; the
application detects regular SQL injection and blind SQL injection vulnerabilities, but it doesn’t include a tool for
exploitation as does WebInspect), HP Scrawlr (crawls the URL specified and analyzes the parameters of each Web
page for SQL injection vulnerabilities; HTTP crawling is the action of retrieving a Web page and identifying the Web
links contained on it; this action is repeated for each identified link until all the linked content of the Web site has
been retrieved; this is how Web assessment tools create a map of the target Web site and how search engines index
contents; during the crawling process Web assessment tools also store parameter information for later testing.),
SQLiX (is a scanner that is able to crawl Web sites and detect SQL injection and blind SQL injection vulnerabilities),
Raros Proxy (Web assessment tool primarily used for manually manipulating Web traffic; it acts as a proxy and traps
the requests made from the Web browser, allowing manipulation of the data sent to the server).
a. Sa nu avem incredere in datele de intrare
        Dezvoltatorii ar trebui să lucreze pentru a se asigura că intrările sunt dezinfectate înainte de interogarea bazei
de date, sa se asigure că datele pe care utilizatorii le dau la intrare sa fie exact datele pe care le căutam, deci, dacă
cerem de exemplu CNP-ul, dorim sa ne asiguram ca nu exista litere la intrare.
b. Declaraţii parametrizate
        Pentru a ne proteja împotriva injecţie SQL, datele introduse de utilizator nu trebuie să fie direct încorporate în
declaraţiile SQL. În schimb, declaraţiile parametrizate trebuie să fie utilizate, iar date introduse de utilizator trebuie să
fie atent filtrate.
    Language specific recommendations:
     Java EE – use PreparedStatement() with bind variables
     .NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
     PHP – use PDO with strongly typed parameterized queries (using bindParam())
     Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)
c. Implementarea filtrelor si a uneltelor de monitorizare
        Filtering and monitoring tools at the Web application and database levels will help block attacks and detect
attack behavior in order to mitigate risk of exposure to mass SQL injection attacks.
        At the application level, organizations should implement runtime security monitoring to defend against SQL
injection attacks and vulnerabilities in production systems. Similarly, Web application firewalls can help
organizations put certain behavior-based rule sets in place to block attacks before they do damage.
        On the database, database activity monitoring can also filter attacks from the back end. Database activity
monitoring is a great tool against SQL injections. For example, for known injection attacks, there's always filters out
there that will help alert the DBAs that something bad is going on and there's also some pretty generic filters that look
for things that are very typical in SQL injections -- things like an uneven number of quotes that break up the SQL
code.
d. Evitarea aruncarii mesajelor de eroare care dau informatii detaliate
        Hackers can and will use error messages to better dial in future attacks. That's why both the development team
and DBAs need to think about the error messages they're returning when users input something unexpected.
Organizations should configure the Web and database servers to not output error or warning messages. Attackers can
use such messages to learn about your database schema using techniques such as 'blind SQL injection'.
e. Configurarea bazei de date
        The risks associated with SQL injections are escalated when the databases tied to the Web applications under
attack are weak due to poor patching and configuration.
f. Limitarea privilegiilor la baza de date
        Organizations need to do a better job at managing how accounts associated with Web applications are
interacting with back-end databases. Many problems arise due to DBAs giving carte blanche to these accounts in
order to make developers' lives easier. But these super accounts are very vulnerable to attack and greatly broaden the
risks to databases posed by SQL injection and other Web app-based attacks. They need to make sure they don't have
any rights to make changes on the database.
IULIAN
Slide 10-11
5. Exemple din lumea reală
    • 1 noiembrie 2005: un elev de liceu foloseste injectarea comenzilor SQL pentru a sparge site-ul unei reviste
       din Taiwan (a grupului Tech Target) cu informatii din securitatea informatiei si fura informatiile clientilor.
    • 12 ianuarie 2006: Hackeri rusi sparg pagina guvernului din Rhode Island si fura datele din cardurile de credit
       ale persoanelor care au incheiat tranzactii online cu agentiile de stat.
    • 29 martie 2006: Susam Pal descopera o poblema intr-un site official de turism al guvernului Indian ce ar
       putea duce la atacul prin injectare SQL 29 iunie 2007: un hacker sterge informatiile de pe pagina Microsoft
       UK folosind injectarea SQL. Pe pagina ziarului “The Register”, a fost citat un purtator de cuvant al Microsoft
       care a confirmat problema.
    • ianuarie 2008: zeci de mii de calculatoare sunt infectate de un atac de injectare a comenzilor SQL care
       exploateaza o vulnerabilitate in codul aplicatiei care utilizeaza drept baza de date Microsoft SQL Server.
    • mai 2008: in China sunt folosite interogari automate pentru motorul de cautare “Google” cu scopul de a
       identifica paginile web care sunt vulnerabile unui atac de injectare.
    • aprilie – august 2008: o serie de atacuri exploateaza vulnerabilitatile injectarii comenzilor SQL in cadrul
       serverului IIS al Microsoft si serverul bazelor de date al SQL Server. Atacul nu necesita ghicirea numelui unei
       tabele sau coloane, si corupe toate coloanele text din toate tabelele printr-o singura cerere. Un string HTML
       referentiind un malware JavaScript este atasat fiecarei valori. Cand valoarea din baza de date este afisata
       ulterior unui vizitator al site-ului, scriptul incearca diverse metode pentru a castiga controlul asupra sistemului
       vizitatorului.
    • 17 august 2009: Departamentul de Justitie al SUA acuza un cetatean American impreuna cu doi cetateni rusi
       de furtul a 130 milioane de numere de carduri de credit utilizand injectarea comenzilor SQL.
    •    decembrie 2009: un atacator sparge o baza de date de text (RockYou) continand nume de utilizatori si
       parole necriptate a aproximativ 32 milioane de oameni, prin injectarea comenzilor SQL
    •    iulie 2010: un cercetator sud-american in securitate (Ch RUsso) obtine informatiile utilizatorilor site-ului
       BitTorrent si The Pirate Bay (castiga acces la panoul de control administrative si exploateaza vulnerabilitatea
       la injectarea comenzilor SQL, colectand informatii din conturile utilizatorilor, inclusiv adresa IP, parola hash
       MD5 si liste cu fisierele torrent accesate de acestia).
    •    24-26 iulie 2010: atacatori din Japonia si China utilizeaza injectarea SQL pentru a castiga acces la datele de
       pe cardurile de credit ale clientilor companiei Neo Beat ce detine un supermarket online. Atacatorul a afectat
       si alti sapte parteneri (inclusiv lanturile de supermarketuri Izumiya Co, Maruetsu Inc si Ryukyu Jusco Co).
       Furtul de date a afectat un numar de 12.191 de clienti. La data de 14 august 2010 s-au raportat peste 300 de
       cazuri de utilizari ale informatiilor de pe cardurile de credit de catre atacatori care au achizitionat bunuri si
       servicii in China.

IULIAN
Slide 12
6. Bibliografie

Concluzie: The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser
extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In
general, consider SQL Injection a high impact severity.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:21
posted:1/11/2012
language:Romanian
pages:4