常见漏洞简介 防御建议
Burt Force(暴力破解漏洞)
概述：连续性尝试+字典+自动化（攻击者在不知道目标账号和密码的情况下进行尝试性的登录，在这个尝试的过程中，会使用一些自动化的工具和一个特定的字典，比如一个账号密码库，实现一个高效的自动化的连续的尝试性登录，从而得到一些有效的账户和密码）
字典：一个有效的字典可以大大的提高暴力破解的效率
常用的账号密码（弱口令）
互联网上被脱裤后账号密码（社工库）
使用指定的字符使用工具按照指定的规则进行排列组合算法生成密码
如果一个网站没有对登录接口实施防暴力破解的措施，或者实施了不合理的措施。则该网站存在暴力破解漏洞。
防暴力破解的措施：是否要求用户设置了复杂的密码；是否每次认证都使用安全的验证码；是否对尝试登录的行为进行判断和限制；是否在必要的情况下采取了双因素认证等等。
XSS(跨站脚本漏洞)
存储型XSS：存储型XSS，持久化，代码是存储在服务器中的，如在个人信息或发表文章等地方，插入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种XSS比较危险，容易造成蠕虫，盗窃cookie
反射型XSS：非持久化，需要欺骗用户自己去点击链接才能触发XSS代码（服务器中没有这样的页面和内容），一般容易出现在搜索页面。反射型XSS大多数是用来盗取用户的Cookie信息。
DOM型XSS：不经过后端，DOM-XSS漏洞是基于文档对象模型(Document Objeet Model,DOM)的一种漏洞，DOM-XSS是通过url传入参数去控制触发的，其实也属于反射型XSS。
可能触发DOM型XSS的属性：
document.referer
window.name
location
innerHTML
documen.write
XSS的攻击载荷
以下所有标签的 > 都可以用 // 代替， 例如 <script>alert(1)</script//
<script>标签：<script>标签是最直接的XSS有效载荷，脚本标记可以引用外部的JavaScript代码，也可以将代码插入脚本标记中 <script>alert("hack")</script> #弹出hack <script>alert(/hack/)</script> #弹出hack <script>alert(1)</script> #弹出1，对于数字可以不用引号 <script>alert(document.cookie)</script> #弹出cookie <script src=http://xxx.com/xss.js></script> #引用外部的xss svg标签 <svg onload="alert(1)"> <svg onload="alert(1)"// <img>标签： <img src=1 οnerrοr=alert("hack")> <img src=1 οnerrοr=alert(document.cookie)> #弹出cookie <body>标签： <body οnlοad=alert(1)> <body οnpageshοw=alert(1)> video标签: <video οnlοadstart=alert(1) src="/media/hack-the-planet.mp4" /> style标签： <style οnlοad=alert(1)></style>
三、XSS可以插在哪里？
用户输入作为script标签内容
用户输入作为HTML注释内容
用户输入作为HTML标签的属性名
用户输入作为HTML标签的属性值
用户输入作为HTML标签的名字
直接插入到CSS里
最重要的是，千万不要引入任何不可信的第三方JavaScript到页面里！
#用户输入作为HTML注释内容，导致攻击者可以进行闭合绕过
<!-- 用户输入 -->
<!-- --><script>alert('hack')</script><!-- -->
#用户输入作为标签属性名，导致攻击者可以进行闭合绕过
<div 用户输入="xx"> </div>
<div ></div><script>alert('hack')</script><div a="xx"> </div>
#用户输入作为标签属性值，导致攻击者可以进行闭合绕过
<div id="用户输入"></div>
<div id=""></div><script>alert('hack')</script><div a="x"></div>
#用户输入作为标签名，导致攻击者可以进行闭合绕过
<用户输入 id="xx" />
<><script>alert('hack')</script><b id="xx" />
#用户输入作为CSS内容，导致攻击者可以进行闭合绕过
<style>用户输入<style>
<style> </style><script>alert('hack')</script><style> </style>
CSRF(跨站请求伪造)
攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等
1. GET型：
如果一个网站某个地方的功能，比如用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&email=123@163.com ，这个链接的意思是用户id=1将邮箱修改为123@163.com。当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ，然后通过各种手段发送给被攻击者，诱使被攻击者点击我们的链接，当用户刚好在访问这个网站，他同时又点击了这个链接，那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了
2.POST型：
在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常，但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。比如：/coures/user/handler/25332/buy.php 。通过提交表单，buy.php处理购买的信息，这里的25532为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容
<form action=/coures/user/handler/25332/buy method=POST>
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script>
当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为25332的视频，从而导致受害者余额扣除
CSRF攻击的防御
验证 HTTP Referer 字段
在请求地址中添加 token 并验证(Anti-CSRF token)
在 HTTP 头中自定义属性并验证
SQL-Inject(SQL注入漏洞)
SQL注入漏洞是Web层面最高位的漏洞之一。所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令，比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击。当应用程序使用输入内容来构造动态sql语句以访问数据库时，会发生sql注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生sql注入。 黑客通过SQL注入攻击可以拿到网站数据库的访问权限，之后他们就可以拿到网站数据库中所有的数据，恶意的黑客可以通过SQL注入功能篡改数据库中的数据甚至会把数据库中的数据毁坏掉。
SQL注入漏洞原理：程序开发过程中，由于不重视书写规范，对sql关键字未进行过滤，导致客户端可以通过POST或GET提交sql语句到服务器端正常运行。SQL注入就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。
防御：
永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对特殊字符和符号进行转换等。
永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。
永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。
应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。
RCE(远程命令/代码执行)
RCE漏洞，可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。一般出现这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口。比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上。一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，后台会对该IP地址进行一次ping测试，并返回测试结果。 如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，从而让后台进行执行，从而控制整个后台服务器。
系统命令执行函数
system()
passthru()
exec()
shell_exec()
popen()
proc_open()
pcntl_exec()
windows系统命令拼接方式
“|”:管道符，前面命令标准输出，后面命令的标准输入。例如：help |more
“&” commandA & commandB 先运行命令A，然后运行命令B
“||” commandA || commandB 运行命令A，如果失败则运行命令B
“&&” commandA && commandB 运行命令A，如果成功则运行命令B
防御
尽量不要使用命令执行函数。
不要让用户控制参数。
执行前做好检测和过滤。
Files Inclusion(文件包含漏洞)
文件包含，是一个功能。在各种开发语言中都提供了内置的文件包含函数，其可以使开发人员在一个代码文件中直接包含（引入）另外一个代码文件。 比如 在PHP中，提供了：
include(),include_once()
require(),require_once()
这些文件包含函数，这些函数在代码设计中被经常使用到。大多数情况下，文件包含函数中包含的代码文件是固定的，因此也不会出现安全问题。 但是，有些时候，文件包含的代码文件被写成了一个变量，且这个变量可以由前端用户传进来，这种情况下，如果没有做足够的安全考虑，则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行，从而造成恶意操作。 根据不同的配置环境，文件包含漏洞分为本地文件包含漏洞和远程文件包含漏洞。
本地文件包含漏洞：仅能够对服务器本地的文件进行包含，由于服务器上的文件并不是攻击者所能够控制的，因此该情况下，攻击着更多的会包含一些 固定的系统配置文件，从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞，从而形成更大的威力。
我们通过改变URL来进行测试。首先我们要确定后台系统是windows还是linux系统。如果目标服务器在 Linux 上，则可以用“../”的方式进行目录跳转， ../../../../../../../../etc/passwd
如果是windows操作系统的话，则可以利用 ../../../../Windows/System32/drivers/etc/hosts
远程文件包含漏洞：能够通过URL地址对远程的文件进行包含，这意味着攻击者可以传入任意的代码。因此，在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数，如果非要这么做，也一定要做严格的白名单策略进行过滤。
防范措施：
在功能设计上尽量不要将文件包含函数对应的文件放给前端进行选择和操作。
过滤各种../../，http://，https://
配置php.ini配置文件：
allow_url_fopen = off
allow_url_include=off
magic_quotes_gpc=on
通过白名单策略，仅允许包含运行指定的文件，其他的都禁止。
Unsafe file downloads(不安全的文件下载)
不安全的文件下载概述
文件下载功能在很多web系统上都会出现，一般我们当点击下载链接，便会向后台发送一个下载请求，一般这个请求会包含一个需要下载的文件名称，后台在收到请求后 会开始执行下载代码，将该文件名对应的文件response给浏览器，从而完成下载。 如果后台在收到请求的文件名后,将其直接拼进下载文件的路径中而不对其进行安全判断的话，则可能会引发不安全的文件下载漏洞。
此时如果 攻击者提交的不是一个程序预期的的文件名，而是一个精心构造的路径(比如../../../etc/passwd),则很有可能会直接将该指定的文件下载下来。 从而导致后台敏感信息(密码文件、源代码等)被下载。
所以，在设计文件下载功能时，如果下载的目标文件是由前端传进来的，则一定要对传进来的文件进行安全考虑。 切记：所有与前端交互的数据都是不安全的，不能掉以轻心！
不安全的文件上传漏洞概述
文件上传功能在web应用系统很常见，比如很多网站注册的时候需要上传头像、上传附件等等。当用户点击上传按钮后，后台会对上传的文件进行判断 比如是否是指定的类型、后缀名、大小等等，然后将其按照设计的格式进行重命名后存储在指定的目录。 如果说后台对上传的文件没有进行任何的安全判断或者判断条件不够严谨，则攻击着可能会上传一些恶意的文件，比如一句话木马，从而导致后台服务器被webshell。
所以，在设计文件上传功能时，一定要对传进来的文件进行严格的安全考虑。比如：
--验证文件类型、后缀名、大小;
--验证文件的上传方式;
--对文件进行一定复杂的重命名;
--不要暴露文件上传后的路径;
--等等...
Over Permisson(越权漏洞)
如果使用A用户的权限去操作B用户的数据，A的权限小于B的权限，如果能够成功操作，则称之为越权操作。 越权漏洞形成的原因是后台使用了 不合理的权限校验规则导致的。
一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对 对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应。
如果校验的规则过于简单则容易出现越权漏洞。
因此，在在权限管理中应该遵守：
1.使用最小权限原则对用户进行赋权;
2.使用合理（严格）的权限校验规则;
3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;
../../../(目录遍历)
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。 在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“../”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。
看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载，甚至文件包含漏洞有差不多的意思，是的，目录遍历漏洞形成的最主要的原因跟这两者一样，都是在功能设计中将要操作的文件使用变量的 方式传递给了后台，而又没有进行严格的安全考虑而造成的，只是出现的位置所展现的现象不一样，因此，这里还是单独拿出来定义一下。
需要区分一下的是,如果你通过不带参数的url（比如：http://xxxx/doc）列出了doc文件夹里面所有的文件，这种情况，我们成为敏感信息泄露。 而并不归为目录遍历漏洞。（关于敏感信息泄露你你可以在"i can see you ABC"中了解更多）
敏感信息泄露概述
由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。 比如：
--通过访问url下的目录，可以直接列出目录下的文件列表;
---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
---前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。
因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。
点击链接在url中传递的参数是文件名，可以利用../../更改文件名来访问文件
在网站源码中发现账号密码也可利用目录扫描工具来找到文件名
I can see your ABC(敏感信息泄露)
由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。 比如：
---通过访问url下的目录，可以直接列出目录下的文件列表;
---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;
---前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;
类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。
PHP反序列化漏洞
序列化就是将一个对象转换成字符串。字符串包括，属性名，属性值，属性类型和该对象对应的类名。
反序列化则相反将字符串重新恢复成对象
unserialize()反序列化函数用于将单一的已序列化的变量转换回 PHP 的值。
当反序列化参数可控时，可能会产生PHP反序列化漏洞。
在反序列化中，我们所能控制的数据就是对象中的各个属性值，所以在PHP的反序列化中有一种漏洞利用方法叫做 “面向属性编程”，面向对象编程从一定程度上来说，就是完成类与类之间的调用。POP链起于一些小的“组件”，这些小“组件”可以调用其他的“组件”在PHP中，“组件”就是那些魔术方法（如：wakeup()或destruct）
未对用户输入的序列化字符串进行检测，导致攻击者可以控制反序列化过程，从而导致代码执行，SQL注入，目录遍历等不可控后果。
和大多数漏洞一样，反序列化的问题也是用户参数的控制问题引起的，所以好的预防措施就是不要把用户的输入或者是用户可控的参数直接放进反序列化的操作中去。
XXE(XML External Entity attack)
XML 外部实体注入（也称为 XXE）是一种 Web 安全漏洞，允许攻击者干扰应用程序对 XML 数据的处理。它通常允许攻击者查看应用程序服务器文件系统上的文件，并与应用程序本身可以访问的任何后端或外部系统进行交互。
在某些情况下，攻击者可以利用 XXE 漏洞联合执行服务器端请求伪造(SSRF) 攻击，从而提高 XXE 攻击等级以破坏底层服务器或其他后端基础设施。
XXE漏洞发生在应用程序解析XML输入时，没有禁止外部实体的加载，导致可加载恶意外部文件和代码，造成任意文件读取、命令执行、内网端口扫描、攻击内网网站、发起Dos攻击等危害。
XXE漏洞触发的点往往是可以上传xml文件的位置，没有对上传的xml文件进行过滤，导致可上传恶意xml文件
特征1 --- url后缀是 .ashx
特征2 --- 响应体是xml
防御：使用开发语言提供的禁用外部实体的方法;
过滤用户提交的XML数据;
不允许XML中含有自己定义的DTD;
不安全的URL重定向
恶意url跳转的问题 像这种情况下，我们后台一定要做这种重定向功能的设计，那我们需要对url做一个白名单的限制，比如说，我们跳转的是自己的页面，或者固定的网站，我们可以在前面写个方法来判断，传进来的url符不符合我们的要求，如果不符合，我就把它拒绝掉，如果符合，我才进行跳转，这样做是比较合适的做法，那如果不做任何判断，就会造成恶意url跳转的问题，从而导致这个网站会被人拿去做钓鱼
部分参考：
https://zhuanlan.zhihu.com/p/397940947
https://blog.csdn.net/m0_54899775/article/details/123647834
