本文概述
在开发中采取措施来强化和保护你的Web后端安全。
小型企业, 银行和许多行业都依赖于Web应用程序。从构建Web应用程序的角度出发, 至关重要的是, 在开发过程中, 一定要确保有协议来检查漏洞, 以避免安全漏洞, 数据泄漏和财务问题。
最危险的Web攻击是在存储和分析数据的服务器端发生的攻击。
什么是后端?
Web应用程序分为两部分-前端和后端。
- 前端是客户端, 它是用户与之交互的部分。通常, 它是使用HTML, CSS和Javascript构建的。
- 后端是服务器端。基本上就是应用程序的工作方式, 应用业务逻辑, 更改和更新的方式。一些流行的服务器端技术堆栈涉及PHP, NodeJS, Java, Ruby, C, Python, 数据库, 安全性(身份验证, 访问控制等), 结构和内容管理。
开始之前的一点提醒–身份验证, 访问控制和会话管理
对我们来说, 混淆条款是很常见的。因此, 让我们快速澄清一下:
- 身份验证涉及证明用户身份(例如, 密码, 用户名, 问题安全性, 指纹)
- 访问控制关系到用户可以访问应用程序的内容。它强制执行以下策略:用户不能在其预期权限之外采取行动。
- 会话管理涉及与同一用户关联的响应和请求事务。这是用户成功通过身份验证后, 在用户和应用程序之间使用的一种交换机制。
让我们探索以下内容, 以获得更好的后端网络安全性。
注射缺陷
自2010年以来, OSWAP将注入分类为最危险的Web应用程序风险排名第一。
注入漏洞使用户可以提供包含关键字的数据, 这些关键字将修改在数据库上建立的查询的行为。例如, 假设我们有一个SQL脚本, 该脚本检查数据库中是否存在匹配的条目。
uname = request.POST['username']
passwd = request.POST['password']
sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'"
database.execute(sql)
攻击者现在可以使用SQL注入来操纵密码字段, 例如, 输入密码” OR 1 =” 1, 这将导致以下SQL查询:
sql =”从用户名=的用户中选择ID”并且密码=”密码”或1 =” 1″
这样, 攻击者可以访问数据库的所有用户表, 密码始终有效(1 =‘1’)。如果他们以管理员身份登录, 则可以进行所需的任何更改。
怎么预防呢?
避免注入缺陷非常容易。
验证是否没有注入缺陷的最好, 最简单的方法是进行全面的手动源代码检查, 以检查数据库中的查询是否通过准备好的语句完成。你还可以使用工具检查漏洞。
并且你还应该执行以下操作。
- 使用ORM(对象关系映射工具)。
- 转义所有输入。除日期外, 日期字段中不得存储任何其他内容。
- 隔离你的数据, 以便仅保留应从给定位置访问的内容。
- 编写良好的处理错误代码。不要让你的数据库或后端太冗长。
Troy Hunt在SQL注入方面学得很棒。如果有兴趣, 你可以探索一下。
身份验证失败
如前所述, 身份验证处理提供的凭据。这是防范无限制访问的第一线。但是, 实施不当和不遵守安全策略会导致身份验证失败。
身份验证失败的情况主要有以下三种:
- 凭据填充:攻击者拥有有效用户名和密码的列表, 可以自动进行攻击以证明凭据有效。
- Bruteforce攻击:应用程序允许用户或管理员使用弱密码。
- 会话劫持:应用程序公开会话ID, URL或登录后不会轮换使用。
在所有情况下, 攻击者都可以访问重要帐户并依赖可能导致洗钱, 身份盗窃或泄露受法律保护的高度敏感信息的企业。
怎么预防呢?
在实施身份验证系统之前, 请问自己-如果身份验证系统受到攻击, 攻击者可以实现什么目标?
根据响应, 你可以执行以下操作。
- 实施多因素身份验证以防止自动攻击。
- 鼓励(或强迫)用户采用良好的密码策略。
- 限制登录失败。
- 使用高效的算法哈希。选择算法时, 请考虑最大密码长度。
- 测试会话超时系统, 并确保注销后会话令牌无效。
存取控制中断
存在访问控制以确保允许经过身份验证的用户执行操作。身份验证和会话管理是基础或访问控制规则。但是, 如果这些规则设置不当, 可能会导致重大问题。
常见的访问控制缺陷包括:
- CORS配置错误, 允许未经授权的API访问。
- 元数据操作可直接访问方法。
- 强制浏览:攻击者将尝试使用URL, 修改路径(例如, 将http://website.domain/user/更改为http://website.domain/admin), 甚至可以发现重要文件。
怎么预防呢?
通常, 由于对有效访问管理的基本要求不了解而造成了损坏的访问缺陷。
- 默认情况下拒绝, 但公共资源除外。
- 禁用服务器目录列表, 并确保不存在备份文件。
- 对API进行速率限制, 以减少自动攻击的影响。
- 在后端注销后使JWT令牌无效。
数据暴露
数据泄露也称为数据泄露, 是威胁企业及其客户的网络威胁。
当应用程序不能充分保护信息(例如凭据)或敏感数据(例如信用卡或健康记录)时, 就会发生这种情况。每分钟违反4000条记录。
从财务方面来说, 对业务的影响是巨大的:据IBM称, 平均一次违规可能造成392万美元的损失。
怎么预防呢?
作为后端开发人员, 你应该询问需要保护的信息是什么。
然后为防止此类缺陷:
- 加密敏感数据:对于REST上的数据, 请加密所有内容。对于传输中的数据, 请确保使用安全网关(SSL)
- 识别需要额外保护的数据, 并仅通过强制执行基于密钥的加密, 将访问权限限制为一堆合法用户。
- 避免使用弱加密算法:使用最新的强算法。
- 有一个安全的备份计划。
不安全的反序列化
序列化和反序列化是将数据转换为对象格式以存储或发送到另一个应用程序时使用的概念。序列化包括将数据转换为XML或JSON等对象格式以使其可用。反序列化只是相反的过程。
如果存在可以修改以更改行为的类, 则针对反序列化器的攻击可能导致拒绝服务, 访问控制和远程代码执行(RCE)攻击。
OWASP十大文档的第二个示例很好地说明了PHP对象序列化程序:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
这是一个超级Cookie, 其中包含诸如用户ID, 用户级别和哈希密码之类的信息。
攻击者可以更改序列化的对象以获得对管理员特权的访问权:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
怎么预防呢?
至关重要的是, 不要接受来自不受信任来源的序列化对象。
你还应该:
- 永远不要相信用户输入。
- 验证数据:如果你的应用程序除字符串外, 请在使用前确保它是字符串
- 请检查以确保数据没有更改。在两个受信任的来源之间发送数据(例如, 在客户端存储数据)非常有用。
服务器XSS
服务器XSS(跨站点脚本)是攻击者使用Web应用程序将恶意代码发送给不同用户时的一种注入方式。当攻击者发布某些包含应用程序存储的恶意代码的精心制作的数据时, 就会发生这种情况。此漏洞是服务器端的漏洞。浏览器只是呈现响应。
例如, 在论坛中, 用户帖子通常未经验证就保存在数据库中。攻击者借此机会添加带有恶意脚本的帖子。随后, 其他用户通过电子邮件收到此链接, 或查看有问题的帖子并单击它。
怎么预防呢?
在初步确定了可能存在XSS风险并需要保护的所有操作之后, 应考虑以下事项。
- 验证输入:检查输入长度, 使用正则表达式匹配, 并且仅允许某些字符集。
- 验证输出:如果应用程序将对源自某个用户或第三方的任何数据项复制到其响应中, 则应对该数据进行HTML编码以清除潜在的恶意字符。
- 允许限制HTML:例如, 如果你有一个评论博客系统, 则仅允许使用某些标签。如果可以, 请使用适当的框架来提供用户提供的HTML标记, 以确保该标记不包含任何执行JavaScript的方法。
总结
开发阶段对于Web应用程序安全至关重要。并且, 你应该考虑在开发生命周期中包括一个安全漏洞扫描程序, 以便在生产之前解决已确定的问题。
评论前必须登录!
注册