保护网站免受 XSS 攻击

发布于 2024-12-20 00:17:21 字数 210 浏览 3 评论 0原文

我有一个必须符合 PCI 要求的电子商务网站。我遇到的问题是它在 XSS 攻击中失败：

www.mydomain.com?qs=%3c%2fscript%3e%3c script%3ealert(12345)%3c%2fscript%3e

.htaccess 中有没有办法去除任何恶意脚本标签并将用户重定向到另一个页面？还是我找错了树？

原文

I have an ecommerce site which has to be PCI compliant. The issue I have is that it fails on a XSS attack:

www.mydomain.com?qs=%3c%2fscript%3e%3c script%3ealert(12345)%3c%2fscript%3e

Is there a way in .htaccess to strip out any malicious script tags and redirect the user to another page? Or am I barking up the wrong tree?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

相权↑美人 2024-12-27 00:17:21

最好的方法是不信任代码中的用户输入。例如，在未通过 htmlspecialchars 或类似方式运行用户提供的数据之前，切勿将用户提供的数据回显给浏览器。这与 SQL 注入攻击属于同一类别，只不过注入的目标是生成的 HTML 代码而不是 SQL 查询。

用户提供的数据是所有可能从客户端被篡改的数据。这包括：$_POST、$_GET、文件上传、cookie 和 HTTP 标头（如 User-Agent 和 Referer）。此类数据必须始终被视为不可信，并且需要针对每个上下文进行保护。您要将数据插入数据库吗？在将数据放入查询之前对其进行转义（或使用准备好的语句）！您要将其输出到用户的浏览器吗？使用 htmlspecialchars 转义！它应该是一个电子邮件地址吗？在插入电子邮件之前请确保它确实如此！

请注意，即使将数据保存到数据库中，对于某些上下文，数据也可能不安全。例如，正确 SQL 转义的 $_POST 数据可能仍然包含 HTML 标签或其他 XSS 数据，因此在发送到浏览器之前需要对其进行转义（我在这里想说的是 user -provided 标签不会仅仅因为您将数据保存在数据库或文件中而消失）。防止这种情况的一个好方法是尽可能晚对每个上下文进行转义（例如，在回显之前执行 htmlspecialchars），以确保使用的转义方法是在此上下文中正确的数据，但也要尽可能尽早进行验证（首先不要接受无效数据，例如验证电子邮件地址和如果是则抛出错误无效的）。

还有 Apache 的 ModSecurity 扩展，它可以捕获大多数此类攻击，但这并不是万无一失的，因为有几乎无穷无尽的方法制作注射。因此，只有当您已经保护了应用程序代码的安全，但担心将来可能会由于错误而错过某些内容（这可能会以某种方式发生在我们大多数人身上）时，才应使用 ModSecurity。

The best approach would be to not trust user input in your code. For example, never echo user-provided data back to the browser without running it through htmlspecialchars or similar. This is in the same category as SQL injection attacks, except that the injection is targeted at the generated HTML code and not the SQL query.

User-provided data is all data that may be tampered with from the client side. This includes: $_POST, $_GET, file uploads, cookies and HTTP headers (like User-Agent and Referer). Such data must always be treated as untrusted and needs to be secured for each context. Are you going to insert the data into a database? Escape the data before putting it into your query (or use prepared statements)! Are you going to output it to the user's browser? Escape with htmlspecialchars! Is it supposed to be an e-mail address? Make sure it actually is before inserting into an e-mail message!

Note that the data may be unsecure for some contexts even if you save it into a database. For example, $_POST data properly SQL-escaped may still contain HTML tags or other XSS data, so it will need to be escaped before it gets sent to the browser (what I'm trying to say here is that the user-provided label doesn't go away just because you save the data in a database or to a file). A good way to protect against this is to do escaping for each context as late as possible (e.g., htmlspecialchars just before you echo) to make sure that the escaping method used is the correct one for this context, but also to do validation as early as possible (don't accept invalid data in the first place, e.g., validate e-mail addresses and throw an error if it's invalid).

There's also the ModSecurity extension for Apache which will catch most of these attacks, but it's not foolproof because there are almost endless ways to craft an injection. ModSecurity should therefore only be used when you already have secured your application code but are afraid that you may miss something due to bugs in the future (which may happen to most of us in some way or another).

回复收藏 0 原文

染年凉城似染瑾 2024-12-27 00:17:21

为什么不清理代码中的 $_GET 变量呢？

回复收藏 0 原文

送君千里 2024-12-27 00:17:21

是的，我确实这么认为。发现于
http://www.simonecarletti.com/blog/2009/ 01/apache-query-string-redirects/

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/page\.php$
RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^(.*)$ http://mydomain.site/page/%1.pdf [R=302,L]

注意正则表达式。这应该意味着您可以设计正则表达式来适应您试图阻止的事情。谷歌正则表达式参考并看到很多。

请记住，htaccess 文件将影响其所在的任何目录及其所有子目录。
这里有很多好的 .htaccess 提示，包括重定向 http://www.sitepoint.com /htaccess-for-all/

Yes I do believe so. Found at
http://www.simonecarletti.com/blog/2009/01/apache-query-string-redirects/

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/page\.php$
RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^(.*)$ http://mydomain.site/page/%1.pdf [R=302,L]

Notice the regular expressions. This should mean you can design your regex to accomidate the things you are trying to prevent. Google regex reference and see tons of them.

Remember that htaccess file will affect any directory its located and all sub-directories.
There are a lot of good .htaccess tips here including the redirect http://www.sitepoint.com/htaccess-for-all/

回复收藏 0 原文