系统安全不求人：开发者必学的漏洞防御秘籍
专业在线打字练习平台-巧手打字通，只输出有价值的知识。
一 数据库操作，要谨慎
1.1 SQL 注入，危害大
通过 SQL 注入等方式，把用户输入的数据当做代码执行。
简单场景举例：假如程序里有以下基于订单号查询订单的 SQL 语句，订单号是用户从页面传递过来的：
如果黑客构造了如下订单号参数：666'; drop table my_order--
那么最终实际执行的 SQL 语句将会如下：
查询订单的语义，就变成了查询完订单后，再执行一个 drop 表的操作，而这个操作，就是用户构造的恶意攻击命令！
如果应用没有做有效的参数校验及脱敏处理，后台数据库也没有做权限约束，该 sql 注入的危害是极大的。
1.2 SQL 隐式转换，需留意
你知道吗？下面的语句是能够被正常执行的：
查询操作主要影响的是数据返回的结果集，而更新操作则直接关系到整张表中数据的准确性和完整性。因此，在执行 SQL 语句之前，进行严格的正确性检查是极其必要的。
二 跨站脚本攻击,要防御
Cross Site Scripting：跨站脚本攻击,有时也缩写为 XSS。攻击者会在网页中嵌入恶意脚本，一旦用户浏览该页面，这些隐藏的恶意代码就会被执行，进而实现攻击者的特定目的。
举个 HTML 页面渲染攻击的例子：
这段代码就有可能被黑客利用,弹出木马链接，获取本地登录会话信息等：
XSS（跨站脚本攻击）的核心问题在于用户提交的 HTML 代码未经充分过滤和转义就直接被页面回显，为解决这类安全隐患，必须对用户输入的数据进行严格的转换和脱敏处理。
三 跨站请求伪造，需甄别
Cross Site Request Forgery：即跨站请求伪造,有时也缩写为 XSRF。攻击者通过诱导用户在已登录的 Web 应用程序上执行恶意操作，比如诱导用户触发应用的 URL 请求或填写欺骗性表单，实质上是利用了应用的会话（session）机制，非法冒用已认证用户的身份，对应用执行未经授权的恶意 GET/POST 请求，以篡改用户数据。
3.1 实施步骤举例
黑客首先在服务器端精心编写恶意脚本，并构造出包含授信操作的特定 URL，比如用于提交评论的链接。
接着，恶意用户利用这一漏洞，在回复帖子时插入图片，而图片的来源地址则巧妙地指向黑客预先设置好的恶意脚本。
当无辜的用户浏览这些包含恶意图片链接的帖子时，浏览器会自动请求加载这些图片，从而在不知不觉中执行了黑客的恶意脚本。
恶意脚本进一步利用 302 重定向技术，根据帖子内容的不同，将用户重定向至预先设定的、包含敏感操作（如评论提交）的 URL，从而在不经过用户明确授权的情况下执行恶意操作。
上述示例虽仅聚焦于引导用户跳转至评论区作为演示，但实际上，黑客的手段远不止于此。他们还可能精心构造伪装成用户登录页面的 URL，企图诱骗用户输入个人密码；或是设计看似合法的支付页面 URL，以套取用户的支付密码等高度敏感的核心信息。这些操作在用户毫无察觉的情况下进行，其潜在危害极为严重。
3.2 如何防御 XSRF 攻击
可以采用以下几种策略：
使用 CSRF 令牌（Token）
这是最常见和有效的防御方法。服务器生成一个唯一的 CSRF 令牌，并将其嵌入到每个表单或请求中。当客户端提交请求时，这个令牌会作为请求的一部分被发送。服务器在收到请求后，会验证令牌的有效性，确保请求来自受信任的源。这种方法可以有效防止 CSRF 攻击，因为攻击者很难预测或伪造这个令牌。
双重验证
对于重要的操作，如转账、修改密码等，可以实施双重验证机制。除了用户密码外，还需要额外的验证信息，如短信验证码、指纹识别等。这样即使攻击者成功构造了 CSRF 请求，也无法通过双重验证，从而无法完成攻击。
使用 HTTPS
确保 Web 应用程序使用 HTTPS 协议进行通信。HTTPS 可以加密客户端和服务器之间的数据传输，防止攻击者在中间截获或篡改请求。虽然 HTTPS 本身并不直接防御 CSRF 攻击，但它可以增强整体的安全性，降低攻击成功的可能性。
验证请求的来源（Referer 检查）
服务器可以检查请求的 Referer 头部，以判断请求是否来自受信任的源。然而，这种方法并不是百分之百可靠的，因为 Referer 头部可以被伪造或在某些情况下被浏览器省略。因此，它通常作为额外的防御措施，而不是主要的防御手段。
设置 SameSite Cookie 属性
对于敏感操作相关的 Cookie，可以设置 SameSite 属性为 Strict 或 Lax。这样，浏览器就不会在跨站请求中发送这些 Cookie，从而有效防止 CSRF 攻击。但是，需要注意的是，这种方法可能会影响一些合法的跨站请求，因此需要根据实际情况进行配置。
四 越权操作，要杜绝
4.1 水平越权 VS 垂直越权
水平越权控制：“基于数据的访问控制” 设计缺陷引起的漏洞。由于服务器端在接收到请求数据进行操作时没有判断数据的所属人/所属部门而导致的越权数据访问漏洞；
未经检验和加密的参数漏洞是引发水平越权漏洞的基础。当系统直接依据用户提交的手机号发送验证码时，若缺乏有效的验证机制，攻击者便可通过编写自动化脚本，轻易发起短信轰炸攻击。
更为安全稳妥的做法是，依据当前已登录用户的唯一标识，通过后端服务查询并确认其对应的手机号，而非直接采纳前端输入的参数（鉴于所有来自前端的数据均视为潜在的不安全输入）。
或许有人会质疑，既然获取当前登录用户信息也依赖于前端传递的会话标识（如 cookie、session ID），那么这些标识是否就绝对可靠呢？
答案是否定的。尽管通过跨站脚本（XSS）等手段存在会话劫持的风险，但值得注意的是，会话标识的实现通常融合了多重安全机制，包括加密、时效控制及防篡改策略等，相较于普通业务参数而言，这些措施显著增强了数据的安全性，提供了更为坚实的防护屏障。
垂直越权控制: “基于 URL 的访问控制” 设计缺陷引起的漏洞，又叫做权限提升攻击。由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的 URL 或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。
4.2 越权举例说明
登录用户 A 时，正常更改或者是查看 A 的用户信息；
然后抓取数据包，将业务传参 ID 篡改为其他用户的；
如果成功查看或者修改了同权限其他用户信息就属于水平越权；
如果可以获得到更高权限用户（管理员）的操作能力(删除)就是垂直越权；
五 安全漏洞，要规避
把握住传参就能把握住逻辑漏洞的命脉。
5.1 规避策略分类
白名单校验：接受已知的合法数据集。
黑名单校验：拒绝已知的非法数据集；
白名单净化：对任何不属于已验证合法字符数据中的字符进行净化，然后再使用净化后的数据，净化的方式包括删除、编码、替换；
黑名单净化：剔除或者转换某些字符（例如，删除引号、转换成 HTML 实体，防止 SQL 注入）；
5.2 提示文案，也有风险
为提升用户体验，众多系统在注册流程中增设了手机号与邮箱的查重功能，即时反馈如“该手机号已注册！”的提示信息给用户。然而，这种做法不经意间提供了可遍历的接口，增加了注册用户信息泄露的风险，因此必须实施合理的请求频率限制措施以保障安全。
在涉及手机号短信注册、登录、密码找回及邮箱验证等敏感操作中，若直接将验证码（或验证凭证）嵌入交互请求中，则可能面临被恶意攻击者拦截的风险，进而导致验证机制形同虚设。为防止验证流程被轻易绕过，必须优化验证逻辑设计，确保验证信息的安全传输与验证过程的有效执行。
总结
本文全面剖析了系统安全面临的多个关键领域，包括数据、应用、权限及设计等方面，详细阐述了这些领域内影响系统安全的典型场景。
在数据安全层面，文章重点指出了 SQL 注入这一严重威胁，它利用应用程序的漏洞，恶意篡改 SQL 语句，进而窃取或破坏数据库中的敏感信息。同时，也提醒了 SQL 隐式转换虽提升了编程效率，但其潜在的风险不容忽视，特别是在数据类型处理上需格外谨慎，以防安全漏洞的产生。
针对网页安全，本文强调了跨站脚本攻击（XSS）和跨站请求伪造（CSRF）这两种常见且危险的攻击方式，并指出需通过实施内容安全策略等有效防御措施来加以应对。
在权限管理领域，文章深入分析了水平越权和垂直越权这两种复杂的权限问题，强调了构建精细的访问控制策略对于防范此类风险的重要性。
此外，设计安全方面也被纳入讨论范畴，特别是指出了提示文案设计时的敏感性，强调需谨慎处理，以避免误导用户或泄露敏感信息。
综上所述，构建一个稳固的安全防护体系，需要采取一系列综合性的策略，包括但不限于加强输入验证、推广使用参数化查询、实施严格的安全编码规范、部署高效的防御机制，以及加强权限审计与管理等。这些措施的共同作用，将有效保障用户数据与应用的安全，显著降低安全风险。
版权声明: 本文为 InfoQ 作者【巧手打字通】的原创文章。
原文链接:【http://xie.infoq.cn/article/c899714c7b21fb4d457636a81】。文章转载请联系作者。
专业在线打字学习平台：巧手打字通 2019-12-16 加入
vx：一起来打字
评论