Esti aici: Qreferat » Documente informatica

Securitatea in scrierea software-ului

SECURITATEA IN SCRIEREA SOFTWARE-ULUI

Capitolul 1 - Introducere

Pe masura ce Internet-ul creste in importanta, aplicatiile Web devin din ce in ce mai interconectate. Vremurile in care nu conta daca o aplicatie era sau nu sigura, deoarece calculatorul pe care rula nu era conectat intr-o retea, au apus demult. Atata timp cat aplicatia isi indeplinea misiunea, oamenilor nu le pasa de securitate.

Internet-ul este cel mai ostil mediu in care o aplicatie poate rula. Doar numarul mare de utilizatori care folosesc aplicatia poate fi o problema in sine. Utilizatorii pot comite greseli neintentionate care insa pot avea consecinte dezastruoase. Aceste aspecte nu sunt de neglijat, insa preocuparea principala este de a securiza aplicatia in fata actiunilor atacatorilor.

Aplicatiile Intranet se regasesc din ce in ce mai mult in cadrul firmelor, indiferent de profilul acestora. Aplicatii de payroll, de HR, de facturare sunt din ce in ce mai intalnite. La prima vedere nevoia de securitate nu este atat de crescuta ca la aplicatiile Internet. Chiar daca mediul in care ruleaza este unul controlat, utilizatorii interni nu trebuie niciodata subestimati. Un angajat nemultumit poate produce pagube extrem de mari, daca aplicatia nu a fost securizata corect.

Securitatea unei aplicatii este ca platirea taxelor: toti stiu ca e importanta si ca trebuie realizata mai devreme sau mai tarziu, dar acest moment este amanat cat mai mult. Pentru majoritatea aplicatiilor, in special pentru cele Web, securitatea nu este un lux, ci o necesitate, deoarece sunt disponibile atat utilizarii (nu intotdeauna corecte), cat si atacurilor pentru un numar foarte mare de persoane. Protejarea serverelor Web este doar un aspect al securitatii Web.

Aplicatiile construite cu ASP.NET se pot imparti in trei categorii:

Pagini web al caror continut este accesibil tuturor.

Aplicatii Internet care necesita o logare pentru a accesa anumite pagini. Un exemplu ar fi magazinele virtuale: oricine poate vedea produsele disponibile, dar pentru a efectua o comanda este nevoie de un user si o parola.

Aplicatii Intranet care sunt accesibile unui numar restrans de persoane, intr-un cadru controlat (angajatii unei firme, de exemplu), care au conturi intr-un domeniu Windows.

Indiferent de tipul lor, in dezvoltarea aplicatiilor trebuie avute in vedere cateva aspecte:

- cine si cum are va avea dreptul de autliza aplicatia, pentru a determina metodele adecvate de autentificare si autorizare

- validarea datelor de intrare, pentru a proteja informatiile din baza de date de o utlizare incorecta sau de atacuri (injectare SQL, XSS)

- configurarea cat mai sigura a aplicatiei prin intermediul fisierului Web.config

- tratarea erorilor pentru a nu divulga accidental informatii ce ar putea fi folositoare unui atacator.

Capitolul 2 - Autentificare si autorizare

La nivelul aplicatie, securitatea web inseamna in primul rand securizrea paginilor astfel incat acestea sa nu poata fi accesate de persoane neautorizate. Spre exemplu, informatiile despre salarii sau bugete sa nu poata fi vizualitate in intranetul unei companii de catre orice angajat.

In unele cazuri se doreste cunoasterea initiatorului cererii pentru o pagina doar pentru a putea personaliza continutul acesteia. In ambele cazuri ideea este aceeasi: identificarea initializatorului cererii si definirea unor reguli care sa determine cine poate accesa anumite pagini.

Un server web isi identifica apelantii prin mecanismul denumit autentificare. Odata ce autentificarea a fost efectuata pentru un utilizator, prin intermediul autorizarii se decide ce resurse pot fi accesate. ASP.NET suporta o varietate de modele pentru autentificare si autorizare.

Autentificarea permite destinatarului unei cereri sa stabileasca identitatea unui apelant. Acesta poate pretinde ca este Bob, dar acest lucru nu poate fi stiut cu siguranta pana cand autentificarea nu este efectuata. In ASP.NET exista trei tipuri de autentificare:

autentificare de tip Windows

autentificare de tip Passport

autentificare de tip Forms

Odata ce un utilizator a fost identificat, autorizarea este cea care determina ce resurse poate accesa acesta. ASP.NET suporta doua forme de autorizare:

autorizare bazata pe ACL-uri (Access Control List)

autorizare bazata pe URL-uri.

Autorizarea prin intermediul ACL-urilor se bazeaza pe drepturi la nivel de fisier. Pentru a impiedica accesul la un anumit fisier celor care nu sunt administratori, spre exemplu, se procedeaza astfel: din tab-ul Security din Properties vor fi scosi toti utilizatorii si toate grupurile nedorite.

Fig.1.

In acest mod doar utilizatorii care au drepturi de adminstrator vor putea accesa fisierul Admin_Modules.aspx. Deoarece verficarile ACL se fac pe baza token-urilor de acces ce reprezinta conturi Windows, autorizarea pe baza ACL-urilor se foloseste in combinatie cu autentificarea Windows.

Autorizarea bazata pe URL-uri lucreaza diferit, folosindu-se de configurarea Web.config-ului. Acest tip de autorizare este specific ASP.NET-ului si nu necesita interventia IIS-ului. Cel mai adesea este folosit in combinatie cu autentificarea de tip Forms.

1. Autentificare de tip Windows

Pentru acest tip de autentificare, ASP.NET-ul are nevoie de ajutorul IIS-ului, acestuia revenindu-i si cea mai grea parte a acestei operatii. Dupa ce a verificat identitatea utilizatorului, IIS-ul o transmite catre ASP.NET.

Cum functioneaza?

Sa presupunem ca un utilizator, Bob, vrea sa acceseze un fisier Aspx. IIS il autentifica ca fiind Bob si paseaza cererea impreuna cu un token de acces catre ASP.NET, care va folosi acest token pentru a se asigura ca Bob are permisiunea de a accesa resursa ceruta. Mai departe ASP.NET-ul pune acest token la dispozitia aplicatiei prin intermediul careia s-a facut cererea, pentru ca aplicatia sa poata prelua rolul lui Bob (sa nu se execute cod care ar duce la accesarea unor resurse care nu-i sunt permise lui Bob).

Securitatea IIS

Deoarece IIS este un server Web, scopul lui principal este de a accepta conexiuni de la clienti izolati si de a raspunde cererilor HTTP care sosesc prin aceste conexiuni. Cele mai multe cereri sunt comenzi HTTP GET sau POST care solicita fisiere HTML, JPEG, ASPX sau alte resurse. In mod evident, nu se doreste ca orice utilizator care se conecteaza la server sa aiba dreptul de a accesa orice resursa. IIS-ul protejeaza resursele in patru moduri:

- aplicatiile Web se regasesc in directoare virtuale care se pot adresa prin URL-uri. Clientii nu pot lua continutul directoarelor sau subdirectoarelor virtuale.

- IIS-ul atribuie fiecarei cereri un token de acces care permite sistemului de operare sa realizeze o verificare ACL asupra resurselor din cerere. Daca cererea este in numele lui Bob si Bob nu are dreptul de a citi resursa, atunci cererea va fi respinsa. In plus, IIS-ul transmite token-ul de acces al lui Bob catre ASP.NET pentru ca acesta sa realizeze propria verficare.

- IIS-ul suporta restrictii pe baza numelor de domeniu si a adreselor IP, permitand cererilor sa fie aprobate sau respinse in functie de adresa IP sau domeniul entitatii care a lansat cererea.

- IIS-ul suporta conexiuni HTTP criptate, folosind familia de protocoale SSL. SSL-ul nu protejeaza resursele aflate pe server, in schimb previne interceptarea comunicatiei dintre server-ul Web si clienti.

IIS-ul ruleaza intr-un proces denumit Inetinfo.exe. Acesta ruleaza in mod normal folosind identitatea contului SYSTEM, care are privilegii mari pe masina gazda. Cererile directionate de IIS catre ASP.NET nu folosesc insa acest cont. Acestora le este atribuita identitatea unui anumit utilizator.

Prin intermediul IIS configuration manager aflat in Administrative Tools, se poate seta un anumit tip de autentificare pentru fiecare fisier si director in parte. Un fisier sau director poate fi configurat pentru a permite accesul anonim, acces autentificat sau amandoua. Sa presupunem ca server-ul primeste o cerere de accesare a unei resurse pentru care accesul anonim este permis. In mod implicit, cererea se executa in numele utilizatorului IUSR_machinename, unde machinename este numele server-ului. IUSR_machinename se creeaza in momentul instalarii IIS-ului. Daca se doreste, se poate seta ca cererile anonime sa nu ruleze sub acest utilizator. Pentru paginile Web care sunt destinate clientilor anonimi nu trebuie folosite ACL-uri care sa nu permita accesul pentru utilizatorul IUSR_machinename.

Daca se primeste o cerere pentru o resursa care permite doar acces autentificat, IIS-ul ii atribuie identitatea contului pentru care initiatorul a furnizat credentialele. Daca utilizatorul este Bob si poate dovedi acest lucru, atunci cererii ii este atribuit token-ul de acces al lui Bob.

IIS-ul dispune de patru tipuri de autentificare:

- Basic

- Digest

- integrata Windows

- certificate SSL

Pentru ASP.NET, aceste tipuri intra in categoria autentificarii Windows.

Autentificarile Basic si Digest se bazeaza pe credentiale (user si parola) pentru a autentifica utilizatorii. Cand clientul este un browser, acesta va pune la dispozitia utilizatorului o fereastra prin care credentialele pot fi introduse pentru a fi trimise la server. Autentificarea integrata Windows foloseste credentialele de acces in sistem pentru a face autentificarea.

Autentificarea de tip Basic este un standard HTTP ce este documentat in RFC 2617. In acest tip de autentificare credentialele sunt transmise la fiecare cerere. IIS-ul mapeaza aceste credentiale la un cont de pe server-ul Web, eliberand un token de acces care poate fi folosit pentru a realiza verificari bazate pe ACL-uri.

In cele ce urmeaza vom vedea cum functioneaza acest tip de autentificare pe un exemplu concret. Pentru aceasta vom folosi aplicatia MyWork.

Fig. 2.

Asadar, exista un director virtual pentru aceasta aplicatie pentru care vom seta modul de autentificare in modul urmator:

Fig. 3.

La prima incercare de accesare a unei pagini din acest director, server-ul Web va intoarce codul 401, indicand faptul ca este nevoie de autentificare pentru efectuare acestei operatii. De asemenea, in raspuns este inclus un header care identifica tipurile de autentificare acceptate.

Browser-ul raspunde prin afisarea unei ferestre care sa-i permita utilizatorului sa introduca user-ul si parola.

Fig.4.

Credentialele sunt concatenate unui sir care identifica tipul de autentificare. Acesta este codat base-64 si trimis catre server intr-un header de autorizare. Daca credentialele sunt valide, utilizatorului ii este permis sa vizualizeze pagina:

Fig. 5.

Introducerea credentialelor nu se face de fiecare data cand se acceseaza o resursa. Pentru aceasta browser-ul va include acelasi header de autorizare si in cererile viitoare pentru acelasi realm. Acesta este un spatiu logic care poate cuprinde tot site-ul sau doar o parte din el.

Autentificarea de tip Basic functioneaza pentru toate browser-ele. Problema este ca user-ul si parola sunt transmise in clar. Daca nu se foloseste un canal de comunicare criptat, cererile pot fi usor interceptate si un atacator poate afla credentiale valide. Asadar, autentificarea de tip Basic trebuie folosita peste HTTPS.

Autentificarea de tip Digest este similara cu cea de tip Basic. La accesarea unei resurse protejate astfel, browser-ul va afisa o fereastra care sa permita introducerea credentialelor. Server-ul Web foloseste aceste credentiale pentru a atribui o identitate cererii. Diferenta dintre cele doua tipuri de autentificari este ca in acest caz parolele nu sunt transmise in clar.

Modul de functionare al acestui tip de autentificare este descris tot in RFC 2617. In momentul in care un client acceseaza pentru prima data o resursa protejata, server-ul intoarce pe langa eroarea 401 si un "nonce". Browser-ul raspunde prin afisarea ferestrei, iar apoi transmite user-ul si hash-ul unui sir format din user, parola si nonce. Server-ul realizeaza si el acelasi hash. Parola pe care o foloseste acesta in calcularea hash-ului nu este cea transmisa de client, ci una stocata pe server. Daca cele doua hash-uri sunt identice, utilizatorul este autentificat.

Pentru a putea folosi acest tip de autentificare este nevoie de o versiune mai noua decat 5.0 pentru utilizatorii de Microsoft Internet Explorer. Pe server parolele sunt tinute in clar (sau intr-o forma de codare reversibila) ceea ce contravine modelului tipic de securitate al Microsoft. In cazul in care server-ul este compromis, parolele sunt aflate imediat.

Autentificarea integrata Windows foloseste credentialele de acces in sistem pentru a autentifica utilizatorii. In loc sa afiseze o fereastra care sa permita introducerea user-ului si a parolei pentru a fi trimise mai departe peste HTTP, browser-ul comunica cu server-ul Web si identifica utilizatorul folosind identitatea cu care acesta a fost recunoscut de client. Daca nu este configurat altfel, browser-ul va cere credentialele utilizatorului doar daca pe server-ul Web contul cu care acesta a avut acces in sistem nu a fost valid.

Acest tip de autentificare nu este un standard, ci este un protocol de autentificare proprietar ce permite credentialelor de acces in sistem sa circule peste HTTP.

Din punctul de vedere al utilizatorilor, autentificarea integrata Windows este ideala, deoarece nu mai sunt nevoiti sa introduca user-ul si parola dupa ce s-au autentificat in sistem. Parolele nu sunt transmise niciodata in clar prin retea, deci autentificarea este sigura, chiar si cand comunicatia se face prin canale necriptate.

Autentificarea integrata Windows nu este suportata de alte browsere, in afara de Internt Explorer.

Firewall-urile impiedica acest tip de autentificare, deoarece protocoalele folosite (NTLM sau Kerberos) se bazeaza pe porturi care de obicei sunt inchise.

Asadar, autentificarea integrata Windows este o solutie foarte buna pentru retelele interne, aflate in spatele unui firewall si ai caror utilizatori pot fi atent monitorizati.

Securitatea ASP.NET

In figura de mai jos este prezentata legatura dintre IIS si ASP.NET. Cand IIS-ul primeste o cerere pentru un fisier inregistrat sub ASP.NET (un fisier aspx, de exemplu) o transmite catre un DLL ISAPI (Internet Server API), numit Aspnet_isapi.dll. Acesta ruleaza sub acelasi proces ca si IIS-ul, adica sub Inetinfo.exe. ASP.NET-ul ruleaza sub un proces diferit, numit Aspnet_wp.exe. Aspnet_isapi.dll transmite cererea catre Aspnet_wp.exe folosind un pipe cu nume. Cand cererea ajunge la proces, este atribuita unei aplicatii specifice care se executa intr-un anumit AppDomain. Odata ajunsa in AppDomain, cererea trece prin pipeline-urile ASP.NET HTTP, unde este examinata de diferite module HTTP si, in final, procesata de un handler HTTP care corespunde tipului resursei cerute. Maparea dintre tipurile de fisiere din handler-ele HTTP corespunzatoare se regaseste in Machine.config.

Fig.6.

Aspnet_isapi.dll trimite odata cu cererea HTTP catre Aspnet_wp.exe si token-ul de acces dat de IIS. Token-ul de acces poate fi :

- un token IUSR_machinename, reprezentand un utilizator neautentificat

- un token reprezentand un utilizator autentificat

Inainte ca cererea sa fie procesata, Aspnet_wp.exe realizeaza urmatoarele:

- o verificare ACL pentru resursele cerute, folosind token-ul de acces. Daca, spre exemplu, cererea este o comanda GET pentru fisierul Pagina.aspx, token-ul de acces il reprezinta pe Bob, iar pagina.aspx are un ACL care nu permite citirea sa de catre Bob, atunci ASP.NET-ul respinge cererea. ASP.NET-ul realizeaza aceasta verficare indiferent daca personificarea este sau nu activata.

- token-ul de acces devine disponibil pentru aplicatia care se ocupa de cerere

Implicit, Aspnet_wp.exe ruleaza ca ASPNET, un cont special care se creeaza cand ASP.NET este instalat. ASPNET este membru in grupul Users, ceea ce inseamna ca are destule previlegii pentru a putea desfasura actiunile pe care aplicatia le desfasoara. Privilegiile sunt insa indeajuns de restrictionate pentru a preveni anumite atacuri. Daca nu se specifica altfel, cererile executate de ASP.NET folosesc identitatea lui Aspnet_wp.exe.

Cererea poate fi insa executata folosind token-ul de acces pus la dispozitie de IIS. Aceasta tehnica se numeste personificare. Personificarea este activata prin includerea urmatorului enunt in <system.web> din fisierul Web.config:

Acesta poate fi modificat si din Machine.config.

Daca IIS-ul atribuie unei cereri identitatea lui IUSR_machinename, personificarea nu va crea probleme, deoarce acesta este un cont care are putine drepturi pe masina gazda. Daca IIS-ul atribuie token-ul celui care a initiat cererea, prin personificare, aplicatia va avea toate drepturile pe care initiatorul le are.

Aspnet_wp.exe poate fi configurat sa ruleze si sub alt cont decat ASPNET. Daca aplicatia are nevoie de drepturi pentru a scrie in registri, de exemplu, Aspnet_wp.exe poate fi pus sa ruleze ca SYSTEM modificand in Machine.config urmatorul tag:

Astfel, aplicatia va avea drepturi sa faca aproape orice pe masina gazda, ceea ce inseamna ca ASP.NET-ul devine vulnerabil in fata atacurilor. SYSTEM era contul implicit folosit in versiunea beta a ASP.NET-ului, dar a fost schimbat la scurt timp dupa ce produsul a fost lansat.

Autorizare bazata pe URL-uri

Desi se foloseste in mod frecvent in combinatie cu autentificarea de tip Forms, autorizarea pe baza de URL-uri se poate folosi si cu autentificarea de tip Windows. Daca, spre exemplu, intr-o aplicatie exista cateva pagini pe care doar cativa utilizatori le pot accesa, acestea se vor pune intr-un folder separat, in cadrul directorului virtual. In fisierul web.config din acest folder se vor scrie urmatoarele:

<system.web>

</authorization>

</system.web>

</configuration> ,

unde numedomeniu este domeniul in care exista utilizatorul Bob. In acest caz, numai Bob poate accesa respectivele pagini.

Autorizarea bazata pe URL-uri nu functioneaza decat in cazul fisierelor inregistrate sub ASP.NET. Un fisier HTML simplu nu va putea fi protejat prin aceasta metoda.

Autorizarea bazata pe roluri

Securitatea bazata pe roluri este un concept extraordinar al aplicatiilor Web. Inloc sa sa restrictioneze accesul pe baza numelor utilizatorilor, acest tip de autorizare se bazeaza pe rolurile in care sunt inclusi utilizatorii : Project Manager, Developer, etc.

Faptul ca o anumita resursa este proteja astfel se poate se poate realiza in doua moduri:

setand permisiunile asupra resursei

folosind autorizare URL. In acest caz, in fisiereul Web.config se vor scrie urmatoarele:

<system.web>

</authorization>

</system.web>

</configuration> ,

unde numedomeniu este domeniul in care se gaseste grupul Managers.

ASP.NET-ul este cel se ocupa de maparea utilizatorilor care initiaza cereri la grupuri.

Autorizarea pe baza de roluri are aceleasi enajunsuri ca si autorizarea pe baza de URL-uri, de aceea se foloseste in special in combinatie cu autentificarea de tip Forms.

Autorizare Custom

Daca se doreste, autorizarea se poate implementa prin scriere de cod, tinand cont de structura si functionalitatile pe care aplicatia le indeplineste.

In cele ce urmeaza vom considera un astfel de caz, exemplificand pe baza aplicatiei MyWork.

Schema dupa care se face autentificarea este urmatoarea: utilizatorilor li se atribuie diferite roluri, in functie de ce operatii trebuie sa realizeze in cadrul aplicatiei. Rolurile pot cuprinde unul sau mai multe module. Un modul va cuprinde, in general, pagini prin care se efectueaza operatii asemanatoare.

Fig.7.

Pentru a accesa pagina de start a aplicatiei este nevoie doar de autentificare. Credentialele valide de acces in sistem vor garanta si accesul la aceasta pagina. Pentru a putea opera in cadrul celor patru module standard ale aplicatiei (Projects, Tasks, Statistics, Administration) este nevoie de autorizare.

Fig.8.

Un angajat trebuie sa aiba drepturi de a vizualiza proiectele la care lucreaza, de a completa orele lucrate si de a vizualiza cateva statistici. Un project manager va trebui insa, sa poata adauga proiecte noi si de a specifica angajatii care lucreaza la un anumit proiect. Un administrator va trebui in primul rand sa aiba acces in modulul Administration, acesta fiind locul de unde autorizarea se configureaza.

Pentru inceput trebuie stabilit clar ce drepturi trebuie sa aiba un utilizator in aplicatie. Odata paginile identificate, se trece la construirea unui modul corespunzator, in cazul in care acesta nu exista. Daca paginile respective sunt deja cuprinse in module si exista si roluri create, probabil ca va fi de preferat sa se atribuie acele roluri direct utilizatorului. Vom prespune ca nu exista decat modulele standard si ca un angajat are nevoie de drepturi pe o combinatie speciala de pagini.

Mai intai vom crea modulul: din pagina Modules List se va apasa butonul Add.

Fig.9.

Modulul se va chema Modul Custom si va avea asociate paginile: Projects List, Project Edit, Modules List, Employees List si Roles List. Utilizatorul care va avea acest modul va avea asadar drepturi de vizualizare si modificare a proiectelor si dreptul de a vizualiza cum este configurata autorizatia.

Fig.10.

Pasul urmator este de a atribui modulul nou creat unui rol deja existent sau unui rol nou. Deoarece atribuirea modulului oricarui rol existent ar da prea multe drepturi utilizatorului, vom crea un rol nou. Din pagina Roles List se apasa butonul Add.

Fig.11.

Rolul se va numi Rol Custom si va avea atribuit doar modulul creat anterior.

Fig.12.

Daca utilizatorul a fost creat deja, nu ne ramane decat sa-i atribuim rolul dorit. Pentru a adauga un utilizator este nevoie si de un cont Windows valid. Utilizatorul se va chema Custom Employee si va avea atribuit doar rolul Custom Rol.

Fig.13.

In acest moment, utilizatorul Custom Employee poate accesa pagina Roles List, spre exemplu, insa nu va putea opera asupra ei. Daca va incerca sa editeze un rol, va fi anuntat printr-un mesaj ca nu are acest drept.

Fig.14.

Cand se foloseste?

Autentificarea Windows se foloseste de obicei in urmatoarele scenarii:

1. Aplicatia este utilizata in cadrul intranetului unei companii si toti cei care o folosesc au un cont pentru a se loga si a accesa resursele din retea.

2. Aplicatia este folosita in cadrul intranetului, dar se poate accesa si remote.

Scopul general al acestui tip de autentificare este acela de a mapa cererile sosite la conturile utilizatorilor de pe servereul Web (sau din domeniul in care se afla serverul) pentru a preveni intruziunea persoanelor care nu detin credentialele necesare pentru acces se foloseste mecanismul de securitate integrat in sistemul de operare.

2. Autentificarea de tip Passport

Prin aceasta modalitate de autentificare, ASP.NET utilizeaza serviciul centralizat de autentificate Microsoft Passport. ASP.NET ofera o modalitate simpla de acces la aceasta functionalitate, oferita de Microsoft Passport Software Development Kit (SDK), pachet care trebuie instalat pe serverul Web.

Cum functioneaza?

Utilizatorii care se inregistreaza prin Passport pot fi autentificati de oriunde din Internet de aplicatii care prezinta credentialele Passport-ului. Daca acesta determina ca user-ul si parola sunt valide, returneaza aplicatiei un tichet pe care aplicatia il poate coda intr-un cookie pentru ca utilizatorul sa nu fie nevoit sa se logheze de fiecare data.

3. Autentificarea de tip Forms

Acest tip de autentificare se bazeaza pe formele de login din paginile Web si nu necesita ca utilizatorul sa aiba un cont Windows pe server. Autentificarea de tip Forms este la fel de veche ca si Web-ul, dar ASP.Net-ul a facut-o sa fie foarte usor de folosit.

Modul de autentificare este specificat in fisierul Web.config al aplicatiei in felul urmator:

<system.web>

</system.web>

</configuration>

Alte valori valide pentru atributul mode

sunt: None, Windows si Passport. In Machine.config, in mod implicit, este setata autentificarea de tip Windows. Modul de autentficare este acelasi pentru toata aplicatia: nu se poate folosi autentficare Windows intr-o parte si autentficare de tip Forms in alta.

Cum functioneaza?

Acest tip de autentificare este un sistem prin care utilizatorii neautentificati sunt redirectati catre o forma Web in care li se cere sa-si introduca credentialele. Acestea sunt apoi validate, fiind generat in schimb un tichet care este returnat clientului. Tichetul de autentificare mentine identitatea utilizatorului precum si, in mod optional, o lista de roluri in care utilizatorul este membru, pe durata unei sesiuni.

ASP.NET-ul foloseste clasa FormsAuthenticationModule.

Etape:

Un client face o cerere pentru o resursa protejata ( o pagina din aplicatie care necesita logare).

IIS-ul primeste cererea si autentifica utilizatorul. Un token Windows care reprezinta utlizatorul este emis si transferat catre ASP.NET. Daca accesul anonim (Anonymous Access) este activat, clientul va fi transferat automat catre ASP.NET. IIS va emite un token pentru contul IUSR_numemasina. In caz contrar, utilizatorului ii vor fi cerute user-ul si parola. Deoarece aplicatia are setata autentificarea de tip Forms ca fiind activa, autentificarea IIS nu poate fi folosita.

ASP.NET-ul isi realizeaza propria autentificare. Utilizatorul va fi redirectat catre pagina specificata in atributul loginURL din tag-ul Authentication din Web.config. Acest URL trebuie sa contina pagina care sa-i permita utilizatorului sa introduca user-ul si parola pentru a putea accesa resursa protejata.
Utilizatorul introduce credentialele care sunt verificate de aplicatia ASP.NET, care va determina si nivelul de autorizare al acestuia. Daca utilizatorul este autorizat sa acceseze resursa pentru care a initiat cererea, ii este emis un tichet de autentificare. In caz contrar, in mod normal, i se va intoarce un mesaj care sa-i specifice faptul ca accesul la acea resursa nu ii este permis.
In final, clientul poate fi redirectat catre resursa care acum ii este accesibila. Pana la inchiderea browser-ului sau pana la terminarea sesiunii, accesarea resursei nu va mai necesita introducerea credentialelor. Pentru ca datele de autentificare sa persiste mai mult timp, se poate seta data de expirare a tichetului de autentificare.

In cele ce urmeaza vom configura aplicatia MyWork sa foloseasca autentificarea de tip Forms. Pentru inceput specificam faptul ca directorul virtual accepta accesul anonim:

Fig.15.

In fisierul Web.config vom scrie urmatoarele:

</credentials>

</forms> ,

unde loginUrl este adresa paginii de autentificare, defaultUrl reprezinta adresa paginii catre care utilizatorul va fi redirectat in mod implicit dupa autentificare. Dupa cum se poate observa parola este tinuta in clar.

In figura de mai jos este prezentata pagina prin care utilizatorul poate introduce credentialele:

Fig.16.

Daca acestea se regasesc in fisierul Web.config, atunci utilizatorul este redirectat catre pagina specificata in atributul defaultUrl.

Fig.17.

Codul prin care se realizeaza autentificarea este urmatorul:

void OnLogIn (Object sender, EventArgs e)

In cazul in care credentialele nu au fost gasite, utilizatorul va fi instiintat printr-un mesaj ca autentificarea a esuat:

Fig.18.

Desigur, intr-un scenariu real, utilizatorii si parolele acestora nu vor fi tinuti in fisierul Web.config. Cel mai probabil, aceste informatii se vor regasi intr-o baza de date.

Cand se foloseste?

In cazul unui magazin virtual, autentificarea Windows nu este o solutie tocmai practica, deorece este putin probabil ca detinatorul server-ului sa creeze conturi pentru toti cei care doresc sa plaseze comenzi. Asadar, pentru aplicatiile Internet autentificarea de tip Forms este solutia ideala.

Vulnerabilitati

Atacurile asupra sesiunii sau atacurile prin reluare asupra cookie-urilor sunt cat se poate de reale si grave in cazul aplicatiilor care folosesc autentificarea de tip Forms. Interogarea bazei de date folosind credentialele utilizatorilor trebuie facuta tinand seama de pericolul reprezentat de atacurile prin injectare SQL. Pentru a preveni furtul identitatii trebuie avut grija ca datele senzitive sa fie tinute secrete si ca parolele sa fie complexe.

Atacurile asupra sesiunii se savarsesc in doua moduri:

id-ul sesiunii este ghicit

cookie-ul este "furat".

Primul mod implica adunarea de id-uri de sesiuni si ghicirea unui id valid care a fost atribuit unei persoane. Este un atac fara prea mari sanse de reusita asupra aplicatiilor dezvoltate cu ASP.NET, deorece pentru aceste id-uri se folosesc numere aleatoare pe 120 de biti.

Pentru protejarea cookie-ului care contine id-ul sesiunii se poate folosi SSL, dar chiar si in acest caz acesta poate fi obtinut prin atacuri de tipul cross-site scripting sau man-in-the-middle sau prin obtinerea accesului fizic la store-ul de cookie-uri de pe calculatorul victimei. Conectarea la o sesiune nu presupune niciun fel de efort din partea atacatorului dupa ce cookie-ul cu id-ul sesiunii a fost obtinut. din simplul motiv ca ASP.NET-ul nu mai stocheaza in cookie nicio alta informatie care sa identifice utilizatorul. Daca primeste un id de sesiune valid, conectarea la sesiune se face fara alte verificari.

Recomandari pentru reducerea riscurilor

1. Partitionarea site-ului

Paginile care necesita autentificare trebuie plasate intr-un subdirector care este separat de paginile care pot fi accesate anonim.

2. Securizarea paginilor restrictionate utilizand SSL.

Odata site-ul partitonat, trebuie specificat faptul ca pentru accesul la folder-ul care contine paginile restrictionate se foloseste SSL. Acest lucru se configureaza din IIS. Cererile pentru paginile respective vor fi solutionate doar daca se foloseste HTTPS.

Folosirea autorizarii pe baza de URL-uri

Ca si in cazul autentificarii de tip Windows, in cadrul autentificarii de tip Forms, autorizarea pe baza de URL-uri se realizeaza astfel:

<system.web>

</authorization>

</system.web>

In acest fel se specifica faptul ca accesul anonim la paginile nescurizate este permis. Pentru a restrictiona accesul la un folder in care se gasesc anumite pagini, in fisiereul Web.cofig se vor acrie urmatoarele:

<system.web>

</authorization>

</system.web>

</location>

4. Securizarea cookie-ului de autentificare

Pentru a preveni atacurile asupra sesiunii sau atacurile prin reluare asupra cookie-ului, trebuie avut grija ca acesta sa fie trimis doar prin conexiuni securizate SSL, folosind protoculul HTTPS. Criptarea cookie-ului inainte de a fi trimis clientului si limitarea timpului in care acesta este valid sunt, de asemenea, masuri care reduc riscul unui atac.

Continutul unui cookie poate fi criptat chiar si in cazul in care se foloseste SSL. Astfel, un atacator nu va putea vedea sau modifica informatia din cookie in cazul in care a reusit sa-l obtina printr-un atac XSS.

Durata de viata a unui cookie trebuie limitata pentru a reduce timpul in care un atacator poate folosi cookie-ul obtinut pentru a avea acces la aplicatie.

E de preferat ca perioada de valabilitate sa fie fixa si sa nu se reseteze dupa fiecare cerere catre server. Acest lucru se realizeaza prin setarea atributului slidingExpiration = 'false'. In cazul in care nu se foloseste SSL, setarea acestui atribut este critica.

Cookie-urile de autentificare nu trebuiesc pastrate, deorece ele se gasesc in profilul utilizatorului. In cazul in care atacatorul are acces fizic la calculatorul utilizatorului, cookie-ul poate fi furat foarte usor.

Cookie-urile de autentificare si cele de personalizare trebuie tinute in locatii diferite. Furtul unui cookie in care sunt salvate preferintele unui utilizator sau date nesenzitive nu prezinta o amenintare de securitate, in schimb, in urma furtului unui cookie de autentificare, atacatorul mai mult ca sigur va avea acces la aplicatie.

5. Nume unice pentru atributele <name> si <path>

Valorile atributelor name si path din tag-ul <forms> trebuie sa fie unice. In acest fel se evita problemele care ar putea aparea daca pe acelasi server exista mai multe aplicatii. Spre exemplu, un utilizator autentificat intr-o aplicatie poate face o cerere catre o alta aplicatie si sa nu fie redirectionat catre pagina de logare a celei din urma.

6. Folosirea URL-urilor absolute pentru navigare

Trecerea dintr-o zona publica a site-ului intr-una restrictionata (HTTP->HTTPS) este problematica, deoarece o redirectionare foloseste intotdeauna protoculul paginii curente, nu pe cel al paginii destinatie.

Daca, spre exemplu, intr-o pagina publica exista un buton de logare, un cod asemanator celui de mai jos ar trebui folosit pentru a redirectiona utilizatorul catre o zona securizata:

private void btnLogon_Click(object sender, System.EventArgs e)

Utilizarea unor credentiale sigure

Falsificarea identitatii este unul dintre cele mai intalnite atacuri asupra aplicatiilor. Falsificarea identitatii inseamna ca un atacator pretinde ca este un utilizator valid. O metoda de realizare a acestui atac este reprezentat de furtul cookie-ului de sesiune. Utilizand o conexiune sigura si securizand cookie-ul dupa metodele descrise mai sus, acest risc este redus considerabil. Totusi, nu trebuie neglijat faptul ca o parola ar putea fi aflata prin forta bruta, printr-un atac pe baza de dictionare sau prin injectare SQL.

Parolele nu trebuiesc tinute in clar in baza de date. In schimb se va retine valoarea hash a acestora, pentru a reduce riscul produs de un atac cu dictionare.

Pentru ca o parola sa fie sigura, ea trebuie saa indeplineasca niste conditii minime:

sa aiba cel putin 8 caractere

sa contina o combinatie de litere, cifre si simboluri.

sa nu contina caractere consecutive.

Pentru a verifica daca o parola indeplineste asemenea conditii se pot folosi expresii regulate:

protected Boolean IsStrongPassword(string password)

);

Autentificarea de tip Forms este vulnerabila mai ales in fata atacurilor prin injectare SQL, din cauza modului in care credentialele sunt folosite pentru a construi enunturi SQL. Datele de intrare nu trebuie sa prezinte niciodata incredere, ele trebuind validate. Pentru o securitate crescuta se recomanda evitarea folosirii enunturilor SQL dinamice. Pentru interogarea bazei de date se vor folosi enunturi SQL parametrizate sau proceduri stocate.

Capitolul 3 - Injectare SQL

Injectarea SQL este o metoda de atac care exploateaza vulnerabilitatile de securitate din nivelul de stocare a datelor al unei aplicatii. Atacatorul introduce comenzi SQL cu intentia de a manipula executia enunturilor SQL pentru a obtine accesul in aplicatie fara a avea un cont valid, pentru a sterge tabele, modifica datele sau doar a le vizualiza si folosi ulterior in alte scopuri.

Tipuri de Injectare SQL

1. Filtrarea incorecta a caracterelor

Acest tip de injectare SQL se poate utiliza in cazul in care nu se verifica daca datele introduse de utilizatori contin caractere speciale, acestea fiind folosite ca atare in construirea dinamica a enunturilor SQL. In acest fel, ceea ce ajunge sa se execute in baza de date poate fi total diferit de ceea ce era de dorit.

Urmatoarea linie de cod demonstreaza cum functioneaza acest mecanism de atac:

strSql = 'SELECT * FROM Employees WHERE empl_name = '' + UserName + ;

Prin executarea acestei interogari pe baza de date, nu se doreste decat extragerea unor informatii despre un utilizator al carui nume este cunoscut. Un utilizator rau intentionat poate insa introduce caractere care sa modifice comportamentul interogarii. Spre exemplu, daca variabilei UserName ii este atribuita valoarea "a' or 1=1", enuntul SQL va arata astfel:

SELECT FROM Employees WHERE name 'a' OR 1 1

Daca acest cod ar fi fost folosit pentru afisarea informatiilor specifice unui utilizator si niciun fel de validare nu ar fi fost facuta asupra valorii pe care variabila UserName o poate lua, continutul tabelului users ar fi fost afisat in intregime deoarece conditia "1=1" este mereu adevarata.

Prin utilizarea unui astfel de cod intr-o pagina de autentificare, se ofera unui atacator oportunitatea de a avea acces in aplicatie fara a detine si fara a afla un utilizator si o parola valide. Presupunem ca avem urmatoarea metoda de autentificare:

private void cmdLogin_Click(object sender, EventArgs e

else

con.Close();

De cele mai multe ori apasarea butonului de login nu va avea alt efect decat autentificarea utilizatorului sau afisarea unui mesaj de instiintare. Daca insa in locul numelui este introdusa secventa "' Or 1=1 --" in baza se va efectua urmatoarea interogare:

SELECT Count FROM Employees WHERE empl_name Or 1 1 --' AND empl_pwd=''

Cum conditia "1=1" este mereu adevarata, iar verificarea parolei nu se mai face, accesul in aplicatie este garantat.

In functie de cum este implementata procedura de autentificare, atacatorul poate avea si posibilitatea de a-si crea propriul utilizator cu care apoi sa poata opera in cadrul aplicatiei. Daca in exemplul de mai sus nu ar fi fost folosita functia Count(), interogarea SQL ar putea fi modificata in asa fel incat sa furnizeze informatii despre tabelele in care sunt stocate datele utilizatorilor aplicatiei. In acest sens, secventa care trebuie introdusa in locul numelui este urmatoarea: "' having 1=1-- Sql Server va intoarce eroarea:

"Column 'Employees.empl_ID' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.",

furnizand atat numele tabelului, cat si numele primei coloane. Urmatoarea interogare va contine numele coloanei aflate: " group by empl_id having 1 1 ". Se continua astfel pana cand eroarea nu mai apare.

Desi numele coloanelor pot fi concludente in ceea ce priveste tipul de date stocat, atacatorul poate incerca sa produca niste erori de conversie. Iata un exemplu:

UNION SELECT SUM empl_name FROM Employees

Sql Server va intoarce eroarea:

"Operand data type nvarchar is invalid for sum operator."

din cauza utilizarii incorecte a functiei sum si nu din cauza faptului ca cele doua select-uri nu se potrivesc ca numar de coloane. Daca tipul coloanei ar fi fost numeric, atunci eroarea ar fi fost:

"All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists."

Cunoscand numele si structura tabelului atacatorul isi poate introduce acum propriile date.

Construirea dinamica a unui enunt Sql transforma orice pagina intr-o victima sigura. Daca, spre exemplu, filtrarea inregistrarilor dintr-un grid se realizeaza prin intermediul unui textbox, un atacator ar putea modifica interogarea in asa fel incat informatiile afisate sa fie cu totul altele decat cele asteptate.

Fig.19.

Codul de mai jos afiseaza informatii din tabelul Projects si permite utilizatorilor sa caute un proiect dupa numele sau.

private void bindDataGrid()

private DataView createDataView()

SqlConnection cnx = new SqlConnection(strCnx);

SqlDataAdapter sda = new SqlDataAdapter(strSQL, cnx);

DataTable dtProjects = new DataTable();

sda.Fill(dtProjects);

return dtProjects.DefaultView;

}

protected void btnFilter_Click(object sender, EventArgs e)

Introducand date corecte, la apasarea butonului de cautare se va realiza doar filtrarea inregistrarilor. Un atacator insa ar putea folosi aceasta pagina pentru a afisa datele din alte tabele, inclusiv din tabele de sistem. La inceputul unui atac este putin probabil ca atacatorul sa cunoasca structura bazei de date. Pentru a putea afla datele din tabele trebuie mai intai sa afle denumirea acestora. Acest lucru poate fi realizat prin utilizarea operatorului UNION. Daca variabila txtFiter va avea valoarea

UNION SELECT id name FROM sysobjects WHERE xtype 'U'

atunci rezultatul interogarii strSQL va fi afisarea denumirilor tuturor tabelelor din baza de date. In grid-ul din imaginea urmatoare se poate observa cum in loc de numele proiectelor au fost incarcate denumirile tabelelor:

Fig.20

Pentru ca databind-ul sa se poata realiza este necesar ca tipurile si numarul coloanelor din tabelul interogat de atacator sa se potriveasca cu cel initial.
Folosind o a doua interogare modificata se pot afla coloanele din tabelele care prezinta interes si, in final, datele din ele.

Injectarea SQL nu este folosita doar pentru a extrage informatii din baza de date, ci si pentru a le modifica sau distruge. Prin utilizarea unui astfel de cod i se da posibilitatea unui atacator de a produce daune fara a fi fost vreodata logat in aplicatie. Introducand o secventa de tipul "a' DROP TABLE Employees in locul a ceea ce ar trebui sa fie numele proiectului, atacatorul poate distruge intreaga baza de date.

2. Manipularea incorecta a tipurilor de date

Acest tip de Injectare SQL apare atunci cand nu exista constrangeri asupra tipurilor de date pe care o variabila le poate avea. De exemplu, daca informatia asteptata este numerica, dar programatorul nu a facut nici o verifcare in acest sens, rezultatele interogarii pot fi de la o simpla eroare la distrugerea bazei de date.

strSql = 'SELECT * FROM Employees WHERE empl_ID = ' + empl_ID + ;

Orice valoare non-numerica a variablei empl_ID va conduce la aparitia unei erori.

Mai grav, daca variabila ajunge sa aiba o valoare de forma " DROP TABLE Employees", rezultatele pot fi catastrofale.

3. Vulnerabilitati ale server-ului de baze de date

Cateodata vulnerabilitatile pot exista chiar in sever-ul de baze de date. In SQL Server 2005, functiile OPENROWSET si OPENDATASOURCE sunt folosite pentru a interoga baze de date aflate pe alte servere decat cel de pe care se lucreaza. Daca utilizarea lor este permisa, un atacator poate sa-si aduca informatii intr-o baza detinuta de el sau poate opera modificari asupra unei alte baze de date decat cea pe care o foloseste aplicatia.

In septembrie 2005, David Litchfield a publicat articolul 'Data Mining with SQL Injection and Inference', in care a dezbatut tehnici de atac bazate pe timp si a propus alte moduri de a obtine intarzieri utilizand apeluri (de sistem) catre proceduri, cum ar fi xp_cmdshell, pentru a efectua un ping.

Executand xp_cmdshell 'ping -n 10 127.0.0.1', in functie de configuratia serverului SQL se poate obtine fie o intarziere de 10 secunde, fie eroarea:

SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 'xp_cmdshell', see 'Surface Area Configuration' in SQL Server Books Online.

4. Injectare SQL oarba

Acest tip este folosit cand aplicatia este vulnerabila atacurilor prin Injectare SQL, dar rezultatele acestuia nu sunt vizibile atacatorului. Pagina atacata poate sa nu fie una care afiseaza informatii, dar in cazul unui atac se va incarca diferit in functie de rezultatele enunturilor logice concatenate enuntului original.

4.1. Erori conditionate:

Acest tip de injectare SQL oarba consta in determinarea aparitiei unei erori prin evaluarea unui enunt doar in cazul in care clauza Where este indeplinita. Spre exemplu, folosind enuntul:

SELECT DISTINCT

CASE WHEN empl_name 'Lioara' THEN 1 0

ELSE

END AS a

FROM Employees ,

se va obtine eroare din cauza impartirii la 0, doar daca un angajat cu numele "Lioara" exista in tabel.

4.2. Raspunsuri conditionate

Ca si in cazul erorilor conditionate, pentru acest tip de injectare SQL se va forta aparitia unui anumit raspuns in functie de rezultatul evaluarii unei conditii. Spre exemplu, incarcarea cu date a grid-ului care afiseaza proiectele poate fi conditionata de valoarea literelor din numele versiunii server-lui SQL. Acest lucru este posibil deoarece urmatoarele doua enunturi SQL sunt identice la momentul executiei:

SELECT FROM Projects WHERE project_Name 'Proiect Disertatie'

SELECT FROM Projects WHERE project_Name 'Proiect' ' Disertatie'

Mergand mai departe, valoarea cautata poate fi data sub forma:

SELECT FROM Projects WHERE project_Name 'P' SELECT 'r' 'oiect' ' Disertatie'

sau sub forma:

SELECT FROM Projects WHERE project_Name 'P' SELECT SUBSTRING 'r' 1 1 'oiect' ' Disertatie'

Acest tip de atac nu poate fi detectat urmarind log-urile cu raspunsurile sever-ului. Ceea ce difera in functie de valoarea de adevar a unei conditii, este doar continutul paginii web. Cautand "Proiect Disertatie" este clar ce informatie se va afisa in grid. Schimband insa o singura litera, informatiile aferente proiectului "Proiect Disertatie" nu vor mai fi afisate. Folosind tehnica prezentata mai sus, se poate forta cautarea dupa "Proiect Disertatie" in cazul in care un anumit bit dintr-un octet al numelui versiunii server-ului bazei de date este 1 sau dupa "PXoiect Disertatie" in caz contrar.

SELECT FROM Projects WHERE project_Name 'P'

select case when

ascii substring select @@version 1 1 & power 2 0 > 0 then char 114

else char 88 end

'oiect' ' Disertatie'

Cum primul bit din primul octet al versiunii server-ului este 1, pagina arata astfel:

Fig.20.

Al doilea bit se obtine folosind enuntul:

SELECT FROM Projects WHERE project_Name 'P'

select case when

ascii substring select @@version 1 1 & power 2 1 > 0 then char 114

else char 88 end

'oiect' ' Disertatie'

Deoarece este 0, in grid nu se va afisa nimic.

Fig.21.

4.3. Intarzieri de timp

Atacurile bazate pe timp sunt un tip de Injectare SQL ce determina serverul SQL sa execute interogari care necesita un timp mare pentru a se finaliza sau comenzi care sa intarzie aparitia rezultatelor interogarii in functie de logica injectata. Atacatorul poate masura timpul in care pagina se incarca pentru a determina daca enuntul injectat este adevarat sau nu.

Primele referinte la atacuri oarbe se pot gasi in lucrarea lui Chris Anley 'More Advanced SQL injection', in care autorul atrage atentia asupra crearii unor astfel de atacuri, in acest caz specific, pe timp, unul din cazurile mai putin comune. De exemplu, folosind interogarea:

declare @s varchar 8000

select @s db_name

if ascii substring @s 1 1 & power 2 0 > 0 waitfor delay

se obtine o intarziere de 5 secunde in cazul in care primul bit din primul octet al numelui bazei de date este 1.

Dupa aceasta prima referinta, tehnicile de Injectare SQL oarba au continuat sa fie studiate cu majoritatea tehnicilor de generare a mesajelor de eroare din sistemul atacat, datorita simplitatii, executiei rapide si extensiei de a arata un mesaj de eroare fata de intarzierea unui raspuns al bazei de date. Un an mai tarziu, in septembrie 2003, Ofer Maor si Amichai Shulman au publicat lucrarea 'Blindfolded SQL Injection'. In acesta, ei analizeaza moduri diferite de a identifica un parametru vulnerabil la injectarea SQL, chiar si cand informatia procesata si returnata de sistem nu este vizibila. La Conferinta BlackHat din 2004, Cameron Hotchkies a prezentat lucrarea sa 'Blind SQL Injection Automation Techniques'. El a propus metode alternative de exploatare a parametrilor vulnerabili la SQL injection orb utilizand aplicatii personalizate. El sugereaza 3 solutii diferite pentru automatizare:

1) Cautarea unor cuvinte cheie cu rezultate pozitive si negative.

2) Utilizarea de semnaturi MD5 pentru a separa rezultatele pozitive si cele negative.

3) Utilizarea de motoare de diferente textuale.

Tot in cadrul acestei conferinte a prezentat si SQueal, o aplicatie automata de extragere a informatiei prin injectare SQL oarba, care a evoluat mai tarziu intr-o alta aplicatie numita Absinthe.

Metodele de exploatare prin injectare SQL oarba pot fi evitate doar folosind tehnici de programare adecvate, sau, dupa cum spunea Michael Howard, "Orice data de intrare este considerata nociva pana cand se dovedeste contrariul'.

Un mod foarte simplu de a genera intarzieri este de a profita de una din cele mai mari probleme a oricarei baze de date: interogarea complexa. Tot ce trebuie facut pentru a accesa un tabel care are anumite inregistrari este construirea unei interogari suficient de complexe care sa forteze motorul SQL sa lucreze. In alte cuvinte, trebuie construita o interogare ignorand ceea ce ne recomanda practicile de imbunatatire a performantei.

Urmatoarea intergaare SQL se executa in aproximativ 1 minut:

SELECT count FROM sysusers AS sys1 sysusers AS sys2 sysusers AS sys3 sysusers AS sys4 sysusers AS sys5 sysusers AS sys6 sysusers AS sys7 sysusers AS sys8

In general, conditiile dintr-o clauza Where sunt analizate in ordine si neindeplinirea uneia dintre ele opreste verificarile celorlalte. Totusi, acest lucru nu este valabil pentru toate server-ele de baze de date, verificarea clauzelor depinzand de planul de executie pe care si-l face server-ul.

Rezultatul unei interogari de forma:

SELECT FROM Projects WHERE project_id 1

and 300>(select top 1 ascii substring name 1 1 from sysusers