web 安全漏洞检查 十二个常见的Web安全漏洞总结及防范措施

前言本篇文章部分摘要自《OWASP Top 10 2017》，我来为大家科普一下关于web 安全漏洞检查 十二个常见的Web安全漏洞总结及防范措施?下面希望有你要的答案，我们一起来看看吧!

web 安全漏洞检查 十二个常见的Web安全漏洞总结及防范措施

前言

本篇文章部分摘要自《OWASP Top 10 2017》。

OWASP，开放式Web应用程序安全项目（Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。

一、SQL注入

SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

示例：

比如我们使用的登录接口：在登录界面包括用户名和密码输入框，以及提交按钮，输入用户名和密码，提交。

登录时调用接口/user/login/ 加上参数username、password，首先连接数据库，然后后台对请求参数中携带的用户名、密码进行参数校验，即sql的查询过程。假设正确的用户名和密码为ls和123456，输入正确的用户名和密码、提交，相当于调用了以下的SQL语句。

SELECT * FROM user WHERE username = 'ls' AND password = '123456'

1

sql中会将#及–以后的字符串当做注释处理，如果我们使用“’ or 1=1 #” 作为用户名参数，那么服务端构建的sql语句就如下：

select * from users where username='' or 1=1#' and password='123456'

1

#会忽略后面的语句，因此上面的sql也等价于：

select * from users where username='' or 1=1

1

1=1属于常等型条件，因此这个sql便成为了如下，查询出所有的登陆用户。

select * from users

1

其实上面的sql注入只是在参数层面做了些手脚，如果是引入了一些功能性的sql那就更危险了，比如上面的登陆接口，如果用户名使用这个“’ or 1=1;delete * from users; #”，那么在";"之后相当于是另外一条新的sql，这个sql是删除全表，是非常危险的操作，因此sql注入这种还是需要特别注意的。

防范措施：

严格限制web应用的数据库的操作权限，给用户提供仅能满足需求的最低权限，从而最大限度的减少注入攻击对数据库的危害。

严格限制变量的类型。

对进入数据的特殊字符（‘ “ \ <> & *）进行转义处理（或编码转换）

不要直接拼接SQL语句，所有的查询语句建议使用数据库提供的参数化查询接口，使用参数化的语句而不是将用户输入的变量嵌入SQL语句中。

在应用发布之前建议使用专业的SQL注入检测工具进行检测，及时修补被检测出的SQL注入漏洞。

避免网站打印SQL错误信息，比如类型错误、字段不匹配等，可对异常信息做封装，给出友好提示，不直接打印堆栈信息到前端。

二、失效的身份认证

应用中负责认证和会话管理的部分没有正确实现，使得攻击者得以泄露密码，口令或令牌，进而可能获取其他用户的身份。

漏洞成因：

允许自动化的攻击，如凭据填充（credential stuffing,撞库）攻击。

允许暴力破解或其他自动攻击。

允许默认，弱，广为人知的密码， 例 “admin/admin”。

使用弱，或无效的凭据恢复和忘记密码策略。

使用明文，加密或弱hash的密码。

使用损坏的或无效的多因子认证。

在URL中暴露会话ID。

在成功登录后没有轮换会话ID。

没有及时把会话ID，验证令牌等信息无效化。

防范措施：

实现多因子认证以组织自动化攻击和凭据重用。

避免使用默认密码。

进行弱密码检查。

对齐密码长度，复杂度。

确保注册，凭据恢复和API被加固以抵御账户枚举攻击。

限制或延迟失败的登录尝试，并记录所有失败尝试并在发动攻击时报警。

使用服务端，安全，内置的会话管理，确保对于每次登录生成随机会话ID。会话ID不应该在URL中，且应该及时销毁。

三、敏感数据泄露

攻击者不是直接攻击密码，而是在传输过程中或从客户端（例如：浏览器）窃取密钥、发起中间人攻击，或从服务器端窃取明文数据。这通常需要手动攻击。通过使用图形处理单元（GPU），早前检索的密码数据库可能被暴力破解。

防范措施：

对系统处理、存储或传输的数据分类，并根据分类进行访问控制。

对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。

确保存储的所有敏感数据被加密。

确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。

确保传输过程中的数据被加密，如：使用安全传输层协议（TLS）。确保数据加密被强制执行，如：使用HTTP严格安全传输协议（HSTS ）。

禁止缓存对包含敏感数据的响应。

确保使用密码专用算法存储密码，如：Argon2 、 scrypt 、bcrypt 或者PBKDF2 。将工作因素（延迟因素）设置在可接受范围。

四、越权访问

越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。

该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。越权访问漏洞主要分为水平越权访问和垂直越权访问

水平越权访问漏洞

水平越权访问是一种“基于数据的访问控制”设计缺陷引起的漏洞。由于服务器端在接收到请求数据进行操作时没有判断数据的所属人/所属部门而导致的越权数据访问漏洞。

假设用户A和用户B属于同一角色，拥有相同的权限等级，他们能获取自己的私有数据（数据A和数据B），但如果系统只验证了能访问数据的角色，而没有对数据做细分或者校验，导致用户A能访问到用户B的数据（数据B），那么用户A访问数据B的这种行为就叫做水平越权访问。

垂直越权访问漏洞

垂直越权是一种“基于URL的访问控制”设计缺陷引起的漏洞，又叫做权限提升攻击。

由于后台应用没有做权限控制，或仅仅在菜单、按钮上做了权限控制，导致恶意用户只要猜测其他管理页面的URL或者敏感的参数信息，就可以访问或控制其他角色拥有的数据或页面，达到权限提升的目的。

防范措施：

前后端同时对用户输入信息进行校验，双重验证机制

调用功能前验证用户是否有权限调用相关功能

执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限

直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理

永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

五、安全性错误配置

攻击者能够通过未修复的漏洞、访问默认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问或了解。

使用默认账户和密码、在应用栈中任意一处没有安全加固，云服务器授权没有正确配置、应用服务器，应用框架，库，数据库中的安全设置没有被设为安全值、服务器没有发送安全头或指令等都有可能造成安全性错误配置漏洞。

防范措施：

一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。

搭建最小化平台，不包含任何非必须地特性，组件，文档。

包管理工具中检查并更新安全配置。

一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安组。

向客户端发送安全指令，如：安全标头。

在所有环境中能够进行正确安全配置和设置的自动化过程。

六、XSS跨站脚本攻击

XSS漏洞出现在当web页面包含不可信的数据，却没有合适的验证手段来找到它的时候。XSS使得攻击者能够在受害者的浏览器中执行脚本，从而劫持会话，或重定向到恶意站点。

漏洞成因：

存在三种XSS类型，通常针对用户的浏览器：

反射式XSS：应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。例如恶意漏洞网站，广告或类似内容。

存储式XSS：你的应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页展示出来。存储型XSS一般被认为是高危或严重的风险。

基于DOM的XSS：会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。

防范措施:

防止XSS需要将不可信数据与动态的浏览器内容区分开。这可以通过如下步骤实现：

使用自动转义XSS的框架，比如React JS。学习每种框架的XSS保护，并手动处理用例没有覆盖到的部分。

转义不可信的HTTP请求数据能够解决反射型和存储型XSS威胁。

在客户端修改浏览器文档时应用内容敏感的编码以抵御DOM XSS。或使用相似的内容敏感转义技术。

启用CSP(Content Security Policy),这是一种对抗XSS的纵深防御弥补控制。

七、不安全的反序列化

反序列化最严重可导致远程代码执行（RCE，Remote Code Execution），但最常见的反序列化安全问题却是通过修改序列化之后的数据字段，从而进行提权或越权操作。

注：用户登陆后，服务器将用户身份信息存储在浏览器cookie中

存储于cookie中的这份数据的格式是应用程序自定义的，但攻击者通过探索尝试后发现，修改其中的某个字段就能将用户从普通用户修改为管理员。

存储于cookie中的原始数据：

Cookie: 3844998|AliceM|y|27|*NU*|active|null|201809

1

经过修改后的数据

Cookie: 3844998|AliceM|y|27|*ADMIN*|active|null|201809

1

由于缺乏对数据完整性的校验，服务器端在收到被修改过的这段数据后，就把当前用户当作ADMIN用户来处理了。

防范措施：

唯一的安全模式是不接受来自不可信的参与者的序列化对象。如果不得不接受，使用以下策略：

对任何序列化对象进行完整性检测，比如数字签名以防止数据篡改或恶意对象。

在反序列化过程中强制严格的类型限制。

在低权限环境中独立运行反序列化代码。

记录反序列化异常和错误，比如收到的类型并不是期望的类型。

限制或监管入的和出的来自反序列化的容器或服务器的网络链接。

监管反序列化，当用户一直反序列化时报警。

八、使用具有已知漏洞的组件

库，框架等软件组件和应用有着相同的权限。如果存在有漏洞的组件，那么攻击就能够导致数据泄露甚至控制服务器。组件中的漏洞会导致整个应用和API安全性的下降。

漏洞成因：

管理员不知道使用的所有组件的版本，包括直接使用的和其依赖的组件。

软件易受攻击，不再支持，或是过时的。包括OS, web服务器，DBMS，APIs和所有组件，运行时环境，库。

没有周期性扫描漏洞，没有关注所使用组件的安全公告。

没有及时修复或升级平台，框架，依赖。

软件开发者没有测试升级，更新，补丁的兼容性。

防范措施：

移除不使用的依赖、不需要的功能、组件、文件和文档。

利用如 versions、DependencyCheck 、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE 和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。

仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险。

监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。

九、不足的日志记录和监控

日志和监控不足，再加上缺失或无效的事件响应，允许攻击者进一步攻击系统，他可以转向更多系统，进行篡改，提取，销毁数据。大部分研究表明违反往往会在超过200天后才被检测出来，而且还是由外部参与者检测到的。

漏洞成因：

未记录可审计性事件，如：登录、登录失败和高额交易。

告警和错误事件未能产生或产生不足的和不清晰的日志信息。

没有利用应用系统和API的日志信息来监控可疑活动。

日志信息仅在本地存储。

没有定义合理的告警阈值和制定响应处理流程。

渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发告警。

对于实时或准实时的攻击，应用程序无法检测、处理和告警。

防范措施：

确保登录，访问控制失败，服务断输入验证失败等事件会被日志记录，同时记录足够多的用户上下文以确定可疑账号。保存足够长的时间以用于分析。

确保日志以一定格式生成，便于日志管理。

确保高额转账带有审计跟踪和完整性控制以避免篡改或删除。

建立有效的监管和报警机制，使得可疑活动被及时检测和响应。

建立事件响应和恢复计划。

十、CSRF跨站请求伪造

简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

防范措施：

在表单中添加一个随机的数字或字母验证码，通过强制用户和应用进行交互，来有效地遏制CSRF攻击。

如果检查发现是非正常页面提交的请求（根据Referer进行判断），则极有可能是CSRF攻击。

在请求的参数里增加一个随机的token参数，且不可被猜测。

敏感的操作应该使用POST，而不是GET，以form表单的形式提交，可以避免token泄露。

十一、点击劫持

点击劫持 (Clickjacking) 技术又称为界面伪装攻击 (UI redress attack )，是一种视觉上的欺骗手段。攻击者使用一个或多个透明的 iframe 覆盖在一个正常的网页上，然后诱使用户在该网页上进行操作，当用户在不知情的情况下点击透明的 iframe 页面时，用户的操作已经被劫持到攻击者事先设计好的恶意按钮或链接上。攻击者既可以通过点击劫持设计一个独立的恶意网站，执行钓鱼攻击等

黑客创建一个网页利用iframe包含目标网站；

隐藏目标网站，使用户无法察觉到目标网站存在；

构造网页，诱骗用户点击特定按钮 (图1中的PLAY!按钮)；

用户在不知情的情况下点击按钮，触发执行恶意网页的命令。

防范措施：

X-FRAME-OPTIONS是目前最可靠的方法。

X-FRAME-OPTIONS是微软提出的一个http头，专门用来防御利用iframe嵌套的点击劫持攻击。

并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。

这个头有三个值：

DENY // 拒绝任何域加载

SAMEORIGIN // 允许同源域下加载

ALLOW-FROM // 可以定义允许frame加载的页面地址

十二、任意文件上传和读取下载

1. 任意文件上传

任意文件上传（Unrestricted File Upload），是一种常见的web安全漏洞，由于web应用程序在实现文件上传功能是对上传的文件缺少必要的检查，使得攻击者可上传任意文件。利用该漏洞，攻击者可以直接上传webshell（webShell 就是以asp\php\jsp或者cgi等网页文件形式存在的一种命令执行环境，也可以将其称之为一种网页后门）、病毒、恶意脚本等各种危险文件，可能导致服务器权限被直接获取，从而危及整个系统的安全运行。

防范措施：

校验文件格式，对上传的文件后缀进行判断，如果是上传头像处，仅允许jpg、png、gif等图片文件格式上传，而且对图片进行二次渲染，防止黑客利用解析漏洞来getshell。

校验文件大小，限制过大文件上传。

重命名上传文件。

2. 任意文件读取下载

由于业务需求，往往需要提供文件查看或文件下载功能，但若对用户查看或下载的文件不做限制，则恶意用户就能够查看或下载任意敏感文件，这就是文件查看与下载漏洞。

一般链接形式：

download.php?path=

down.php?file=

data.php?file=

防范措施：

过滤"."，使用户在url中不能回溯上级目录

正则严格判断用户输入参数的格式

php.ini配置open_basedir限定文件访问范围

设置白名单，即只能下载/访问某个目录下的文件，权限给到最低

参考资料

OWASP Top 10 2017：https://owasp.org/www-project-top-ten/

OWASP Top 10 2017（中文版）：https://wiki.owasp.org/images/d/dc/OWASP_Top_10_2017_中文版v1.3.pdf

————————————————

版权声明：本文为CSDN博主「chenlijian」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/chenlijian/article/details/115006677

,