Jump to content

Search the Community

Showing results for tags 'xpath'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

Found 2 results

  1. Introducere Aplicatiile web folosesc foarte mult bazele de date pentru a aduna datele necesare si ale folosii la buna lor functionare . De multi ani, bazele de date relationale sunt tehnologia preferata pentru gestionarea datelor, dar in ultimul timp, au inceput sa iasa solutii organizate in structuri XML . Daca DB-urile relationale erau interogate folosind limbajul SQL, DB-urile XML folosesc XPath pentru a efectua query . Asa cum in limbajul SQL exista vulnerabilitati, exista si in XPath . In particular XPath injection, care ne permite sa injectam sintaxe XPath in internul request-ului, pe care aplicatia trebuie sa-l interpreteze, permitandu-ne astfel sa folosim interogari ad-hoc, de exemplu, by-pass al mecanismelor de autentificare, sau accesul la informatii care nu ar trebuii sa fie citite . Structura unei baze XML Pentru a intelege cum functioneaza query XPath, sa ne imaginam o baza de date care contine date de autentificare ( username, password si nivelul de acces ) . <?xml version="1.0" encoding="ISO-8859-1"?> <auth> <user> <username>admin</username> <password>Password</password> <account>admin</account> </user> <user> <username>guest1</username> <password>Passosp1t31</password> <account>guest</account> </user> <user> <username>guest2</username> <password>Passosp1r32</password> <account>guest</account> </user> </auth> Sa specificam mai in detaliu ce semnificatie au tagurile folosite . <auth>, este elementul radacina si il putem considera numele pe care vrem sa-l dam DB-ului nostru . <user>, defineste prima separare de elemente al aceluia intreg, intr-o baza de date relationala ar corespunde cu numele tabelului . <username>, <password> si <account>, definec inregistrarile relative al fiecarui <user> Putem presupune ca un utilizator poate accesa DB-ul prin intermediul front-end, care este programat intr-un oarecare limbaj web compatibil . Prin intermediul acestui instrument va fi posibil sa introducem date, sa le verificam si asa vom garanta accesul la DB, asta in posibilitatile permisiilor . XPath injection In momentul verificarii credentialelor accesului, va fi generat un string asemanator acestuia : //user[username/text()='USERNAME' and password/text()='PASSWORD']/account/text() Aici imput-ul utilizatorului, este reprezentat de string-ul USERNAME si PASSWORD . Daca aplicatia care interpreteaza codul XPath, nu filtreaza amandoua string-urile ( adica nu sterge '' ) atunci aplicatia este expusa unei vulnerabilitati de tip XPath injection . Pentru inceput trebuie sa se verifice injectia de fazabilitate, putem face asta punand un singur apex . Facand asa, serverul va returna o eroare de sintaxa si asa vom fii destul de sigur ca aplicatia este expusa unei vulnerabilitati . Sa vedem acum, cum putem sa profitam . Sa presupunem sa string-urile precedente ( USERNAME si PASSWORD ) sunt valorificate ca aici : USERNAME || ‘ or ‘a’='a PASSWORD || ‘ or ‘a’='a Cu aceste valori, query-ul care va fi rezultat va fi : //user[username/text()='' or 'a'='a' and password/text()='' or 'a'='a']/account/text() Situatia prezentata in acest tip de query va returna in totdeauna pozitiv ( TRUE ), ce va garanta accesul la DB, fara ca utilizatorul sa fii introdus credentiale valide . Daca nu cunoastem nimic despre structura interna al DB-ului XML, sau aplicatia nu furnizeaza nici un mesaj despre eroare, putem folosii un atac de tip Blind Xpath injection . Blind XPath injection In urma datelor pe care le cautam, este posibil sa mai obtinem si functii interne al limbajului XPath si asa vom avea mult mai multe informatii despre structura DB-ului XML . stringlenght() Cu aceasta functie putem extrage lungimea unui string ( sir ) de orice fel din teriorul bazei de date, ca in exemplu . stringlenght(//user[position()=1]/child::node()[position()=2]) In acest caz, vom obtine lungimea string-ului al doilea al primului utilizator . Putem chiar sa verificam daca lungimea este egala cu o valoare determinata . stringlength(//user[position()=1]/child::node()[position()=2]) = 6 Rezultatul va fii TRUE sau FALSE . substring() Putem extrage valoarea continuta in internul unui camp al DB-ului ca in exemplu : substring((//user[position()=1]/child::node()[position()=2]),1,1) In acest fel am obtinut primul caracter al username-ului . Pe langa asta, putem controla daca string-ul de output este egal cu o valoare determinata . substring(//user[position()=1]/child::node()[position()=2]),1,1) = "a" Si in acest caz rezultatul valorii este unu boolean . count() Aceasta functie este aceea care ne permite sa obtinem numarul de noduri in internul structurii . count(//user/child::node()) Si aici putem verifica manual, specificand o valoare si obtinand inca un TRUE sau FALSE . count(//user/child::node()) = 1 Cu aceste trei simple functii, suntem deja in gradul de a explora datele continute de baza de date . Evident procesul de blind injection este lung daca va fii facut manual, dar tool-uri cum ar fii " BurpSuite ", ne permit sa obtinem mult mai rapid rezultate . Prevenire ( Prevention ) Vulnerabilitatile de tip XPath se pot evita intr-un mod analog, ca si in cazul unei SQL injection : Tratand toti input-tii, care previn de la utilizator ca nesiguri si sa aplicam filtre asupra lor . Cand se aplica un filtru input-ului utilizatorului, sa verificam coectitudinea tipului de date, lungimea, formatul si continutul . De exemplu se poate folosii o expresie regulara pentru a controla prezenta tag-uriloe XML si a caracterelor speciale . Intr-o aplicatie " client-server ", sa efectuam controale si pe latura client si pe latura server . Sa facem mereu teste pe aplicatie inanite de a o produce . O alta tehnica buna de prevenire si corectare a vulnerabilitatilor de tip injection este PARAMETRIZAREA . In generam pentru a garanta un nivel de siguranta, este bine sa aplicam filtre urmatoarelor tipuri de caractere : < > / ' = " * ? : ( ) Sursa tutorial
  2. Sample application showing practical approach how to exploit Blind XPath Injection flaw. The tool is intended to be used by IT security researchers and pentesters for educational purposes only. It was first presented at Black Hat 2011. Download: http://xpath-blind-explorer.googlecode.com/files/Xpath%20Blind%20Explorer%201.0.zip
×
×
  • Create New...