Double Trap XSS Injection : An Analyis

Core Analysis.

Aditya K Sood, SecNiche.
zeroknock [at] secniche.org


The Analysis is done for Education Purposes Only! The issue have been reported to the owner ha.ckers.org.Patched Already.


Analysis

This analysis will enable you to the different realm of XSS injection attacks. No XSS cheatsheat is used in this. I am presenting the full analysis of it. The demonstration target is SecTheory security consultation website. This process goes in both ways. This will throw light on the trodden basics of security companies and also helpful in determining new class of exploitation. The end result is same but the way is different. The hackers for exploiting websites look for the security loopholes. Where he finds it he will attack it. When i was enumerating the website i always track for two elements i.e.

I was traversing the website I would not find any url parameter where input values can be passed. As I clicked the last page , which I like the most , The Contact Us page. This provide me with four basic input values object which are used bu the administrator to contact the company. A simple snapshot is provided below.

If you look I got four input tracks.The next step is to check the limit of the input that one can induce in the form input boxes.Then I jump to have a look at the input box parameters. Lets see: 
			<INPUT TYPE="TEXT" NAME="login" style="width:300px" MAXLENGTH="100">
	        	<div id="contact" align="right">
	          	Your phone number:
	          	<INPUT TYPE="TEXT" NAME="number" style="width:300px" MAXLENGTH="100">
	        	<div id="contact" align="right">
	          	Your email address:
	          	<INPUT TYPE="TEXT" NAME="email" style="width:300px" MAXLENGTH="100">


The max length used is 100.Thats enough.The next point is to check whether error is generated or by testing against false arguments.The point comes to (') injection which is one of my favourite. Then the placed the defined injection as: 


			'<script>alert(document.cookie);</script>
			'<script>alert(document.domain);</script>


I inject this code in the form applet nothing happens at the value is posted to the server. This injection not act as a useful entity.Remember always never ever forgive to perform the ("") injections because if you kick your brain a bit than you find the value passed to the form is always as:




Our point is to test the application form against it.I loaded the browser and again and feed the form with the defined code but this time bit different. 


	 	'<script>alert("XSS Says :Let Me IN !");</script>''''''''

The result I gathered is :




The injection does not trap the application full but gives hint about the injected element. I get back to the source and find something really useful as :



This provides information about the half injection.I tried many injection as Single Trap of XSS but not useful.Then I decided to play with Double Trap XSS Injections and see what i got: The very first injection I tried is:



The double trapping works.The XSS injection is on the way. Lets try another injection:


	
		'<script>alert("XSS");</script>'<script>alert(document.domain)'</script>

Lets see:





The domain is displayed after the injections: 


	'<script>alert("XSS");</script>'<a href="telnet://203.197.219.33"><h3>TELNET</h3></a>




The double trap XSS is working very fine.The analysis is quiet successfull.The Protection is all yours.

Concern

This is a serious security issue, with potential implications that are only starting to be understood. However, it is critical to realize that this problem does not expose any way to break into the server itself. What it allows is for malicious attackers to potentially take control of the interaction between a user and a website. If your website contains entirely static content with all information being publicly accessible, an attacker can gain very little from taking over this interaction. It is likely that the most serious thing that an attacker can potentially do in this situation is change how a page appears to a particular user. The sites where this poses the most potential danger are sites where users have some type of account or login and where they can perform actions with real world implications or access data that should not be publicly available. This security problem poses a serious threat to such sites; it isn't necessary to break into the server to take control of a site if instead you can gain access on the user's end of things.

Response

http://ha.ckers.org/blog/20070316/forgetting-global-replace-xss-woes/