Web 应用程序跨站脚本
我的网站 http://www.imayne.com 似乎存在此问题，已由 MacAfee 验证。有人可以告诉我如何解决这个问题吗？ （标题）
它是这样说的：
一般解决方案：
在接受用户输入时，如果您将数据显示回客户端，请确保对潜在的恶意字符进行 HTML 编码。
通过执行以下操作，确保参数和用户输入得到清理：
我似乎无法显示实际的代码。这个网站正在展示其他东西。
我不是网络开发人员，但我可以做一些事情。我正在努力遵守 PCI 标准。
My website http://www.imayne.com seems to have this issue, verified by MacAfee. Can someone show me how to fix this? (Title)
It says this:
General Solution:
When accepting user input ensure that you are HTML encoding potentially malicious characters if you ever display the data back to the client.
Ensure that parameters and user input are sanitized by doing the following:
I cannot seem to show the actual code. This website is showing something else.
Im not a web dev but I can do a little. Im trying to be PCI compliant.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
让我回答你的问题并给你一些建议。正确防止 XSS 需要通过在用户输入时定义可接受值的白名单，而不是禁止值的黑名单。在您开始考虑编码之前，这首先需要发生。
一旦开始编码，请使用您选择的框架中的库，不要尝试自己进行字符替换。有关于此的更多信息，请参见 面向 .NET 开发人员的 OWASP Top 10 第 2 部分：跨站脚本 (XSS)（不用担心它是面向 .NET 的，这些概念在所有框架中都是一致的）。
现在，请提供一些友好的建议：尽快获得专家支持。您在电子商务网站中发现了一个非常明显的反射型 XSS 缺陷，并且根据您在此页面上的评论，这不是您想要自行解决的问题。此缺陷的明显性质表明您很可能在该网站中遇到了更隐蔽的问题。您自己承认，“您在这里是个菜鸟”，您不会在一夜之间获得充分保护此类网站所需的能力。
Let me both answer your question and give you some advice. Preventing XSS properly needs to be done by defining a white-list of acceptable values at the point of user input, not a black-black of disallowed values. This needs to happen first and foremost before you even begin thinking about encoding.
Once you get to encoding, use a library from your chosen framework, don't attempt character substitution yourself. There's more information about this here in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS) (don't worry about it being .NET orientated, the concepts are consistent across all frameworks).
Now for some friendly advice: get some expert support ASAP. You've got a fundamentally obvious reflective XSS flaw in an e-commerce site and based on your comments on this page, this is not something you want to tackle on your own. The obvious nature of this flaw suggests you've quite likely got more obscure problems in the site as well. By your own admission, "you're a noob here" and you're not going to gain the competence required to sufficiently secure a website such as this overnight.
您所描述的更改类型通常是通过 HTML 编码功能以多种语言完成的。该网站是用什么编写的。如果这是 ASP.NET 网站，本文可能会有所帮助：
http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4- and-asp-net-mvc-2.aspx
在 PHP 中，使用此函数来包装所有正在输出的文本：
http://ch2.php.net/manual/en/function.htmlentities.php
在任何地方看到 echo(...) 或 print(...) 时都可以将其替换为：
查看页面中间的示例部分以获得其他指导。
The type of changes you are describing are often accomplished in several languages via an HTML Encoding function. What is the site written in. If this is an ASP.NET site this article may help:
http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx
In PHP use this function to wrap all text being output:
http://ch2.php.net/manual/en/function.htmlentities.php
Anyplace you see echo(...) or print(...) you can replace it with:
Take a look at the examples section in the middle of the page for other guidance.
严格按照这些步骤操作，就可以开始了。主要的事情是确保您不会将用户提交给您的任何内容视为代码（HTML、SQL、Javascript 或其他）。如果未能正确清理输入，则会面临脚本注入的风险。
如果您想查看此问题的一个简单示例，请
在您的网站上进行搜索，您会看到回显的搜索词是红色的。
Follow those steps exactly, and you're good to go. The main thing is to ensure that you don't treat anything the user submits to you as code (HTML, SQL, Javascript, or otherwise). If you fail to properly clean up the inputs, you run the risk of script injection.
If you want to see a trivial example of this problem in action, search for
on your site, and you'll see that the echoed search term is red.