[Owasp-antisamy] Owasp-antisamy Digest, Vol 18, Issue 10

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Tue May 26 16:26:13 EDT 2009


The data: URI [1]. It can be used by attackers to inject otherwise disallowed content. See the link I sent my first email for an example of using <embed> + data: to execute arbitrary JavaScript.
 
Arshan

________________________________

From: Jason Copp [mailto:jason at singsnap.com]
Sent: Tue 5/26/2009 4:06 PM
To: Arshan Dabirsiaghi
Cc: Andrew Grosset; owasp-antisamy at lists.owasp.org
Subject: Re: [Owasp-antisamy] Owasp-antisamy Digest, Vol 18, Issue 10


Excellent! 

What non-HTTP URI do you speak of? 


On Tue, May 26, 2009 at 3:58 PM, Arshan Dabirsiaghi <arshan.dabirsiaghi at aspectsecurity.com> wrote:


	That smacks of a useful feature. Something like:
	 
	<tag name="embed">
	    <require-attribute name="allowScriptAccess" value="never" provide-if-missing="true"/>
	    ...
	</tag>
	 
	Of course you must also have strict validation on the src of the embed as well to prevent non-HTTP(s) URIs.
	 
	Arshan

________________________________

	From: Jason Copp [mailto:jason at singsnap.com]
	Sent: Tue 5/26/2009 3:49 PM
	To: Arshan Dabirsiaghi
	Cc: Andrew Grosset; owasp-antisamy at lists.owasp.org 

	Subject: Re: [Owasp-antisamy] Owasp-antisamy Digest, Vol 18, Issue 10
	

	Great point on the embed / object. This is preventable by setting allowscriptaccess to never. I replace all occurances of allowscriptaccess with garbage, and inject allowscriptaccess = "never" for every object / embed tag.
	
	It's not perfect, but its a balance. 
	
	
	On Tue, May 26, 2009 at 3:01 PM, Arshan Dabirsiaghi <arshan.dabirsiaghi at aspectsecurity.com> wrote:
	

		The param being swallowed, if it's allowed in your policy file, represents a bug. It might be a regression for the recent "formjacking" type of attack we tried to prevent. 
		 
		Did I miss an email that had some example strings? I'd like to be able look at what's happening here. 
		 
		Also, it should be noted that allowing arbitrary <embed> content is essentially the same as allowing <script> content. You can use the embed tag to import malicious Flash that executes arbitrary JavaScript, or use the data scheme to execute JavaScript directly [1].
		 
		Arshan
		 
		[1] http://ha.ckers.org/xss.html <http://ha.ckers.org/xss.html> 
		 

________________________________

		From: owasp-antisamy-bounces at lists.owasp.org on behalf of Jason Copp
		Sent: Tue 5/26/2009 2:40 PM
		To: Andrew Grosset
		Cc: owasp-antisamy at lists.owasp.org
		Subject: Re: [Owasp-antisamy] Owasp-antisamy Digest, Vol 18, Issue 10
		
		
		That is nearly my exact work-around, but now I've found that antisamy barks up the CSS that myspace css generators make, so it mustn't be 100% compatible. We fully allow object and embed, and style sheets, etc, just like myspace, so I am going with a blacklist for now. We use additional behind the scenes protection for the main concern (cookie hijacking) and must balance security with expectations, as always.
		
		Thanks though,
		Jason
		
		
		On Tue, May 26, 2009 at 1:16 PM, Andrew Grosset <ag5743 at telus.net> wrote:
		

			owasp-antisamy-request at lists.owasp.org wrote:
			

				Hi folks,
				
				I've got antisamy 1.3 running under CF8. I'm unable to allow the <param> tag regardless of it's inclusion in a policy file or not. I can add any other tag, including object and applet.
				
				I searched the source to determine if it is hard coded but didn't find it (but that was tough since the word param is all over the source).
				
				Additionally, is there a directive or some other method of specifically allowing a tag that has no content? The <param> tag used on sites like youtube in their embed code is in this format and I wish to allow it.
				
				
				Thanks,
				Jason
				
				-- 
				
				Find me on SingSnap:
				http://www.singsnap.com/jason
				
				
________________________________


				_______________________________________________
				Owasp-antisamy mailing list
				Owasp-antisamy at lists.owasp.org
				https://lists.owasp.org/mailman/listinfo/owasp-antisamy
				  

			Hi Jason,
			
			I convert the youTube object into a gif image with a specific (style) class and  the id of the movie into the title of the image then pass it through anti-samy after that I  convert the image back into a youTube object. Trying to allow <param> or <object> tags under specific circumstances is dangerous to say the least so if allowing a youTube object you have to be real careful that it actually is genuine. All you need to look for with youTube is the id of the movie and parse that to make sure its only alphanumeric and "-" and "_" and "&amp;" then build the object again using that id.
			
			Andrew.
			

			_______________________________________________
			Owasp-antisamy mailing list
			Owasp-antisamy at lists.owasp.org
			https://lists.owasp.org/mailman/listinfo/owasp-antisamy
			
			




		-- 
		
		Find me on SingSnap:
		http://www.singsnap.com/jason
		




	-- 
	
	Find me on SingSnap:
	http://www.singsnap.com/jason
	




-- 

Find me on SingSnap:
http://www.singsnap.com/jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-antisamy/attachments/20090526/b697ed35/attachment.html 


More information about the Owasp-antisamy mailing list