- Jan 24, 2011
- 9,378
Another day, another zero-day.
This time, Microsoft Internet Explorer is attracting the sort of publicity a browser doesn't want, following the public disclosure of what's known as a Cross-Site Scripting, or XSS, bug.
With Microsoft apparently now investigating and looking at a patch, the timing of the disclosure certainly looks to be irresponsible.
There's no suggestion that Microsoft failed to meet any sort of deadline to get a patch out, or even that the company was contacted in advance.
Nevertheless, details of the bug have been revealed, including some proof-of-concept JavaScript showing how to abuse the hole.
So, what is XSS, and what does this mean for security?
A SOP for security
Browser security, as you will have read before on Naked Security, depends heavily on what's called the Same Origin Policy, or SOP.
Simply put, any resources specific to site X that are stored locally by the browser, such as cookies and JavaScript data objects, should only subsequently be visible when you are looking at content from site X.
In other words, if you visit my site, example.com, and I set a cookie that says, "This user last searched for the word 'banana'," only JavaScript from my site should ever be able to read that data back.
If your next web page is another.example, then my cookie should essentially vanish from view.
But if ever you browse back to a page on the example.com site, the 'banana' cookie will be visible again.
There are two obvious reasons for this:
But what if I can rig up a web link or some JavaScript on my site that fetches a page from your site, and somehow adapts it with malicious content of my choice before the user's browser displays it?
If I can somehow inject JavaScript of my own into one of your web pages, thenmy script suddenly has your origin.
In theory, I could access your cookies, or read text displayed in your web page, and post the data to a third party site in order to collect it for my own nefarious purposes.
After all, the browser thinks my script has the same origin as your web page.
Indeed, if the user looks at the address bar, he'll see your website name – and any script with your origin can access data private to your website, by design.
By now, the reason for the name XSS should be obvious: I have made my script "cross over" into your site.
As you can imagine, browsers are supposed to take special care not to allow XSS, to prevent data from one web page being illegally modified or stolen by another.
In this case, however, Internet Explorer (IE 11, at least, according to the company that disclosed the bug), fails to prevent XSS, leading to a security hole.
This vulnerability has been dubbed CVE-2015-0072.
Read more: https://nakedsecurity.sophos.com/20...orer-has-a-cross-site-scripting-zero-day-bug/
This time, Microsoft Internet Explorer is attracting the sort of publicity a browser doesn't want, following the public disclosure of what's known as a Cross-Site Scripting, or XSS, bug.
With Microsoft apparently now investigating and looking at a patch, the timing of the disclosure certainly looks to be irresponsible.
There's no suggestion that Microsoft failed to meet any sort of deadline to get a patch out, or even that the company was contacted in advance.
Nevertheless, details of the bug have been revealed, including some proof-of-concept JavaScript showing how to abuse the hole.
So, what is XSS, and what does this mean for security?
A SOP for security
Browser security, as you will have read before on Naked Security, depends heavily on what's called the Same Origin Policy, or SOP.
Simply put, any resources specific to site X that are stored locally by the browser, such as cookies and JavaScript data objects, should only subsequently be visible when you are looking at content from site X.
In other words, if you visit my site, example.com, and I set a cookie that says, "This user last searched for the word 'banana'," only JavaScript from my site should ever be able to read that data back.
If your next web page is another.example, then my cookie should essentially vanish from view.
But if ever you browse back to a page on the example.com site, the 'banana' cookie will be visible again.
There are two obvious reasons for this:
- Safety. Two sites might set a cookie with the same name, e.g.UserHasLoggedIn. These are different cookies and must not be allowed to clash.
- Security. Whether a UserHasLoggedIn or not on my site is no business of yours. So my cookie should be kept private.
But what if I can rig up a web link or some JavaScript on my site that fetches a page from your site, and somehow adapts it with malicious content of my choice before the user's browser displays it?
If I can somehow inject JavaScript of my own into one of your web pages, thenmy script suddenly has your origin.
In theory, I could access your cookies, or read text displayed in your web page, and post the data to a third party site in order to collect it for my own nefarious purposes.
After all, the browser thinks my script has the same origin as your web page.
Indeed, if the user looks at the address bar, he'll see your website name – and any script with your origin can access data private to your website, by design.
By now, the reason for the name XSS should be obvious: I have made my script "cross over" into your site.
As you can imagine, browsers are supposed to take special care not to allow XSS, to prevent data from one web page being illegally modified or stolen by another.
In this case, however, Internet Explorer (IE 11, at least, according to the company that disclosed the bug), fails to prevent XSS, leading to a security hole.
This vulnerability has been dubbed CVE-2015-0072.
Read more: https://nakedsecurity.sophos.com/20...orer-has-a-cross-site-scripting-zero-day-bug/
![[correlate]](/data/avatars/s/79/79653.jpg?1556985072){kind=avatar}
