在 Web 应用程序或本机应用程序中的编码期间或代码(如 sql 注入和跨站点脚本 (XSS))中可以处理哪些类型的攻击?
编辑:由于答案被搁置,我只想要最常见或前 5 名的名称,这些名称可以在编码中处理,而不是服务器(主机)或网络或操作系统问题。
编辑 2:我已将其缩小到由于持有而导致的攻击类别。
在 Web 应用程序或本机应用程序中的编码期间或代码(如 sql 注入和跨站点脚本 (XSS))中可以处理哪些类型的攻击?
编辑:由于答案被搁置,我只想要最常见或前 5 名的名称,这些名称可以在编码中处理,而不是服务器(主机)或网络或操作系统问题。
编辑 2:我已将其缩小到由于持有而导致的攻击类别。
下面的答案与SQL Injection和HTTP Response Splitting相关。
当应用程序在应用程序的行为中直接使用用户输入时,就会发生这种利用。这被认为是不好的做法,并且会使任何应用程序因跨站点脚本 (XSS)、主机标头攻击(修改Host
HTTP 请求中的标头以执行恶意行为)等事件而遭受多次破坏。
那么直接接受用户输入是什么意思呢?例如,假设您有一个简单的表单,其中包含一个Person ID
字段和一个提交按钮。一旦提交按钮,系统会动态生成一个 SQL 查询来匹配用户所需的信息。
SELECT * FROM Users WHERE PersonID = '$person_id'
此查询采用了用户应该被信任的错误假设,而这绝不应该是这种情况。那么,为了防止这种情况,在您的代码中采取什么好的步骤呢?尽可能准备好语句、参数查询。
我从上面的维基百科链接中获取的常见示例:
$mysqli = new mySqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
$$mysqli->real_escape_string($Username),
$$mysqli->real_escape_string($Password));
$mysqli->query($query);
跨站点脚本 (XSS) 通常通过编码特殊字符来缓解,允许浏览器显示实体但不运行它们。下面是一个很好的列表,显示了某些字符是如何编码的。我强烈建议您访问这篇文章以进一步了解它或查看我在下面提到的 Web 漏洞字典。
请注意,这里适用的概念与 SQL 注入相同。用户输入永远不可信任。
<?php
$name = $_GET['name'];
echo "Welcome $name<br>";
echo "<a href="http://xssattackexamples.com/">Click to Download</a>";
?>
查看上面的示例,您会注意到$name
它是一个存储变量,稍后将在代码中直接引用它。现在,恶意用户不再查询名称Bob
(例如),而是查询<script>alert('attacked')</script>
. 使用上面的代码,这个查询将在 web 应用程序中执行上面的命令(这可能比这更严重)。
黑客可能能够找到一个标头注入漏洞,该漏洞允许他制定一个将整个 HTTP 正文注入响应和另一个第二个响应正文的请求(听起来可能有点混乱)。本质上,服务器会将其识别为链接在一起的两个单独的请求——这就是为什么它被称为 HTTP 拆分,因为您正在有效地拆分服务器的响应。
我决定将这个漏洞放在这个答案中的原因是因为它是最容易利用的漏洞之一,它不需要大量的知识,并且会使您的应用程序面临 XSS 等主要漏洞。执行此漏洞的关键字符是%0d%0a
- 更正式地称为CRLF
(回车和换行),这对于许多协议来说都是必不可少的,因为它标志着行尾 (EOL)。
如果您的 Web 应用程序没有使用上述方法正确处理此类字符,那么恶意用户可能会让他们的输入影响服务器的行为,这显然是我们不想要的。
让我们看一个部分示例:
http://www.yoursite.com/somepage.php?page=%0d%0a
Content-Type:text/html%0d%0aHTTP/1.1 200 OK%0d%0a
Content-Type:text/html%0d%0a%0d%0a%3Chtml%3EHacker Content%3C/html%3E
<html>Hacker Content</html>
当用户单击上面的链接时,该页面将被提供给谁。有趣的部分?这是通过您的服务器完成的。您的易受攻击的服务器正在为受害者提供这些恶意内容。
有关这方面的更多信息,我建议阅读下面的Acunetix CRLF 注入和OWASP 的 HTTP 响应拆分文章
可以通过多种方式缓解 Web 应用程序上的漏洞,但是在查看特定漏洞之前,最好先查看系统结构以及它本身是否脆弱且容易受到攻击(许多人会监督这个问题)。
其余的完全可以通过互联网获得。当谈到 Web 应用程序安全时,我鼓励阅读来自不同作者的大量文章。
我发现的一个非常有用的链接是 Acunetix 的这个Web Vulnerabilities 字典,它提供了关于所需漏洞、常见修复技术以及社区文章的很好但不是过于详细的描述。