常见web安全漏洞_web漏洞
一、暴力破解
1、概述
“暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。
2、基于表单的暴力破解
条件：用户没有任何安全验证，可直接抓包进行暴力破解。
3、验证码绕过
验证码绕过（on server）：验证码校验在服务端完成，但是验证码存在时效性，这个时候我们可以在这个时效内进行抓包实现短时间内的验证码绕过。
验证码绕过（on client）：在前端进行验证码的校验，这个时候驶入正确的验证码提交，进行抓包后，我们通过修改密码和账号发现我们不需要再对验证码进行修改，从而绕过了验证码，实现暴力破解。
4、token防爆破？
由于token值输出在了前端的源码中，容易被获取，因此也就失去了防爆破的意义。我们可以在每次暴力破解的过程中获取到前端页面生成的token的值，从而实现暴力破解。
5、安全策略
1.是否要求用户设置复杂的密码；
2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机app；
3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4.是否采用了双因素认证；
二、XSS
1、基本概念和原理介绍
跨站点脚本攻击，指攻击者通过篡改网页，嵌入恶意脚本程序，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。一般XSS可以分为如下几种常见类型：
1.反射性XSS
交互的数据一般不会被存在在数据库里面，一次性，所见即所得，一般出现在查询
2.存储型XSS
交互的数据会被存在在数据库里面，永久性存储，一般出现在留言板，注册等页面。
3.DOM型XSS
不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性也属于反射型。
形成原因
形成xss漏洞的主要原因是程序对输入输出的控制不够严格，导致“精心设计”的脚本输入后，在输出到前端时被浏览器当作有效代码执行从而产生危害。
2、跨站脚本漏洞测试流程
（1）在目标站点上找到输入点，比如查询接口，留言板等。
（2）输入一组"特殊字符+唯一识别字符"，点击提交后，查看返回的源码，是否有做对应的处理。
（3）通过搜索定位唯一字符，结合唯一字符前后语法确认是否可以执行js的条件（构造闭合）。
（4）提交构造的脚本代码（以及各种绕过姿势），看是否可以成功执行，如果成功执行则说明存在现在xss漏洞；
TIPS：
（1）一般查询接口容易出现反射型xss，留言板容易出现存储型xss；
（2）由于后台可能存在过滤措施，构成的script可能会被过滤掉，二无法生效，或者环境限制了执行（浏览器）。
（3）通过变化不同的script，尝试绕过后台过滤机制。
3、安全策略
（1）输入时：严格过滤单引号，双引号，尖括号。
记住一点：不要相信任何输入的内容。例如用户名只能以字母和数字组合，手机号码只能有 11 位且全部为数字，否则即为非法。这些格式检查类似于白名单效果，限制输入允许的字符，让一下特殊字符的攻击失效。
（2）输出时：对单引号，双引号，尖括号等转化为HTML实体。
三、csrf
1、原理
CSRF（Cross-Site Request Forgery，跨站点伪造请求）是一种网络攻击方式，该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在未授权的情况下执行在权限保护之下的操作，具有很大的危害性。
2、如何确认一个web系统纯在CRSF漏洞
（1）对目标网站增删查改的地方进行标记，并观察其逻辑，判断是否可以被伪造
–比如修改管理员账号时，并不需要验证旧密码，导致请求容易被伪造；
–比如对于敏感信息的修改并没有使用安全的token验证，导致请求容易被伪造；
（2）确认凭证的有效日期（这个问题会提高CRSF被利用的概率）
–虽然退出并关闭了浏览器，但cookie仍然有效，或者session并没有及时过期，导致CRSF攻击变的简单。
3、防御措施
（1）验证HTTP Referer字段
（2）在请求地址中添加token并验证，后端生成token发送到前端，前端提交到后端在进行验证。
（3）在HTTP头中自定义属性并验证
（4）在服务端区严格区分好POST与GET的数据请求（建议不要使用GET请求进行持久性操作）
（5）使用验证码或者密码确认方式进行
四、SQL注入
1、概述
2、形成原因
什么是SQL注入攻击
攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。
用户登录，输入用户名 lianggzone，密码 ‘ or ‘1’=’1 ，如果此时使用参数构造的方式，就会出现
select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’
不管用户名和密码是什么内容，使查询出来的用户列表不为空。如何防范SQL注入攻击使用预编译的PrepareStatement是必须的，但是一般我们会从两个方面同时入手。
Web端
1）有效性检验。
2）限制字符串输入的长度。
服务端
1）不用拼接SQL字符串。
2）使用预编译的PrepareStatement。
3）有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)
4）过滤SQL需要的参数中的特殊字符。比如单引号、双引号。
五、RCE
1、RCE(remote command/code execute)概述
RCE漏洞，可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。
远程系统命令执行
一般出现这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口。
比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，后台会对该IP地址进行一次ping测试，并返回测试结果，而，如果设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，从而让后台进行执行，从而控制整个后台服务器。
比如：127.0.0.1 & ipconfig
现在很多的甲方企业都开始实施自动化运维,大量的系统操作会通过"自动化运维平台"进行操作。在这种平台上往往会出现远程系统命令执行的漏洞,不信的话现在就可以找你们运维部的系统测试一下,会有意想不到的"收获"。
shell_exec() 用于执行用户传输的命令
远程代码执行
同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。
因此，如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断，比如实施严格的白名单策略会是一个比较好的方法。
eval() 用于执行用户传输的代码
六、文件包含漏洞
1、概述
文件包含，是一个功能。在各种开发语言中都提供了内置的文件包含函数，其可以使开发人员在一个代码文件中直接包含（引入）另外一个代码文件。
比如 在PHP中，提供了：
include(),include_once()
require(),require_once()
include和require语法是相同的，除了错误处理方面：
- require会生成指明错误（E_COMPLIE_ERROR）并停止脚本；
- include只会生成警告（E_WARNING），并且脚本会继续；
这些文件包含函数，这些函数在代码设计中被经常使用到。
大多数情况下，文件包含函数中包含的代码文件是固定的，因此也不会出现安全问题。但是，有些时候，文件包含的代码文件被写成了一个变量，且这个变量可以由前端用户传进来，这种情况下，如果没有做足够的安全考虑，则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行，从而造成恶意操作。根据不同的配置环境，文件包含漏洞分为如下两种情况：
**1.本地文件包含漏洞：**仅能够对服务器本地的文件进行包含，由于服务器上的文件并不是攻击者所能够控制的，因此该情况下，攻击着更多的会包含一些固定的系统配置文件，从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞，从而形成更大的威力。
防护措施：设置白名单（if函数用"||"的方式设置）
**2.远程文件包含漏洞：**能够通过url地址对远程的文件进行包含，这意味着攻击者可以传入任意的代码，这种情况没啥好说的，准备挂彩。因此，在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数，如果非要这么做，也一定要做严格的白名单策略进行过滤。
前提：需要php.ini配置如下
allow_url_fopen = on //默认打开
Allow_url_include = on //默认关闭
危害：可直接传输比如一句话木马等文件，导致客户机被控制。
2、防范措施
（1）在功能设计上尽量不要将文件包含函数对应的文件放给全段进行选择和操作；
（2）过滤各种…/…/, http:// , https://
（3）配置php.ini配置文件
allow_url_fopen=off
allow_url_include=off
magic_quotes_gpc=on //gpc在
（4）通过白名单策略，进允许包含运行指定的文件，其他的都禁止；
七、不安全的文件下载和文件上传
1、文件下载
很多网站都会提供文件下载的功能，即用户可以点击下载链接，下载到链接所对应的文件。但是如果文件下载功能不当，则可能导致攻击者可以通过构造文件路径，从未获取到后台服务器上的其他敏感文件（又称：任意文件下载）。
防范措施
（1）对传入的文件名进行严格的过滤和限定
（2）对文件下载的目录进行严格的限定
2、文件上传
因为业务功能需求，很多web站点都有文件上传的接口，比如：
（1）注册时上传头像图片（比如jpg，png，gif等）；
（2）上传文件附件（doc，xsl等）；
而在后台开发时并没有对文件上传的文件功能进行安全考虑或者采用了有缺陷的措施，导致攻击者可以通过一些手段绕过安全措施从而上传一些恶意文件（如：一句话木马）。从而通过对该恶意文件的访问；来控制整个web后台。
3、文件上传漏洞测试流程
（1）对文件上传的地方按照要求上传文件，查看返回结果（路径，提示等）
（2）尝试上传不同类型的"恶意"文件，比如xx.php文件，分析结果；
（3）查看html源码，看是否通过js在前端做了上传限制，可以绕过；
（4）尝试使用不同的方式进行绕过；黑白名单绕过/MIME类型绕过/目录0x00截断绕过等；
（5）猜测或者结合其他漏洞（比如敏感信息泄露）得到木马路径，连接测试
防范措施
（1）不在前端使用js实施上传策略
（2）通过服务器对文件上传进行限制
进行多条组合检查：比如文件的大小，路径，拓展名，文件类型，文件完整性，或者设置文件后缀白名单。
对上传的文件在服务器存储是进行重命名（指定合理的命名规则）
对服务器上传文件的目录进行权限控制（比如只读），限制执行去权限带来的危害。
八、越权漏洞
由于没有对用户权限进行严格判断，导致低权限的账户（比如普通用户）可以去完成高权限账号（比如超级管理员）范围内的操作。
1、水平越权
A用户和B用户属于同一级别用户，但各自不能操作对方个人信息，A用户如果越权操作B用户的个人信息的情况称为平行越权操作。
2、垂直越权
A用户权限高于B用户，B用户越权操作A用户权限的情况称为垂直越权。
3、修复建议
- 验证一切来自客户端的参数，重点是和权限相关的参数，比如用户ID或者角色权限ID等。
- session ID 和认证的token做绑定，放在服务器的会话里，不发送给客户端。
- 对于用户登录后涉及用户唯一信息的请求，每次都要验证检查所有权，敏感信息页面加随机数的参数，防止浏览器缓存内容。
- 把程序分成匿名，授权和管理的区域，通过将角色和数据功能匹配。
- 不适用参数来区分管理员和普通用户。
九、PHP反序列化
1、序列化serialize()
序列化说通俗点就是把一个对象变成可以传输的字符串,比如下面是一个对象:
class S{
public $test="pikachu";
}
$s=new S(); //创建一个对象
serialize($s); //把这个对象进行序列化
序列化后得到的结果是这个样子的:O:1:"S":1{s:4:"test";s:7:"pikachu";}
O:代表object
1:代表对象名字长度为一个字符
S:对象的名称
1:代表对象里面有一个变量
s:数据类型
4:变量名称的长度
test:变量名称
s:数据类型
7:变量值的长度
pikachu:变量值
2、反序列化unserialize()
就是把被序列化的字符串还原为对象,然后在接下来的代码中继续使用。
$u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}");
echo $u->test; //得到的结果为pikachu
常见的几个魔法函数:
__construct()当一个对象创建时被调用
__destruct()当一个对象销毁时被调用
__toString()当一个对象被当作一个字符串使用
__sleep() 在对象在被序列化之前运行
__wakeup将在序列化之后立即被调用
漏洞举例:
class S{
var $test = "pikachu";
function __destruct(){
echo $this->test;
}
}
$s = $_GET['test'];
@$unser = unserialize($a);
payload:O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
十、xee漏洞
1、概述
“xml外部实体注入漏洞”。
概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"，也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
2、防范措施
1.使用开发语言提供的禁用外部实体的方法
2.过滤用户提交的XML数据
关键词：<!DOCTYPE和<!ENTITY，或者，SYSTEM和PUBLIC。
十一、ssrf漏洞
1、概述
SSRF(Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。利用拥有权限的服务器，对没有权限的服务器进行攻击。
2、防护措施
1、过滤返回的信息，如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
2、统一错误信息，避免用户可以根据错误信息来判断远程服务器的端口状态。
3、限制请求的端口，比如80,443,8080,8090。
4、禁止不常用的协议，仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp://等引起的问题。
5、使用DNS缓存或者Host白名单的方式。
十二、目录遍历（…/…/）
1、概述
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“…/”这样的手段让后台打开或者执行一些其他的文件。从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。
十三、敏感信息泄露
由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。
比如：
—通过访问url下的目录，可以直接列出目录下的文件列表;
—输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
—前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。
十四、url重定向
1、概述
不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话就可能发生"跳错对象"的问题。
2、危害
–>钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站。
3、预防措施
白名单限制
目录，可以直接列出目录下的文件列表;
—输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
—前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。
十四、url重定向
1、概述
不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话就可能发生"跳错对象"的问题。
2、危害
–>钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站。
3、预防措施
白名单限制
