Cross-Site Scripting vulnerability in Mozilla, Firefox and Chrome

Hello SecurityFocus!

I want to warn you about Cross-Site Scripting vulnerability in Mozilla,
Firefox and Chrome.

Some time ago Mozilla fixed vulnerability in Firefox described in MFSA
2009-22 (http://www.mozilla.org/security/announce/2009/mfsa2009-22.html).
Which allowed Refresh header to redirect to javascript: URIs.

This vulnerability was fixed in Firefox 3.0.9. And recently, 06.07.2009, I
found possibility to bypass this protection in Firefox. Also this method of
XSS attacks works in Mozilla (1.7.x) and Chrome.

To bypass protection from JavaScript code execution via refresh header its
needed to use data: URI, which will be containing requisite JS code. This
method of conducting of XSS attacks via meta-refresh tag is already known -
it was in XSS Cheat Sheet (http://ha.ckers.org/xss.html) already in 2006
year. And I used it to bypass protection in Firefox and to conduct attacks
via refresh-header redirectors.

XSS:

Meta-refresh tag and refresh header attack vectors:

<meta http-equiv="refresh"
content="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+">

With request to script at web site:

http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b

Which returns in answer the refresh header and the code will execute in the
browser:

refresh: 0;
URL=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b

Via data: its possible to bypass in Firefox 3.0.9 and higher (I tested in
3.0.11) prohibition on JavaScript code execution in refresh header. But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way, but its
possible in old Mozilla (and in those versions of Firefox where there is
relation between data: page and original page).

Vulnerable version is Mozilla 1.7.x and previous versions.

Vulnerable version is Mozilla Firefox 3.0.11 and previous versions (and 3.5
should be also vulnerable).

Vulnerable version is Google Chrome 1.0.154.48 and previous versions (and
potentially next versions too).

I mentioned about this vulnerability at my site
(http://websecurity.com.ua/3315/).

P.S.

After I informed Mozilla, they declined to fix this vulnerability. Thus
allowing to execute JavaScript code in their browsers (particularly for
malware spreading) on all refresh-header redirectors, which there are a lot
in Internet.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua 


!DSPAM:4a5e0423317718290892692!




Replies to this exploit:

From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!




From: Michal Zalewski lcamtuf@coredump.cx
Sent: Wed 15. Jul 2009 13:00
> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: advisories@intern0t.net
Sent: Thu 16. Jul 2009 02:18
I agree completely with mz,


This is just how FireFox works, the data:text/html,base64;somestringinbase64== is just pure functionality. The redirection parameters is not equal to a vulnerability since as mz said, the attacker could just redirect to his own site.

The best way to defend against any Cross Site Scripting attacks is to sanitize all inputs and outputs properly on your website and perhaps run NoScript as an extra safety precaution as well.

If it was possible to execute system() commands directly through the browser and not javascript nor html then that would be a vulnerability since One could almost do anything with a malicious site, if the input in this example to this function wouldnt be sanitized of course.


Best Regards,
MaXe

> To bypass protection from JavaScript code execution via refresh header its
> needed to use data: URI, which will be containing requisite JS code.
> [...] After I informed Mozilla, they declined to fix this vulnerability.

"Refresh" or "Location" redirection in Firefox will not bestow a
security context derived from the referring site upon the executed
code. This is different from the behavior on javascript: URLs.
Granted, it and also somewhat counterintuitive, as other types of
data: navigation - e.g., link navigation, IFRAMEd content, location.*
updates - do inherit that context.

This means that there is nothing to be gained by redirecting to data:
through www.example.com; he could as well just redirect to his own
site and run any potentially malicious JavaScript there.

/mz


From: MustLive mustlive@websecurity.com.ua
Sent: Sun 26. Jul 2009 23:54
Hello Michal!

First I note, that when Ill find time, Ill answer at your previous comment
about redirection to javascript: URIs in different browsers.

Second I note, that, please, write about something new, not about that I
already mentioned in my advisory ;-).

> "Refresh" or "Location" redirection in Firefox will not bestow a
...
> updates - do inherit that context.

I know it. And I mentioned about this in my paragraph "Via data: its
possible to bypass in Firefox ...". In these paragraph I wrote "But in
Firefox 3.0.11 and Google Chrome you cant get to cookies this way", which
is the same that your wrote, but in more laconic way. And in the same
paragraph I wrote "but its possible in old Mozilla (and in those versions
of Firefox where there is relation between data: page and original page)".
So there are such browsers which data: URIs from redirectors inherit context
of the site. In any case JavaScript execution is dangerous even without
relation with original site.

Your position is similar to Mozillas position. And because Mozilla declined
to fix this hole due to "lack of inheritance" between data: URI and the site
with redirector, and Chrome also has no such inheritance, I didnt send my
advisory directly to Google Security Team. And from your declining of this
vulnerability, I see that its Googles official position about this issue.

I understand your and Mozillas position, but I dont agree with you. And I
wrote enough (as I was thinking) arguments in my advisory, why its
dangerous and why it need to be fixed.

Third, I note that no need to hurry up to write about location redirection
in Firefox. Because the day before your comment I posted at my site advisory
about this vulnerability in Firefox (and not only in it, but also in Opera).
And Ill write separate advisory (when will find time) to Bugtraq about
those holes.

> This means that there is nothing to be gained by redirecting to data:

Michal, there are always something that bad guys can gain. And they can gain
benefits even from data: URL without inheritance with original site. Only
just JavaScript execution (of evil code) is dangerous. Like I said to
Mozilla, cookie stealing (and such things as access to DOM) is only one
vector, there are other vectors of attacks. As I mentioned in advisory, it
can be used particularly for malware spreading.

> he could as well just redirect to his own site and run any potentially
> malicious JavaScript there.

First he need to have his web site (with malicious JS code) and then he need
to redirect users to it. With this hole in different browsers new attack
vectors appears - no need to redirect to any site, just execute JS code from
redirector. Bad guys even no need to have their bad sites, just use all
vulnerable redirectors (so they cant be closed, so they have no such risk
and for this reason itll be harder to stop such malware spreading, because
there will be no site to close, and no site to block with antifishing
lists). And there are a lot of vulnerable redirectors in Internet.

I planned to write an article about JavaScript Execution attacks in
different browsers via different redirectors to draw attention of Internet
community to this problem. Didnt write it in last two weeks, but Id do it
in near time.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: "Michal Zalewski" <lcamtuf@coredump.cx>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, July 15, 2009 11:00 PM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>> To bypass protection from JavaScript code execution via refresh header
>> its
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz


!DSPAM:4a6ccdc2221422067717600!