您的位置:首页 > 其它

常见几种web攻击方式和防御方法

2019-08-04 16:23 162 查看
版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/weixin_43837229/article/details/90906032

前言

网站的安全对于网站的可持续发展不言而喻,一个不安全的网站,例如经常被攻击导致宕机、被窃取个人隐私信息、被冒名发不良广告等,势必会导致大量用户流失,轻则影响公司形象,重则惹上官司,从而对网站对公司造成不可挽回的损失。下面介绍几种常见的攻击手段和一般防御方法。

1、SQL 注入

简介:
所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。具体来说,它是利用现有应用程序,将(恶意的)SQL命令注入到后台数据库引擎执行的能力,它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库,而不是按照设计者意图去执行SQL语句。比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击。

原理:
SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作,其主要原因是程序没有细致地过滤用户输入的数据,致使非法数据侵入系统。
根据相关技术原理,SQL注入可以分为平台层注入和代码层注入。前者由不安全的数据库配置或数据库平台的漏洞所致;后者主要是由于程序员对输入未进行细致地过滤,从而执行了非法的数据查询。
基于此,SQL注入的产生原因通常表现在以下几方面:

  1. 不当的类型处理;
  2. 不安全的数据库配置;
  3. 不合理的查询集处理;
  4. 不当的错误处理;
  5. 转义字符处理不合适;
  6. 多个提交处理不当。

防护:
归纳一下,主要有以下几点

  1. 永远不要信任用户的输入。对用户的输入进行校验,可以通过正则表达式,或限制长度;对单引号和
    双"-"进行转换等;
  2. 永远不要使用动态拼装sql,可以使用参数化的sql或者直接使用存储过程进行数据查询存取;
  3. 永远不要使用管理员权限的数据库连接,为每个应用使用单独的权限有限的数据库连接;
  4. 不要把机密信息直接存放,加密或者hash掉密码和敏感的信息;
  5. 应用的异常信息应该给出尽可能少的提示,最好使用自定义的错误信息对原始错误信息进行包装;
  6. sql注入的检测方法一般采取辅助软件或网站平台来检测,软件一般采用sql注入检测工具jsky,网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入,XSS攻击等。

举例:

  1. 构造SQL语句绕过后台身份验证漏洞
    如果输入用户名为正常的用户名如 admin,密码栏输入OR ‘1’ = ‘1’和’’ OR 1 = 1 – ’ AND password = ‘’,那么SQL查询语句就变成这样,’–‘两个减号在SQL是注释,和’#'号一样
SELECT * FROM `table` WHERE `user` = 'abc' AND `password` = '' OR '1' = '1';
select * FROM `table` WHERE `user` = 'abc' OR 1 = 1 -- ' AND  password = '';

这种SQL是恒成立,相当于免密登录。

  1. 通过猜的方式获取表名及列名,假如用户输入的数据直接拼到SQL后面组装成新的SQL进行查询,返回正确的,那么写的表名或列名就是正确
AND 0 <> (select count(*) from admin); -- 判断是否存在admin这张表
AND (select count(`name`) from admin)<> 0; -- 猜列名

这里只举一些简单的例子,让大家知道SQL注入的一般手段和危害。SQL注入远没有这么简单,大家有兴趣可以自行查阅相关资料。

如何防范:

  1. 使用参数化的过滤性语句
    要防御SQL注入,用户的输入就绝对不能直接被嵌入到SQL语句中。用户的输入必须进行过滤,或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中,SQL语句就得以修正。
  2. 输入验证
    检查用户输入的合法性,确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行,之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性。
    在客户端,攻击者完全有可能获得网页的源代码,修改验证合法性的脚本(或者直接删除脚本),然后将非法内容通过修改后的表单提交给服务器。因此,要保证验证操作确实已经执行,唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象,例如Regular Expression Validator,它们能够自动生成验证用的客户端脚本,当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象,你可以通过Custom Validator自己创建一个。
  3. 错误消息处理
    防范SQL注入,还要避免出现一些详细的错误消息,因为黑客们可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。
  4. 加密处理
    将用户登录名称、密码等数据加密保存。加密用户输入的数据,然后再将它与数据库中保存的数据比较,这相当于对用户输入的数据进行了“消毒”处理,用户输入的数据不再对数据库有任何特殊的意义,从而也就防止了攻击者注入SQL命令。
  5. 存储过程来执行所有的查询
    SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外,它还使得数据库权限可以限制到只允许特定的存储过程执行,所有的用户输入必须遵从被调用的存储过程的安全上下文,这样就很难再发生注入式攻击了。
  6. 使用专业的漏洞扫描工具
    攻击者们目前正在自动搜索攻击目标并实施攻击,其技术甚至可以轻易地被应用于其它的Web架构中的漏洞。企业应当投资于一些专业的漏洞扫描工具,如大名鼎鼎的Acunetix的Web漏洞扫描程序等。一个完善的漏洞扫描程序不同于网络扫描程序,它专门查找网站上的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。
  7. 确保数据库安全
    锁定你的数据库的安全,只给访问数据库的web应用功能所需的最低的权限,撤销不必要的公共许可,使用强大的加密技术来保护敏感数据并维护审查跟踪。如果web应用不需要访问某些表,那么确认它没有访问这些表的权限。如果web应用只需要只读的权限,那么就禁止它对此表的 drop 、insert、update、delete 的权限,并确保数据库打了最新补丁。
  8. 安全审评
    在部署应用系统前,始终要做安全审评。建立一个正式的安全过程,并且每次做更新时,要对所有的编码做审评。开发队伍在正式上线前会做很详细的安全审评,然后在几周或几个月之后他们做一些很小的更新时,他们会跳过安全审评这关, “就是一个小小的更新,我们以后再做编码审评好了”。请始终坚持做安全审评。

PHP一般防御:

  1. 校验数据类型
    使用内置函数校验输入的是否是数字类型:is_numeric() ;函数用于检测变量是否为数字或数字字符串;
    用正则匹配输入的字符是否合法,如手机号、邮箱、用户名等,preg_match()、preg_match_all。
  2. 转义特殊字符
    使用内置函数 addslashes、intval 过滤、转义输入参数;函数返回在预定义的字符前添加反斜杠的字符串;
  3. 使用数据对象 PDO,其实现的参数绑定,预编译处理等手段能很好的防SQL注入。经测试,PDO 的 CURL 效率比不上原生的 MySQL 直连,效率低5% ~ 15%,但是它本身封装的的接口对于操作数据库和安全过滤做的比较好,根据自己项目需求自行选择,需要安全性高的可选择PDO。(摘自《PHP-核心技术与原理分析》之 PDO 的效率问题)

2、XSS

定义:
XSS是一种经常出现在web应用中的计算机安全漏洞,它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型的漏洞由于被骇客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。

危害:
攻击者可以采用XSS攻击偷取用户Cookie、密码等重要数据,进而伪造交易、盗取用户财产、盗取个人信息等。

如何防范:

  1. 过滤
    对输入数据进行过滤和消毒处理,过滤用户输入的任何数据,对一些特殊字符进行转义;
  2. HttpOnly
    即禁止浏览器页面 Javascript 访问带有 HttpOnly 属性的 Cookie,达到防止 XSS 攻击者窃取 Cookie的目的。(摘自《大型网站技术架构:核心原理与案例分析》)

3、CSRF

定义:
CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,XSS利用站点内的信任用户,而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
其核心原理是利用了浏览器 Cookie 或服务器 Session 策略,盗取用户 身份。

危害:
攻击者通过跨站请求,以用户合法身份进行非法操作,如转账交易、发布假消息等。

一般防范:

  1. Referer check
    HTTP 请求人的Referer 域中记录着请求来源,可通过检查请求来源,验证其是否合法。很多网站使用这个功能实现图片防盗链。缺点是此字段可以为空或手动修改,只能增加攻击成本,无法达到完全防护的目的。
  2. 表单 Token
    表单 Token 通过在请求参数中增加随机数的方法来阻止攻击者获得所有请求参数:在页面表单中增加一个随机数作为 Token,每次响应页面的 Token 都不相同,正常的请求都带有该 Token,而伪造的非法请求无法获得该值,从而被服务器拦截请求,达到防御目的。次方案用的较多。
  3. 验证码
    此方法原理跟表单 Token 一样,都是增加一个随机参数,而这个随机参数是伪造者不能得知的,从而达到拦截非法请求的目的。只是该方案也有弊端,就是影响用户体验,每次都得输入验证码是用户无法忍受的,除了必要场景,如交易、登录等,否则此方案还是少用为好。(摘自《大型网站技术架构:核心原理与案例分析》)

4、DDOS

定义:
分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术,将多个计算机联合起来作为攻击平台,对一个或多个目标发动DDoS攻击,从而成倍地提高拒绝服务攻击的威力。通常,攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上,在一个设定的时间主控程序将与大量代理程序通讯,代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术,主控程序能在几秒钟内激活成百上千次代理程序的运行。

一般防范:

  1. 全面综合地设计网络的安全体系,注意所使用的安全产品和网络设备。
  2. 提高网络管理人员的素质,关注安全信息,遵从有关安全措施,及时地升级系统,加强系统抗击攻击的能力。
  3. 在系统中加装防火墙系统,利用防火墙系统对所有出入的数据包进行过滤,检查边界安全规则,确保输出的包受到正确限制。
  4. 优化路由及网络结构。对路由器进行合理设置,降低攻击的可能性。
  5. 优化对外提供服务的主机,对所有在网上提供公开服务的主机都加以限制。
  6. 安装入侵检测工具(如NIPC、NGREP),经常扫描检查系统,解决系统的漏洞,对系统文件和应用程序进行加密,并定期检查这些文件的变化。

5、Http Heads攻击

描述:
凡是用浏览器查看任何WEB网站,无论你的WEB网站采用何种技术和框架,都用到了HTTP协议.HTTP协议在Response header和content之间,有一个空行,即两组CRLF(0x0D 0A)字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到headers中,这种攻击就可以发生。

以登陆为例:有这样一个url:

http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

当登录成功以后,需要重定向回page参数所指定的页面。下面是重定向发生时的response headers

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server:Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/index

假如把URL修改一下,变成这个样子:

http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

那么重定向发生时的reponse会变成下面的样子:

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>

这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向(Location header)上,也有可能发生在其它headers中,如Set-Cookie header。这种攻击如果成功的话,可以做很多事,例如:执行脚本、设置额外的cookie(Set-Cookie: evil=value)等。

一般防范:
避免这种攻击的方法,就是过滤所有的response headers,除去header中出现的非法字符,尤其是CRLF。

服务器一般会限制request headers的大小。例如Apache server默认限制request header为8K。如果超过8K,Aapche Server将会返回400 Bad Request响应:
对于大多数情况,8K是足够大的。假设应用程序把用户输入的某内容保存在cookie中,就有可能超过8K.攻击者把超过8k的header链接发给受害者,就会被服务器拒绝访问.解决办法就是检查cookie的大小,限制新cookie的总大写,减少因header过大而产生的拒绝访问攻击。

6、Cookie攻击

描述:
通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站,然后在浏览器地址栏中输 入:javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie(如果有的话)。攻击者可以利用这个特 性来取得你的关键信息。例如,和XSS攻击相配合,攻击者在你的浏览器上执行特定的Java Script脚本,取得你的cookie。假设这个网站仅依赖cookie来验证用户身份,那么攻击者就可以假冒你的身份来做一些事情。

一般防范:
现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记,就会大大增强cookie的安全性。

7、上传文件攻击

描述:
攻击者利用网站的上传功能,如上传头像、图片、视频等,上传可执行程序,并通过该程序获得服务器端命令执行能力,那么攻击者就可能在服务器上为所欲为,达到攻击目的。

一般防范:
限制上传文件类型,只允许上传指定文件类型,并且上传存放地址专门存储的地方,避免影响到服务器正常运行。(摘自《大型网站技术架构:核心原理与案例分析》)

来源百度百科
https://blog.csdn.net/u010856276/article/details/82151130

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: