如何防止XSS跨站攻击，让fortify检测通过?
最近做一个漏洞修复的项目，验收标准是fortify的扫描结果。

比如:txtInfo.Text=dr["info"].ToString();

扫描类型是"Critical"高危，

然后，代码修改为txtInfo.Text=Server.HtmlEncode(dr["info"].ToString());

按理说，HtmlEncode了，把所有html标记<都替换成&gt了，显示文本而不会执行html效果，已经避免跨站攻击了。

但是，重新扫描，类型为"Medium",降级了，没有彻底解决。

fortify的说法是，非法字符串不止< > & ",应该用白名单(值允许某些字符)，或者黑名单(阻止非法字符)。写了黑名单过滤后还是没有效果。 用正则表达式替换所有HTML标记也还是没有效果。

有解决过这个问题的大侠么，支支招...


软件的扫描信息：
Recommendations:

The solution to XSS is to ensure that validation occurs in the correct places and checks for the correct properties.

Since XSS vulnerabilities occur when an application includes malicious data in its output, one logical approach is to validate data immediately before it leaves the application. However, because web applications often have complex and intricate code for generating dynamic content, this method is prone to errors of omission (missing validation). An effective way to mitigate this risk is to also perform input validation for XSS.

Web applications must validate their input to prevent other vulnerabilities, such as SQL injection, so augmenting an application's existing input validation mechanism to include checks for XSS is generally relatively easy. Despite its value, input validation for XSS does not take the place of rigorous output validation. An application may accept input through a shared data store or other trusted source, and that data store may accept input from a source that does not perform adequate input validation. Therefore, the application cannot implicitly rely on the safety of this or any other data. This means the best way to prevent XSS vulnerabilities is to validate everything that enters the application or leaves the application destined for the user.

The most secure approach to validation for XSS is to create a whitelist of safe characters that are allowed to appear in HTTP content and accept input composed exclusively of characters in the approved set. For example, a valid username might only include alpha-numeric characters or a phone number might only include digits 0-9. However, this solution is often infeasible in web applications because many characters that have special meaning to the browser should still be considered valid input once they are encoded, such as a web design bulletin board that must accept HTML fragments from&n