I prefer if you mind your own business and not bother me or the opencart community. The exploit that is being discussed will be fixed in the next release. I don't need your services. Stop wasting my time.

Stop bothering me!

The disclosure timeline follows:
* Reported by root@80sec.com: May 11 2009
* Discovered by webmaster@lapstore.de: June 19 2009
* Discovered by Giorgio Maone / Eduardo Vela: July 14 2009
* Reported and Fixed on PHPIDS: July 14 2009
* Microsoft notified of a XSS Filter bypass: July 14 2009
* Fixed XSS Filter bypass on NoScript 1.9.6:  July 20 2009
* Vulnerability disclosed on BlackHat USA 2009: July 29 2009
* Added signature to Acunetix WVS: August 14 2009
* Re-reported by sird@rckc.at: September 27 2009
* Vendor claims it was fixed on 5.2.11: September 29 2009
* Re-re-reported by sird@rckc.at after checking 5.2.11: October 16 2009
* Published sirdarckcat.blogspot.com: October 16 2009

As REQUIRED by UNICODE 3.1, and noted in the Unicode Technical Report #36, UTF-8 is forbidden to interpretate a character's non-shortest form.

// add slashes!
foreach($_GET as $k=>$v)$_GET[$k]=addslashes("$v");

//  .... some code ...

// $name is encoded in utf8
$name=utf8_decode($_GET['name']);
mysql_query("SELECT * FROM table WHERE name='$name';");

?>

// htmlentities
foreach($_GET as $k=>$v)$_GET[$k]=htmlentities("$v",ENT_QUOTES);

//  ... some code ...

$name=$_GET['name'];
$url=$_GET['url'];

//  ... some code ...

$profileImage="<img alt="Photo of $name" src="http://$url" />";

// ... some code ...
echo utf8_decode($profileImage);
?>

//  php/ext/xml/xml.c#558
PHPAPI char *xml_utf8_decode(    //  ...
{
    int pos = len;
    char *newbuf = emallo    //  ...
    unsigned short c;          // sizeof(unsigned short)==16 bits
    char (*decoder)(unsig    //  ...
    xml_encoding *enc = x    //  ...
//  ...
//  #580
    c = (unsigned char)(*s);
    if (c >= 0xf0) {         /* four bytes encoded, 21 bits */
        if(pos-4 >= 0) {
            c = ((s[0]&7)<<18) | ((s[1]&63)<<12) | ((s[2]&63)<<6) | (s[3]&63);
        } else {
            c = '?';   
        }
        s += 4;
        pos -= 4;
//  ...

x= ((s[0]&7)<<18) | ...

(xxxx xxxx & 0000 0111) << 18

...  ((s[1]&63)<<12) | ...

(xxxx xxxx & 0011 1111) << 12

0xF0 0x81 0x80 0x80

0xE1 0x80 0x80

Bad Request
Your browser sent a request that this server could not understand.

Size of a request header field exceeds server limit.

Cookie:

v 1.1.6.25
=====================================================================
+ Fix for Sirdarckcat's JS redirection trick

v 1.1.7.6
=====================================================================
+ srv.br "special" TLD (thanks Rodrigo Ristow Branco)
+ Better protection against "setter" based XSS vectors and encoded
"name" payloads (thanks RSnake, Sirdarckcat and Kuza55, see
http://ha.ckers.org/blog/20071104/owning-hackersorg-or-not/ )
+ Improved hidden links management, preserves original body CSS
attributes when possible (thanks mdots)

v 1.1.7.8
=====================================================================
+ JAR uris are forbidden from loading as documents by default, see
http://noscript.net/faq#jar for details
+ Block untrusted XBL (thanks Sirdarckcat for inspiration)
x Various IFrame blocking refinements

v 1.2.2
=====================================================================
x Changed noscript.filterXGetRx default to make single quote removal
happen only after positive injection checks (thanks sirdarckcat for
suggestion)

v 1.6.9.2
=====================================================================
x Fixed Injection Checker checking ASCII 43 as a "plus" sign but not
as a www-form-encoded space (thanks Sirdarckcat for report)
x Google search anti-XSS exception now checks for real TLDs, rather
than short 2nd level domains (thanks Sirdarckcat for report)
+ Refactored unescaping flow, allowing for easier extension
+ Ebay-style unescaping

Re: Hacking noscript Posted by: sirdarckcat (IP Logged) Date: June 16, 2008 04:02AM
Ah! hacking noscript?

thats easy..
[trustedsite.com]

for example.. (eBay has a XSS issue very similar to the one I'm describing (well, actually, a lot of sites, but eBay rocks))

var x='';

But duuuude!! what's happening?

Well, NoScript thinks, that.. "+" is a plus.. but in reality.. "+" is a space, and so..

var x=''+alert(document.cookie) //a:';

is valid js code! (damn, I'm good, 10 minutes to hack NoScript :D)

Greetz!!

PS. It's a joke, noscript is great :P, and even do I did spent 10 minutes to find the issue, it was because I had this idea for attacking noscript since a couple of months ago, but I didnt tested it till today.


but WAIT!!
thats all?

The hell it isn't!! (anyway, this last attack is not so dangerous, since it requires user interaction [enabling javascript on an untrusted domain])

Let's take a look at NoScript's default anti-xss rules:
^[url]http://[/url]([a-z]+).google.(?:[a-z]{1,3}.)?[a-z]+/(?:search|custom|1)?

That means, well.. that:
[images.google.com]

Will bypass NoScript (because we all trust google =D), but.. wait.. that's for google domains exclusively right?

Well, wrong!! because, well.. 20 bux, we can get a 3 letter domain [www.3character.com]

And so do:

[www.google.xss.com]

Pointing google.xss.com to your router or something.

There's an issue with this last attack.. NoScript does his job, and automatically denies google.xss.com.. anyway, enabling javascript in such domain (social engineering) would allow the attacker to send evil XSS attacks to your router/intranet what-ever.

Anyway, hacking noscript is fun :D

And in any case someone wondered..

[search.ebay.com]

And yeah, that's not triggering noscript alarms :D

Greetz!!

Re: Hacking noscript Posted by: ma1 (IP Logged) Date: June 16, 2008 09:36AM
FIXED

Now that it's fixed, I'll explain my innuendo to Ebay's "scary and brainless" issue, which reminds me closely last month's Base64 Yahoo one.

Your PoC was

hxxp://search.ebay.com/search/search.dll?_trksid=&satitle=ME+XSS+U&category0=&from=%27%2Balert(document.cookie)%2B%27

and it did not bypass NoScript. I guess you meant to write it in the "mixed plus" form, but this is not.

But here's the truly scary one:

[search.ebay.com]

As you can see, ebay uses its own custom "Q-encoding", allowing XSS payloads virtually undetectable to any filter, except NoScript >= 1.6.9.2 ;)

IMPORTANT REQUEST (rules change)
Since as far as I can see NoScript now is actively used by more than 1.5 million users, it would be kind of you if new issues were responsibly disclosed to me before posting them there.
I guarantee to handle them the very same day I read your report and to publish a development build with proper credits, but since one week is probably the minimum user-bearable window for automatic updates on stable releases, a 7 days grace period would be nice as a compromise to avoid an excessively tight update schedule for stable version users.

v 1.6.9.8
=====================================================================
x Restored the noscript.forbidData preference to its orginal "true"
default value (thanks Sirdarckcat for reporting an issue in the
about:blank context prevented by this change)

/(?:Ctrl|Shift)[::click::]/.test(NoScript);
9 messages

Eduardo Vela	Sat, Jun 21, 2008 at 7:07 AM
To: Giorgio Maone
Hi Giorgio! I've found out that NoScript allows javascript code execution on untrusted sites if you make your visitor click Control or Shift, and click on a page. I've mounted a PoC: [www.sirdarckcat.net] Hold Control and then click somewhere. The script runs on about:blank context.. so it's not so, so, dangerous, but anyway.. Greetings!! -- Arnold Schwarzenegger - "I have a love interest in every one of my films - a gun."

Giorgio Maone	Sat, Jun 21, 2008 at 9:32 AM
To: Eduardo Vela
Hi Edoardo! Thanks for the info, it's very interesting. I'm investigating it. Cheers -- Giorgio[Quoted text hidden]

Giorgio Maone	Sat, Jun 21, 2008 at 9:35 AM
To: Eduardo Vela
BTW, shift does not work for me (must still test on a clean profile, though) but ctrl does.[Quoted text hidden]

Eduardo Vela	Sat, Jun 21, 2008 at 9:36 AM
To: Giorgio Maone
Control should open the script on a new tab, and shift on a new window.. maybe popup blocker stuff, or something?[Quoted text hidden]-- Frank Lloyd Wright - "TV is chewing gum for the eyes."

Giorgio Maone	Sat, Jun 21, 2008 at 9:38 AM
To: Eduardo Vela
Maybe, or Tab Mix Plus. Shift does open a window for me, but it's empty and no script gets executed. [Quoted text hidden]

Giorgio Maone	Sat, Jun 21, 2008 at 9:56 AM
To: Eduardo Vela
Forgot to tell, this is a bug for me (likely a regression), because I've got code in place to prevent exactly this sort of javascript:/data: url openings. Hence expect a fix build in a very short time. Thanks![Quoted text hidden]

Giorgio Maone	Sat, Jun 21, 2008 at 10:12 AM
To: Eduardo Vela
OK, I found the culprit. At a certain point in time I turned the default for the "noscript.forbidData" about:config preference to "false", in order to work-around a Firebug bug. It seemed a relatively innocuous change, considered also that about:blank is not in the default whitelist. Anyway, since the Firebug issue is obsolete and I'm much more worried of this kind of bypass, next build will restore the original "true" default. Thanks again -- Giorgio[Quoted text hidden]

Giorgio Maone	Sat, Jun 21, 2008 at 10:34 AM
To: Eduardo Vela
Done :) Please wait for public release of 1.7 (in a week or even earlier) to disclose the details.[Quoted text hidden]

1. So, the first "fact" is that using the iframes on any website, you can capture top.location's and keystrokes (this is well known).
   
   
2. So, there's a way of modifying iframes on a window, on a domain is not ours.
   
   
3. So, we need a way of getting a reference to a window.

• window.opener.window
• open().window
• frames[].window
• top
• parent
• [maybe others I don't know]

1. So, once we have that, we need a reference to the iframes.

• document.getElementsByTagName("iframe");
• window.frames[];

• getElementsByTagName fails (IE6, IE7, FF2, FF3, Safari 3).
  
• window.frames[] doesnt fail (IE6, IE7, FF2, FF3, Safari 3);

1. We will try to modify the location of such frames.

• parent.open("new location","frame-name");
• frame.location="new location";
• frame.open("new location","_self");

1. So so far, we have an exploit that only works on IE (6&7).