[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Full-disclosure] 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@xxxxxxxxxxxxxx      Mobile:  972-54-2108830
Office: 972-39007530     
 
-----Original Message-----
From: Brian Eaton [mailto:eaton.lists@xxxxxxxxx] 
Sent: Monday, July 10, 2006 2:06 PM
To: full-disclosure@xxxxxxxxxxxxxxxxx
Cc: Erez Metula
Subject: Re: [Full-disclosure] MIMESweeper For Web 5.X Cross Site
Scripting

On 7/9/06, Erez Metula <erezmetula@xxxxxxxxxxxxxx> 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/