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

Jason Copp jason at singsnap.com
Tue May 26 16:31:53 EDT 2009


Ah, saw that, thought you meant others as well. Heart rate going back down,
lol. I replace all data: javascript: and vbscript: with

da<!-- mucked up for your safety -->ta:

etc. Think this is adequate? It allows a profile to still use the word data:
and display the html output fine, with limited possibility of execution. And
just for giggles I replace document.cookie with notument.nookie as a catch
in case I miss something.

Jason

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

>  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
>>>
>>>
>>> ------------------------------
>>> *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 listOwasp-antisamy at lists.owasp.orghttps://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
>



-- 

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/e8af31ec/attachment-0001.html 


More information about the Owasp-antisamy mailing list