基于CSRF防御的智慧道路救援系统设计

胡文生

关键词：
CSRF；
网络攻击；
智慧救援；
攻击防御；
LBS

中图分类号：TP393 文献标识码：A

文章编号：1009-3044（2023）20-0100-03

0 引言

CSRF的全称为Cross Site Request Forgery，即跨站点请求伪造[1]。该漏洞于2000年由国外网络安全人员首次发现并提出，在2006年，CSRF攻击才引起了国内安全从业人员的极大关注，2008年是CSRF漏洞集中爆发年，一些著名网站，如NYTimes.com、Metafilter、YouTube 和百度HI均报道发现网站上存在CSRF 漏洞[2-3]， 2013年OWASP（开放式Web应用程序安全项目，一个致力于解决网络安全挑战的开放式Web社区）将CSRF评价为世界十大网络安全漏洞之一[4]。但是相对于XSS（跨站脚本攻击）比较受关注来说，由于CSRF很难识别和缓解，所以长期以来CSRF不被网络从业人员重视，CSRF攻击在某些Web安全威胁分类中没有出现过，甚至有些人可能会有一种错误的印象，即针对XSS（跨站脚本攻击）问题的防御也可能针对CSRF攻击提供保护。其实XSS与CSRF攻击原理、攻击过程、防范措施以及造成的后果有很大不同，由于长期对CSRF了解的欠缺，很多Web应用系统在开发过程中没有对CSRF做有效的防范，导致目前有大量的网站存在CSRF漏洞，而且网站一旦存在该漏洞受到攻击时就很难进行防范，随时都有可能爆发，所以CSRF也被称为“沉睡的巨人”[5]。

1 CSRF 攻击原理

从图1可以看出，CSRF攻击过程中Cookie扮演很重要的角色，Cookie用于记录用户登录信息，使得用户不需要每次访问网站时都要输入用户名和密码信息，当用户登录某个网站成功后，Cookie用于实现客户端与服务器端之间的状态保持。用户C通过可信任的浏览器向可信任的服务端网站A发送连接请求，一旦用户C的账号和密码通过服务器端网站A验证后，用户C的浏览器就接受服务器端反馈回来的响应报文，该报文包含有用户登录信息的Cookies值，客户端浏览器通过获取报文中Set-Cookie首部字段信息并保存Cookie信息，形成一个小型的纯文本文件，下次客户端C再次向服务器端网站发送请求时会自动在请求报文中加入Cookie值，服务器端通过Cookie识别出发送请求的客户端是否为身份验证过程的用户。当用户成功登录网站A，在没有关闭登录网站A页面的浏览器时，不小心或者被攻击者诱导点击了攻击者伪造的一个Web应用网站B，而网站B可能包含有一段使用img、iframe等标签向可信任服务器端Web应用网站A发送的请求报文，此时，发送的请求报文带上了用户C的Cookie，于是攻击者通过伪造的Web应用网站B达到模拟合法用户C的目的，实现攻击者的目的。

2 CSRF 防范措施

攻击者可以使用CSRF攻击冒充合法用户执行属于合法用户权限的任何操作。因此，网站给予用户的权利越多，CSRF攻击就越危险，如目标用户的账户具有完全权限，这可能会破坏整个Web应用程序。然而，如果能够理解Web应用程序受到CSRF攻击的所有步骤，就可以设计对策来阻止它。为了克服CSRF 攻击，可以使用多种技术来保护服务器端的Web应用程序和客户端最终用户免受CSRF攻击。从CSRF攻击原理来看，该类攻击最主要的特点就是“冒充”合法用户达到登录Web应用程序修改数据、盗取用户信息的目的，因此，对CSRF攻击的防御主要围绕如何识别和预防合法用户的身份被攻击者“冒用”，客户端和服务器端是防御CSRF攻击的重点，从这个意义上来说CSRF保护和预防技术从宏观上可分为三大类，即客户端保护技术、服务器端保护技术、混合型保护技术[6]：1） 客户端保护技术：客户端在与服务器交互过程中主要涉及两类信息，即从客户端传出去的HTTP请求以及由服务器反馈回来的响应信息，因此客户端保护技术可以通过监视传出HTTP请求和传入响应来保护用户免受CSRF攻击。客户端保护技术与用户使用网络联系紧密，用户必须养成良好的上网习惯，如不轻易点击不信任的网址、及时退出已经登录的账户、使用HTTP代理、安装浏览器插件或反恶意软件等方式。这些解决方案涉及仅在需要CSRF保护的单个计算机上运行的应用程序（如客户端浏览器），而无须服务器端的网站干预。现有的客户端对策过于严格，它们应用暴力技术，阻止或剥离特定类型的所有跨源请求（包括GET、POST 等）的标头，这实际上可以防止CSRF攻击，但这也会破坏用户与许多依赖于经过身份验证的跨源请求的有效网站的会话。例如，使用第三方支付系统的网站或使用云计算平台的公司使用的单点登录解决方案。仅限客户端的解决方案非常少见，也不完整[7]。

2） 服务端保护技术：相对于客户端保护技术来说，服务器端保护技术可以采用的手段会更多一些，如使用Origin字段或Referer字段、添加token值、建立白名单、增加验证码等方式来防止CSRF攻击。根据HTTP协议，在HTTP 请求头部中包含有一个Refer字段，该字段记录了合法用户要访问的目标网站URL地址，服务端通过对该字段的校驗可以区分该请求是同域下还是跨站发起的，从而做出接受请求或拒绝请求的响应，但是该种防御方式有时候也可能会失效或者误伤，如有些浏览器或者攻击者利用工具可以篡改 Referer字段的值达到攻击的目的，同时用户也可以通过对浏览器设置发送HTTP请求时不提供 Referer字段，甚至单点登录时对用户一个合法的请求也做出拒绝响应。Origin字段防御原理与Referer字段类似，只不过HTML5中XHR2.0新增的功能，一般与服务端建立的白名单一起使用，不在白名单内的http请求就会遭到拒绝，该字段在一定程度上能够减轻 Referer字段引起的隐私问题，但大多数浏览器不支持该字段。添加token值比校验Referer字段效果要更可靠，为了防止攻击者冒用合法用户经过服务器端验证的身份信息（即http请求中的cookie值），可以在http请求中以参数的形式添加一个随机产生的token值，客户端每次发送http请求时都要带上token值，服务器端验证请求中的token值是否为服务器产生的并发送给客户端的随机数，若验证不通过，有可能是CSRF攻击而拒绝该请求。而验证码机制是所有服务器端防御CSRF 攻击最好的方法，该方法强制要求用户与Web应用程序之间进行实时交互，每次发送http请求之前先需要输入基于服务端判断的验证码，两者一致才能完成最终请求，攻击者很难获取验证码的值，因此该方法成为目前防御CSRF攻击的最佳方法为大多数商业网站所采用。

3） 混合型保护技术：包括客户端和基于服务器的解决方案的组合。支持CSRF的客户端应用程序可识别Web服务器漏洞，并可能阻止此类攻击。在这里，服务器应用程序同样涉及令人信服的大规模不断发展的编程工作。

从上面阐述的CSRF攻击原理和防范措施可以发现CSRF攻击者虽然需要借助于经过身份认证的合法用户的浏览器实施网络攻击，但是本质上还是对Web 服务器的攻击，这一事实导致许多防御CSRF攻击的措施都是针对服务器端的解决方案。而且现有的客户端对策需要用户的广泛参与，例如要求用户定义受信任站点的白名单或弹出用户确认对话框，很多商业网站的用户并不具备做出准确安全决策的能力。就严重程度来说，攻击者攻击服务器所获得的利益最大，对Web应用程序伤害也是最大的，因此服务器端的保护技术尤为迫切。一般Web应用程序都是由互联网企业开发并搭建服务器，作为服务提供者有义务为用户提供安全的网络服务。综合上述原因，CSRF 攻击最好的解决方案是在服务器端解决。

3 基于CSRF防御的智慧道路救援系统设计与实现

基于LBS（Location Based Services，简称LBS） 的智慧救援公共服务平台是基于现实社会需求开发设计一款Web应用系统，该系统围绕汽车救援行业的车主救援呼叫、救援过程、救援调度、救援评价、救援数据管理和应用服务等场景，重点突破车辆故障信息快速获取、救援位置服务自动获取、服务过程安全监督、评价信用机制建立、异构信息资源集成、关键过程数据信息加密存储等关键技术；
探索适合汽车救援行业与互联网、大数据等信息技术的融合发展，行业信息化服务内容、模式和技术支撑体系；
构建科学、准确、实时、安全的行业专业信息化服务平台；
实现救援“呼叫简单化、过程可视化、调度智能化、体系标准化”。基于LBS的智慧救援公共服务平台的服务端部署在第三方云服務商提供的云平台上。除了云平台提供相应的安全保护外，Web应用程序的所有者也必须根据自己系统的业务需求采取相应的安全措施，确保系统能够安全运行。

从系统的整个流程图来看，涉及注册登录、下单/ 接单、支付结算、评价等功能，作为一个Web应用程序来说，也面临其他Web应用程序所遇到的安全风险，尤其是如XSS、SQL注入、中间人、网络钓鱼、CSRF等网络攻击风险。在本系统中注册/登录、下单/接单、支付结算、评价等环节很容易受到CSRF攻击，为了保证系统安全运行，必须结合开发过程中使用的技术、云平台部署等因素综合设计一个合理的防御CSRF攻击的方案。本系统有两个地方特别需要对CSRF攻击进行预防，一个是用户注册登录阶段，另一个是与社交账号绑定的过程。前者可以采用CSRF最常用的随机生成的token进行验证的方式来进行预防。而后者则稍微复杂一些，利用OAuth2.0认证技术提供绑定功能将系统用户与其他社交账号（如微信、QQ、微博等）绑定，提升用户使用该系统快速登录的用户体验，但是OAuth2.0技术如果使用不当，很容易受到CSRF攻击[8]。OAuth2.0在整个认证流程中，攻击者将自己提前从OAuth2.0服务器中获得code 值设置为Authorization code参数的值并构造攻击网页，诱导受害者点击网页，从而使得受害者将自己在Web应用程序中的账号与攻击者的社交账号绑定，使得攻击者达到冒充受害者的合法身份登录Web 应用程序从事非法操作的目的。为防止OAuth2.0环境下的CSRF攻击，Web应用程序的开发者在设计OAuth2.0认证请求时在URL中加入值为随机字符串的state参数，OAuth2.0服务提供者返回Authorization code时，验证一起返回的state参数值，若一致，则绑定社交账号，否则拒绝。在整个过程中，OAuth2.0服务提供者相当于服务器代理，具体防范CSRF攻击过程见图5。

4 结论

跨站点请求伪造（CSRF） 攻击中，Web应用程序对其已验证用户的信任被利用，从而允许攻击者以受害者的名义进行任意HTTP请求。CSRF防范措施有很多种，然而每一种都有相应的缺陷、有一定的限制条件，当前的CSRF缓解技术存在限制其普遍适用性的缺点。因此，解决CSRF攻击问题，必须结合具体项目做出相应的安排。本文结合具体的项目，利用OAuth2.0、Node.js 等平台的特点设计一个综合防范CSRF攻击的解决方案，该解决方案提供了对CSRF攻击的多方安全保护。