Skip to content

Latest commit

 

History

History
329 lines (172 loc) · 22.1 KB

网络安全.md

File metadata and controls

329 lines (172 loc) · 22.1 KB

网络安全

1. 怎么知道连接是恶意的呢?可能是正常连接?

  1. 验证码(最简单有效的防护),采用点触验证,滑动验证或第三方验证码服务,普通验证码很容易被破解
  2. 频率,限制同设备,同IP等发送次数,单点时间范围可请求时长
  3. 归属地,检测IP所在地是否与手机号归属地匹配;IP所在地是否是为常在地
  4. 可疑用户,对于可疑用户要求其主动发短信(或其他主动行为)来验证身份
  5. 黑名单,对于黑名单用户,限制其操作,API接口直接返回success,1可以避免浪费资源,2混淆黑户判断
  6. 签名,API接口启用签名策略,签名可以保障请求URL的完整安全,签名匹配再继续下一步操作
  7. token,对于重要的API接口,生成token值,做验证
  8. https,启用https,https 需要秘钥交换,可以在一定程度上鉴别是否伪造IP
  9. 代码混淆,发布前端代码混淆过的包
  10. 风控,大量肉鸡来袭时只能受着,同样攻击者也会暴露意图,分析意图提取算法,分析判断是否为恶意 如果是则断掉;异常账号及时锁定;或从产品角度做出调整,及时止损。
  11. 数据安全,数据安全方面做策略,攻击者得不到有效数据,提高攻击者成本
  12. 恶意IP库,https://threatbook.cn/,过滤恶意IP

tips:

  • 鉴别IP真伪(自己识别代理IP和机房IP成本略高,可以考虑第三方saas服务。由肉鸡发起的请求没辙,只能想其他方法)
  • 手机号真伪(做空号检测,同样丢给供应商来处理,达不到100%准确率,效率感人,并且不是实时的,可以考虑选择有防攻击的运营商)
  • 安全问题是长期的和攻击者斗智斗勇的问题,没有一劳永逸的解决方案,不断交锋,不断成长

2. 跨站脚本攻击XSS

XSS攻击是什么

  • XSS是跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。

XSS的危害

其实归根结底,XSS的攻击方式就是想办法“教唆”用户的浏览器去执行一些这个网页中原本不存在的前端代码。

可问题在于尽管一个信息框突然弹出来并不怎么友好,但也不至于会造成什么真实伤害啊。的确如此,但要说明的是,这里拿信息框说事仅仅是为了举个栗子,真正的黑客攻击在XSS中除非恶作剧,不然是不会在恶意植入代码中写上alert(“say something”)的。

在真正的应用中,XSS攻击可以干的事情还有很多,这里举两个例子。

  • 窃取网页浏览中的cookie值

在网页浏览中我们常常涉及到用户登录,登录完毕之后服务端会返回一个cookie值。这个cookie值相当于一个令牌,拿着这张令牌就等同于证明了你是某个用户。

如果你的cookie值被窃取,那么攻击者很可能能够直接利用你的这张令牌不用密码就登录你的账户。如果想要通过script脚本获得当前页面的cookie值,通常会用到document.cookie。

试想下如果像空间说说中能够写入xss攻击语句,那岂不是看了你说说的人的号你都可以登录(不过某些厂商的cookie有其他验证措施如:Http-Only保证同一cookie不能被滥用)

  • 劫持流量实现恶意跳转

这个很简单,就是在网页中想办法插入一句像这样的语句:

<script>window.location.href="http://www.baidu.com";</script>

那么所访问的网站就会被跳转到百度的首页。

早在2011年新浪就曾爆出过严重的xss漏洞,导致大量用户自动关注某个微博号并自动转发某条微博。具体各位可以自行百度。

攻击分类举例

(1)反射型XSS

又称为非持久性跨站点脚本攻击,它是最常见的类型的XSS。漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性XSS包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)。

简单例子

正常发送消息:http://www.test.com/message.php?send=Hello,World!

接收者将会接收信息并显示Hello,Word

非正常发送消息:http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>!

接收者接收消息显示的时候将会弹出警告窗口

(2)持久型XSS

又称为持久型跨站点脚本,它一般发生在XSS攻击向量(一般指XSS攻击代码)存储在网站数据库,当一个页面被用户打开的时候执行。每当用户打开浏览器,脚本执行。持久的XSS相比非持久性XSS攻击危害性更大,因为每当用户打开页面,查看内容时脚本将自动执行。谷歌的orkut曾经就遭受到XSS。

简单例子:

从名字就可了解到存储型XSS攻击就是将攻击代码存入数据库中,然后客户端打开时就执行这些攻击代码。例如留言板

留言板表单中的表单域:<input type=“text” name=“content” value=“这里是用户填写的数据”>

**正常操作:**用户是提交相应留言信息;将数据存储到数据库;其他用户访问留言板,应用去数据并显示。

**非正常操作:**攻击者在value填写<script>alert(‘foolish!’)</script>【或者html其他标签(破坏样式。。。)、一段攻击型代码】;将数据存储到数据库中;其他用户取出数据显示的时候,将会执行这些攻击性代码

(3)DOM-based XSS

基于DOM的XSS,通过对具体DOM代码进行分析,根据实际情况构造dom节点进行XSS跨站脚本攻击。

注:domxss取决于输出位置,并不取决于输出环境,因此domxss既有可能是反射型的,也有可能是存储型的。dom-based与非dom-based,反射和存储是两个不同的分类标准。

防范

记住一句至理名言——“所有用户输入都是不可信的。”(注意: 攻击代码不一定在<script></script>中)

使用XSS Filter

  • 输入过滤,对用户提交的数据进行有效性验证,仅接受指定长度范围内并符合我们期望格式的的内容提交,阻止或者忽略除此外的其他任何数据。
  • 输出转义,当需要将一个字符串输出到Web网页时,同时又不确定这个字符串中是否包括XSS特殊字符,为了确保输出内容的完整性和正确性,输出HTML属性时可以使用HTML转义编码(HTMLEncode)进行处理,输出到<script>中,可以进行JS编码。

使用 HttpOnly Cookie

将重要的cookie标记为httponly,这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段,但是在js脚本中却不能访问这个cookie,这样就避免了XSS攻击利用JavaScriptdocument.cookie获取cookie

困难和幸运

真正麻烦的是,在一些场合我们要允许用户输入HTML,又要过滤其中的脚本。这就要求我们对代码小心地进行转义。否则,我们可能既获取不了用户的正确输入,又被XSS攻击。 幸好,由于XSS臭名昭著历史悠久又极其危险,现代web开发框架如vue.jsreact.js等,在设计的时候就考虑了XSS攻击对html插值进行了更进一步的抽象、过滤和转义,我们只要熟练正确地使用他们,就可以在大部分情况下避免XSS攻击。 同时,许多基于MVVM框架的SPA(单页应用)不需要刷新URL来控制view,这样大大防止了XSS隐患。另外,我们还可以用一些防火墙来阻止XSS的运行。

参考资料:

3. 跨站请求伪造CSRF

CSRF是什么?

跨站请求伪造(英语:Cross-site request forgery),维基百科的解释是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法,听起来很厉害的样子。

简单来说,攻击者利用一些技术手段去欺骗用户浏览器去访问一些曾经认证过的网站而执行一些操作。由于认证过,所以浏览器认为是用户的本意。

其实咋们可以简单理解为虎符调兵,正常是大将军颁发虎符才能调兵,但是军队只认虎符不认人,假如奸臣偷取虎符假传命令私自调兵造反,那可就大事不好!

例如 localhost/deleteAriticle.php?id=3&username=xiaoxiao,攻击者在被攻击的网站页面嵌入这样的代码,当用户xiaoxiao访问该网站的时候,会发起这条请求。服务器会删除id为3的数据。 客户端防范:对于数据库的修改请求,全部使用POST提交,禁止使用GET请求。 服务器端防范:一般的做法是在表单里面添加一段隐藏的唯一的token(请求令牌)。

CSRF原理

那我们具体看看攻击细节


看图说话,大致过程

  • 用户访问浏览正常网站
  • 正常网站服务器响应并且返回标识该用户身份的cookie
  • 用户未注销正常网站的情况下,访问恶意网站
  • 恶意网站里访问正常网站并且带着标识用户的cookie
  • 正常网站服务器接受来自恶意网站的请求

再次访问正常网站时,浏览器会自动带上标识该用户身份的cookie发送请求,所以正常网站服务器会接受来自恶意网站的请求,从而完成攻击。

当我访问登录一个正常网站,成功访问后服务器会产生一个标识用户身份的cookie给用户的浏览器保存,在标识cookie还存在时访问恶意网站,在该网站里攻击者会让你不知不觉的访问之前的正常网站并且执行一些操作,由于标识用户身份的cookie还存在,所以用户浏览器认为是用户的本意操作而执行该请求,从而攻击成功。

这些欺骗的访问方式有很多,例如“点击小广告、找回密码”等等诱导用户去点击操作。

如何预防CSRF

目前预防方式有二种:

  1. 检查Referer字段

HTTP请求head里有个Referer字段,用于表明请求的来源地址。正常情况下,Referer字段和请求的地址是位于同一域名下的,如果是CSRF攻击发起的请求,那么Referer字段和请求的地址就不是同一域名了,那么服务器就能识别出恶意访问。

这个方法缺点是攻击者有可能篡改该Referer字段内容,从而欺骗服务器。

  1. 添加校验token

当用户正常访问网站时,服务器会生产一个随机数,并且把该随机数埋入该页面里(一般放在form表单,<input type="hidden" name="_csrf_token" value="xxxx">)。正常访问,客户的浏览器是能够得到并且返回该字段,而CSRF一开始是不知道该字段的数值,服务器接受请求发现该字段的异常,从而拒绝该请求。

如何用简洁生动的语言说明 XSS 和 CSRF 的区别?

xss原理上利用的是浏览器可以拼接成任意的javascript,然后黑客拼接好javascript让浏览器自动地给服务器端发出多个请求(get、post请求)。 csrf原理上利用的是网站服务器端所有参数都是可预先构造的原理,然后黑客拼接好具体请求url,可以引诱你提交他构造好的请求。

参考资料:

4. SQL注入攻击

什么是SQL注入?

所谓SQL注入,是将客户机提交或Web表单递交的数据,拼接成SQL语句字符串时。如果客户端提交的数据有非法字符或SQL语句关键字时,会造成执行的SQL语句语法错误,或执行结果不正确的情况。通过SQL注入,黑客可以最终达到欺骗服务器,执行恶意的SQL语句,甚至破坏数据库结构的目的。

SQL注入攻击大多是利用设计上的漏洞,在目标服务器上运行Sql语句的攻击方式。开发者在动态生成Sql语句时,没有对用户输入的数据进行验证,是Sql注入攻击得逞的主要原因。

如何防止SQL注入?

在Java中,是使用JDBC和数据库建立连接,并执行SQL语句,和数据库进行数据交互的。

JDBC在执行SQL语句操作时,提供了 StatementPreparedStatementCallableStatement 三种方式来执行SQL语句。其中 Statement 用于通用查询, PreparedStatement 用于执行参数化查询,而 CallableStatement则是用于存储过程。 在三个接口中,Statement是PreparedStatement和CallableStatement的父接口。Statement在执行SQL语句时,对于客户端提交的数据只支持拼接SQL语句的方式。

String sql = "select * from  t_user where userName='" + name + 
    "' and  password='" + password + "'"; 

所以,使用Statement在执行SQL语句,容易引起SQL注入。PreparedStatement在执行参数化查询时,支持占位符方式

String sql = "select * from  t_user where userName=? and password=?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1,name);
ps.setString(2,password);

在使用参数化查询的情况下,数据库系统不会将参数的内容,视为SQL指令的一部分来处理。而是在数据库完成SQL指令的编译后,才套用参数运行。因此,就算参数中含有破坏性的指令,也不会被数据库所运行。所以,使用PreparedStatement的参数化查询可以有效的阻止SQL注入。

另外,PreparedStatement相比Statement还有以下几个优势

  1. 可以预编译SQL语句,多次查询时速度快。
  2. 防止数据库缓冲区溢出
  3. 代码的可读性可维护性好

由于有以上优点,所以,在开发JDBC时,PreparedStatement成为访问数据库的语句对象的首选。

总结

  1. 所谓SQL注入,是将客户机提交或Web表单递交的数据,拼接成SQL语句字符串时。如果客户端提交的数据有非法字符或SQL语句关键字时,会造成执行的SQL语句语法错误,或执行结果不正确的情况。通过SQL注入,黑客可以最终达到欺骗服务器,执行恶意的SQL语句,甚至破坏数据库结构的目的。
  2. 在JDBC中使用 PreparedStatement 的参数化查询,数据库系统不会将参数的内容,视为SQL指令的一部分来处理。可以有效防止SQL注入。
  3. 开发JDBC时,尽量采用 PreparedStatement 执行SQL语句,相比 Statement 有以下优势:
    1. 可以防止SQL注入
    2. 可以预编译SQL语句,多次查询时速度快
    3. 防止数据库缓冲区溢出
    4. 代码的可读性可维护性好

5. 拒绝服务攻击DDoS

举个形象的例子:

  • 某饭店可以容纳100人同时就餐,某日有个商家恶意竞争,雇佣了200人来这个饭店坐着不吃不喝,导致饭店满满当当无法正常营业。(DDOS攻击成功)
  • 老板当即大怒,派人把不吃不喝影响正常营业的人全都轰了出去,且不再让他们进来捣乱,饭店恢复了正常营业。(添加规则和黑名单进行DDOS防御,防御成功)
  • 主动攻击的商家心存不满,这次请了五千人逐批次来捣乱,导致该饭店再次无法正常营业。(增加DDOS流量,改变攻击方式)
  • 饭店把那些捣乱的人轰出去只后,另一批接踵而来。此时老板将饭店营业规模扩大,该饭店可同时容纳1万人就餐,5000人同时来捣乱饭店营业也不会受到影响。(增加硬防与其抗衡)

DDOS是Distributed Denial of Service的缩写,翻译成中文是“分布式拒绝服务“攻击,网络中的DDOS攻击与防御与上面例子所述差不多,DDOS只不过是一个概称,其下有各种攻击方式,比如“CC攻击、SYN攻击、NTP攻击、TCP攻击、DNS攻击等等”,现在DDOS发展变得越来越可怕,NTP攻击渐渐成为主流了,这意味着可以将每秒的攻击流量放大几百倍,比如每秒1G的SYN碎片攻击换成NTP放大攻击,就成为了200G或者更多。

SYN Flood

这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。建立TCP连接,需要三次握手——客户端发送SYN报文,服务端收到请求并返回报文表示接受,客户端也返回确认,完成连接。

SYN Flood 就是用户向服务器发送报文后突然死机或掉线,那么服务器在发出应答报文后就无法收到客户端的确认报文(第三次握手无法完成),这时服务器端一般会重试并等待一段时间后再丢弃这个未完成的连接。一个用户出现异常导致服务器的一个线程等待一会儿并不是大问题,但恶意攻击者大量模拟这种情况,服务器端为了维护数以万计的半连接而消耗非常多的资源,结果往往是无暇理睬客户的正常请求,甚至崩溃。从正常客户的角度看来,网站失去了响应,无法访问。


CC 攻击

CC攻击是目前应用层攻击的主要手段之一,借助代理服务器生成指向目标系统的合法请求,实现伪装和DDoS。我们都有这样的体验,访问一个静态页面,即使人多也不需要太长时间,但如果在高峰期访问论坛、贴吧等,那就很慢了,因为服务器系统需要到数据库中判断访问者否有读帖、发言等权限。访问的人越多,论坛的页面越多,数据库压力就越大,被访问的频率也越高,占用的系统资源也就相当可观。

CC攻击就充分利用了这个特点,模拟多个正常用户不停地访问如论坛这些需要大量数据操作的页面,造成服务器资源的浪费,CPU长时间处于100%,永远都有处理不完的请求,网络拥塞,正常访问被中止。这种攻击技术性含量高,见不到真实源IP,见不到特别大的异常流量,但服务器就是无法进行正常连接。


之所以选择代理服务器是因为代理可以有效地隐藏自己的身份,也可以绕开防火墙,因为基本上所有的防火墙都会检测并发的TCP/IP连接数目,超过一定数目一定频率就会被认为是Connection-Flood。当然也可以使用肉鸡来发动CC攻击,攻击者使用CC攻击软件控制大量肉鸡发动攻击,肉鸡可以模拟正常用户访问网站的请求伪造成合法数据包,相比前者来说更难防御。

CC攻击是针对Web服务在第七层协议发起的攻击,在越上层协议上发动DDoS攻击越难以防御,上层协议与业务关联愈加紧密,防御系统面临的情况也会更复杂。比如CC攻击中最重要的方式之一HTTP Flood,不仅会直接导致被攻击的Web前端响应缓慢,对承载的业务造成致命的影响,还可能会引起连锁反应,间接攻击到后端的Java等业务层逻辑以及更后端的数据库服务。

由于CC攻击成本低、威力大,知道创宇安全专家组发现80%的DDoS攻击都是CC攻击。带宽资源严重被消耗,网站瘫痪;CPU、内存利用率飙升,主机瘫痪;瞬间快速打击,无法快速响应。

NTP Flood

NTP是标准的基于UDP协议传输的网络时间同步协议,由于UDP协议的无连接性,方便伪造源地址。攻击者使用特殊的数据包,也就是IP地址指向作为反射器的服务器,源IP地址被伪造成攻击目标的IP,反射器接收到数据包时就被骗了,会将响应数据发送给被攻击目标,耗尽目标网络的带宽资源。一般的NTP服务器都有很大的带宽,攻击者可能只需要1Mbps的上传带宽欺骗NTP服务器,就可给目标服务器带来几百上千Mbps的攻击流量。

因此,“问-答”方式的协议都可以被反射型攻击利用,将质询数据包的地址伪造为攻击目标地址,应答的数据包就会都被发送至目标,一旦协议具有递归效果,流量就被显著放大了,堪称一种“借刀杀人”的流量型攻击。


预防

没有根治的办法,除非不用TCP/IP链接

  • 确保服务器的系统文件是最新版本,并及时更新系统补丁
  • 关闭不必要的服务
  • 限制同时打开SYN的半连接数目
  • 缩短SYN半连接的time out时间
  • 正确设置防火墙
  • 禁止对主机的非开放服务的访问
  • 限制特定IP短地址的访问
  • 启用防火墙的防DDos的属性
  • 严格限制对外开放的服务器的向外访问
  • 运行端口映射程序祸端口扫描程序,要认真检查特权端口和非特权端口。
  • 认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更,那这台机器就可能遭到了攻击。
  • 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会,主机的信息暴露给黑客,无疑是给了对方入侵的机会。

DOS攻击之泪滴攻击

泪滴攻击(TearDrop) 指的是向目标机器发送损坏的IP包,诸如重叠的包或过大的包载荷。借由这些手段,该攻击可以通过TCP/IP协议栈中分片重组代码中的bug来瘫痪各种不同的操作系统。

泪滴攻击是拒绝服务攻击的一种。 泪滴是一个特殊构造的应用程序,通过发送伪造的相互重叠的IP分组数据包,使其难以被接收主机重新组合。他们通常会导致目标主机内核失措。 泪滴攻击利用IP分组数据包重叠造成TCP/ IP分片重组代码不能恰当处理IP包。 泪滴攻击不被认为是一个严重的DOS攻击,不会对主机系统造成重大损失。 在大多数情况下,一次简单的重新启动是最好的解决办法,但重新启动操作系统可能导致正在运行的应用程序中未保存的数据丢失。