Vulnerabilities IN THE IE 8 XSS Filter – UNDER-LINUX
Posted: Monday, May 3, 2010 by Ajin Kabeer in
"It is a fact that when a security feature creates uncertainty, it is time to ask if it should not be taken from the field, or even, if not better rethink the whole concept and restructure it again (redundant with) the zero. But that’s not the way Microsoft seems to be, since the third update your filter XSS (Cross-Site Script) for Internet Explorer 8, in an attempt to further protect the power system, makes the sites that were not vulnerable, become vulnerable. Hackers could exploit the flaw to inject JavaScript code in HTML pages, and run it with normal privileges of their own web page normally visible.”
The presence of filter XSS vulnerabilities in Internet Explorer 8 was first discovered in November 2009. Meanwhile Microsoft had already released two updates to try to fix the problem: MS10-002 in January 2010 and MS10-028 in March this year, which can correct some of these vulnerabilities. A new update is already being planned to be released in June this year, to correct the vulnerabilities related to the SCRIPT tag, which was described last week, Black Hat conference in Europe.
But even with all this discussion of the problem, David Ross from Microsoft, yet continues to insist that the browsers must have the capability of filtering for XSS. He sincerely believes that the existence of protection against XSS attacks standard in most cases, outweighs the potential risk of bugs.
While the popular NoScript plugin, used in most browsers Firefox installed, always asks the user interaction to determine whether blocking or scripts found on the web pages during browsing by the user, the filters responses from the server to block XSS in Internet Explorer 8, operates quite differently. Instead of making requests to the user for each malicious code found, it changes them. And this “functionality” may well be exploited by attackers to modify the server responses, and thus able to inject code that will.
Clearly, for this, the attacker must have some level of control over the content of the pages visited by users, as those achieved in social networking sites, forums and wikis. And the example in the Black Hat conference was none other than the greatest of all the social networking world – Facebook.
Google itself and its services are also affected. But the Internet giant has a “weapon” to the benefit of users who use the Internet Explorer browser with the locking system. It sends a header X-XSS-Protection: 0 to disable this feature. But since the last update made in Internet Explorer 8 in March this year, already supports blocking the header X-XSS-Protection: 1, mode = block. This tells the browser to woe instead of modifying the server responses, if in doubt, it must make the block all content from the suspicious site.
The Google Chrome also has a 4-blocker known as XSS XSS experimental Auditor. to run, it checks if there are any before returning JavaScript code to generate a vulnerable Web page that is included in the request. If confirmed, the system may be experiencing a classic case of reflective XSS attack involving a manipulated link. but do not worry because the browser will block the script execution. WebKit, the main engine of Chrome browser also supports headers XSS. But the lock mode is not implemented yet, but scheduled for inclusion in a future version of Chrome.
If you are a user’s Internet Explorer browser might start thinking about migrating to Firefox, and can use the extension NoScritp. Remember that the “safe than sorry.” No sense in getting stuck in a browser that is not worrying much about their safety. Remember that most attack vectors in Inter5net are made by flaws found in Microsoft tools, is your browser, or even your operating system. And you? What browser do you use in your day to day, and what their tactics to ensure its security on the Internet? Leave your comments below.