web安全(一)

2017-01-05 11:13:00 Web安全 13782 0

其实web本来是没有漏洞的,但有的东西被人非法利用了起来,就成了漏洞了
在web开发时,如果是一个非常注重web安全方面的人独自开发,那么安全性肯定是很高的
但现在的情况常常是团队协作开发,并不是所有人都对安全有一定的意识的,自然就会流出可被攻击的点

本次概览

view层

XSS、CSRF、点击劫持、url跳转

model层

SQL注入、认证、重放攻击、文件上传、加密算法、webServer安全、语言安全

后端框架

链路层劫持

XSS

定义

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

案例1

若某个网站,赋予游客回复的权限,然后给用户用的是markdown
分析:markdown的超链接生成的时候,生成超链接的过程:

[标题](链接)

若未对超链接进行有效性过滤,则可这样攻击

[云天河](javascript:alert('云天河好厉害'))

若,已经做了安全性过滤,也许可以通过,拼接的方式

[美女直播](javascript:alert('此网站有高风险');//http://baidu.com)
案例2

对用户留言直接用pre包起来的网站
普通留言,如下

<pre>这里是内容</pre>

代码拼接方式,攻击

<pre></pre><script>alert('xss')</script><pre></pre>

或者图片方面做文章

<img src="xxx" onerror="alert()">xxxxxx</p>

甚至css上

<divstyle=”height:expression_r(alert(’XSS’),1)” />(这个仅限 IE 有效)

此外有,善变的iframe

1.1 最好懂的,onload执行js
<iframe onload="alert(1)"></iframe>
1.2 src 执行javascript代码
<iframe src="javascript:alert(1)"></iframe>
1.3 IE下vbscript执行代码
<iframe src="vbscript:msgbox(1)"></iframe> 
1.4 Chrome下data协议执行代码
<iframe src="data:text/html,<script>alert(1)</script>"></iframe> Chrome
1.5 上面的变体
<iframe src="data:text/html,&lt;script&gt;alert(1)&lt;/script&gt;"></iframe>
1.6 Chrome下srcdoc属性
<iframe srcdoc="&lt;script&gt;alert(1)&lt;/script&gt;"></iframe>

案例3

大多数网站都是utf-8的,有的网站过滤的时候 \ 这个符号没有被转义
导致的unicode编码被没有被过滤,而造成攻击
肯定会被过滤的script代码,示例代码:

<script>alert('xss')</script>

转为unicode编码后,代码拥有一样的作用

\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0027\u0078\u0073\u0073\u0027\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e

解决方法

a.统一前后端、数据库的字符集
b.富文本编译器使用时,后端得过滤XSS。[回复内容,尽量不使用它]
c.全局过滤htmlspecialchars 请不要太信任这个函数的过滤效果,它可能被绕过
d.引入第三方过滤库htmlpurifier

CSRF

定义

CSRF(Cross-site request forgery跨站请求伪造,也被称为“One Click Attack”或者Session Riding
通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS)
但它与XSS非常不同,并且攻击方式几乎相左。XSS利用站点内的信任用户
而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站
与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范
所以被认为比XSS更具危险性

案例1

因为有 同源策略(CORS) 想通过别的页面写iframe是不能获取到目标网站的cookie的
然而通过浏览器请求某网站数据的时候,它会带上自己的cookie
而且不会管你是从哪个页面发送请求过来的,这时候,你就可以搞点事情了

银行网站A:它以GET请求来完成银行转账的操作,如:

http://www.mybank.com/Transfer.php?toBankId=11&money=1000 

危险网站B:它里面有一段HTML的代码如下:

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先,你登录了银行网站A,然后访问危险网站B,噢,这时你会发现你的银行账户少了1000块

防御方法

理论上 99% 可防御
a.在表单中增加一个随机的数字或字母验证码,通过强制用户和应用进行交互,来有效地遏制CSRF攻击
b.来源判断 判断HTTP头信息中的 Referer 是否为本网站
c.验证码,不推荐,影响用户体验

案例2 XSS + CSRF

这就是防御不了的 1%
比如说,现在你已经登陆过百度贴吧了
百度贴吧某个页面被XSS攻击了,攻击者在此页面嵌入了js脚本
该脚本会在你加载这个页面的时候,把贴吧的Cookie全部获取到,并转发到它的网站去
他的网站接收到你的cookie后,就可以立马用于发广告帖什么的

点击劫持

定义

点击劫持,click jacking,也被称为UI-覆盖攻击
它是通过覆盖不可见的框架误导受害者点击
虽然受害者点击的是他所看到的网页,但其实他所点击的是被黑客精心构建的另一个置于原网页上面的透明页面

这张图后面大到有可能iframe了一个银行转账页面,小则可能是莫名其妙发出了不该发的消息,粉了不认识的人,或是一个广告。形如:

<iframe src="http://hlzblog.top/" style="width:100%;height:100%;opacity:0"></iframe>
案例1

腾讯微博刷粉

<!DOCTYPE html> 
<html>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 
<head> 
<title>点击劫持 POC</title>
 <style> iframe { width: 1440px; height: 900px; position: absolute; top: -0px; left: -0px; z-index: 2; -moz-opacity: 0; opacity: 0; filter: alpha(opacity=0); } 
button { position: absolute; top: 250px; left: 770px; z-index: 1; width: 80px; height:20px; }
 </style>
 </head>
 <body>
 <button>点击脱衣</button> 
<img src="http://b.hiphotos.baidu.com/image/pic/item/3ac79f3df8dcd1001341dbcd768b4710b8122f78.jpg"> <iframe src="http://search.t.qq.com/user.php?pos=436&k=东北保钓" scrolling="no"></iframe> 
</body> 
</html>

思路即为,找到有用的地方,查到坐标,放置按钮,放置诱惑信息

URL跳转

定义

URL重定向/跳转漏洞,由于应用越来越多的需要和其他的第三方应用交互,以及在自身应用内部根据不同的逻辑将用户引向到不同的页面,譬如一个典型的登录接口就经常需要在认证成功之后将用户引导到登录之前的页面,整个过程中如果实现不好就可能导致一些安全问题,特定条件下可能引起严重的安全漏洞。

出现场景

对于URL跳转的实现一般会有几种实现方式:
1.META标签内跳转
2.javascript跳转
3.header头跳转

案例1

譬如一个典型的外链跳转,如下:

<?php
$url = @$_GET['to_url'];
header('Location: '.$url);

如果 to_url 没有任何限制,别人还以为是可信任的网站,就相信了链接里面的内容了呢

http://www.hlzblog.top/jump.php?to_url=http://www.baidu.com/

再如新浪的短地址 http://t.cn
测试本网站: http://t.cn/Rtafz2r
如果你经常玩微博,也许你以为它是新浪的网站

也许,二维码扫一扫,你没注意过吧,不能乱扫哟,小心进入恶意网站

防御方法

配置跳转站点白名单,判断是否可信任
百度搜索,跳向目标链接,如此做

SQL注入

定义

所谓SQL注入,就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串
最终达到欺骗服务器执行恶意的SQL命令

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

原理

SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序,而这些输入大都是SQL语法里的一些组合
通过执行SQL语句进而执行攻击者所要的操作
其主要原因是程序没有细致地过滤用户输入的数据,致使非法数据侵入系统

SQL注入的产生原因通常表现在以下几方面

a.不当的类型处理;
b.不安全的数据库配置;
c.不合理的查询集处理;
d.不当的错误处理;
e.转义字符处理不合适;
f.多个提交处理不当。

案例1

先猜表名,再猜列名,若当前页面的sql帐号有相应权限,即可获得自己猜出来的表名与列名的数据

我一般都是把表名,统一加上前缀,使得表名难以暴露

案例2

AND和OR的运算规则,拼接sql语句
比如,传入$name // 这里$name="云天河"
正常情况下,$pwd // $pwd="xxx"

select `uid` from `user` where `name`='云天河' And `pwd`='$pwd' ;

注入时:传入的$pwd变为 "xxx or 1=1",即

select `uid` from `user` where `name`='云天河' And `pwd`='$pwd' or 1=1 ;

这样就能随便被人登陆了。

法一:pwd进行md5加密

法二:字符串转义处理=>转义单双引号

常见预防方案【PHP语言】
1.过滤固定类型的字符串
$real_int    = intval($param,10); // 获取十进制整数,但请注意该函数最大取值
$real_string = addslashes($param); // 字符串转义
...
2.PDO预处理sql语句

参数化,可让PDO负责发送sql模板,使得转义参数发生在mysql server中,从根本上杜绝了sql注入

$conn = new PDO("mysql:host=$servername;dbname=$dbname", $username, $password);
// 设置 PDO 错误模式为异常
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); 
// 预处理 SQL 并绑定参数
$stmt = $conn->prepare("INSERT INTO MyGuests (firstname, lastname) 
VALUES (:firstname, :lastname)");
$stmt->bindParam(':firstname', $firstname);
$stmt->bindParam(':lastname', $lastname); 

认证

定义
身份认证方面

数字签名 => RSA

Session认证;cookie_id

SSL证书

站点节点认证方面
被攻击场景

开发者没有对后台操作的每个站点进行权限认证
导致黑客可以直接跳转到管理界面进行操作

解决方案

使用RBAC、Auth认证方式,对每个敏感操作或者每个网站节点进行权限认证

重放攻击

定义

重放攻击(Replay Attacks)又称重播攻击、回放攻击或新鲜性攻击(Freshness Attacks),是指攻击者发送一个目的主机已接收过的包,特别是在认证的过程中,用于认证用户身份所接收的包,来达到欺骗系统的目的,主要用于身份认证过程,破坏认证的安全性。

原因

根据消息的来源
1.协议轮内攻击:一个协议轮内消息重放
2.协议轮外攻击:一个协议不同轮次消息重放

根据消息的去向
1.偏转攻击:改变消息的去向
2.直接攻击:将消息发送给意定接收方

其中偏转攻击分
1.反射攻击:将消息返回给发送者
2.第三方攻击:将消息发给协议合法通信双方之外的任一方

场景

微信:并发执行积分增长攻击

防御方法

双方规定同一时间戳或者加锁执行即可

文件上传

常见场景

向服务器上传了,可执行的木马或者病毒,造成系统资料泄露甚至瘫痪

解决方案

对即将上传文件的类型进行判断,以及文件权限控制,比如上传的图片文件,只能有read权限

加密算法

定义

数据加密的基本过程就是对原来为明文的文件或数据按某种算法进行处理
使其成为不可读的一段代码,通常称为“密文”
使其只能在输入相应的密钥之后才能显示出本来内容
通过这样的途径来达到保护数据不被非法人窃取、阅读的目的
该过程的逆过程为解密,即将该编码信息转化为其原来数据的过程

对称加密

DES(Data Encryption Standard)

对称算法,数据加密标准,速度较快,适用于加密大量数据的场合

3DES(Triple DES)

是基于DES的对称算法,对一块数据用三个不同的密钥进行三次加密,强度更高

常见场景
a.经后端加密,存于Bowser端的数据
b.防止数据库泄露,存入数据库前加密数据

不可逆加密

RSA in Github :RSA公开密钥密码体制。所谓的公开密钥密码体制就是使用不同的加密密钥与解密密钥,是一种“由已知加密密钥推导出解密密钥在计算上是不可行的”密码体制

md5、sha1、crc32

但这些函数有一个缺点,就是有碰撞的可能,平时用的时候,得再处理,比如,在加密前或者后,加上一个secretKey

常见场景
a.用户注册或者修改密码的传输过程中,需要 RSA 加密[如果有ssl加密,就不需要了]
b.[需要明文],如,存入数据库前后,对称加解密
c.[不需明文],如,用于对比的数据 => 密码存入数据库

webService安全

这块没有案例,详情请自行百度!反正记得都要隐藏版本号!

Apache

尽可能少的使用Module模块,不用的则关闭
否则别人有可能通过攻击你不常用的Module进而侵入服务器,从而获取Shell执行权限

Nginx

DDOS攻击
它可以在一定层面防止DDOS攻击CC攻击 -> 限制单IP并发连接量
但软件本身,可能会有BUG,得及时升级软件版本

语言安全

比如,php语言,要禁用一些shell函数,防止入侵后,执行shell
PHPInfo()信息泄漏漏洞利用提权及防范
所以我们与此同时应有警觉 关于“phpMyAdmin”
对此我们可以通过限制IP访问权限 ,例:Apache 如下

<VirtualHost *:81>
# Do not open it when you don't need it
# Allow IP is your current IP that you can find it by enter "IP" in "www.baidu.com"
  DocumentRoot "/data/www/default/phpmyadmin"
  <Directory />
    Order deny,allow
    deny from all # 拒绝所有ip
    allow from 123.12.123.12  # 运行某个ip访问
  </Directory>
</VirtualHost>

后端框架

别人了解你网站的架构越多,你越容易被攻击,下面我说个案例吧

thinkphp3.2.2

它的入口文件在根目录下
如果,你没改过框架结构,这样会使得它的内部日志文件、git文件可直接被访问到
日志文件:会泄露你网站的各种登陆地址[如果你的phpmyadmin也在这个根目录下,shell相关函数没关闭的话,你基本完蛋了]

其logs文件命名方式,你可以很清楚地看到,它的日志样式是很规律的
现在我们可以尝试进一个,平时它里面有默认的日志,关于数据库的,有的甚至会暴露http请求信息

Git文件

./git文件夹泄露

扫描你的站点有没有可访问的 ./git文件 ,如果有,黑客可通过以下方法得到你的源代码

1、解析.git/index文件,找到工程中所有的: ( 文件名,文件sha1 )  
2、去.git/objects/ 文件夹下下载对应的文件  
3、zlib解压文件,按原始的目录结构写入源代码  
git开源项目

用git的人大多开源项目吧,可是有时候你只是为了方便存代码
而且为了节约成本,也没有开通并设为私人项目
人们可利用搜索引擎,找到你的项目
扫描你的站点有没有可访问的 ./git文件
[有的猪队友,会吧数据库信息也传上去(传上去之后,只能把整个项目删了,重新传,不然git会记录之前的操作的)] 如果一定要git,请使用oschina的私人服务[毕竟国内,而且没那么贵]

措施

服务器禁止访问git文件目录

location ~ /\.git { deny all; }

链路层劫持

链路层劫持是指第三方(可能是运营商、黑客)通过在用户至服务器之间,植入恶意设备或者控制网络设备的手段
侦听或篡改用户和服务器之间的数据,达到窃取用户重要数据(包括用户密码,用户身份数据等等)的目的
链路层劫持最明显的危害就是帐号、密码被窃取
最常见的就是某些设备实现的对非法站点的访问拦截,以及一些地区运营商的网页植入广告行为

示例 wireshark 软件监听http请求

链路劫持的原理就是运营商(也可能是黑客)在用户访问网站的时候进行窃听,获取用户访问的目的ip后
然后以这个ip为source-ip冒充网站给用户响应,通常响应中会插入一段JS代码
这段代码可能会让用户去get一些非真实网站资源,最终可能造成真实页面被插入广告,被蒙层,甚至整页面被替换
严重影响用户体验以及企业形象。由于链路劫持可能通常发生在last-mile
而last-mile被运营商牢牢控住,所以这对监测以及解决问题带来了巨大的挑战。劫持原理大概如图所示。
流量劫持

目前发现的TCP链路劫持攻击一般有两种形式:中断访问型(分为单向发包和双向发包)和替换页面型

中断访问型常见于阻止用户访问某些网站,如某些设备禁止用户访问某些站点、某地运营商的禁止ADSL多终端上网功能
其原理就是伪造服务端给用户发RST包阻止TCP连接的建立(单向发包)
某些设备做得比较狠,在冒充服务端给用户发RST包的同时也冒充用户给服务端发RST包(双向发包)

替换页面型常见于运营商植入广告,也有篡改正常网页进行SEO、骗流量的。最恶劣的莫过于钓鱼
如,2011年出现过的Gmail钓鱼事件以及一些不为人知的钓鱼事件
原理也简单,就是在一个HTTP请求后伪造服务端的HTTP响应给客户端

解决方案

HTTPS

https是目前应对链路劫持用的较多的解决方案。https是加密协议,我们随便抓个http包,发现http包里面的所有东西都是明文的,这样就会被监听,而https协议是加密的

但是光加密还不够,因为只是application data被加密了,网络层的信息都没有被加密,邪恶势力依然可以用数据包的目的ip作为源ip响应用户
https还有另一大特点是要验证数字证书,为了确保客户端访问的网站是经过CA验证的可信任的网站
所以这就几乎彻底杜绝了链路劫持的可能

但是https也不是如此完美,虽然https解决了诸多安全问题,但是对性能也有着比较大的影响

1.用户要从http跳转到https,并且要多几次 TLS的握手,这会消耗一定的时间;
2.服务器的压力也会增加。除此之外如果使用全站的https,所有页面里面的嵌入资源都要改成https
APP的程序也要进行相应的修改,CDN的所有节点也必须都支持https并且导入证书
所以全站https并不是一件容易的事情,国外的Google、 Facebook、Twitter早已支持全站https
但目前国内大多数公司都没有采用全站https的方式。全站https应该是未来互联网的趋势

加强监控与检测

目前网上也有一些链路劫持检测方法,如使用libpcap判断链路层劫持
其原理是在链路层劫持的设备缺少仿造协议头中ttl值的程序(或者说,伪造流量要优先真实流量到达客户电脑,所以没有机会去伪造ttl值)
电脑每收到一个数据包,便交给程序,如果判断某一IP地址流量的ttl值与该IP前一次流量的ttl值不同且相差5以上,便判定此次流量为在链路层中伪造的

注:若无特殊说明,文章均为云天河原创,请尊重作者劳动成果,转载前请一定要注明出处