[Owasp-antisamy] Owasp-antisamy Digest, Vol 18, Issue 10
jason at singsnap.com
Tue May 26 16:06:12 EDT 2009
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"
> Of course you must also have strict validation on the src of the embed as
> well to prevent non-HTTP(s) URIs.
> *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
>>  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,
>> 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.
>>> Find me on SingSnap:
>>> 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 "&" then build the object again
>>> using that id.
>>> Owasp-antisamy mailing list
>>> Owasp-antisamy at lists.owasp.org
>> Find me on SingSnap:
> Find me on SingSnap:
Find me on SingSnap:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-antisamy