CSRF/XSRF(跨站请求伪造)
攻击者通过跨站请求，以合法的用户身份进行非法操作
攻击原理
1.主要归结于浏览器同源策略限制级别的问题。
2.对于Cookie，DOM和XMLHttpRequest（ajax）所有浏览器都会严格遵守同源策略。但是也有例外，如'img'标签，"script"标签，"iframe"标签等的链接会自动加载，更重要的是，表单提交也是可以跨域。
正是因为这些html标签和表单提交的可以跨域问题，一些黑产在恶意站点设置了在用户不感知的情况下发起其他站点的请求，比如用户登录了某支付网站后，不经意点开了某恶意站点，该站点自动请求某支付网站（浏览器会匹配domain和path自动带上了cookie凭证），此时就相当于黑产拿到用户的身份凭证了。
防御措施
表单提交请求CRSF攻击防御
因为表单提交是可以跨域的，所以表单提交的CRSF防御已经成为站点的标配了。原理也很简单，因为表单的提交都要分为两个阶段，表单渲染和表单提交。检查表单提交的表单是否是自己的服务器渲染的即可。
Ajax请求CRSF攻击防御
颁发一个令牌token，放在严格遵循同源策略的媒介上来识别请求是否可信。
解决方案
弃用cookie机制，荐用方案JSON Web Token
SQL注入
攻击原理
利用现有应用程序，将（恶意的）SQL命令注入到后台数据库引擎执行。通过在参数中输入特殊符号，来篡改并通过程序SQL语句的条件判断。
防御措施
被动防御
主流框架已基本可阻止sql注入。
主动防御
- 通过使用静态和动态测试，定期检查并发现应用程序中的SQL注入漏洞。
- 通过使用参数化查询和对象关系映射(Object Relational * Mappers，ORM)，来避免和修复注入漏洞。此类查询通过指定参数的占位符，以便数据库始终将它们视为数据，而非SQL命令的一部分。
- 使用转义字符，来修复SQL注入漏洞，以便忽略掉一些特殊字符。
- 通过对数据库强制执行最小权限原则，来减缓SQL注入漏洞的影响。籍此，应用程序的每一个软件组件都只能访问、并仅影响它所需要的资源。
- 对访问数据库的Web应用程序采用Web应用防火墙(Web Application Firewall，WAF)。这有助于识别出针对SQL注入的各种尝试，进而防止此类尝试作用到应用程序上。
解决方案
使用更加安全的开发框架,提高开发者安全编码意识。
XSS(Cross-Site Scripting,跨站脚本攻击)
攻击原理
恶意代码未经过滤，与网站的正常代码混在一起，浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。由于直接在用户的终端代码执行，恶意代码能够直接获取用户的信息，利用这些信息冒充用户向网站发起攻击请求。
防御措施
入参字符过滤。
在源头控制，把输入的一些不合法的东西都过滤掉，从而保证安全性。如移除用户提交的的DOM属性如onerror，移除用户上传的Style节点，'iframe', 'script'，'a'节点等
HTML转义处理
转义编码参考：
出参进行编码
如果源头没控制好，就得后期补救了：像一些常见的符号，如<>在输出的时候要对其进行转换编码，这样做浏览器是不会对该标签进行解释执行的，同时也不影响显示效果。例如：对<>做编码如："<"用:"<",">"用:">"来代替。
public function processVal($value = null, $type = self::VAL_STRING)
{
if ($value !== null)
switch ($type) {
case self::VAL_STRING:
$value = Html::encode($value);
break;
case self::VAL_INT:
$value = intval($value);
break;
case self::VAL_TEXT:
$value = HtmlPurifier::process($value);
break;
case self::VAL_FLOAT:
$value = floatval($value);
break;
default:
break;
}
}
return $value;
}
越权
越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为Web应用十大安全隐患的第二名。
越权访问分类
垂直越权访问（权限提升攻击）
垂直越权是指不同用户级别之间的越权，如普通用户执行管理员用户的权限。
水平越权访问
水平越权是指相同级别用户之间的越权操作
解决方案
- 对平行越权漏洞防护中，增加访问与操作对象的用户属性，在对目标对象进行访问与操作时，服务端校验会话与对象的用户属性，在校验通过后才能执行读取和操作。
2.对垂直越权漏洞防护中，所有访问采取默认拒绝机制，采取基于角色访问控制，对于各个功能的访问，规定不同角色拥有不同的访问权限，当用户在使用该功能时，系统要校对用户的权限和访问控制机制是否与规定相同，通过校对者才能使用，否则拒绝使用该功能。
短信安全
短信攻击常见于短信接口被恶意利用，导致业务无法正常访问。
短信接口被刷的危害
- 过多的短信接口请求导致服务器负载增加，严重情况下导致服务器资源耗尽，无法响应请求，影响用户正常的访问。
- 过多的短信接口发送，导致正常用户无法使用短信验证服务
- 过多的短信接口非法调用消耗短信包资源，从而直接导致运营成本增加。
通用防护措施
- 手机号码逻辑检测
在手机号码窗口增加号码有效性检测，防止恶意攻击者使用无效或非法的号码，从而在第一窗口屏蔽非手机号的乱码等无效数字。 - 随机校验
在注册页添加个隐藏的'input'，设置保存在session中的随机验证码，发短信前验证一下，保证发验证码短信请求是在业务页面点击。 - 增加友好的图形验证码
即当用户进行“获取动态短信” 操作前，弹出图片验证码，要求用户输入验证码后，服务器端再发送动态短信到用户手机上，该方法可有效缓解短信轰炸问题。
由于当前验证码在攻防对抗中逐步被成功自动化识别破解，我们在选用安全的图形验证码也需要满足一定的防护要求。 - 同号码短信发送频率限制
采用限制重复发送动态短信的间隔时长， 即当单个用户请求发送一次动态短信之后，服务器端限制只有在一定时长之后（此处一般为60-120秒），才能进行第二次动态短信请求。该功能可进一步保障用户体验，并避免包含手工攻击恶 意发送垃圾验证短信。
5. 不同号码请求数量限制
根据业务特点，针对不同手机号码、不同访问源IP访问请求进行频率限制，防止高并发非法请求消耗更多的短信包和服务器性能，提高业务稳定性。 - 场景流程限定
将手机短信验证和用户名密码设置分成两个步骤，用户在填写和校验有效的用户名密码后，下一步才进行手机短信验证，并且需要在获取第一步成功的回执之后才可进行校验。 - 启用https协议
为网站配置证书，启用https加密协议，防止传输明文数据被分析。 - 单IP请求限定
使用了图片验证码后，能防止攻击者有效进行“动态短信”功能的自动化调用。但若攻击者忽略图片验证码验证错误的情况，大量执行请求会给服务器带来额外负担，影响业务使用。建议在服务器端限制单个 IP 在单位时间内的请求次数，一旦用户请求次数(包括失败请求次数)超出设定的阈值，则暂停对该IP一段时间的请求。
短信安全防护
针对同一用户和同一IP短信发送频率限制。
文件上传安全
攻击原理
一些web应用程序中允许上传图片，文本或者其他资源到指定的位置。
文件上传漏洞就是利用网页代码中的文件上传路径变量过滤不严将可执行的文件上传到一个到服务器中，再通过URL去访问以执行恶意代码。
防御措施
- 文件上传之前客户端检验上传文件的大小和类型是否合法，但是该方法可以通过禁用JavaScript的方式绕过。
- 服务端通过检查http包的Content-Type字段中的值来判断上传文件类型是否合法。该方法可以抓包修改的方法绕过。
- 服务端检测上传文件的扩展名来判断文件是否合法，服务端对文件重新命名，且根据文件类型强制修改来源文件的后缀名。
- 设置保存上传文件的目录为不可执行。
- 在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈建议采用白名单的方式。此外，对于图片的处理可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的恶意代码。
- 文件服务器使用独立的域名。
- 使用第三方对象存储服务。
完结。
不足之处，敬请指正。
