文章目录
前言
处于现在这个互联网时代，一些在web开发中常见的漏洞我也必须重视起来，比如下面我介绍的第一个问题sql注入问题。
如果这个问题我们不注意，那我们的数据可能是有风险全部暴露出去的，而且导致这个问题还很简单，只需要在select上增加一个or 1=1 即可。
SQL 注入
SQL 注入就是通过给 web 应用接口传入一些特殊字符，达到欺骗服务器执行恶意的 SQL 命令。
SQL 注入漏洞属于后端的范畴，但前端也可做体验上的优化。
核心原因就是当使用外部不可信任的数据作为参数进行数据库的增、删、改、查时，如果未对外部数据进行过滤，就会产生 SQL 注入漏洞。
因为由于 SQL 语句是直接拼接的，也没有进行过滤，所以，当用户输入 ‘’ or ‘1’=‘1’ 时，这个语句的功能就是搜索 users 全表的记录。
select * from users where name='' or '1'='1';
具体的解决方案很多，但大部分都是基于一点：不信任任何外部输入，不将外部输入作为条件，只能作为数据。
所以，对任何外部输入都进行过滤，然后再进行数据库的增、删、改、查。
防御方式
- 数据校验
将所输入的数据进行校验，检查输入的数据是否具有所期望的数据格式。
或者设置数据黑名单，非法字段就不能接收。
- 权限限制
严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害。**请记住永远不要使用超级用户或所有者帐号去连接数据库！**当数据库被攻击时将损伤限制在当前表的范围是比较明智的选择。
- 日志处理
当数据库操作失败的时候，尽量不要将原始错误日志返回，比如类型错误、字段不匹配等，把代码里的 SQL 语句暴露出来，以防止攻击者利用这些错误信息进行 SQL 注入。除此之外，在允许的情况下，使用代码或数据库系统保存查询日志也是一个好办法。
CSRF 攻击
CSRF 攻击全称跨站请求伪造，简单的说就是攻击者盗用了你的身份，以你的名义发送恶意请求。
一个典型的 CSRF 攻击有着如下的流程：
- 受害者登录 a.com，并保留了登录凭证（Cookie）
- 攻击者引诱受害者访问了 b.com
- b.com 向 a.com 发送了一个请求：a.com/act=xx（浏览器会默认携带 a.com 的 Cookie）
- a.com 接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
- a.com 以受害者的名义执行了 act=xx
- 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作
CSRF的特点
攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。
防御方式
CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。
所以防止 CSRF 攻击需要在服务器端入手，基本的思路是能正确识别是否是用户发起的请求。
上文中讲了CSRF的两个特点：
- CSRF（通常）发生在第三方域名。
- CSRF攻击者不能获取到Cookie等信息，只是使用。
针对这两点，我们可以专门制定防护策略，如下：
阻止不明外域的访问
同源检测
既然CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。
那么问题来了，我们如何判断请求是否来自外域呢？
在HTTP协议中，每一个异步请求都会携带Header，用于标记来源域名：
使用Origin Header确定来源域名
这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。
服务器可以通过解析这两个Header中的域名，确定请求的来源域。
附加本域
- CSRF Token
1.将CSRF Token输出到页面中
首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。因此，为了安全起见Token最好还是存在服务器的Session中，之后在每次页面加载时，使用JS遍历整个DOM树，对于DOM中所有的a和form标签中的url后面加入Token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的HTML代码，这种方法就没有作用，还需要程序员在编码时手动添加Token。
当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。
这种方法要比之前检查Origin要安全一些，Token可以在产生并放于Session之中，然后在每次请求时把Token从Session中拿出，与请求中的Token进行比对，但这种方法的比较麻烦的在于如何把Token以参数的形式加入请求。
- 双重Cookie验证
在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。
在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
DDoS 攻击
DoS 攻击全称拒绝服务，简单的说就是让一个公开网站无法访问，而 DDoS 攻击（分布式拒绝服务 Distributed Denial of Service）是 DoS 的升级版。
原因
攻击者不断地提出服务请求，让合法用户的请求无法及时处理，这就是 DoS 攻击。
攻击者使用多台计算机或者计算机集群进行 DoS 攻击，就是 DDoS 攻击。
防御方式
防止 DDoS 攻击的基本思路是限流，限制单个用户的流量（包括 IP 等）。
IP限流
对单个IP的大量请求做限流。但是这个只能有效解决DOS攻击，对于DDoS不友好。
分布式集群防御
这是目前网络安全界防御大规模DDoS攻击的最有效办法。分布式集群防御的特点是在每个节点服务器配置多个IP地址，并且每个节点能承受不低于10G的DDoS攻击，如一个节点受攻击无法提供服务，系统将会根据优先级设置自动切换另一个节点，并将攻击者的数据包全部返回发送点，使攻击源成为瘫痪状态，从更为深度的安全防护角度去影响企业的安全执行决策。
IP轮询技术
对稳定性、流畅性以及安全性上要求较高的业务，用户遭受 DDoS 攻击且达到一定峰值时，系统通过 IP 轮询机制，将从IP 池中灵活调取一个新的 IP 充当业务 IP，使攻击者失去攻击目标，以此保证业务在 DDoS 的攻击下正常运转。
SYN Flood 攻击
TCP连接洪水攻击是在连接创建阶段对TCP资源进行攻击的。
在三次握手进行的过程中，服务器会创建并保存TCP连接的信息，这个信息通常被保存在连接表结构中，但是，连接表的大小是有限的，一旦服务器接收到的连接数量超过了连接表能存储的数量，服务器就无法创建新的TCP连接了。攻击者可以利用大量受控主机，通过快速建立大量恶意的TCP连接占满被攻击目标的连接表，使目标无法接受新的TCP连接请求，从而达到拒绝服务攻击的目的。
SYN洪水攻击就是攻击者利用受控主机发送大量的TCP SYN报文，使服务器打开大量的半开连接，占满服务器的连接表，从而影响正常用户与服务器建立会话，造成拒绝服务。
在连接超时之前，半开连接会一直保存在服务器的连接表中。
由于连接表的大小是有限的，如果在短时间内产生大量的半开连接，而这些连接又无法很快的结束，连接表就会很快被占满，导致新的连接TCP连接无法建立。
解决思路
- 将SYN报文的源IP地址随机伪造其他主机的IP地址或者不存在的IP地址，这样攻击目标将会应答发送给被伪造的IP地址，从而占用连接资源并隐藏攻击来源。
- 使用代理服务器建立连接
- 使用token来进行三次握手的可靠关系建立。
暴力破解
这个一般针对密码而言，弱密码（Weak Password）很容易被别人（对你很了解的人等）猜到或被破解工具暴力破解。
防御方式
密码复杂度要足够大，也要足够隐蔽
限制尝试次数
信息泄露
由于 Web 服务器或应用程序没有正确处理一些特殊请求，泄露 Web 服务器的一些敏感信息，如用户名、密码、源代码、服务器信息、配置信息等。
- 所以一般需注意：
应用程序报错时，不对外产生调试信息
过滤用户提交的数据与特殊字符
保证源代码、服务器配置的安全