Leaderboard

CVE OneLogin - python-saml - CVE-2017-11427 OneLogin - ruby-saml - CVE-2017-11428 Clever - saml2-js - CVE-2017-11429 OmniAuth-SAML - CVE-2017-11430 Shibboleth - CVE-2018-0489 Duo Network Gateway - CVE-2018-7340 The Security Assertion Markup Language, SAML, is a popular standard used in single sign-on systems. Greg Seador has written a great pedagogical guide on SAML that I highly recommend if you aren't familiar with it. For the purpose of introducing this vulnerability, the most important concept to grasp is what a SAML Response means to a Service Provider (SP), and how it is processed. Response processing has a lot of subtleties, but a simplified version often looks like: The user authenticates to an Identity Provider (IdP) such as Duo or GSuite which generates a signed SAML Response. The user’s browser then forwards this response along to an SP such as Slack or Github. The SP validates the SAML Responses signature. If the signature is valid, a string identifier within the SAML Response (e.g. the NameID) will identify which user to authenticate. A really simplified SAML Response could look something like: <SAMLResponse> <Issuer>https://idp.com/</Issuer> <Assertion ID="_id1234"> <Subject> <NameID>user@user.com</NameID> </Subject> </Assertion> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="xml-c14n11"/> <Reference URI="#_id1234"/> </SignedInfo> <SignatureValue> some base64 data that represents the signature of the assertion </SignatureValue> </Signature> </SAMLResponse> This example omits a lot of information, but that omitted information is not too important for this vulnerability. The two essential elements from the above XML blob are the Assertion and the Signature element. The Assertion element is ultimately saying "Hey, I, the Identity Provider, authenticated the user user@user.com." A signature is generated for that Assertion element and stored as part of the Signature element. The Signature element, if done correctly, should prevent modification of the NameID. Since the SP likely uses the NameID to determine what user should be authenticated, the signature prevents an attacker from changing their own assertion with the NameID "attacker@user.com" to "user@user.com." If an attacker can modify the NameID without invalidating the signature, that would be bad (hint, hint)! XML Canononononicalizizization: Easier Spelt Than Done The next relevant aspect of XML signatures is XML canonicalization. XML canonicalization allows two logically equivalent XML documents to have the same byte representation. For example: <A X="1" Y="2">some text<!-- and a comment --></A> and < A Y="2" X="1" >some text</ A > These two documents have different byte representations, but convey the same information (i.e. they are logically equivalent). Canonicalization is applied to XML elements prior to signing. This prevents practically meaningless differences in the XML document from leading to different digital signatures. This is an important point so I'll emphasize it here: multiple different-but-similar XML documents can have the same exact signature. This is fine, for the most part, as what differences matter are specified by the canonicalization algorithm. As you might have noticed in the toy SAML Response above, the CanonicalizationMethod specifies which canonicalization method to apply prior to signing the document. There are a couple of algorithms outlined in the XML Signature specification, but the most common algorithm in practice seems to be http://www.w3.org/2001/10/xml-exc-c14n# (which I'll just shorten to exc-c14n). There is a variant of exc-c14n that has the identifier http://www.w3.org/2001/10/xml-exc-c14n#WithComments. This variation of exc-c14n does not omit comments, so the two XML documents above would not have the same canonical representation. This distinction between the two algorithms will be important later. XML APIs: One Tree; Many Ways One of the causes of this vulnerability is a subtle and arguably unexpected behavior of XML libraries like Python’s lxml or Ruby’s REXML. Consider the following XML element, NameID: <NameID>kludwig</NameID> And if you wanted to extract the user identifier from that element, in Python, you may do the following: from defusedxml.lxml import fromstring payload = "<NameID>kludwig</NameID>" data = fromstring(payload) return data.text # should return 'kludwig' Makes sense, right? The .text method extracts the text of the NameID element. Now, what happens if I switch things up a bit, and add a comment to this element: from defusedxml.lxml import fromstring doc = "<NameID>klud<!-- a comment? -->wig</NameID>" data = fromstring(payload) return data.text # should return ‘kludwig’? If you would expect the exact same result regardless of the comment addition, I think you are in the same boat as me and many others. However, the .text API in lxml returns klud! Why is that? Well, I think what lxml is doing here is technically correct, albeit a bit unintuitive. If you think of the XML document as a tree, the XML document looks like: element: NameID |_ text: klud |_ comment: a comment? |_ text: wig and lxml is just not reading text after the first text node ends. Compare that with the uncommented node which would be represented by: element: NameID |_ text: kludwig Stopping at the first text node in this case makes perfect sense! Another XML parsing library that exhibits similar behavior is Ruby's REXML. The documentation for their get_text method hints at why these XML APIs exhibit this behavior: [get_text] returns the first child Text node, if any, or nil otherwise. This method returns the actual Text node, rather than the String content. Stopping text extraction after the first child, while unintuitive, might be fine if all XML APIs behaved this way. Unfortunately, this is not the case, and some XML libraries have nearly identical APIs but handle text extraction differently: import xml.etree.ElementTree as et doc = "<NameID>klud<!-- a comment? -->wig</NameID>" data = et.fromstring(payload) return data.text # returns 'kludwig' I have also seen a few implementations that don’t leverage an XML API, but do text extraction manually by just extracting the inner text of a node’s first child. This is just another path to the same exact substring text extraction behavior. The vulnerability So now we have the three ingredients that enable this vulnerability: SAML Responses contain strings that identify the authenticating user. XML canonicalization (in most cases) will remove comments as part of signature validation, so adding comments to a SAML Response will not invalidate the signature. XML text extraction may only return a substring of the text within an XML element when comments are present. So, as an attacker with access to the account user@user.com.evil.com, I can modify my own SAML assertions to change the NameID to user@user.com when processed by the SP. Now with a simple seven-character addition to the previous toy SAML Response, we have our payload: <SAMLResponse> <Issuer>https://idp.com/</Issuer> <Assertion ID="_id1234"> <Subject> <NameID>user@user.com<!---->.evil.com</NameID> </Subject> </Assertion> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="xml-c14n11"/> <Reference URI="#_id1234"/> </SignedInfo> <SignatureValue> some base64 data that represents the signature of the assertion </SignatureValue> </Signature> </SAMLResponse> How Does This Affect Services That Rely on SAML? Now for the fun part: it varies greatly! The presence of this behavior is not great, but not always exploitable. SAML IdPs and SPs are generally very configurable, so there is lots of room for increasing or decreasing impact. For example, SAML SPs that use email addresses and validate their domain against a whitelist are much less likely to be exploitable than SPs that allow arbitrary strings as user identifiers. On the IdP side, openly allowing users to register accounts is one way to increase the impact of this issue. A manual user provisioning process may add a barrier to entry that makes exploitation a bit more infeasible. Sursa: https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

This post requires you to click the Likes button to read this content. http://a.pomf.se/pjmwvx.png """ OLX.ro scraper Gets name, phone no., Yahoo! & Skype addresses, where applicable http://a.pomf.se/pjmwvx.png """ import re import json import requests from bs4 import BeautifulSoup as b pages = 1 # How many pages should be scraped # Category URL, a.k.a. where to get the ads from catURL = "http://olx.ro/electronice-si-electrocasnice/laptop-calculator/" # Links to the Ajax requests ajaxNum = "http://olx.ro/ajax/misc/contact/phone/" ajaxYah = "http://olx.ro/ajax/misc/contact/communicator/" ajaxSky = "http://olx.ro/ajax/misc/contact/skype/" def getName(link): # Get the name from the ad page = requests.get(link) soup = b(page.text) match = soup.find(attrs={"class": "block color-5 brkword xx-large"}) name = re.search(">(.+)<", str(match)).group(1) return name def getPhoneNum(aID): # Get the phone number resp = requests.get("%s%s/" % (ajaxNum, aID)).text try: resp = json.loads(resp).get("value") except ValueError: return # No phone number if "span" in resp: # Multiple phone numbers nums = b(resp).find_all(text=True) for num in nums: if num != " ": return num else: return resp def getYahoo(aID): # Get the Yahoo! ID resp = requests.get("%s%s/" % (ajaxYah, aID)).text try: resp = json.loads(resp).get("value") except ValueError: return # No Yahoo! ID else: return resp def getSkype(aID): # Get the Skype ID resp = requests.get("%s%s/" % (ajaxSky, aID)).text try: resp = json.loads(resp).get("value") except ValueError: return # No Skype ID else: return resp def main(): for pageNum in range(1, pages+1): print("Page %d." % pageNum) page = requests.get(catURL + "?page=" + str(pageNum)) soup = b(page.text) links = soup.findAll(attrs={"class": "marginright5 link linkWithHash \ detailsLink"}) for a in links: aID = re.search('ID(.+)\.', a['href']).group(1) print("ID: %s" % aID) print("\tName: %s" % getName(a['href'])) if getPhoneNum(aID) != None: print("\tPhone: %s" % getPhoneNum(aID)) if getYahoo(aID) != None: print("\tYahoo: %s" % getYahoo(aID)) if getSkype(aID) != None: print("\tSkype: %s" % getSkype(aID)) if __name__ == "__main__": main() Tocmai scraper: https://rstforums.com/forum/98245-tocmai-ro-scraper-nume-oras-numar-telefon.rst

Salutare vin cu un nou tutorial dupa multa inactivitate dar de folos . Am venit cu un tutorial de scoatere a contului Google Dupa un reset sau FRP/Oem unlock aceasta metoda este pentru toate Procesoarele MTK ,titlul este asa deoarece nu am gasit nicaieri fie in romana sau engleza de o modalitate pentru tableta asta momentan nu au pus developeri mana pe ea fiind lansata anul acesta in luna Mai ,o sa incep sa pun eu mana pe ea:)) Dupa o suta de mi de incercari 3 zile de nervi si 6 beri baute am data de metoda asta Bun,sa incepem 1. Instalam driverele MTK de aici: https://www.4shared.com/rar/KjRZvp_Lce/Mediatek_Preloader_USB_VCOM_dr.htm?locale=en 2. Descarcam Miracle box crack :https://docs.google.com/uc?id=0B73CdsYiX90zVkhia0dEUVBrTms&export=download (Atentie NU ne trebuie Interfata MIRACLE BOX!) 3.Instalam miracle box apoi copiem fisierul crack si loader in folderul miraclebox/programfiles 4.Deschidem Miracel box Loader selectam sectiunea MTK apoi subsectiunea Unlock/fix si selectam Clear setting/FRP 5.Apasam butonul start si conectam Tableta/device-ul la usb ATENTIE! Device-ul trebuie sa fei stins (Daca nu il recunoaste ca Mediatek preloader VCOM in timp ce il conectam apasam butonul Vol +) 6. Programul isi fa face treaba si ne va aparea mesajul Done! ATENTIE! dupa mesajul done trebuie lasata 5-10 minute conectata apoi sa o pornim! 7.Siii VOILA! avem o tableta fara cont google! P.S O sa revin si cu un UPDATE cu Firmwareul/ROM-ul dupa ce il extrag cumva sa fie compatibil cu SP flash tool SPOR la treaba! br, pHilo UPDATE: Modelul de baza este un TCL ALCATEL OT-9003 alctel pixi 4(7)

Ii facem salata din sfecla rosie. Multumesc, si multa sanatate tatalui tau, ti-am lasa in privat cartea, poate vrei sa te inspiri din ea.

A YouTuber who claimed being vegan cured her cancer has died from cancer

Hello everybody! I'm Dorian, 41 years old from Romania, I'm a web & graphic designer quite fond of cybersecurity intelligence and pentest. I've joined this community to offer and receive information on web applications security and vulnerability. I know, normally I should not care about security hence I'm just a designer, but in 20 years I've encountered numerous and various situations of defacing and hacking and I needed to learn how to protect my work or my client's websites. In time I succeeded to offer a minimal and required percent of security and now I'm offering this service to all my clients if they agree. I do web application pentest on my own work and usually I ask other people to pentest and/or give me an opinion. I'm present on a series of websites where I can exchange knowledge but no Romanian ones, thus I've joined RST and I'm greeting the community for a good work and activity. I know that because one of my friends has referred RST to me. My everyday activity consists of designing websites, offering counseling to my clients, pentesting applications, doing some social engineering for a few companies with 100s of employees and filter the weak ones. As tools I use two laptop PCs with Slackware ( Predator Helios 300 17" - for production) and Kali Linux in dual boot with Tails (ASUS Vivobook - for pentest related stuff). I run a couple of VMs, too - I have to (macOS and Windows). I use only FOSS for production and stay with it. I do my graphics using GIMP and Inkscape, I write my code with gEdit and Bluefish, check my mail and handle calendar with Evolution. For penetration testing I use the well-known tools provided by Kali Linux plus a few more like uniscan, SPF, Katana Framework, routerspolit, whatweb, airgeddon, weeman. When it's the case I "drop" the RubberDucky which I took the time to customise a bit, I'm not a pro in pentest (I'm a pro in design), but I've managed to create some scripts that brought me good enough results. Other than that, I have a small KIT of antenna's, loads of cables (perhaps too many, hehe), external drives with tools for cloning machines, extract information etc. Ah, and of course, the screw-driver KIT and pliers and a chocolate, you never know when you need it I'm not sure yet what my contribution will be for the RST community, but I'm glad I'm here and looking forward to make friends, read your threads and perhaps have some geek fun. Cheers, Dorian

sa sugi pl rautatioasa mica ca vorbesti aiurea Am comanda ulei OCB pentru tatal meu,el are cancer la plamani si metastaze la mandibula. Este foarte nasol sansele sunt mici, sperantele sunt mari,este in ultimul stadiu.Citostaticile sunt apa de ploaie. Le face de 6 luni si cancerul a fost depistat din timp. Sper sa isi faca efectu' uleiul. Multa sanatate!Ca realizezi cat ai nevoie doar dupa ce o pierzi.

Pupy Pupy este un OpenSource , multi-platforma(WIN,Linux,OSX,Android).Este un RAT(instrument de administrare de la distanta) si un instrument de post-exploatare.In principal este scris in Python. Modulele Pupy pot accesa în mod transparent obiecte Python de la distan?ă folosind rpyc pentru a efectua diverse activită?i interactive. Pupy poate genera sarcini utile în mai multe formate, cum ar fi executabilele PE, DLL-uri, fi?iere Python pure, PowerShell, apk, ... -Alege un lansator (connect,bind...), un transport(ssl,http,rsa,obfs3,scramblesuit,...) si un numar de "scriptlets".Scriptlets sun scripturi menite sa fie incorporate pentru a efectua sarcini diverse off-line(fara a necesista o sesiune), cum ar fi adaugarea de persistenta, de a porni un keylogger, detectarea de sandbox. Caracteristici -Pe ferestre, Pupy este compilat ca un DLL si este incarcat in memorie. -Poate migra reflexiv in alte procese. -Poate importa la distanta, din memorie, pachete python pure(PY,.PYC), Pyhton C(.pyd). -Pupy este usor extensibil, foloseste[rpyc]. -Pupy poate comunica folosind si obfsproxy.Toate modulele non interactive pot fi expediate la gazde multiple intr-o singura comanda. -Multi-platforma(testat pe win 7,8,10,kali linux,ubuntu,OSX,Android) -In mai multe formate exe(x86, x64), dll (x86, x64), Python, apk, ... Transport -rsa -Un strat cu autentificare sicriptare folosind RSA si AES256, de multe ori cu alte straturi suprapuse. -Strat folosind o cheie AES256 statica -Ssl(defaut) -http - obfs3 -cu ajutorul stratului rsa pentru o securitate mai buna. -etc. Windows Specific -migreaza -functioneaza foarte bine cu [mimitakz] -screenshot -inregistrare microfon -keylogger -inregistrare tastatura -capturi de ecran la fiecare click -etc Screenshots https://github.com/n1nj4sec/pupy/wiki/Screenshots Install git clone https://github.com/n1nj4sec/pupy.git pupy cd pupy git submodule update --init --depth 1 pupy/payload_templates git submodule init git submodule update pip install -r requirements.txt

Tin de la inceput sa mentionez ca tutorialul este pentru aplicatii web. De-a lungul timpului am vazut numeroase persoane care, desi aveau cunostinte despre anumite vulnerabilitati web(de ce apar, cum se exploateaza, etc.), nu reuseau sa gaseasca mai nimic in aplicatii web reale. Acest lucru se datoreaza faptului ca au sarit peste o etapa esentiala a unui audit de securitate si anume, Information Gathering. Neavand o metodologie clara si un plan de atac bine stabilit, acestia nu erau in masura sa obtina date suficiente despre aplicatiile pe care le analizau iar ca urmare a acestui lucru nu reuseau sa identifice vulnerabilitatile. In acest tutorial vom discuta despre care sunt informatiile de care avem nevoie despre tinta si cum le putem afla astfel incat sa ne maximizam rezultatele. Asa cum spuneam la inceputul acestui tutorial, Information Gathering este etapa initiala a oricarui audit de securitate IT care poate face diferenta dintre succes si esec. Prin aceastea, pentesterul incearca sa obtina toate informatiile posibile despre tinta folosindu-se de diferite servicii (motoare de cautare, diferite utilitare, etc.). Intrucat nu exista un model standard, fiecare pentester este liber sa isi construiasca propria metodologie astfel incat rezultatele sa fie cat mai bune. In cele ce urmeaza voi prezenta modul in care obisnuiesc eu sa abordez o tinta atunci cand realizez un audit de securitate. 1.Motoarele de cautare Primul lucru pe care trebuie sa il faci este sa cauti informatii prin intermediul motoarelor de cautare folosindu-te de diferiti operatori de cautare. Astfel poti obtine subdomeniile, diferite fisiere, tehnologiile folosite de aplicatia web si chiar unele vulnerabilitati. Exemplu: diferite subdomenii ale yahoo.com Cei mai folositori operatori ai motorului de cautare Google sunt: site: - acest operator permite afisarea rezultatelor doar de pe un anumit domeniu si este extrem de folositor pentru descoperirea subdomeniilor. Exemplu: site:*.yahoo.com filetype: sau ext: limiteaza rezultatele afisand doar paginile care au o anumita extensie si pot fi folosite pentru a descoperi tehnologiile folosite in dezvoltarea aplicatiei web. Exemplu: site:*.yahoo.com ext:php – am limitat rezultatele cautarii la subdomeniile yahoo.com care au fisiere .php intext:<termen> limiteaza rezultatele afisand doar paginile in care se regaseste termenul specificat si poate fi folosit pentru a descoperi diferite vulnerabilitati. Exemplu: site:targetwebsite.com intext:”You have an error in your SQL syntax” site:targetwebsite.com intext:”Microsoft OLE DB Provider for SQL Server” site:targetwebsite.com intext:”Microsoft JET Database Engine” site:targetwebsite.com intext:”Type mismatch” site:targetwebsite.com intext:”Invalid SQL statement or JDBC” site:targetwebsite.com intext:”mysql_fetch_array()” site:targetwebsite.com intext:”mysql_” operatori logici: Google accepta anumiti operatori logici care de cele mai multe ori sunt foarte folositori. De exemplu, putem exclude din rezultate anumite subdomenii folosind operatorul - . Astfel, site:.yahoo.com -site:games.yahoo.com va returna subdomeniile yahoo.com, mai putin rezultatele care au legatura cu games.yahoo.com. Mai multe informatii despre operatorii de cautare pentru Google gasesti aici si aici. Pe langa motoarele de cautare obsnuite ca Google, Bing, Yahoo etc., foloseste si: Censys - Foarte folositor in descoperirea subdomeniilor Exemplu: https://www.censys.io/certificates?q=parsed.subject.organization%3A%22Yahoo%22 Shodan 2. Determinarea tehnologiilor folosite La acest pas va trebuie sa verifici daca: aplicatia web este protejata de vreun Web Application Firewall (WAF) Cel mai simplu mod prin care poti face acest lucru este folosind wafw00f: $ python watw00f2.py http://www.targetwebsite.com aplicatia web foloseste un Content Management System (CMS) open-source (Wordpress, Joomla, Drupal, etc.) Poti verifica acest lucru folosind whatweb, cms-explorer, CMSmap. $ whatweb -a 3 http://targetwebsite.com $ cms-explorer.pl -url http://targetwebsite.com/ -type wordpress Urmatorul pas consta in identificarea sistemului de operare, al tipului de WebServer (Apache, IIS) folosit de tinta si versiunea acestora. Daca versiunile celor doua sunt outdated, cel mai probabil exista cateva vulnerabilitati cunoscute (CVE) in acele produse. Poti descoperi acest lucru cu o simpla cautare pe http://cvedetails.com . Exemplu: Vulnerabilitatile cunoscute pentru Apache 2.3.1 Determinarea sistemului de operare se poate realiza foarte simplu folosind nmap. $ nmap -sV -O www.targetwebsite.com Metodele prin care poti identifica versiunea Webserver-ului sunt: Analizand output-ul cererilor HTTP care folosesc metoda HEAD, OPTIONS sau TRACE Raspunsul HTTP al unei cereri care foloseste una din metodele de mai sus va contine, de cele mai multe ori, si headerul Server. Analizand pagina de eroare 404 Folosind httprecon / httprint . Un alt aspect important il constituie tehnologia server-side folosita de tinta. Cel mai simplu mod in care aceasta poate fi descoperita este urmarind extensiile fisierelor. De exemplu, daca URL-ul tintei este http://targetwebsite.com/index.php , este clar ca aplicatia web a fost scrisa in limbajul PHP. Alte extensii specifice tehnologiilor server-side sunt: .py – Python .rb – Ruby .pl – Perl .php / .php3 / .php4 / .php5 / .phtml / .phps – PHP .asp – Active Server Pages (Microsoft IIS) .aspx – ASP+ (Microsoft .NET) .asmx – ASP.NET WebServer .cfm – ColdFusion .cfml – Cold Fusion Markup Language .do – Java Struts .action – Java Struts .jnpl – Java WebStart File .jsp – Java Server Page .nsf – Lotus Domino server In cazul in care extensiile nu sunt vizibile in URL, poti identifica tehnologia server-side folosita analizand cookie-ul pe care aplicatia web il seteaza. Exemplu: PHPSESSID=12355566788kk666l544 – PHP De asemenea, iti poti da seama daca o aplicatie web este scrisa in PHP si prin intermediul unui Easter Egg. Daca adaugi codul ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 la finalul unui URL iar in pagina apare o imagine amuzanta inseamna ca aplicatia respectiva a fost dezvoltata folosind PHP. Bineinteles, acest Easter Egg poate fi dezactivat din php.ini. Mai multe informatii gasesti aici. 3. Identificarea fisierelor aplicatiei web La acest pas nu trebuie decat sa accesezi cat mai multe pagini alte aplicatiei web, fara a face nimic altceva. Viziteaza fiecare pagina insa nu uita sa conectezi browserul la Burp Suite pentru a se crea site-map-ul aplicatiei web. Astfel vei avea o evidenta mult mai clara asupra fisierelor pe care urmeaza sa le testezi. Foloseste Burp Spider pe langa navigarea manuala pentru a descoperi cat mai multe fisiere. PS: verifica daca exista fisierul robots.txt Dupa ce consideri ca ai navigat suficient printre fisierele aplicatiei web, trebuie sa descoperi fisierele ascunse. Exista numeroase aplicatii care te pot ajuta: Dirbuster Functia Discover Content a aplicatiei BurpSuite Wfuzz Patator Burp Intruder Liste de cuvinte pentru scripturile de mai sus: fuzzdb gitDigger svnDigger SecLists Urmatorul pas este sa iei la rand fiecare fisier gasit si sa incerci sa intelegi cum functioneaza aplicatia web respectiva. Pentru a-ti fi mai usor sa iti dai seama unde ar putea exista o vulnerabilitate, pune-ti urmatoarele intrebari: 1. In fisierul pe care il testezi, continutul se modifica in mod dinamic in functie de anumite criterii (valoarea unui parametru din URL, cookie, user agent etc.) ? Mai exact, este posibil ca in acel fisier aplicatia web sa foloseasca informatii dintr-o baza de date? Daca da, testeaza in primul rand pentru vulnerabilitatile de tip injection (SQL, XPATH, LDAP, etc.) insa nu neglija celelalte tipuri de vulnerabilitati. S-ar putea sa ai surprize. 2. Poti controla in vreun fel continutul paginii? Ceilalti utilizatori pot vedea datele pe care le introduci tu? Daca da, testeaza in special pentru vulnerabilitati de tip Cross Site Scripting si Content Spoofing. 3. Aplicatia web poate interactiona cu alte fisiere? Daca da, testeaza in special pentru Local File Inclusion. 4. In fisierul respectiv exista functii care necesita nivel sporit de securitate (cum ar fi formular de schimbare al emailului/parolei etc.)? Daca da, testeaza in special pentru Cross Site Request Forgery. Nu uita sa testezi fiecare parametru al fiecarui fisier pe care l-ai descoperit.

60mil ii faci in 10 luni roi ma refer, indiferent de ce placi iti iei de banii aia... cam ala e roi cu, curent si net moca (dar netul e infim poti folosi si un stick rds, hai sa nu mai vb de el) Uita-te asa informativ pe olx si vezi ce poti sa cumperi: https://www.olx.ro/oferte/q-rig-minat/ (sa nu uitam ca ce e acolo e obosit si SH) ----------------vezi ca este si noi boss scrie prin descrieri

mineaza vreounu dintre cei care ati comentat?