WEB安全之探究

我们是光大科技有限公司智能云计算部安全管理团队，致力于提升光大集团信息安全防御能力，保障集团IT系统安全稳定运行，支撑集团业务发展；在集团“五统一”方针指引下，为集团成员企业提供定制化信息安全服务和安全产品，实现安全赋能；为金融科技行业提供有光大特色的信息安全解决方案及安全治理服务，提升光大科技品牌知名度。

然而，当我开始接触计算机网络、了解相关知识后才逐渐发现，黑客并没有想象中那么深不可测。所谓的“神秘感”，归根结底还是出于对事物的无知。《左传》中有一句名言：人非圣贤，孰能无过。那么，由人开发出来的程序和系统自然也免不了会有一些漏洞。而黑客，正是利用了系统本身带有的漏洞，才给了人“无所不能”的错觉。

随着WEB2.0、社交网络等一系列新型互联网产品的诞生，基于WEB环境的互联网应用越来越广泛。企业信息化的过程中，各种应用都架设在WEB平台上，WEB业务的迅速发展也引起了黑客们的强烈关注，WEB安全威胁问题随之凸显。

正如一个硬币会有两面一样，在用户体验提升的同时，安全风险也会有所上升。黑客利用网站操作系统的漏洞和WEB程序的注入漏洞等得到WEB服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，甚至在网页中植入恶意代码，使得网站访问者受到侵害。下面我将介绍WEB安全防护中黑客常用的两种攻击方式及其原理、危害与预防。

简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了WEB中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

普通用户登录网站A认证之后，A系统服务端生成用户cookie返回给浏览器。在没有退出网站A的情况下，用户打开了攻击者构建的网页B，网站B构建一个恶意攻击网站A的请求，浏览器发出该恶意攻击的请求，在这个过程中，浏览器发送本地保存的cookie到网站A，网站A收到cookie，以为此链接是受害者发出的操作，导致受害者的身份被盗用，达到恶意攻击的目的。

例如，某系统C的超级管理员在对用户A进行管理员授权操作，以get请求向后台发送用户id，角色id。

如：http://www.xxx.com/authUser?uid=user1&role=m。

攻击者可以构造另外一个连接http://www.xxx.com/authUser?uid=user2&role=m并诱导用户点击，用户如果在浏览器打开此链接，会将之前登陆后的cookie信息一起发送给后台服务器，服务端在收到该请求之后确认cookie信息无误会完成请求操作。这样user2就有了不该有的系统C的管理权限。如果用在交易转账等场景下更会造成不可挽回的损失。

简单来说，CSRF 就是网站 A 对用户建立信任关系后，在网站 B 上利用这种信任关系，跨站点向网站 A 发起一些伪造的用户操作请求，以达到攻击的目的。

而之所以可以完成攻击是因为B向A发起攻击的时候会把A网站的cookie带给A网站，也就是说cookie已经不安全了。

对于csrf攻击可以在一些关键步骤增加二次认证的环节来加强防护，但是会带来体验上的不便利。

个人感觉最简单有效的防护手段，就是在前端请求后台服务的时候，在cookie中添加csrf_token值，并且把csrf_token值hashCode(或者其他加密方式)之后作为请求参数发送。

后台可以在拦截器中拿到cookie中的csrf_token值后得到hashCode值，然后与前端传过来的csrf_token参数值进行比较，一样则通过。

为了和样式表(Cascading Style Sheets，CSS)区分开，所以跨站脚本在安全领域叫做“XSS”。

首先举一个例子，微博、论坛等系统通常的任务就是把用户留言的内容展示出来。正常情况下，用户的留言都是正常的语言文字，留言板显示的内容也就没问题。然而这个时候如果有人不按套路出牌，在留言内容中丢进去一行。

那么当别的用户看到这一条留言的时候，浏览器解析到这一行就会弹出“hahaha!you are attacked”。

相对于csrf来说，xss的攻击原理比较简单，攻击者在web页面插入恶意的Script代码，当用户浏览该页之时，嵌入其中web里面的Script代码会被执行，从而达到恶意攻击用户的特殊目的。

根据XSS攻击的效果，可以将XSS分为2类：

反射型XSS

反射型XSS，又称非持久型XSS。也就是攻击相当于受害者而言是一次性的，具体表现在受害者点击了含有的恶意JavaScript脚本的url，而Web应用程序只是不加处理的把该恶意脚本“反射”回受害者的浏览器而使受害者的浏览器执行响应的脚本。

存储型XSS

存储型XSS，也就是持久型XSS。攻击者上传的包含恶意js脚本的留言等信息被Web应用程序保存到数据库中，Web应用程序在生成新的页面的时候如果包含了该恶意js脚本，这样会导致所有访问该网页的浏览器解析执行该恶意脚本。这种攻击类型一般常见在博客、论坛等网站中。

一般攻击者攻击某个网站都是想要达到自身的一些不好的目的，那么xss攻击有什么样的危害呢？

大概可以分为以下几种：

窃取Cookie

攻击者一般注入的JavaScript脚本都是运行在被攻击的网站www.xxx.com域名下的，这样攻击者就可以在JavaScript中通过document.cookie获取到cookie信息，再通过window.location跳转，JavaScript文件等方式向攻击者的网站发送带有Cookie的get请求，获取到Cookie内容。

造成恶意传播

例如攻击者利用JavaScript脚本，让用户发送了一个留言或者微博，其中含有反射型XSS的连接，这样每个点击连接的用户都会发送这样的内容，造成很多的传播。

按键记录

JavaScript能够记录到用户在页面上的很多操作，比如：页面的输入内容，操作点击等等。也就是说用户在登录框输入的用户名密码，身份证号码等等都可以被注入的恶意脚本记录下来并且传送出去。

了解了xss的危害之后，我们应该怎么进行防护呢，通过攻击手段和危害层面，我们认识到，防护xss的核心原则是：一切用户输入皆不可信。

总结一下主要通过以下几个方面来进行防护：

①对输入内容的特定字符进行编码，例如表示 html标记的 < > 等符号,对数据做JSON.stringify等等，服务后请求进入进行放xss攻击处理拦截处理，比如使用Filter+HttpServletRequestWrapper替换非法字符，使用StringEscapeUtils.escapeHtml()来处理，或者自定义拦截规则处理等等。

②对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie。

CSRF是攻击者控制用户的浏览器发起伪造请求，从而可以伪装用户的身份来越权获取数据或者发起一些请求。此外CSRF产生于正常的业务功能逻辑中，我们没有办法从根本上阻止攻击者，只能通过加强token认证或者在关键操作上来增加二次认证来加强系统自身的防护。而XSS是通过在用户的浏览器中注入脚本，通过脚本的提交来达到注入的目的，获取到用户的Cookie、输入信息等，预防 XSS 主要通过对用户内容的验证来完成。

总而言之，在日常业务中，开发者也需要考虑到一些基本的安全问题，做好接口防护、规范编码、尽量避免程序漏洞的产生。只有心中安全的警钟长鸣，才能让神秘的黑客无所遁形。