常见漏洞原理及修复方式

漏洞原理及防护

Burte Force（暴力破解）

在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
防御：
1.是否要求用户设置复杂的密码；
2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4.是否采用了双因素认证；

XSS（跨站脚本攻击）

Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。通过将精心构造的代码注入到网页中，并且有浏览器解释执行，以达到恶意攻击的效果。（xss漏洞一般发生在服务器）
一般XSS可以分为如下几种常见类型：
1.反射性XSS;
2.存储型XSS;
3.DOM型XSS;
XSS是一种发生在前端浏览器端的漏洞，所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因：
是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
XSS危害：
盗取取用户账户，
窃取用户cookie资料冒充用户登录
劫持会话
刷流量
传播蠕虫病毒
防御修补：
因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入点：使用filter过滤敏感字符或进行编码转义对特定结构类型的数据进行格式检查，针对输入点的检查最好放在服务器。
输出点：对输出到html页面中的信息进行编码转义，如（HTMLEncode）如果输出在Javascript脚本中时进行javascriptEncode。对使用javascript变量都放在引号中并转义危险字符，data 部分就无法逃逸出引号外成为 code 的 一部分。还可以使用更加严格的方法，对所有数字字母之外的字符都使用十六进制编码。此外，要注 意在浏览器中，HTML 的解析会优先于 Javascript 的解析，编码的方式也需要考虑清楚，针对不同的 输出点，我们防御 XSS 的方法可能会不同。
此外还可以做HTTPonly 或者对COOKIE劫持做限制。
XSS的检测：
反射型XSS：反射性通常诱导用户点击我们构造好的恶意payload才会触发，反射性xss的检测在我们每次请求带payload带payload连接时页面会带有特定的畸形数据的
DOM型XSS：
人工检测：找到类似的document.write，innerHTML赋值，window.location操作，写javascript后内容eval，settimeout等直接执行的函数。找到其变量，回溯变量来源，是否经过安全函数。
自动化检测：思路是从变量入手，观察变量传递过程，检查是否存在危险函数输出，或者是否经过安全函数，

CSRF(跨站请求伪造）

Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。

CSRF与XSS的区别：
CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。
防御：
–对敏感信息的操作增加安全的token；
–对敏感信息的操作增加安全的验证码；
–对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等；

SSRF(Server-Side Request Forgery:服务器端请求伪造)

其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据
数据流:攻击者----->服务器---->目标地址
PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
防御：
–过滤返回信息
–统一错误信息
–限制请求端口
–禁用不常用的协议
–使用DNS缓存或者host名单
–如果一定要通过后台服务器远程去对用户指定(“或者预埋在前端的请求”)的地址进行资源请求,则请做好目标地址的过滤。

Sql Inject(SQL注入)

由于程序在处理数据和程序交互时使用了字符串拼接，且没有对用户输入做过滤

防御：
对用户输入进行转义
限制关键字输入
使用SQL语句预处理，对SQl语句进行预编译，然后进行参数绑定，最后传入参数

RCE(远程命令执行)

可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。
远程系统命令执行：
一般出现这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口
比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上 一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，后台会对该IP地址进行一次ping测试，并返回测试结果。 而，如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，从而让后台进行执行，从而控制整个后台服务器
防御:
如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断，比如实施严格的白名单策略会是一个比较好的方法。

File Inclusion(文件包含漏洞)

在PHP中，提供了：nclude(),include_once() require(),require_once()这些文件包含函数，这些函数在代码设计中被经常使用到。
大多数情况下，文件包含函数中包含的代码文件是固定的，因此也不会出现安全问题。 但是，有些时候，文件包含的代码文件被写成了一个变量，且这个变量可以由前端用户传进来，这种情况下，如果没有做足够的安全考虑，则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行，从而造成恶意操作。 根据不同的配置环境，文件包含漏洞分为如下两种情况：
1.本地文件包含漏洞：仅能够对服务器本地的文件进行包含，由于服务器上的文件并不是攻击者所能够控制的，因此该情况下，攻击着更多的会包含一些 固定的系统配置文件，从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞，从而形成更大的威力。
2.远程文件包含漏洞：能够通过url地址对远程的文件进行包含，这意味着攻击者可以传入任意的代码，这种情况没啥好说的，准备挂彩。
防御：
在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数，如果非要这么做，也一定要做严格的白名单策略进行过滤。
关闭allow_url_open

不安全的文件

文件上传功能在web应用系统很常见，比如很多网站注册的时候需要上传头像、上传附件等等。当用户点击上传按钮后，后台会对上传的文件进行判断 比如是否是指定的类型、后缀名、大小等等，然后将其按照设计的格式进行重命名后存储在指定的目录。 如果说后台对上传的文件没有进行任何的安全判断或者判断条件不够严谨，则攻击着可能会上传一些恶意的文件，比如一句话木马，从而导致后台服务器被webshell。
防御:
–验证文件类型、后缀名、大小;
–验证文件的上传方式;
–对文件进行一定复杂的重命名;
–不要暴露文件上传后的路径;

不安全的文件下载

文件下载功能在很多web系统上都会出现，一般我们当点击下载链接，便会向后台发送一个下载请求，一般这个请求会包含一个需要下载的文件名称，后台在收到请求后 会开始执行下载代码，将该文件名对应的文件response给浏览器，从而完成下载。 如果后台在收到请求的文件名后,将其直接拼进下载文件的路径中而不对其进行安全判断的话，则可能会引发不安全的文件下载漏洞。
此时如果 攻击者提交的不是一个程序预期的的文件名，而是一个精心构造的路径(比如…/…/…/etc/passwd),则很有可能会直接将该指定的文件下载下来。 从而导致后台敏感信息(密码文件、源代码等)被下载。
防御：
过滤（.）使的用户不能回溯到上级目录
正则表达式验证用户出入的格式
php.ini配置open——basedir限制文件范围

越权

如果使用A用户的权限去操作B用户的数据，A的权限小于B的权限，如果能够成功操作，则称之为越权操作。 越权漏洞形成的原因是后台使用了 不合理的权限校验规则导致的。
一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对 对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞。
防御：
1.使用最小权限原则对用户进行赋权;
2.使用合理（严格）的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;

目录遍历

在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。 在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“…/”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。

敏感信息泄露概述

由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。 比如：
—通过访问url下的目录，可以直接列出目录下的文件列表;
—输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
—前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。

PHP反序列化漏洞

为了方便存取，web程序通常将对象通过serliaize（）函数(序列化说通俗点就是把一个对象变成可以传输的字符串将类对象变成数组存储)反序列就是使用的unserialize()把被序列化的字符串还原为对象,然后在接下来的代码中继续使用。序列化和反序列化本身没有问题,但是如果反序列化的内容是用户可以控制的,且后台不正当的使用了PHP中的魔法函数,就会导致安全问题
常见的几个魔法函数:
__construct()当一个对象创建时被调用

    __destruct()当一个对象销毁时被调用

    __toString()当一个对象被当作一个字符串使用

    __sleep() 在对象在被序列化之前运行

    __wakeup将在序列化之后立即被调用

xml外部实体注入漏洞

概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
具体的关于xml实体的介绍,网络上有很多,自己动手先查一下。
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。
以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。

不安全的url跳转

不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。
如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话就可能发生"跳错对象"的问题。

url跳转比较直接的危害是:
–>钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站