这篇文章将为大家详细讲解有关网站攻防技术有哪些，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。

我们提供的服务有：网站建设、成都做网站、微信公众号开发、网站优化、网站认证、津南ssl等。为成百上千企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的津南网站制作公司

1. XSS攻击

XSS攻击的全称是跨站脚本攻击(Cross Site Scripting),是WEB应用程序中最常见到的攻击手段之一。跨站脚本攻击指的是攻击者在网页中嵌入恶意脚本程序, 当用户打开该网页时,脚本程序便开始在客户端的浏览器上执行,以盗取客户端cookie、 盗取用户名密码、下载执行病毒木马程序等等。

1.1 非持久型XSS

非持久型XSS漏洞，也叫反射型XSS漏洞，一般是通过给别人发送带有恶意脚本代码参数的URL，当URL地址被打开时，特有的恶意代码参数被HTML解析、执行。

XSS之所以会发生,是因为用户输入的数据变成了代码。因此,我们需要对用户输入的数据进行HTML转义处理,将其中的“尖括号”、“单引号”、“引号” 之类的特殊字符进行转义编码。此外还需要注意Web页面渲染的所有内容或者渲染的数据都必须来自于服务端，尽量不要从URL、document.referrer、document.forms等这种DOM API中获取数据直接渲染，前端渲染的时候对任何的字段都需要做escape转义编码。

1.2 持久型XSS

持久型 XSS 漏洞，也被称为存储型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如发帖留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。主要注入页面方式和非持久型 XSS 漏洞类似，只不过持久型的不是来源于 URL，refferer，forms 等，而是来源于后端从数据库中读出来的数据。持久型 XSS 攻击不需要诱骗点击，黑客只需要在提交表单的地方完成注入即可，但是这种 XSS 攻击的成本相对还是很高。攻击成功需要同时满足以下几个条件：POST 请求提交表单后端没做转义直接入库；后端从数据库中取出数据没做转义直接输出给前端；前端拿到后端数据没做转义直接渲染成DOM。

1.2.1 如何防范？

为了防止持久型 XSS 漏洞，需要前后端共同努力：

后端在入库前应该选择不相信任何前端数据，将所有的字段统一进行转义处理。
后端在输出给前端数据统一进行转义处理。
前端在渲染页面DOM的时候应该选择不相信任何后端数据，任何字段都需要做转义处理。

1.3 基于字符集的XSS

其实现在很多的浏览器以及各种开源的库都专门针对了XSS进行转义处理，尽量默认抵御绝大多数XSS攻击，但是还是有很多方式可以绕过转义规则，让人防不胜防。比如「基于字符集的XSS攻击」就是绕过这些转义处理的一种攻击方式，比如有些Web页面字符集不固定，用户输入非期望字符集的字符，有时会绕过转义过滤规则。

以基于utf-7的XSS为例
utf-7是可以将所有的unicode通过7bit来表示的一种字符集(但现在已经从Unicode规格中移除)。
这个字符集为了通过7bit来表示所有的文字,除去数字和一部分的符号,其它的部分将都以base64编码为基础的方式呈现。

可以被解释为：
+ADw-script+AD4-alert(+ACI-xss+ACI-)+ADw-/script+AD4-
可以形成「基于字符集的XSS攻击」的原因是由于浏览器在meta没有指定charset的时候有自动识别编码的机制，所以这类攻击通常就是发生在没有指定或者没来得及指定meta标签的charset的情况下。

1.3.1 如何防范？

• 记住指定

• XML中不仅要指定字符集为utf-8，而且标签要闭合

1.4 未经验证的跳转XSS

有一些场景是后端需要对一个传进来的待跳转的URL参数进行一个302跳转，可能其中会带有一些用户的敏感（cookie）信息。如果服务器端做302跳转，跳转的地址来自用户的输入，攻击者可以输入一个恶意的跳转地址来执行脚本。

1.4.1 如何防范？

• 对待跳转的URL参数做白名单或者某种规则过滤

• 后端注意对敏感信息的保护，比如cookie使用来源验证。

2. CSRF攻击

CSRF攻击的全称是跨站请求伪造(cross site request forgery), 是一种对网站的恶意利用,你可以这么理解CSRF攻击：攻击者盗用了你的身份,以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件、发短信、进行交易转账等等,甚至盗取你的账号。

                                

                                                                 图-CSRF示意图

尽管听起来跟XSS跨站脚本攻击有点相似,但事实上CSRF与XSS差别很大，XSS利用的是站点内的信任用户,而CSRF则是通过伪装来自受信任用户的请求来利用受信任的网站。

2.1 CSRF防御

• cookie设置为HttpOnly

CSRF攻击很大程度上是利用了浏览器的cookie,为了防止站内的XSS漏洞盗取cookie,需要在cookie中设置"HttpOnly"属性,这样通过程序(如JavascriptS脚本、Applet等)就无法读取到cookie信息,避免了攻击者伪造cookie的情况出现。

• 增加token

CSRF攻击之所以能够成功,是因为攻击者可以伪造用户的请求,该请求中所有的用户验证信息都存在于cookie中,因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。由此可知,抵御CSRF攻击的关键在于:在请求中放入攻击者所不能伪造的信息,并且该信息不存在于cookie之中。鉴于此,系统开发人员可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务端进行token校验,如果请求中没有token或者token内容不正确,则认为是CSRF攻击而拒绝该请求。

• 通过Referer识别

根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求都来自于同一个网站。比如某银行的转账是通过用户访问http://www.xxx.com/transfer.do页面完成,用户必须先登录www.xxx.com,然后通过点击页面上的提交按钮来触发转账事件。当用户提交请求时,该转账请求的Referer值就会是提交按钮所在页面的URL(本例为www.xxx.com/transfer.do)。如果攻击者要对银行网站实施CSRF攻击,他只能在其他的网站构造请求,当用户通过其他网站发送请求到银行时,该请求的Referer的值是其他网站的地址,而不是银行转账页面的地址。因此,要防御CSRF攻击,银行网站只需要对于每一个转账请求验证其Referer值,如果是以www.xxx.com域名开头的地址,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer是其他网站的话,就有可能是CSRF攻击,则拒绝该请求。

3. SQL注入攻击

所谓SQL注入,就是通过把SQL命令伪装成正常的HTTP请求参数,传递到服务端,欺骗服务器最终执行恶意的SQL命令,达到入侵目的。攻击者可以利用SQL注入漏洞,查询非授权信息, 修改数据库服务器的数据,改变表结构,甚至是获取服务器root权限。总而言之,SQL注入漏洞的危害极大,攻击者采用的SQL指令,决定攻击的威力。当前涉及到大批量数据泄露的攻击事件,大部分都是通过利用SQL注入来实施的。

3.1 SQL注入的防御

• 使用预编译语句

预编译语句PreparedStatement是java.sql中的一个接口,继承自Statement接口。通过Statement对象执行SQL语句时,需要将SQL语句发送给DBMS,由DBMS先进行编译后再执行。而预编译语句和Statement不同,在创建PreparedStatement对象时就指定了SQL语句,该语句立即发送给DBMS进行编译,当该编译语句需要被执行时,DBMS直接运行编译后的SQL语句,而不需要像其他SQL语句那样首先将其编译。

前面介绍过,引发SQL注入的根本原因是恶意用户将SQL指令伪装成参数传递到后端数据库执行,作为一种更为安全的动态字符串的构建方法,预编译语句使用参数占位符来替代需要动态传入的参数,这样攻击者无法改变SQL语句的结构,SQL语句的语义不会发生改变,即便用户传入类似于前面'or'1'='1这样的字符串,数据库也会将其作为普通的字符串来处理。

Mybatis中#{ }是预编译处理，${ }是字符串替换（会导致sql注入，不利于系统的安全性），一般使用$接收dao参数时,这些参数一般是字段名,表名等,例如order by {column}。具体区别可以参考 程序猿DD-Mybatis中$和#千万不要乱用！

• 严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害。

• 在应用发布之前建议使用专业的 SQL 注入检测工具进行检测，以及时修补被发现的 SQL 注入漏洞。网上有很多这方面的开源工具，例如 sqlmap、SQLninja等

• 处理好相应的异常

  后台的系统异常,很可能包含了一些如服务器版本、数据库版本、编程语言等等的信息,甚至是数据库连接的地址及用户名密码,攻击者可以按图索骥,找到对应版本的服务器漏洞或者数据库漏洞进行攻击,因此,必须要处理好后台的系统异常,重定向到相应的错误处理页面,而不是任由其直接输出到页面上。

• 避免密码明文存放

  对存储的密码进行单向Hash,如使用MD5对密码进行摘要,而非直接存储明文密码,这样的好处就是万一用户信息泄露,即圈内所说的被“拖库”,黑客无法直接获取用户密码,而只能得到一串跟密码相差十万八千里的Hash码。

类似的还有命令行注入，后端对前端提交内容需要完全选择不相信，并且对其进行规则限制（比如正则表达式）；在调用系统命令前对所有传入参数进行命令行参数转义过滤；不要直接拼接命令语句，借助一些工具做拼接、转义预处理，例如Node.js的shell-escapenpm包。

4. 重放攻击

重放攻击就是把以前窃听到的数据原封不动地重新发送给接收方。很多时候，网络上传输的数据是加密过的，此时窃听者无法得到数据的准确意义。但如果他知道这些数据的作用，就可以在不知道数据内容的情况下通过再次发送这些数据达到愚弄接收端的目的。例如，有的系统会将鉴别信息进行简单加密后进行传输，这时攻击者虽然无法窃听密码，但他们却可以首先截取加密后的口令然后将其重放，从而利用这种方式进行有效的攻击。再比如，假设网上存款系统中，一条消息表示用户支取了一笔存款，攻击者完全可以多次发送这条消息而偷窃存款。

4.1 防御手段

• 加随机数

该方法优点是认证双方不需要时间同步，双方记住使用过的随机数，如发现报文中有以前使用过的随机数，就认为是重放攻击。缺点是需要额外保存使用过的随机数，若记录的时间段较长，则保存和查询的开销较大。

• 加时间戳

该方法优点是不用额外保存其他信息。缺点是认证双方需要准确的时间同步，同步越好，受攻击的可能性就越小。但当系统很庞大，跨越的区域较广时，要做到精确的时间同步并不是很容易，同时时间窗口设定还要考虑到网络传输延时的影响。

在实际中，常将方法(1)和方法(2)组合使用，这样就只需保存某个很短时间段内的所有随机数，而且时间戳的同步也不需要太精确。

5. 上传文件漏洞

在上网的过程中,我们经常会将一些如图片、压缩包之类的文件上传到远端服务器进行保存,文件上传攻击指的是恶意攻击者利用一些站点没有对文件的类型做很好的校验这样的漏洞,上传了可执行的文件或者脚本,并且通过脚本获得服务器上相应的权利,或者是通过诱导外部用户访问或者下载上传的病毒或者木马文件,达到攻击目的。

为了防范用户上传恶意的可执行文件和脚本,以及将文件上传服务器当做免费的文件存储服务器使用,需要对上传的文件类型进行白名单(非黑名单,这点非常重要)校验,并且限制上传文件的大小,上传的文件,需要进行重新命名,使攻击者无法猜测到上传文件的访问路径。

对于上传的文件来说,不能简单的通过后缀名称来判断文件的类型,因为恶意攻击可以将可执行文件的后缀名称改成图片或者其他的后缀类型,诱导用户执行。因此,判断文件类型需要使用更安全的方式。很多类型的文件,起始的几个字节内容是固定的,因此,根据这几个字节的内容,就可以确定文件类型,这几个字节也被称为魔数(magic number)。

6. DDoS攻击

DDoS又叫分布式拒绝服务，全称Distributed Denial of Service，其原理就是利用大量的请求造成资源过载，导致服务不可用。具体参考资料zoumiaojiang.com-常见Web安全攻防总结

7. 流量劫持

分为DNS劫持和HTTP劫持，DNS劫持（域名劫持），如果当用户通过某一个域名访问一个站点的时候，被篡改的DNS服务器返回的是一个恶意的钓鱼站点的IP，用户就被劫持到了恶意钓鱼站点，然后继而会被钓鱼输入各种账号密码信息，泄漏隐私，如何防止域名被劫持。HTTP劫持主要是当用户访问某个站点的时候会经过运营商网络，而不法运营商和黑产勾结能够截获HTTP请求返回内容，并且能够篡改内容，然后再返回给用户，从而实现劫持页面，轻则插入小广告，重则直接篡改成钓鱼网站页面骗用户隐私。能够实施流量劫持的根本原因，是HTTP协议没有办法对通信对方的身份进行校验以及对数据完整性进行校验。如果能解决这个问题，则流量劫持将无法轻易发生。所以防止HTTP劫持的方法只有将内容加密，让劫持者无法破解篡改，这样就可以防止HTTP劫持了。HTTPS协议就是一种基于SSL协议的安全加密网络应用层协议，可以很好的防止HTTP劫持。

关于“网站攻防技术有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。

本文标题：网站攻防技术有哪些
文章起源：http://ybzwz.com/article/iieoej.html