deng131
- 浏览: 673498 次
- 性别:
- 来自: 深圳
-
文章分类
最新评论
-
zhouyicang：
为嘛人气不够，这么好的文章，我找了几十篇博客，才找到这篇解惑了 ...
HTML 块级元素/内联元素 -
young7：
不错，解惑了
HTML 块级元素/内联元素 -
lvjin948：
获取浏览器语言的完美方案。http://blog.csdn.n ...
JavaScript获取浏览器语言类型 -
tarena_hhh：
我用了css优化工具，发现他的顺序有很大不一样？？？？？
CSS属性书写顺序及命名规则 -
deng131：
谢谢你的提醒，是有个地方写错了
javascript事件绑定addEventListener,attachEvent
IE浏览器安全方面的处理，本人英文不好建议大家直接看英文：
Safer Mashups
While the XSS Filter helps mitigate reflected scripting attacks when navigating between two servers, in the Web 2.0 world, web applications are increasingly built using clientside mashup techniques. Many mashups are built unsafely, relying SCRIPT SRC techniques that simply merge scripting from a third-party directly into the mashup page, providing the third-party full access to the DOM and non-HttpOnly cookies.
To help developers build more secure mashups, for Internet Explorer 8, we’ve introduced support for the HTML5 cross-document messaging feature that enables IFRAMEs to communicate more securely while maintaining DOM isolation. We’ve also introduced the XDomainRequest object to permit secure network retrieval of “public” data across domains.
While Cross-Document-Messaging and XDomainRequest both help to secure mashups, a critical threat remains. Using either object, the string data retrieved from the third-party frame or server could contain script; if the caller blindly injects the string into its own DOM, a script injection attack will occur. For that reason, we’re happy to announce two new technologies that can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.
Safer Mashups: HTML Sanitization
IE8 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library mentioned previously.
So, for example, you can use toStaticHTML to help ensure that HTML received from a postMessage call cannot execute script, but can take advantage of basic formatting:
document.attachEvent('onmessage',function(e) {
if (e.domain == 'weather.example.com') {
spnWeather.innerHTML = window.toStaticHTML(e.data);
}
}
Calling:
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");
will return:
This is some <b>HTML</b> with embedded script following... !
Safer Mashups: JSON Sanitization
JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON-parser to ensure that the JSON object does not contain executable script, but there’s a performance penalty for this.
Internet Explorer 8 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations. If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.
The following example uses both JSON and HTML sanitization to prevent script injection:
<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
var xdr1 = new XDomainRequest();
xdr1.onload = function(){
var objWeather = JSON.parse(xdr1.responseText);
var oSpan = window.document.getElementById("spnWeather");
oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
+ objWeather.Weather.Forecast.Tonight + "</b> in <u>"
+ objWeather.Weather.City+ "</u>.");
};
xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>
…even if the weather service returns a malicious response:
HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1
{"Weather": {
"City": "Seattle",
"Zip": 98052,
"Forecast": {
"Today": "Sunny",
"Tonight": "<script defer>alert('bang!')</script>Dark",
"Tomorrow": "Sunny"
}
}}
MIME-Handling Changes
Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). For compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different than the type specified by the web server. For instance, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, IE determines that the content should be rendered as HTML. Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.
Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.
To combat this problem, we’ve made a number of changes to Internet Explorer 8’s MIME-type determination code.
MIME-Handling: Restrict Upsniff
First, IE8 prevents “upsniff” of files served with image/* content types into HTML/Script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector-- with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact because servers rarely knowingly send HTML or script with an image/* content type.
MIME-Handling: Sniffing Opt-Out
Next, we’ve provided web-applications with the ability to opt-out of MIME-sniffing. Sending the new nosniff directive prevents Internet Explorer from MIME-sniffing a response away from the declared content-type.
For example, consider the following HTTP-response:
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain;
X-Content-Type-Options: nosniff
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
In IE7, the text is interpreted as HTML:
IE7 text interpreted as HTML
In IE8, the page is rendered in plaintext:
IE8 text rendered as plain text
Sites hosting untrusted content can use the nosniff directive to ensure that text/plain files are not sniffed to anything else.
MIME-Handling: Force Save
Lastly, for web applications that need to serve untrusted HTML files, we have introduced a mechanism to help prevent the untrusted content from compromising your site’s security. When the new X-Download-Options header is present with the value noopen, the user is prevented from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection.
HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html
Save File Dialog
Taken together, these new Web Application Defenses enable the construction of much more secure web applications.
Local Browser Defenses
While Web Application attacks are becoming more common, attackers are always interested in compromising ordinary users’ local computers. In order to allow the browser to effectively enforce security policy to protect web applications, personal information, and local resources, attacks against the browser must be prevented. Internet Explorer 7 made major investments in this space, including Protected Mode, ActiveX Opt-in, and Zone Lockdowns. In response to the hardening of the browser itself, attackers are increasingly focusing on compromising vulnerable browser add-ons.
For Internet Explorer 8, we’ve made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.
Add-on Security
We kicked off this security blog series with discussion of DEP/NX Memory Protection, enabled by default for IE8 when running on Windows Server 2008, Windows Vista SP1 and Windows XP SP3. DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. You can read more about this defense in the original blog post: IE8 Security Part I: DEP/NX Memory Protection.
In a follow-up post, Matt Crowley described the ActiveX improvements in IE8 and summarized the existing ActiveX-related security features carried over from earlier browser versions. The key improvement we made for IE8 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls. IE8 also supports non-Administrator installation of ActiveX controls, enabling domain administrators to configure most users without administrative permissions. You can get the full details about these improvements by reading: IE8 Security Part II: ActiveX Improvements. If you develop ActiveX controls, you can help protect users by following the Best Practices for ActiveX controls .
Protected Mode
Introduced in IE7 on Windows Vista, Protected Mode helps reduce the severity of threats to both Internet Explorer and extensions running in Internet Explorer by helping to prevent silent installation of malicious code even in the face of software vulnerabilities. For Internet Explorer 8, we’ve made a number of API improvements to Protected Mode to make it easier for add-on developers to control and interact with Protected Mode browser instances. You can read about these improvements in the Improved Protected Mode API Whitepaper.
For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone. Protected Mode was originally enabled in the Intranet Zone for user-experience reasons: when entering or leaving Protected Mode, Internet Explorer 7 was forced to create a new process and hence a new window.
IE7 new window prompt
Internet Explorer 8’s Loosely Coupled architecture enables us to host both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating this user-experience annoyance. Of course, IE8 users and domain administrators have the option to enable Protected Mode for Intranet Zone if desired.
Application Protocol Prompt
Application Protocol handlers enable third-party applications (such as streaming media players and internet telephony applications) to directly launch from within the browser or other programs in Windows. Unfortunately, while this functionality is quite powerful, it presents a significant amount of attack surface, because some applications registered as protocol handlers may contain vulnerabilities that could be triggered from untrusted content from the Internet.
To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 will now prompt before launching application protocols.
IE8 prompt prior to launching application protocols
To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN.
File Upload Control
Historically, the HTML File Upload Control (<input type=file>) has been the source of a significant number of information disclosure vulnerabilities. To resolve these issues, two changes were made to the behavior of the control.
To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control, the File Path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog.
IE8 read-only File Path box
Additionally, the “Include local directory path when uploading files” URLAction has been set to "Disable" for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path C:\users\ericlaw\documents\secret\image.png, Internet Explorer 8 will now submit only the filename image.png.
Social Engineering Defenses
As browser defenses have been improved over the last few years, web criminals are increasingly relying on social engineering attacks to victimize users. Rather than attacking the ever-stronger castle walls, attackers increasingly visit the front gate and simply request that the user trust them.
For Internet Explorer 8, we’ve invested in features that help the user make safe trust decisions based on clearly-presented information gathered from the site and trustworthy authorities.
Address Bar Improvements
Domain Highlighting is a new feature introduced in IE8 Beta 1 to help users more easily interpret web addresses (URLs). Because the domain name is the most security-relevant identifier in a URL, it is shown in black text, while site-controlled URL text like the query string and path are shown in grey text.
When coupled with other technologies like Extended Validation SSL certificates, Internet Explorer 8’s improved address bar helps users more easily ensure that they provide personal information only to sites they trust.
IE8 SSL Address Bar with Domain Highlighting
IE8 SmartScreen Filter Address Bar
SmartScreen® Filter
Internet Explorer 7 introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites. For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks millions of phishing attacks per week) and developed the SmartScreen® Filter. The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software which attempts to attack your computer or steal your personal information. SmartScreen works in concert with other technologies like Windows Defender and Windows Live OneCare to provide comprehensive protection against malicious software.
You can read more about the new SmartScreen Filter in my earlier post: IE8 Security Part III - The SmartScreen Filter.
参考：
http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx
Safer Mashups
While the XSS Filter helps mitigate reflected scripting attacks when navigating between two servers, in the Web 2.0 world, web applications are increasingly built using clientside mashup techniques. Many mashups are built unsafely, relying SCRIPT SRC techniques that simply merge scripting from a third-party directly into the mashup page, providing the third-party full access to the DOM and non-HttpOnly cookies.
To help developers build more secure mashups, for Internet Explorer 8, we’ve introduced support for the HTML5 cross-document messaging feature that enables IFRAMEs to communicate more securely while maintaining DOM isolation. We’ve also introduced the XDomainRequest object to permit secure network retrieval of “public” data across domains.
While Cross-Document-Messaging and XDomainRequest both help to secure mashups, a critical threat remains. Using either object, the string data retrieved from the third-party frame or server could contain script; if the caller blindly injects the string into its own DOM, a script injection attack will occur. For that reason, we’re happy to announce two new technologies that can be used in concert with these cross-domain communication mechanisms to mitigate script-injection attacks.
Safer Mashups: HTML Sanitization
IE8 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library mentioned previously.
So, for example, you can use toStaticHTML to help ensure that HTML received from a postMessage call cannot execute script, but can take advantage of basic formatting:
document.attachEvent('onmessage',function(e) {
if (e.domain == 'weather.example.com') {
spnWeather.innerHTML = window.toStaticHTML(e.data);
}
}
Calling:
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");
will return:
This is some <b>HTML</b> with embedded script following... !
Safer Mashups: JSON Sanitization
JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON-parser to ensure that the JSON object does not contain executable script, but there’s a performance penalty for this.
Internet Explorer 8 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations. If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.
The following example uses both JSON and HTML sanitization to prevent script injection:
<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
var xdr1 = new XDomainRequest();
xdr1.onload = function(){
var objWeather = JSON.parse(xdr1.responseText);
var oSpan = window.document.getElementById("spnWeather");
oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
+ objWeather.Weather.Forecast.Tonight + "</b> in <u>"
+ objWeather.Weather.City+ "</u>.");
};
xdr1.open("POST", "http://evil.weather.example.com/getweather.aspx");
xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>
…even if the weather service returns a malicious response:
HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1
{"Weather": {
"City": "Seattle",
"Zip": 98052,
"Forecast": {
"Today": "Sunny",
"Tonight": "<script defer>alert('bang!')</script>Dark",
"Tomorrow": "Sunny"
}
}}
MIME-Handling Changes
Each type of file delivered from a web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (e.g. image, text, application, etc). For compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different than the type specified by the web server. For instance, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, IE determines that the content should be rendered as HTML. Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.
Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.
To combat this problem, we’ve made a number of changes to Internet Explorer 8’s MIME-type determination code.
MIME-Handling: Restrict Upsniff
First, IE8 prevents “upsniff” of files served with image/* content types into HTML/Script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector-- with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact because servers rarely knowingly send HTML or script with an image/* content type.
MIME-Handling: Sniffing Opt-Out
Next, we’ve provided web-applications with the ability to opt-out of MIME-sniffing. Sending the new nosniff directive prevents Internet Explorer from MIME-sniffing a response away from the declared content-type.
For example, consider the following HTTP-response:
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain;
X-Content-Type-Options: nosniff
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
In IE7, the text is interpreted as HTML:
IE7 text interpreted as HTML
In IE8, the page is rendered in plaintext:
IE8 text rendered as plain text
Sites hosting untrusted content can use the nosniff directive to ensure that text/plain files are not sniffed to anything else.
MIME-Handling: Force Save
Lastly, for web applications that need to serve untrusted HTML files, we have introduced a mechanism to help prevent the untrusted content from compromising your site’s security. When the new X-Download-Options header is present with the value noopen, the user is prevented from opening a file download directly; instead, they must first save the file locally. When the locally saved file is later opened, it no longer executes in the security context of your site, helping to prevent script injection.
HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html
Save File Dialog
Taken together, these new Web Application Defenses enable the construction of much more secure web applications.
Local Browser Defenses
While Web Application attacks are becoming more common, attackers are always interested in compromising ordinary users’ local computers. In order to allow the browser to effectively enforce security policy to protect web applications, personal information, and local resources, attacks against the browser must be prevented. Internet Explorer 7 made major investments in this space, including Protected Mode, ActiveX Opt-in, and Zone Lockdowns. In response to the hardening of the browser itself, attackers are increasingly focusing on compromising vulnerable browser add-ons.
For Internet Explorer 8, we’ve made a number of investments to improve add-on security, reduce attack surface, and improve developer and user experience.
Add-on Security
We kicked off this security blog series with discussion of DEP/NX Memory Protection, enabled by default for IE8 when running on Windows Server 2008, Windows Vista SP1 and Windows XP SP3. DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. You can read more about this defense in the original blog post: IE8 Security Part I: DEP/NX Memory Protection.
In a follow-up post, Matt Crowley described the ActiveX improvements in IE8 and summarized the existing ActiveX-related security features carried over from earlier browser versions. The key improvement we made for IE8 is “Per-Site ActiveX,” a defense mechanism to help prevent malicious repurposing of controls. IE8 also supports non-Administrator installation of ActiveX controls, enabling domain administrators to configure most users without administrative permissions. You can get the full details about these improvements by reading: IE8 Security Part II: ActiveX Improvements. If you develop ActiveX controls, you can help protect users by following the Best Practices for ActiveX controls .
Protected Mode
Introduced in IE7 on Windows Vista, Protected Mode helps reduce the severity of threats to both Internet Explorer and extensions running in Internet Explorer by helping to prevent silent installation of malicious code even in the face of software vulnerabilities. For Internet Explorer 8, we’ve made a number of API improvements to Protected Mode to make it easier for add-on developers to control and interact with Protected Mode browser instances. You can read about these improvements in the Improved Protected Mode API Whitepaper.
For improved performance and application compatibility, by default IE8 disables Protected Mode in the Intranet Zone. Protected Mode was originally enabled in the Intranet Zone for user-experience reasons: when entering or leaving Protected Mode, Internet Explorer 7 was forced to create a new process and hence a new window.
IE7 new window prompt
Internet Explorer 8’s Loosely Coupled architecture enables us to host both Protected Mode and non-Protected Mode tabs within the same browser window, eliminating this user-experience annoyance. Of course, IE8 users and domain administrators have the option to enable Protected Mode for Intranet Zone if desired.
Application Protocol Prompt
Application Protocol handlers enable third-party applications (such as streaming media players and internet telephony applications) to directly launch from within the browser or other programs in Windows. Unfortunately, while this functionality is quite powerful, it presents a significant amount of attack surface, because some applications registered as protocol handlers may contain vulnerabilities that could be triggered from untrusted content from the Internet.
To help ensure that the user remains in control of their browsing experience, Internet Explorer 8 will now prompt before launching application protocols.
IE8 prompt prior to launching application protocols
To provide defense-in-depth, Application Protocol developers should ensure that they follow the Best Practices described on MSDN.
File Upload Control
Historically, the HTML File Upload Control (<input type=file>) has been the source of a significant number of information disclosure vulnerabilities. To resolve these issues, two changes were made to the behavior of the control.
To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control, the File Path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog.
IE8 read-only File Path box
Additionally, the “Include local directory path when uploading files” URLAction has been set to "Disable" for the Internet Zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path C:\users\ericlaw\documents\secret\image.png, Internet Explorer 8 will now submit only the filename image.png.
Social Engineering Defenses
As browser defenses have been improved over the last few years, web criminals are increasingly relying on social engineering attacks to victimize users. Rather than attacking the ever-stronger castle walls, attackers increasingly visit the front gate and simply request that the user trust them.
For Internet Explorer 8, we’ve invested in features that help the user make safe trust decisions based on clearly-presented information gathered from the site and trustworthy authorities.
Address Bar Improvements
Domain Highlighting is a new feature introduced in IE8 Beta 1 to help users more easily interpret web addresses (URLs). Because the domain name is the most security-relevant identifier in a URL, it is shown in black text, while site-controlled URL text like the query string and path are shown in grey text.
When coupled with other technologies like Extended Validation SSL certificates, Internet Explorer 8’s improved address bar helps users more easily ensure that they provide personal information only to sites they trust.
IE8 SSL Address Bar with Domain Highlighting
IE8 SmartScreen Filter Address Bar
SmartScreen® Filter
Internet Explorer 7 introduced the Phishing Filter, a dynamic security feature designed to warn users when they attempt to visit known-phishing sites. For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks millions of phishing attacks per week) and developed the SmartScreen® Filter. The SmartScreen Filter goes beyond anti-phishing to help block sites that are known to distribute malware, malicious software which attempts to attack your computer or steal your personal information. SmartScreen works in concert with other technologies like Windows Defender and Windows Live OneCare to provide comprehensive protection against malicious software.
You can read more about the new SmartScreen Filter in my earlier post: IE8 Security Part III - The SmartScreen Filter.
参考：
http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx
分享到：
发表评论
-
IE浏览器stylesheets加载资源限制问题
2015-03-08 20:30 1070@import url（）做一下总结： 1：@import ... -
理解Javascript原型及继承
2012-08-15 22:13 1345js初次使用起来觉得很简单但是在使用一段时间后很不深入的理解原 ... -
JS判断IE浏览器支持版本
2012-02-01 19:00 2968/* * @description 判断是否是IE，返回具体 ... -
jsonp动态创建script方式IE9问题
2012-02-01 16:28 2384在IE9浏览器创建一个script元素，然后指定其src属性u ... -
IE9下使用jsonp方式调用问题
2012-01-31 19:03 22901. 如果JSONP返回的Content-Type不符合规范， ... -
JavaScript获取浏览器语言类型
2011-12-31 18:24 7806获取浏览器语言： IE： navigator.browser ... -
javaScript 中比较数字字符串问题
2011-10-10 21:49 4674在实现前端页面排序功能过程中遇到的问题，由于自己的粗心导致了生 ... -
javascript设置label标签 for属性
2011-09-11 10:36 3606js创建label标签的for属性用来增加操作响应区域。 v ... -
javascript事件绑定addEventListener,attachEvent
2011-07-31 18:55 3523为了考虑浏览器的兼容性问题，都需要对浏览器进行类型检测。 f ... -
readyState五种状态详解
2011-07-24 14:15 1611(0) UNINITIALIZED 未初始化 The obje ... -
getElementByTagName 与 querySelectorAll
2011-07-14 11:29 1478虽然网上有中文翻译但是还是直接看英文有感觉。getElemen ... -
拖放 Drag and drop 方法
2011-07-10 18:55 1525虽然网上又很多实现方法，但是还是需要理解拖放原理。通过绑定on ... -
闭包传入参数 window & undefined
2011-07-03 08:53 2302大家在前端开发中对闭包应该和熟悉了，也就是几种常见的闭包方式： ... -
textarea光标位置插入文字
2011-06-18 18:14 2126各浏览器TextArea获得焦点后的光标位置情况： text ... -
IE6上Array不支持indexOf方法
2011-06-06 10:17 2250在IE6不支持Array上indexOf方法，又是可恶的ie， ... -
处理不支持JavaScript脚本情况
2011-05-26 10:24 1337现在主流的浏览器都支持javascrip, 但还是有小部分不支 ... -
动态创建iframe设置属性name问题
2011-04-20 13:54 2731通常iframe的name可以是link或者form的targ ... -
WebSocket and Socket.IO
2011-04-06 15:39 3463WebSocket API是下一代客户端-服务器的异步通信方法 ... -
Preload CSS/JavaScript预加载
2011-04-06 10:20 1472希望达到效果是页面第一次载入以后，如果在次刷新页或者进入下一个 ... -
JavaScript Comma Operator
2011-04-04 16:34 1112记得以前面试时候遇到过类似问题： js中','操作符优先级问题 ...
相关推荐
Based on computation and network technology, Cyber-Physical Systems (CPS) has achieved rapid growth but it is faced with increasingly serious security problems and needs targeted security protection ...
BS ISO-IEC 24745-2022 Information security, cybersecurity and privacy protection. Biometric information protection.pdf
We live in a world where the kind of ... While these connections help us create a bustling life online, they have also become a cause for worry and concern, hence the need to understand cyber security.
Exchange 2013优质学习资源
[RT-CN]Exchange Security Protection - Customer Preview
This book presents comprehensive Azure Security Center techniques for safeguarding cloud and hybrid environments. Leading Microsoft security and cloud experts Yuri Diogenes and Dr. Thomas Shinder show...
操作系统概念answer之Protection_and_Security
IEInternetSecurity是一个可以对IE进行密码保护并可以根据需要定制IE可选功能的软件,程序可以帮助你限制别人修改IE中的所有设置，或者单独的限制别人无法修改IE中的某几个设置选项,按钮等，包含了几十种IE的设置选项...
6. **CSRF Protection**：Spring Security 自动提供CSRF（跨站请求伪造）防护，通过生成和验证CSRF令牌确保只有合法的用户交互被处理。 7. **OAuth2 and JWT支持**：Spring Security 提供了对OAuth2和JSON Web ...
Plan for compliance, risk management, identity/access management, operational security, and endpoint and data protection Explore Azure’s defense-in-depth security architecture Use Azure network ...
在IE11浏览器中，使用`canvas.toDataURL`方法可能会遇到`SecurityError`的问题，这是因为IE11在处理跨域图像时的安全策略比其他现代浏览器更为严格。在尝试获取canvas对象上的数据URL时，如果canvas上绘制了来自不...
Spring Security 实践指南 Spring Security 是一个基于 Java 的安全框架，旨在提供身份验证、授权和访问控制等功能。下面是 Spring Security 的主要知识点： 一、身份验证（Authentication） 身份验证是指对用户...
Apress Real World Microsoft Access Database Protection and Security
**关闭IE的Enhanced Security Configuration功能详解** 在Windows Server 2021 R2操作系统中，Internet Explorer（IE）浏览器的Enhanced Security Configuration（增强安全配置，ESC）是一项旨在提高服务器安全性的...
Create appropriate, security-focused business propositions that consider the balance between cost, risk, and usability, while starting your journey to become an information security manager....
nt protection by leveraging Python packages along with writing forensic scripts. By the end of this book, you will be able to get the most out of the Python language to build secure and robust ...
Security+培训全套PPT和知识点分享，供大家学习参考。 1、Security+培训-课程大纲(1) 2、Security+培训-安全基本概念(1.1) 3、Security+培训-网络安全(1.1) 4、Security+培训-合规与运维安全(1.1) 5、Security+培训...
Spring Security 是一个强大的和高度可定制的身份验证和访问控制框架，广泛用于Java应用程序的安全性管理。这个压缩包包含了Spring Security 4.0.0版本所需的jar包，这是一组核心组件，为构建安全的Web应用提供了...
Leading security experts explain how to plan and implement comprehensive security with special emphasis on new Windows security tools, security objects, security services, user authentication and ...
标题 "wpa_ie.rar" 涉及到的是无线网络安全中的关键组件——WPA（Wi-Fi Protected Access）信息元素（IE）和RSN（Robust Security Network）信息元素。这两个概念是Wi-Fi联盟为增强无线网络的安全性而引入的。 **...