Embed
Email

MONICA

Document Sample

Shared by: changcheng2
Categories
Tags
Stats
views:
1
posted:
1/11/2012
language:
pages:
4
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.



Related docs
Other docs by changcheng2
examples
Views: 0  |  Downloads: 0
Reg_2011_Cl_3à_pr_gir_2
Views: 1  |  Downloads: 0
odgupdates
Views: 0  |  Downloads: 0
CecilCounty
Views: 0  |  Downloads: 0
CP_Snow_lect
Views: 0  |  Downloads: 0
Magie_et_croyances
Views: 3  |  Downloads: 0
RFHSnack_bar_Schedule_2010
Views: 1  |  Downloads: 0
Porcelain _ Bakelite Lampholders
Views: 0  |  Downloads: 0
Algebra
Views: 3  |  Downloads: 0
By registering with docstoc.com you agree to our
privacy policy

You are almost ready to download!

You are almost ready to download!