Dr. Sabin Buragahttp://www.infoiasi.ro/~busaco/ Tehnologii Tehnologii Web Web <?xml version=“1.0” ?> <curs desc=“…” /> Tehnologii Web Dr. SabinCorneliu Buraga Facultatea de Informatica Universitatea “A.I.Cuza” – Iasi, Romania http://www.infoiasi.ro/~busaco/
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Stabilirea tintei ataculuimecanismul de autentificare (login)cimpuri de intrare ale formularelor Webmanagementul sesiunilorinfrastructura folositae.g., serverele de stocare a datelor, servicii aditionale,…
Cunoasterea profilului atacatoruluiResursele avute la dispozitie: financiare, tehniceTimpul acordatRiscul asumat – revendicarea sau nu a ataculuiAccesul la Internet si calitatea acestuiaObiectivele urmarite: recunoastere mondiala, denigrarea tintei, furt de informatii/bani etc.
La nivel de HTTPDeturnarea sesiunilor (session hijacking): atacatorul determina SID‐ul utilizatorului siil foloseste in scop propriuExemplu: analizarea cimpului Referer
SQL injectionPresupune scrierea unor interogari SQL care permitafisarea, alterarea, stergerea de date din baze de datevia formulare Web ori direct folosind URL‐uri
SQL injection – variatii:Exemplu: http://www.sit.org/prog.asp?id=1+OR+gh=1Se poate obtine un mesaj precum:[Microsoft][ODBC SQL Server Driver] [SQL Server]Invalid column name ’gh’.SELECT group_id, securityName, maxSalesCharge, price,security_id, trade_date FROM fundsWHERE group_id = 1 OR gh=1 ORDER BY price DESCAtacatorul poate continua, de pilda, cu:
CrossSite Scripting (XSS) – variatii:Folosirea de cod JavaScript pentru a modifica textulredat de navigatorul Web utilizatoruluitehnici mai sofisticate pot recurge la DOM, AJAX,…
Adoptarea de tehnici de social engineering:manipularea utilizatorilor de catre atacator(prin intimidare, santaj, autoritate, flatare, substitutie de persoana, vanitate etc.)
O alta problema: folosirea parolelor93% din procesele de autentificare folosesc paroleCu cit utilizatorul trebuie sa retina mai multe parole,cu atit sistemul de protectie via parole e predispusla brese in securitate: alegerea unor parole slabe, partajarea parolelor(grupuri de prieteni, colegi,...), scrierea parolelor pehirtie (eventual, la vedere), folosirea aceleasi parole timp indelungat, pentru mai multe aplicatii/sisteme
Solutii: SSO (vezi OpenID), identificare biometrica etc.
O alta problema: troienii WebSituri (adrese) aparent folositoare, la care utilizatorulpoate ajunge eventual via redirectare automata
Se pot folosi in conjunctie cu XSS sautehnici de tip social engineering
Solutie: implementarea unui sistem de tichete (ticket system) – fiecare actiune ce poate fi realizata de utilizator are asociat un tichet (numar) aleatoriu, folosit o singura data
Exemple de actiuni:Detectia versiunilor de programeavind bug‐uri cunoscute: "Apache/2.0.52 server at"
Accesul la fisiere .bak: inurl:index.php.bakAccesarea intranet‐ului: intitle:intranetDetectarea paginilor de administrare: "admin login"Gasirea unor instalari implicite:
intitle:"welcome to" intitle:internet IISLocalizarea interfetelor spre sistemelede baze de date: inurl:main.php phpMyAdmin
Tehnici:Nivelul retea: firewallurinu ajuta prea mult, portul 80 fiind public
Nivel de transport: TLS (Transport Layer Security) – asiguraautentificarea & confidentialitateamesajelor HTTPautentificare via certificate digitaleconfidentialitate prin criptare Vezi
Tehnici:Nivel de aplicatie: securitate persistenta a mesajelor vehiculate
confidentialitate via XML Encryptionintegritate prin XML Signatureautentificare/autorizare via SAML (SecurityAssertions Markup Language), XACML (ExtensibleAccess Control Markup Language), XKMS (XML Key Management Specification) etc.
Studiu de caz: securizarea serverului ApacheFolosirea mod_ssl pentru HTTP peste TLSEliminarea generarii “semnaturii” serverului pentrupaginile generate automate: ServerSignature Off siServerTokens Prod
Studiu de caz: securizarea serverului ApacheVerificarea permisiunilor fisierelor publiceLimitarea cererilor la server (e.g., interzicerea efectuarii metodei POST)
Limitarea folosirii .htaccess de utilizatorii obisnuitiConfigurarea serverelor de aplicatii sa nu trimitabrowser‐ului mesajele de eroare(e.g., la PHP cu display_errors off)
Studiu de caz: securizarea serverului ApacheRularea script‐urilor in mod “sigur” (Perl in taint mode, PHP: safe_mode on, allow_url_fopen off), semnarea codului ca fiind “sigur” (e.g., la Java/.NET)
Limitarea/inhibarea upload‐urilor de fisiereInterzicerea accesului la tabela users la MySQLActualizarea continutului sitului doar prin metodesecurizate – “sigure” (ssh, scp, sftp)
Se iau in consideratie:Tipul navigatorului (+setarile implicite)Platforma (hardware, sistem de operare,...)Interfata (rezolutia ecranului, adincimea de culoare, largimea de banda,...)
Politica de caching (+siguranta proxy‐ului)Suportul pentru redarea unor tipuri de documente(securitatea folosirii plugin‐urilor)
Limbajul/limbajele de programare utilizate(inclusiv, serverul/serverele de aplicatii)
Teste specifice legate de programare:Probleme de escaping
Exemplu: escaping pentru sirul cs/b: cs%2Fb sau cs%%252Fb sau cs%25%32%46b
“Injectare” directa a datelor via URI sauprin intermediul interfetei Web sau printr‐un fisier(upload ilegal) sau folosind un program (e.g., de administrare la distanta a aplicatiei),...
Teste specifice legate de programare:Solutii & strategii:
Programare defensiva (defensive programming)Adoptarea standardelor de redactare a codului(enforcing coding standards)
Recurgerea la unitati de testare (testing units)Includerea unui sistem de prevenire, detectare siraportare a erorilor survenite in cod + un sistemde urmarire a bug‐urilor (bug tracking)
Teste privitoare la integrarea componentelor:Gradul de securitate al unei aplicatii este datde gradul de securitate al celei mai vulnerabilecomponente
Exemplu: neverificarea validitatii identificatoruluide utilizator in cazul unei modificari a unor date, pe baza faptului ca aceasta verificare s‐a efectuat dejala nivelul browser‐ului
Teste privind opacizarea datelor (obfuscation):Datele nu trebuie stocate in locatii predictibileContinutul propriu‐zis al sitului poate conduce la probleme de securitate (information disclosure)
monitorizare & testareBrese referitoare la information disclosure:
Accesarea cimpurilor ascunse ale formularelorConsultarea fisierului robots.txt scanarea fisierelor de configurare sau a directoarelor temporare(e.g., rapoarte ale traficului)
Comentariile din codul‐sursa XHTML, CSS, JavaScriptMesajele de eroare emise de aplicatiile WebFisierele cu extensii incorecte
acces la codul‐sursa al script‐urilor de pe serverVizualizarea continutului directoarelor serveruluiScanarea traficului de retea (in primul rind, URI‐uri)
Teste specifice legate de exploatare:Pregatirea judicioasa a exploatarii in practica(deployment)
Detectarea problemelor de flux (e.g., tratareacorespunzatoare a codurilor HTTP 4xx si 5xx): legaturi “moarte”, acces la resurse autentificate, executia anormala a script‐urilor CGI
Testarea interactiunii cu aplicatia Webprograme simulind vizitatori virtuali
Realizarea testelor de incarcare (load testing)scenarii si interpretarea rezultatelor
Teste referitoare la performanta:Platforma (hardware & software)
Configurare, upgrading, updating, UPS, RAID etc.Serverul Web – configurare, module, suport pentru utilizarea certificatelor digitale,...
Serverul de baze de dateNormalizare, integritate, implementarea celor maibune practici & standarde, strategii de conectivitate(e.g., ODBC, JDBC,...), monitorizarea volumului dedate, tranzactii, sincronizare, politica actualizarilor
Tipuri de vulnerabilitati specifice: Probleme de autentificareManagementul sesiunilorInjectarea de scripturi (XSS) ori comenzi SQL Expunerea (involuntara) a informatiilor delicate (information disclosure)
Accesul la codul‐sursa orila fisierele de configurare a aplicatiei Web
Principii de securitate a aplicatiilor WebSepararea serviciilor – masini diferite pentru server Web, server de aplicatii, de baze de date etc.
Limitarea privilegiilor – la nivel de sistem de fisiere, pentru baze de date, acordarea de permisiuniutilizatorilor sub care ruleaza aplicatiile –e.g., Apache, Tomcat, CGI‐uri etc.
Ascunderea secretelor (e.g., parole, SID‐uri,…)Utilizarea de biblioteci standard, actualizateMentinerea & studierea fisierelor de jurnalizareEfectuarea de teste si ajustari (Web tunning)
Reguli/bune practici (Sverre Huseby, 2004):Do not underestimate the power of the dark sideUse POST requests when actions have side effectsIn a server‐side context, there is no such thing as client‐side security
Always generate a new session ID once the user logs inNever pass detailed error messages to the clientIdentify every possible meta‐character to a subsystemWhen possible, pass data separate from control information
Reguli/bune practici (Sverre Huseby, 2004):Do not blindly trust the API documentationIdentify all sources of input to the applicationWhen filtering data, use white‐listing rather than black‐listing
Create application‐level logsNever use client‐side scripts for securityPass as little internal state information as possible to the client
Do not assume that requests will come in a certain order
Riscurile de securitate nu vizeaza numaiproprietarul sitului, ci si utilizatorul final
Disconforturi cauzate de un sit nesigur:financiare (pierdere de bani/informatii)de performanta (e.g., blocarea/incetinirea actiunilor)psihologice (insatisfactie)sociale (e.g., incapacitatea de munca, lipsa comunicarii cu partenerii de lucru etc.)
de timp (navigare greoaie, deturnare spre alt sit,...)