Saturday, 4. October 2003, 17:40:04
Browser Security Test
[url]http://bcheck.scanit.be/bcheck/Enable cookies, java and java script. Select "Run all available tests" and run all 30 tests.
Oh and disable any html filters like proxomitron etc.
Anyone see any problems for Opera 7.x?
Saturday, 4. October 2003, 17:55:16
here are my results
Browser Security Test Results
Dear Customer,
The Browser Security Test is finished. Please find the results below:
High Risk Vulnerabilities0
Medium Risk Vulnerabilities2
Low Risk Vulnerabilities0
medium risk recommends that i use microsoft update to elimanate the vulnerabilities
i already updated to most current this morning
so go figure the results
Browser Security Test Results
Dear Customer,
The Browser Security Test is finished. Please find the results below:
High Risk Vulnerabilities0
Medium Risk Vulnerabilities2
Low Risk Vulnerabilities0
medium risk recommends that i use microsoft update to elimanate the vulnerabilities
i already updated to most current this morning
so go figure the results
Saturday, 4. October 2003, 18:46:22
Is this something the Opera team should take a look at, to insure it is not a problem in Opera?
If so bug report or will they look at it here?
If so bug report or will they look at it here?
Saturday, 4. October 2003, 18:53:36
[url]http://my.opera.com/forums/showthread.php?s=&threadid=32280&highlight=brower+testSame test. My results were 0
IE came out terrible there....Saturday, 4. October 2003, 19:07:39
Re: Browser Security Test
Originally posted by smokeonH2O
[url]http://bcheck.scanit.be/bcheck/
Anyone see any problems for Opera 7.x?
i went back and ran the test for OPERA alone and here are the results...The Browser Security Test is finished. Please find the results below:
High Risk Vulnerabilities0
Medium Risk Vulnerabilities0
Low Risk Vulnerabilities0
so imo i don`t think OPERA has anything to worry about as i had suspected all along
my result earlier had 2 med risks all related to ie and which i also question because i just received the most current critical updates earlier in the day...but i`m not very concerned with ie anymore
Saturday, 4. October 2003, 19:14:52
Originally posted by akh
Same test. My results were 0
On the thread you mentioned, seems no one bothered to try and discern reason for why some get clean run vs. more than a couple saying same results as jhobo above.
2 medium risk vulnerabilities.
dismissing the test and not going further seems to not fit what Opera is about...
cum patch for IE should have no impact on whether Opera can clear all 30 tests without incident.
Saturday, 4. October 2003, 19:23:54
Re: Re: Browser Security Test
Originally posted by jhobo4
i went back and ran the test for OPERA alone and here are the results...The Browser Security Test is finished. Please find the results below:
High Risk Vulnerabilities0
Medium Risk Vulnerabilities0
Low Risk Vulnerabilities0
so imo i don`t think OPERA has anything to worry about as i had suspected all along
my result earlier had 2 med risks all related to ie and which i also question because i just received the most current critical updates earlier in the day...but i`m not very concerned with ie anymore
something is amiss here.
I know running just the Opera tests gives Opera a clean bill, since they are probably testing for the vulnerabilities sited here:
Phantom of the Opera Feb 3,2003
[url]http://security.greymagic.com/news/
which the Opera team was commended on in fixing in less than 5 days.
******************************
running all 30 tests was the question.
again should the Opera development team look at this further to understand what is amiss here?
Saturday, 4. October 2003, 23:24:51
So, are these actual problems, or is the test merely misinterpereting its results?
Both are named as MSIE vulnerablities, so the latter possibility seems just as likely as the former to me.
Here are the 2 specific problems mentioned by the site for those who don't want to run all the tests:
Microsoft Internet Explorer document.write() Zone Bypass Vulnerability (bid6017)
Description
This bug allows a malicious web site to spoof content in windows opened by other web sites.
Technical Details
Saving a reference to document.write() method allows to use it even after the location of the document changes to a different domain. So a malicious web site can open a window with a page in its own domain, save a reference to the document.write method of that window and then change the location of that window to a different domain and call document.write using saved reference to modify the content of the page from another domain. This technique might be used to inject Javascript code into other domain's context.
Recommendations
We recommend using Windows Update to correct this problem.
Additional Information
Additional Information
Microsoft Security Bulletin MS02-066
November 2002, Cumulative Patch for Internet Explorer (Q328970)
MSIE:"SaveRef" cracks "(VictimWindow).document.write"
Microsoft Internet Explorer file:javascript: Cross Domain Scripting Vulnerability (ldy20030910-01)
Description
This bug allows a web site to read the contents of any file on your computer. The web site has to know the exact path and name of the file. A malicious website may also be able to exploit this vulnerability to delete mail from your webmail account or to spoof trusted websites.
Technical Details
It is possible to inject JavaScript code into Search bar and Media bar in Internet Explorer using "file:javascript:.." URL. The code will be execurted in the domain context of the document that was loaded in the bar.
A malicious web site can first open a document from any domain in Search bar and then execute JavaScript code getting access to the document.
There is a technique that allows injecting JavaScript code into Local Computer zone using this vulnerability. This allows a malicious web site to get access to local files and even execute arbitrary code. See "Additional Information" for details.
Recommendations
No patch for this problem is available yet. A possible workaround is to disable JavaScript.
Additional Information
Liu Die Yu. BugTraq posting: WsOpenFileJPU
Jelmer. BugTraq posting: Internet explorer 6 on windows XP allows exection of arbitrary code
Both are named as MSIE vulnerablities, so the latter possibility seems just as likely as the former to me.
Here are the 2 specific problems mentioned by the site for those who don't want to run all the tests:
Microsoft Internet Explorer document.write() Zone Bypass Vulnerability (bid6017)
Description
This bug allows a malicious web site to spoof content in windows opened by other web sites.
Technical Details
Saving a reference to document.write() method allows to use it even after the location of the document changes to a different domain. So a malicious web site can open a window with a page in its own domain, save a reference to the document.write method of that window and then change the location of that window to a different domain and call document.write using saved reference to modify the content of the page from another domain. This technique might be used to inject Javascript code into other domain's context.
Recommendations
We recommend using Windows Update to correct this problem.
Additional Information
Additional Information
Microsoft Security Bulletin MS02-066
November 2002, Cumulative Patch for Internet Explorer (Q328970)
MSIE:"SaveRef" cracks "(VictimWindow).document.write"
Microsoft Internet Explorer file:javascript: Cross Domain Scripting Vulnerability (ldy20030910-01)
Description
This bug allows a web site to read the contents of any file on your computer. The web site has to know the exact path and name of the file. A malicious website may also be able to exploit this vulnerability to delete mail from your webmail account or to spoof trusted websites.
Technical Details
It is possible to inject JavaScript code into Search bar and Media bar in Internet Explorer using "file:javascript:.." URL. The code will be execurted in the domain context of the document that was loaded in the bar.
A malicious web site can first open a document from any domain in Search bar and then execute JavaScript code getting access to the document.
There is a technique that allows injecting JavaScript code into Local Computer zone using this vulnerability. This allows a malicious web site to get access to local files and even execute arbitrary code. See "Additional Information" for details.
Recommendations
No patch for this problem is available yet. A possible workaround is to disable JavaScript.
Additional Information
Liu Die Yu. BugTraq posting: WsOpenFileJPU
Jelmer. BugTraq posting: Internet explorer 6 on windows XP allows exection of arbitrary code
Sunday, 5. October 2003, 00:54:57
And another thing: if you have to disable some of the stuff like cookies and pop ups, isn't the test a bit misleading?
Nope. I want my browser to stand on it's own in the context of layered defenses.
By the way Firebird 0.7 passes all 30 tests so I've read.
So, are these actual problems, or is the test merely misinterpereting its results?
No way to know for sure unless Opera tech team takes a look. Two threads same test, no answer so rather than prolong the agony, I submitted a bug report.
bug-128172
Also note Firebird 0.7 result on the same 30 tests.
Sunday, 5. October 2003, 22:23:37
Just ran across a note to myself regarding another test which Opera team may want to look at:
Browser Security Tests: JavaScript On-Unload Test
[url]http://www.jasons-toolbox.com/BrowserSecurity/javascript-onunload.asp
Opera can beat this test by disabling java script, but one would think that it should be able to beat the test by unchecking, enable automatic redirection, and it does not. At least for me.
Browser Security Tests: JavaScript On-Unload Test
[url]http://www.jasons-toolbox.com/BrowserSecurity/javascript-onunload.asp
Opera can beat this test by disabling java script, but one would think that it should be able to beat the test by unchecking, enable automatic redirection, and it does not. At least for me.
Sunday, 12. October 2003, 17:18:25
High Risk Vulnerabilities0
Medium Risk Vulnerabilities2
Low Risk Vulnerabilities0
Medium Risk Vulnerabilities
Microsoft Internet Explorer document.write() Zone Bypass Vulnerability (bid6017)
Description
This bug allows a malicious web site to spoof content in windows opened by other web sites.
Technical Details
Saving a reference to document.write() method allows to use it even after the location of the document changes to a different domain. So a malicious web site can open a window with a page in its own domain, save a reference to the document.write method of that window and then change the location of that window to a different domain and call document.write using saved reference to modify the content of the page from another domain. This technique might be used to inject Javascript code into other domain's context.
Recommendations
We recommend using Windows Update to correct this problem.
Additional Information
Microsoft Security Bulletin MS02-066
November 2002, Cumulative Patch for Internet Explorer (Q328970)
MSIE:"SaveRef" cracks "(VictimWindow).document.write"
Microsoft Internet Explorer file:javascript: Cross Domain Scripting Vulnerability (ldy20030910-01)
Description
This bug allows a web site to read the contents of any file on your computer. The web site has to know the exact path and name of the file. A malicious website may also be able to exploit this vulnerability to delete mail from your webmail account or to spoof trusted websites.
Technical Details
It is possible to inject JavaScript code into Search bar and Media bar in Internet Explorer using "file:javascript:.." URL. The code will be execurted in the domain context of the document that was loaded in the bar.
A malicious web site can first open a document from any domain in Search bar and then execute JavaScript code getting access to the document.
There is a technique that allows injecting JavaScript code into Local Computer zone using this vulnerability. This allows a malicious web site to get access to local files and even execute arbitrary code. See "Additional Information" for details.
Recommendations
No patch for this problem is available yet. A possible workaround is to disable JavaScript.
Medium Risk Vulnerabilities2
Low Risk Vulnerabilities0
Medium Risk Vulnerabilities
Microsoft Internet Explorer document.write() Zone Bypass Vulnerability (bid6017)
Description
This bug allows a malicious web site to spoof content in windows opened by other web sites.
Technical Details
Saving a reference to document.write() method allows to use it even after the location of the document changes to a different domain. So a malicious web site can open a window with a page in its own domain, save a reference to the document.write method of that window and then change the location of that window to a different domain and call document.write using saved reference to modify the content of the page from another domain. This technique might be used to inject Javascript code into other domain's context.
Recommendations
We recommend using Windows Update to correct this problem.
Additional Information
Microsoft Security Bulletin MS02-066
November 2002, Cumulative Patch for Internet Explorer (Q328970)
MSIE:"SaveRef" cracks "(VictimWindow).document.write"
Microsoft Internet Explorer file:javascript: Cross Domain Scripting Vulnerability (ldy20030910-01)
Description
This bug allows a web site to read the contents of any file on your computer. The web site has to know the exact path and name of the file. A malicious website may also be able to exploit this vulnerability to delete mail from your webmail account or to spoof trusted websites.
Technical Details
It is possible to inject JavaScript code into Search bar and Media bar in Internet Explorer using "file:javascript:.." URL. The code will be execurted in the domain context of the document that was loaded in the bar.
A malicious web site can first open a document from any domain in Search bar and then execute JavaScript code getting access to the document.
There is a technique that allows injecting JavaScript code into Local Computer zone using this vulnerability. This allows a malicious web site to get access to local files and even execute arbitrary code. See "Additional Information" for details.
Recommendations
No patch for this problem is available yet. A possible workaround is to disable JavaScript.
Sunday, 30. November 2003, 02:50:27
These so-called vulnerabilities only affect MSIE. Opera is safe.
I will try to explain: basically both the two tests Opera supposedly failed were looking for an "error" condition in the scripting engine. The script tried to do something known to be dangerous and exploitative, and if the browser says "Error!" the script will assume the browser to be safe against this exploit. For these two issues, however, this is not a correct conclusion for Opera.
First, the "Microsoft Internet Explorer document.write() Zone Bypass Vulnerability (bid6017)". Opera does not use MSIE's "security zone" system. It has a different security model, which means that even though it does not throw an error on the illegal document.write, the "malicious" document is unable to insert executable script in the "exploited" document. In other words, it is safe.
Now the "file:javascript: Cross Domain Scripting Vulnerability (ldy20030910-01)". The script makes two presumptions: one, that there is a special window named "_search" (a reference to IE's search frame, I assume) and two, that the browser will throw a script error if the script tries to open an address that can not be opened. As there is no "_search" frame Opera opens a normal, no-nonsense popup and names it "_search".
You may have noticed while running the test that Opera popped up a warning message saying that a file did not exist. This error is not causing Opera to throw a script error, for security reasons. A script should not have ANY way to test whether or not a local file exists. IMO the behaviour the test suite is looking for as evidence of "safety" here is a security hole of its own.
Opera informs you, the user, and not the script, that an error happened. The script concludes that Opera is vulnerable because it thinks that "opening" the specially crafted URL to insert malicious code was successful.
Finally, the onUnload issue: browsers are supposed to support onUnload as a matter of standards-compliance and supporting it is not usually labelled as a security problem although it can be abused. However, any stream of unstoppable popup windows opened by a webmaster abusing onUnload would in Opera be classified as unwanted popups and any of the two more restrictive popup settings would stop the "exploit".
Does that clarify things? ;-)
I will try to explain: basically both the two tests Opera supposedly failed were looking for an "error" condition in the scripting engine. The script tried to do something known to be dangerous and exploitative, and if the browser says "Error!" the script will assume the browser to be safe against this exploit. For these two issues, however, this is not a correct conclusion for Opera.
First, the "Microsoft Internet Explorer document.write() Zone Bypass Vulnerability (bid6017)". Opera does not use MSIE's "security zone" system. It has a different security model, which means that even though it does not throw an error on the illegal document.write, the "malicious" document is unable to insert executable script in the "exploited" document. In other words, it is safe.
Now the "file:javascript: Cross Domain Scripting Vulnerability (ldy20030910-01)". The script makes two presumptions: one, that there is a special window named "_search" (a reference to IE's search frame, I assume) and two, that the browser will throw a script error if the script tries to open an address that can not be opened. As there is no "_search" frame Opera opens a normal, no-nonsense popup and names it "_search".
You may have noticed while running the test that Opera popped up a warning message saying that a file did not exist. This error is not causing Opera to throw a script error, for security reasons. A script should not have ANY way to test whether or not a local file exists. IMO the behaviour the test suite is looking for as evidence of "safety" here is a security hole of its own.
Opera informs you, the user, and not the script, that an error happened. The script concludes that Opera is vulnerable because it thinks that "opening" the specially crafted URL to insert malicious code was successful.
Finally, the onUnload issue: browsers are supposed to support onUnload as a matter of standards-compliance and supporting it is not usually labelled as a security problem although it can be abused. However, any stream of unstoppable popup windows opened by a webmaster abusing onUnload would in Opera be classified as unwanted popups and any of the two more restrictive popup settings would stop the "exploit".
Does that clarify things? ;-)
Sunday, 30. November 2003, 05:49:53
May be Opera has to push the people of the Browser Security Test to fix the diagnostic tool. Now you have arround 9000 users that think Opera have vulnerabilities... (see the statistics) 
Sunday, 30. November 2003, 06:10:38
funny how going to 7.22 defeated 1 of the 2 browser security vulns. Anyone try it again on 7.23?
unless Opera threw up a new error flag... or someone verified by looking at the test code... if so maybe exclude words like assume in your response
... wait a sec. weren't there some security issues resolved from 7.2 thru 7.23
i'm sure these fixes had no impact on "defeating the error flag" of one of the vulns... at the browser security test...
__________________ _______________ ___________________
Changelog for Opera 7.21 for Windows:
Privacy and security
Updated to latest version of OpenSSL
Changelog for Opera 7.22 for Windows
Privacy and security
Security update specifically addressing the downloading of setup files in Opera (bug reported by S.G. Masood)
Opera directory traversal [url]http://jouko.iki.fi/adv/opera.html not to mention buffer overflow
Changelog for Opera 7.23 for Windows
Security
Addressing two issues reported by Jouko Pynnönen.
Forced placement of downloaded skin-files in undesirable locations
Buffer overflow when processing skins
------------------------ -------------------- -------------------
guess I'm the only one who thinks that when a pref box is unchecked it means to disallow the enabled check box pref ... oh well...
if it can be abused, it can be exploited
res ipsa layered defense mon ami
finally this link comes to mind for some reason...
[url]http://my.opera.com/forums/showthread.php?postid=374060#post374060
unless Opera threw up a new error flag... or someone verified by looking at the test code... if so maybe exclude words like assume in your response
... wait a sec. weren't there some security issues resolved from 7.2 thru 7.23
i'm sure these fixes had no impact on "defeating the error flag" of one of the vulns... at the browser security test...
__________________ _______________ ___________________
Changelog for Opera 7.21 for Windows:
Privacy and security
Updated to latest version of OpenSSL
Changelog for Opera 7.22 for Windows
Privacy and security
Security update specifically addressing the downloading of setup files in Opera (bug reported by S.G. Masood)
Opera directory traversal [url]http://jouko.iki.fi/adv/opera.html not to mention buffer overflow
Changelog for Opera 7.23 for Windows
Security
Addressing two issues reported by Jouko Pynnönen.
Forced placement of downloaded skin-files in undesirable locations
Buffer overflow when processing skins
------------------------ -------------------- -------------------
guess I'm the only one who thinks that when a pref box is unchecked it means to disallow the enabled check box pref ... oh well...
if it can be abused, it can be exploited
res ipsa layered defense mon ami
finally this link comes to mind for some reason...
[url]http://my.opera.com/forums/showthread.php?postid=374060#post374060
Sunday, 30. November 2003, 14:52:02
Originally posted by smokeonH2O
funny how going to 7.22 defeated 1 of the 2 browser security vulns. Anyone try it again on 7.23?
Perhaps the document.write behaviour was changed? I'm testing with 7.30 (internal) and only get the other "vulnerability" reported.
guess I'm the only one who thinks that when a pref box is unchecked it means to disallow the enabled check box pref ... oh well...
if it can be abused, it can be exploited
Different terms, different severity. Show me a test case that demonstrates a real security exploit using onunload...
Actually, in Opera the potential for abuse is far less than in IE because (probably against the spec) the onUnload event is not triggered when you close a window.
And then there is also the popup blocker :-)
onUnload is a part of the HTML standard:
[url]http://www.w3.org/TR/REC-html40/interact/scripts.html
If you don't like it, argue with the W3C ;-)
Sunday, 30. November 2003, 18:26:35
Different terms, different severity. Show me a test case that demonstrates a real security exploit using onunload...
Actually, in Opera the potential for abuse is far less than in IE because (probably against the spec) the onUnload event is not triggered when you close a window.
And then there is also the popup blocker
use your imagination and couple this "html standard" of allowing onUnload...
1) in prefs uncheck allow automatic redirection
2) enable: open requested popups only
3) go here [url]http://www.kephyr.com/popupkillertest/test/index.html
for popup tests 3 & 9 onmouse over imagine the use of this in combination with the onunloader here: [url]http://www.jasons-toolbox.com/BrowserSecurity/javascript-onunload.asp and viola your exploit
I know what ur response will be:
but it's the standard in both cases... If you don't like it... blah blah blah
still the point is it gives the user possibly something unwanted in both cases... 8) whoa nellie and put em in combination with whatever else might be an uncovered exploit (the larger issue referenced here [url]http://my.opera.com/forums/showthread.php?postid=374060#post374060 ).. and ur right back to res ipsa layered defense mon ami
point to be made is the last one... nothing is 100%, it's about managing risk, don't be lulled into a sense of false security or relative security or whatever the next excuse is :-)
Sunday, 30. November 2003, 21:28:24
Originally posted by smokeonH2O
use your imagination and couple this "html standard" of allowing onUnload...
Why the quotes? It is a de facto part of the HTML standard. Personally I find it a nearly useless thing to support, and it is more abused than used for anything sensible. It is nevertheless in the spec.
1) in prefs uncheck allow automatic redirection
This setting is about HTTP redirects and META refresh, not JavaScript. I'm not sure why you want it to be off for this test.
2) enable: open requested popups only
3) go here [url]http://www.kephyr.com/popupkillertest/test/index.html
for popup tests 3 & 9 onmouse over imagine the use of this in combination with the onunloader here: [url]http://www.jasons-toolbox.com/BrowserSecurity/javascript-onunload.asp and viola your exploit
...
still the point is it gives the user possibly something unwanted in both cases...
"possibly something unwanted" is not a security exploit.
If the popup window that happened on mousing over had an onUnload handler, you would not even notice it. It would not run when you closed the popup. If the onUnload handler did execute and tried to open another popup, Opera would consider this one unwanted and not allow it.
Sunday, 30. November 2003, 23:47:21
sramov,
already noted Firebird beta 0.7 kicks but on all 30.
[url]http://my.opera.com/forums/showthread.php?postid=322261#post322261
jhobo4,
cool, 7.23 kills all 30 right...
if that is the case then something did change... whether it was a flag or a real or imagined security issue
... guess my approach (layared defense)is a good one... even when told there is no problem
already noted Firebird beta 0.7 kicks but on all 30.
[url]http://my.opera.com/forums/showthread.php?postid=322261#post322261
jhobo4,
cool, 7.23 kills all 30 right...
if that is the case then something did change... whether it was a flag or a real or imagined security issue
... guess my approach (layared defense)is a good one... even when told there is no problem
Monday, 1. December 2003, 09:34:43
All the tests you are running have false positives. Thats it. At the moment, there is no known Opera security bug.
Monday, 2. February 2004, 00:46:48
Browser Security Test finally updated to show Opera is not vulnerable to the 1 remaining false positive.
spoofed as IE so all 30 tests were run
30 out of 30 passed by Opera (with 1 false positive) 8)
browser security opera scores 30 out of 30.gif
spoofed as IE so all 30 tests were run
30 out of 30 passed by Opera (with 1 false positive) 8)
browser security opera scores 30 out of 30.gif
Forums » Opera Community » Opera desktop platforms » Opera for Windows
