[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <C9B2DD4DEDB9214A84BB2937ACE45B6D1F4418@server05.2bsecure.co.il>
Date: Mon Jul 10 16:34:26 2006
From: erezmetula at 2bsecure.co.il (Erez Metula)
Subject: MIMESweeper For Web 5.X Cross Site Scripting
Hi Brian,
Please consider those attack scenarios:
1. Stealing user cookie. Since it requires that the client should
already have such a cookie, it requires that the client visit the banned
site first. This situation is minimized to the time window in which the
user is logged in and the site got banned. Can happen in 2 situations:
1. The product blacklist file is updated (automatically, on a
daily basis) with the added blacklisted site.
2. The administrator adds the specific site to the blacklist
file.
The attacker will make the product / administrator believe that a site
should be blacklisted - even a short period is enough, to launch the
XSS.
2. Phising/Defacement (using HTML Injection). In this scenario, the
attacker is actually using the fact that some site is banned, and
replace the page content with a forged page.
Example:
http://BannedSite.com/<HTML>forged_page_content_in_here</HTML>
The client will think that he is in the requested site (the browser will
also indicate that),but in fact he will see the forged content - sounds
to me like defacement and/or phishing.
Think about a banned bank web site, in which the attacker will replace
the login page and send the credentials to him.
There are more scenarios, but I think that this is bad enough.
Best regards,
Erez.
________________________________
Erez Metula, CISSP
Application Security Department Manager
Security Software Engineer
E-Mail: erezmetula@...ecure.co.il Mobile: 972-54-2108830
Office: 972-39007530
-----Original Message-----
From: Brian Eaton [mailto:eaton.lists@...il.com]
Sent: Monday, July 10, 2006 2:06 PM
To: full-disclosure@...ts.grok.org.uk
Cc: Erez Metula
Subject: Re: [Full-disclosure] MIMESweeper For Web 5.X Cross Site
Scripting
On 7/9/06, Erez Metula <erezmetula@...ecure.co.il> wrote:
> An example attack scenario could be that an attacker will redirect
many
> users (by email, posting in the organization portal, etc.) to some
blocked
> URL and an accompanying script that will steal their authentication
cookies.
It sounds like the net impact of this vulnerability is that an
attacker can steal cookies for a site the user isn't allowed to visit
anyway. In other words, there aren't going to be any interesting
cookies to steal. Is there more to this attack scenario?
Regards,
Brian
Powered by blists - more mailing lists