跨站脚本 (xss) 攻击
我只是有一个关于 XSS 攻击的简单问题。我知道您可以通过清理表单输入来防止它们，但我的问题是，搜索输入（例如网站上的常规搜索）怎么样？我们也应该清理搜索输入吗？我的意思是，这只是一个搜索输入，用户应该能够在网站上搜索他/她想要的任何内容。请对此进行一些澄清。
谢谢
I just have one simple question about XSS attack. I know that you can prevent them by sanitizing the form inputs, but my question is, how about a search input (a general search on a website for example)? Should we sanitize search inputs as well? I mean, it's just a search input, the user should be able to search for anything that he/she wants on the website. Please provide me with some clarification on this.
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
，不，您应该通过清理输出来防止它们。因此，在数据库（或任何地方）中，您需要按原样传递数据，并在将其显示给用户之前对其进行处理
nope, you should prevent them by sanitizing the output. So in database (or wherever) you need to pass the data as-is, and process it right before you show it to user
不过，zerkms 已经回答了这个问题，
如果您显示用户搜索的内容，例如“，则对来自接触数据库的任何用户输入的 sql 注入进行清理需要
mysql_real_escape_string($_REQUEST['search'])在输出上”您搜索过：" use
htmlentities(strip_tags($_REQUEST['search']), ENT_QUOTES);然后您就可以安全地接收和外向的
Tho this has already been answered by zerkms
Doing sanitizing on sql injections from any user input that touches the database requires
mysql_real_escape_string($_REQUEST['search'])On output if your showing what user searched for like "You searched for:" use
htmlentities(strip_tags($_REQUEST['search']), ENT_QUOTES);Then your safe from incoming and outgoing
我只想在此讨论中再补充一点。你说：
这里有一个陷阱：搜索词通常会被打印到搜索后呈现的文档中。即，“您搜索的是：<无论是什么>”。如果您不清理这些内容，这就是您存在 XSS 漏洞的地方。
如果您在想“但我们不这样做”，请记住，您可能现在不这样做，但将来可能会这样做。如果您现在不封堵这个漏洞，以后您可能会忘记这样做——所以最好将这个漏洞消灭在萌芽状态。
I just want to add one more point to the discussion here. You said:
Here's the gotcha: frequently the search term will be printed into the document that's rendered following the search. Ie, "You searched for: <whatever is was>". That's where you'll have your XSS vulnerability if you're not sanitizing this stuff.
If you're thinking "but we don't do that", bear in mind that you may not do so now, but you might do so in the future. And if you don't seal off this vulnerability now, you're likely to forget to do so later - so it's best just to nip this one in the bud.
使用 htmlpurifier 怎么样？
how about using htmlpurifier ?
SQL 注入和XSS是两种不同（但有些相关）的攻击。它们之间的相关性在于，本质上它可以归结为不受信任的数据从其所在的上下文中逸出并随后执行不可预见的操作。
为了遵循构建防御的最佳实践，我建议阅读 OWASP SQL预防注射备忘单及其XSS 预防备忘单。
OWASP 提出了 ESAPI 项目，其中包括用于不同编码的工具可以使用不受信任数据的上下文：
库可用于多种语言，包括Java，.NET，PHP，Classic ASP Python 和 Haskell。如果需要，它还能够执行输入验证。
使用 ESAPI 的一些组织包括美国运通、Apache 基金会、Booz Allen Hamilton、Aspect Security、Foundstone(McAfee)、The Hartford、Infinite Campus、Lockheed Martin、MITRE、美国海军 - SPAWAR、世界银行、SANS Institute。
最后 - 编码将在解释之前执行（越接近越好）。例如：在向 UI 组件提供不可信数据以呈现之前，对其进行编码。 UI 组件不能信任服务器 - 它必须进行编码。
SQL Injection and XSS are two different (yet somewhat related) attacks. They are related in that essentially it boils down to the untrusted data escaping from the context it was placed in and subsequently performing unforeseen operations.
For following best practices in building your defenses I recommend having a read through OWASP's SQL Injection Prevention Cheat Sheet and their XSS Prevention Cheat Sheet.
OWASP has put forth the ESAPI Project which includes tools for encoding for the different contexts in which untrusted data can be used:
This library is available for a number of languages including Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell. It also is able to perform input validation if it's required.
Some organisations who are using ESAPI include American Express, Apache Foundation, Booz Allen Hamilton, Aspect Security, Foundstone(McAfee), The Hartford, Infinite Campus, Lockheed Martin, MITRE, U.S. Navy - SPAWAR, The World Bank, SANS Institute.
Lastly - the encoding is to be performed just before interpretation (the closer the better). Ex: Just before you give the UI component the untrusted data to render you encode it. The UI component can't trust the server - it has to encode.