跨站脚本漏洞及不安全的直接对象引用

跨站脚本漏洞

当应用服务接收不被信任的数据，并且将该数据不经过验证或者字符过滤，就发送给客户的Web浏览器，就会产生XSS（Cross Site Scripting Attack）攻击。XSS攻击允许攻击者在受害者的浏览器中执行脚本，用于劫持受害者用户的会话信息，伤害特定的网站，或者重定向用户到恶意站点。）

（1）我存在XSS漏洞吗

如果我们的服务器端代码使用用户提供的输入作为HTML输出的一部分，并且不使用上下文相关的转义来确保它无法运行，则我们很容易受到服务器XSS的影响。如果网页使用JavaScript来动态地将攻击者可控数据添加到页面，那么我们可能需要注意Client XSS。理想情况下，我们将避免将攻击者可控数据发送到不安全的JavaScript API，但是可以使用输入验证来转义（并在较小程度上）进行输入验证。自动化工具能够自动找到一些跨站脚本漏洞。然而，每一个应用程序使用不同的方式生成输出页面，并且使用不同的浏览器端解释器，例如JavaScript、ActiveX、Flash、和Silverlight，这使得自动检测变得很困难。因此，要想达到全面覆盖，必须使用一种综合的方式，在自动检测的基础上，同时采用人工代码审核和手动渗透测试。类似AJAX的Web 2.0技术使得跨站脚本漏洞更难通过自动工具检测到。

（2） 我如何防止XSS

防止XSS需要将不可信数据与动态的浏览器内容区分开。

1）为了避免 Server XSS，最好的办法是根据数据将要置于的HTML上下文（包括 主体、属性、JavaScript、CSS或URL）对所有的不可信数据进行恰当的转（escape）。更多关于数据转义技术的信息见OWASP DOM XSS Prevention Cheat Sheet。

2）为了避免Client XSS，首选方案是避免将不受信任的数据传递给可生成活动内容的JavaScript和其他浏览器API。当无法避免这种情况时，类似的敏感转义技术可以应用于浏览器API，如基于OWASP DOM based XSS Prevention Cheat Sheet 。

3）更多内容请参考OWASP 的AntiSamy或者Java HTML Sanitizer项目。

4）考虑使用内容安全策略（CSP）来抵御整个网站的跨站脚本攻击。

5）除了做好以上的工作以外，区块链的Web端需要防止由于不可信数据引起的不适当智能合约的调用。

（3）攻击案例

应用程序在下面HTML代码段的构造中使用未经验证或转义的不可信的数据：

String）page += "";

攻击者在浏览器中修改“CC” 参数为如下值：

'>'.

这导致受害者的会话ID被发送到攻击者的网站，使得攻击者能够劫持用户当前会话。请注意攻击者同样能使用跨站脚本攻破应用程序可能使用的任何跨站请求伪造（CSRF）防御机制。CSRF的详细情况见本节“跨站请求伪造”内容的介绍。

不安全的直接对象引用

应用开发者有时候可能会暴露应用内部实现对象的引用，例如文件、目录、或者数据库Key等。如果没有对这些的访问控制或者其他保护，攻击者就有可能利用这些暴露的引用访问未授权的数据。

（1）我有不安全的直接对象引用吗

查找应用程序是否容易受到访问控制漏洞的最佳方法是验证所有数据和函数引用是否具有适当的防御。要确定你是否容易受到攻击，请考虑以下几点。

1）对于数据引用，应用程序是否通过使用映射表或访问控制检查确保用户获得授权，以确保用户对该数据进行授权；

2）对于非公共功能请求，应用程序是否确保用户进行了身份验证，并具有使用该功能所需的角色或权限？

应用程序的代码审查可以验证这些控件是否正确实施，并且在任何地方都需要进行审计。手动测试对于识别访问控制缺陷也是有效的。自动化工具通常不会找到这样的缺陷，因为他们无法识别需要什么保护或什么是安全的或不安全的。

（2）我如何防止

防止访问控制缺陷。需要选择一个适当的方法 来保护每一个用户可访问的对象（如对象号码、文件名）。

1）检查访问。任何来自不可信源的直接对象引用都必须 通过访问控制检测，确保该用户对请求的对象有访问权限。

2）使用基于用户或者会话的间接对象引用。这样能防止 攻击者直接攻击未授权资源。例如，一个下拉列表包含6个授权给当前用户的资源，它可以使用数字1-6来 指示哪个是用户选择的值，而不是使用资源的数据库 关键字来表示。在服务器端，应用程序需要将每个用 户的间接引用映射到实际的数据库关键字。OWASP的 ESAPI包含了两种序列和随机访问引用映射，开发人员 可以用来消除直接对象引用。

3）自动验证。利用自动化来验证正确的授权部署。 这要成为习惯.

4）尽量利用基于用户或者会话的间接对象引用区块链的智能合约和账本信息，尽量避免直接调有。

（3）攻击案例

案例 #1：应用程序在访问帐户信息的SQL调用中使用未验证数据：

pstmt.setString(1, request.getparameter("acct"));

ResultSet results = pstmt.executeQuery();

攻击者能轻易在浏览器将 “acct” 参数修改成他所想要的 任何账户号码。如果应用程序没有进行恰当的验证，攻击 者就能访问任何用户的账户，而不仅仅是该目标用户的账户。

http://example.com/app/accountInfo?acct=notmyacct

案例 #2：攻击者只是简单的强制浏览目标URL。 还需要管理员权限才能访问的管理页面。

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

如果未经身份验证的用户可以访问任何一个页面，这是一个缺陷。 如果非管理员可以访问管理页面，这也是一个缺陷。

下一章我们将介绍安全配置错误及敏感数据泄露

感谢机械工业出版社华章分社的投稿，本文来自于华章出版的著作《区块链安全技术指南》。

作者简介：

黄连金

硅谷Dynamic Fintech Group管理合伙人

吴思进

33复杂美创始人及CEO

曹锋

PCHAIN发起人，中物联区块链协会首席科学家

季宙栋

Onchain分布科技首席战略官，本体联合创始人，

马臣云

北京信任度科技CEO、信息安全专家、产品管理专家

李恩典

美国分布式商业应用公司董事与中国区总裁

徐浩铭

CyberVein数脉链项目技术负责人

翁俊杰

IBM 10余年开发及解决方案经验，批Fabric应用开发者，NEO核心开发者之一

扫描上方微信

备注“入群”，小助手拉你进群

活动多多，交流多多

矩阵财经出品

转载请注明：矩阵财经（矩阵数字经济智库）