HackerNews 编译，转载请注明出处： 攻击者声称通过滥用Meta旗下Facebook的应用程序接口（API）非法获取了包含12亿条用户记录的数据库，并将该数据集发布于知名数据泄露论坛。若得到证实，这将成为Facebook历史上最大规模的数据泄露事件之一。 网络安全媒体Cybernews研究团队对攻击者提供的10万条样本数据进行核查，发现其中包含用户ID、姓名、电子邮箱、用户名、电话号码、地理位置、生日及性别等敏感信息，初步分析显示样本数据格式完整且逻辑合理。但研究人员对“12亿条全新数据”的宣称持审慎态度，因该攻击者此前仅发布过两次数据帖，推测可能通过分批次爬取累积至此规模。 此次事件再次暴露Facebook在API安全防护上的系统性缺陷。2021年曾有攻击者泄露超5亿用户电话号码与地理位置信息，导致欧盟罚款2.65亿欧元。研究人员指出，此类重复性事件表明Meta在数据安全措施上长期采取被动应对策略，尤其在保护公开可见但依然敏感的隐私数据方面存在严重疏漏。缺乏有效防护机制使数亿用户面临钓鱼攻击、金融诈骗及身份盗用风险。 攻击者利用此类大规模数据库可实施自动化攻击，例如向用户精准推送伪装成Facebook登录页面的钓鱼链接，或结合地理位置与生日信息设计定向诈骗剧本。安全专家强调，攻击者通过API接口超量获取数据已成行业顽疾，Shopify、GoDaddy等平台近年均遭遇类似攻击。API作为现代互联网服务的基础组件，其滥用问题亟待技术性与监管层面的双重解决方案。 Meta此前承认使用公开的Facebook与Instagram数据训练AI助手，此举引发隐私合规争议。目前Meta尚未就此次泄露事件发表声明，爱尔兰数据保护委员会正评估事件影响范围。欧盟监管部门重申将依据GDPR第25条“通过设计保护数据”原则，加大对科技企业数据滥用行为的处罚力度。安全社区建议用户立即启用双重验证并监控账户异常活动。       消息来源：cybernews； 本文由 HackerNews.cc 翻译整理，封面来源于网络； 转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 网络安全研究人员近日发现，一些加密货币相关的npm包遭到劫持，攻击者通过这些包从受感染的系统中窃取环境变量等敏感信息。 Sonatype研究员Ax Sharma表示：”其中一些包已在npmjs.com上存在超过9年，为区块链开发者提供了合法功能。然而，这些包的最新版本中被植入了混淆的恶意脚本。” 受影响的npm包及版本： country-currency-map (2.1.8) bnb-javascript-sdk-nobroadcast (2.16.16) @bithighlander/bitcoin-cash-js-lib (5.2.2) eslint-config-travix (6.3.1) @crosswise-finance1/sdk-v2 (0.1.21) @keepkey/device-protocol (7.13.3) @veniceswap/uikit (0.65.34) @veniceswap/eslint-config-pancake (1.6.2) babel-preset-travix (1.2.1) @travix/ui-themes (1.1.5) @coinmasters/types (4.8.16) 软件供应链安全公司对这些包的分析显示，攻击者在”package/scripts/launch.js”和”package/scripts/diagnostic-report.js”中植入了高度混淆的恶意代码。这些脚本会在包安装后立即运行，专门窃取API密钥、访问令牌、SSH密钥等数据，并将其发送到远程服务器（”eoi2ectd5a5tn1h.m.pipedream[.]net”）。 有趣的是，相关库的GitHub代码库并未被篡改，攻击者是如何成功推送恶意代码的仍是一个谜。目前尚不清楚此攻击活动的最终目的。 Sharma表示，他们推测这些劫持事件可能是由于旧版npm维护者账户被攻破所致。攻击者可能通过凭证填充攻击（使用此前数据泄露中的用户名和密码在其他网站上尝试登录）或接管过期域名的方式，取得了这些账户的控制权。 鉴于多个项目的维护者账户几乎在同一时间受到攻击，研究人员认为账户接管的可能性高于精心策划的网络钓鱼攻击。 此次事件凸显了为账户启用双因素认证（2FA）以防止账户接管的必要性。它还反映出在开源项目达到生命周期末期或停止维护时，实施安全防护措施的难度。 Sharma强调：”这次事件进一步表明了加强供应链安全措施的紧迫性。开发者和企业在开发过程的每个阶段都应优先考虑安全性，以降低第三方依赖带来的风险。”   消息来源：The Hacker News；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： Cloudflare宣布，已关闭所有HTTP连接，现在仅接受api.cloudflare.com的安全HTTPS连接。 此举旨在防止未加密的API请求被发送，即使是意外发送的，也会在服务器关闭HTTP连接并重定向到安全通信通道之前，消除敏感信息在明文流量中暴露的风险。 “从今天起，任何未加密的连接到api.cloudflare.com都将被完全拒绝，”Cloudflare周四的公告中写道。 “开发者不应再期望HTTP连接出现403禁止响应，因为我们将通过完全关闭HTTP接口来阻止底层连接的建立。只允许建立安全的HTTPS连接，”这家互联网服务公司补充道。 Cloudflare API帮助开发者和系统管理员自动化和管理Cloudflare服务。它用于DNS记录管理、防火墙配置、DDoS防护、缓存、SSL设置、基础设施部署、访问分析数据以及管理零信任访问和安全策略。 此前，Cloudflare系统允许通过HTTP（未加密）和HTTPS（加密）访问API，要么通过重定向，要么拒绝HTTP。 然而，正如公司所解释的，即使被拒绝的HTTP请求也可能在服务器响应之前泄露敏感数据，如API密钥或令牌。 当连接通过公共或共享Wi-Fi网络时，这种场景更加危险，因为中间人攻击更容易得逞。 通过完全禁用API访问的HTTP端口，Cloudflare在传输层屏蔽了明文连接，在任何数据交换之前强制执行HTTPS。 影响和下一步行动 这一变化立即影响了使用Cloudflare API服务的HTTP协议的任何人。依赖该协议的脚本、机器人和工具将中断。 同样适用于遗留系统和自动客户端、物联网设备以及由于配置不当而不支持或不默认使用HTTPS的低级客户端。 对于在Cloudflare上有网站的客户，公司计划在年底前推出一个免费选项，以安全的方式禁用HTTP流量。 Cloudflare数据显示，所有通过其系统的互联网流量中，仍有约2.4%是通过不安全的HTTP协议进行的。当考虑到自动化流量时，HTTP的份额跃升至近17%。 客户可以在仪表板的“分析与日志”>“通过SSL提供的流量”下跟踪HTTP与HTTPS流量，然后再选择加入，以评估这对他们环境的影响。   消息来源：Bleeping Computer；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 最新分析发现，在公开爬取的网络数据中，DeepSeek 的 11,908 条 API 密钥、密码及身份验证令牌遭到曝光。 据网络安全公司 Truffle Security 披露，这一研究凸显了 AI 模型在未经筛选的互联网数据训练下，可能会内化并复现不安全的编码模式。 此前已有研究表明，大型语言模型（LLM）常建议在代码中硬编码凭据，这引发了关于训练数据如何影响开发实践的讨论。 Truffle Security 通过扫描 Common Crawl 2024 年 12 月的数据集（约 400TB 数据，覆盖 47.5 万个网站、26.7 亿个网页），利用其开源工具 TruffleHog 发现： 11,908 条有效凭据，可用于访问 AWS、Slack、Mailchimp 等服务； 276 万个网页 含有暴露的凭据，其中 63% 的密钥 被多个域名重复使用； WalkScore API 密钥 在 1,871 个子域 上重复 57,029 次，暴露范围极广。 特别值得注意的是，部分数据集涉及高风险暴露，例如： AWS 根密钥 直接嵌入前端 HTML 代码； 同一网页的聊天功能中 硬编码了 17 个独特的 Slack webhook。 Mailchimp API 密钥泄露尤为严重，超 1,500 例，且大多直接嵌入客户端 JavaScript 代码，这种做法不仅助长了网络钓鱼攻击，也增加了数据泄露风险。 Common Crawl 的数据集包含 90,000 份 WARC 文件，存储了网站爬取的 HTML、JavaScript 及服务器响应数据。 Truffle Security 使用 20 节点 AWS 集群 处理这些存档，借助 awk 拆分文件，并通过 TruffleHog 逐一验证密钥是否仍然有效。该工具能区分有效凭据（可用于服务认证）和无效字符串——这是 LLM 训练时无法做到的关键步骤。 研究团队在分析过程中面临基础设施挑战：WARC 数据流式处理效率低，初期严重拖慢分析进度，而 AWS 优化后下载速度提升了 5-6 倍。 尽管面临技术难题，研究团队仍秉持负责任的披露原则，与 Mailchimp 等供应商合作，撤销了数千条泄露的密钥，避免了逐个联系网站所有者的低效通知方式。 这一研究揭示了一项重大安全隐患：基于公开数据训练的 LLM 可能继承其中的不安全模式。尽管 DeepSeek 采用额外的安全防护措施（如微调、对齐技术和提示限制），但硬编码凭据的广泛存在，使得不安全实践易于被模型学习并传播。 此外，非功能性凭据（如占位符令牌）也加剧了问题，因为 LLM 在代码生成时无法识别其有效性。 Truffle Security 警告，在多个客户端项目中重复使用 API 密钥 会带来极大风险。例如，一家软件公司因在多个客户域名间共享 Mailchimp 密钥，导致所有关联账户均面临攻击风险。 为减少 AI 生成代码中的安全漏洞，Truffle Security 建议： 在 AI 编码工具中引入安全防护措施，如 GitHub Copilot 的自定义指令，以强制执行禁止硬编码密钥的政策； 扩展密钥扫描范围，涵盖存档的网络数据，以减少历史泄露数据进入 LLM 训练集的风险； 采用“宪法 AI”技术，使 LLM 生成代码时更符合安全最佳实践，降低敏感信息的无意泄露。 随着 LLM 在软件开发中的影响力持续上升，确保训练数据的安全性已不再是可选项，而是构建安全数字未来的基础。   消息来源：Cybersecurity News；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文

HackerNews 编译，转载请注明出处： 近日，ExHub 被发现存在一个关键的不安全直接对象引用（IDOR）漏洞，该漏洞允许攻击者在未经授权的情况下修改任何项目的网页托管配置，对受影响系统构成重大风险。 ExHub 是一个基于云的平台，提供网页托管、项目协作和部署功能。用户可以配置其项目的网页托管设置，这些设置决定了项目如何部署和被访问。理想情况下，只有授权用户才能修改这些设置。然而，由于访问控制的不当实现，未授权用户可以通过知道项目的唯一标识符来利用系统。 该漏洞存在于 ExHub 的项目部署配置 API 中。具体来说，该 API 缺乏 robust 的授权检查，使得任何用户（无论其角色或认证状态）都可以发送精心构造的请求来修改托管设置。 漏洞利用过程技术复杂度较低： 获取项目 ID：攻击者需要获取一个有效的项目 ID，这可以通过枚举或其他间接手段获得。 构造未授权的 API 请求：通过向漏洞端点 /api/v1/projects/deployment_configuration/<projectid>发送 POST 请求，攻击者可以修改关键的托管参数。 执行请求：使用工具如 Burp Suite 或 Postman 就足以执行攻击并实时观察更改。 验证更改：攻击者可以通过 ExHub 的用户界面确认修改。 该漏洞实际上允许未授权用户执行诸如更改机器类型、端口和 DNS 配置等管理操作，这些操作本应仅限于高权限角色。 漏洞影响 该 IDOR 漏洞的后果严重，攻击者可以操纵部署配置，可能获得对敏感资源的未经授权访问。配置错误可能导致服务中断或无法访问。此外，被利用的配置可能使攻击者能够提升权限或链式攻击以进行进一步利用。 漏洞修复 ExHub 采取了以下措施来解决此漏洞： 在所有 API 端点引入严格的授权检查。 通过实施随机化技术使项目 ID 更难以预测。 重构用户角色以强制执行最小权限原则。 教训 此次事件为开发者和组织提供了几个关键教训： 授权检查至关重要：每个 API 端点都必须严格验证用户权限。 避免可预测的标识符：使用容易猜测的 ID 会增加被利用的风险。 最小权限原则：根据用户角色限制其操作，以最小化配置错误可能造成的损害。 全面测试：安全测试应包括后端 API，以发现诸如 IDOR 之类的隐藏漏洞。 通过实施严格的访问控制并采用安全设计原则，公司可以保护其平台免受利用，并建立用户信任。   消息来源：Cybersecurity News；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文

近期， Imperva 发布的《2024 年 API 安全状况报告》中提到，2023 年的大部分互联网流量（71%）都是由 API 调用，通过 API 传输的大量互联网流量应该引起每一位网络安全专家的关注。 目前，尽管大部分企业已经尽最大努力采用了左移框架和 SDLC 流程，但 API 仍经常在编目、验证或审计之前就被嵌入到了业务流程中（企业在生产中平均拥有 613 个 API 端点），随着当下向客户更快、更高效地交付数字服务的压力不断增加，这一数字也在迅速扩大。 随着时间推移，API 可能会成为有风险、易受攻击的端点。 Imperva 在报告中指出，鉴于API 是访问敏感数据的直接途径，早已成为网络威胁攻击者的常见攻击载体。事实上，Marsh McLennan 网络风险分析中心的一项研究发现，与 API 相关的安全事件每年给全球企业造成的损失高达 750 亿美元。 API 调用量越高，会出现更多安全问题 值得一提的是，研究发现相比其他行业，银行业和在线零售业在 2023 年的 API 调用量最高，这两个行业都依赖大型 API 生态系统向客户提供数字服务。网络威胁攻击者使用各种”手段“攻击 API 端点，其中一个常见的攻击载体便是账户接管（ATO）。当网络威胁攻击者利用 API 身份验证流程中的安全漏洞，未经授权访问账户时，就会发动这种攻击。 2023 年，近一半（45.8%）的 ATO 攻击以 API 端点为目标，这些”企图“通常是以恶意机器人的形式通过自动化来实现（注:恶意机器人是指怀有恶意运行自动化任务的软件代理)。考虑到银行以及其他金融机构管理的客户数据信息价值，ATO 是一个非常令人担忧的业务风险。 这种攻击一旦成功，网络威胁攻击者就会立刻锁定受害者的账户，盗取敏感数据。不仅仅造成经济损失，还会增加违规风险。 为什么管理不善的 API 会带来安全威胁 目前来看，因为没有受到合理的监管，以及缺乏足够的身份验证控制，导致每 10 个应用程序接口中就有近一个容易受到网络攻击，降低 API 的安全风险具有很大挑战，即使最成熟的安全团队也会为此感到”棘手“。其中主要的问题源于软件开发的快节奏，以及缺乏成熟的工具和流程来帮助开发人员和安全团队更好地协同工作。 Imperva 在报告中指出了影子 API、废弃 API 和未认证 API三种常见的 API 端点管理不善类型，它们会给企业带来安全风险： 影子 API： 这些 API 也称为未记录或未发现的 API，它们不受监督、被遗忘和或不在安全团队的可见范围内。据 Imperva 估计，影子 API 占每个组织活动 API 集合的 4.7%。如果不对这些 API 端点进行适当的编目或管理，就会出现安全问题。 企业应该关注影子 API，它们通常可以访问到敏感信息，但没有人知道它们的存在位置或连接内容。一个影子 API 就可能导致合规违规和监管罚款，更有甚者，有动机的网络犯罪分子会滥用它来访问企业的敏感数据。 废弃的 API： 废弃 API 端点是软件生命周期中的一个自然过程。因此，随着软件的快速、持续更新，被废弃的 API 并不少见。 事实上，据 Imperva 估算，已废弃的 API 平均占企业活动 API 集合的 2.6%。当端点被废弃时，支持此类端点的服务就会更新，对废弃端点的请求就会失败。但是，如果服务没有更新，API 也没有删除，端点就会因为缺乏必要的补丁和软件更新而变得脆弱。 未经验证的 API： 未验证的 API 通常是由于配置错误、匆忙发布过程中的疏忽或为适应旧版本软件而放宽了严格的验证过程而引入的。这些应用程序接口平均占企业活动应用程序接口集合的 3.4%。未经身份验证的 API 的存在给企业带来了巨大的风险，因为它可能会将敏感数据或功能暴露给未经授权的用户，从而导致数据泄露或系统操纵。 为降低管理不善的 API 带来的各种安全风险，建议企业进行定期审计，以识别未监控或未经身份验证的 API 端点。此外，开发人员应定期更新和升级 API，以确保用更安全的替代品取代过时的端点。 如何最大程度降低 API 的安全风险 API 的安全风险与日俱增，严重影响了企业正常经营生产。对此，Imperva 提出了几项建议，以帮助企业改善 API 安全状况： 发现、分类和清查所有 API、端点、参数和有效载荷，使用持续发现来维护始终最新的 API 清单，并披露敏感数据的暴露情况； 识别并保护敏感和高风险 API，执行风险评估，特别是针对易受授权和身份验证漏洞以及过度数据暴露影响的 API 端点； 为 API 端点建立强大的监控系统，主动检测和分析可疑行为和访问模式； 采用 API 安全方法，将 Web 应用程序防火墙 (WAF)、API 保护、分布式拒绝服务 (DDoS) 防范和僵尸程序保护整合在一起。   转自Freebuf，原文链接：https://www.freebuf.com/news/395332.html 封面来源于网络，如有侵权请联系删除

苹果公司宣布，从今年秋开始，开发者提交的App若需要调用某些API，需要在提交之前给出详细的调用理由，以确保开发人员不会滥用 API 进行用户的指纹识别。 苹果表示，有一小部分 API 可能被滥用，通过指纹识别收集有关用户设备的数据，这是我们的开发者计划许可协议所禁止的。 该项措施旨在保证应用程序遵守“必要原因使用API”的规定，开发人员必须选择一个或多个与其应用程序的 API 使用情况准确一致的调用理由，且仅限于在所选定的范围内调用API。目前苹果已经将Apple Developer 网站上的将部分 API 标记为“Required Reason APIs”（需提供调用理由的API）。 此外，从2024年春季开始，开发人员还必须在应用程序的隐私清单中包含经批准的API调用原因，才能上传新应用程序或应用程序更新。 但苹果也表示，若一些API有调用的确切必要性，但未被列入能够获批的范围内，需要开发人员提供用例，来证明用户能够从中获益。 近一年来苹果在加强系统及应用安全性上采取了不少措施。自iOS16发布以来，苹果带来了新的iPhone 用户安全和隐私的功能，包括锁定模式和安全检查功能。锁定模式旨在保护一些特定群体免受罕见和高度复杂的网络攻击；安全检查功能旨在为那些人身安全受到直接威胁的人提供了一个账户安全和隐私权限的紧急重置选项，切断他们与攻击者的联系。     转自Freebuf，原文链接：https://www.freebuf.com/news/373444.html 封面来源于网络，如有侵权请联系删除

近日，Cequence Security发布了其2022年上半年的报告，题目为 “API保护报告。影子API和API滥用的爆炸性增长”。其中最主要的发现是，约有50亿（31%）的恶意交易针对未知的、未被管理和未被保护的API，通常被称为影子API，这使其成为挑战行业的首要威胁。 Cequence Security首席执行官Ameya Talwalkar说：”现实情况是，我们作为消费者享受的日常奢侈品，如共享单车和食品配送服务，都是建立在API上的。我们的研究发现，企业可以创新客户体验，但新的方式也是对其安全、客户信任的最大威胁。公司必须重新思考在其安全战略中优先考虑的内容，首先是API保护。 该报告基于对2022年上半年观察到的200多亿次API交易的分析，旨在强调当今困扰企业的顶级API威胁。   顶级威胁1： 31%的恶意攻击针对影子API 在观察到的167亿次恶意请求中，大约有50亿次（31%）针对未知的、未管理的和未受保护的API，通常被称为影子API，跨越了广泛的使用案例。从试图抢购最新款Dunks或Air Jordans的高容量运动鞋机器人，到试图用被盗信用卡进行缓慢的卡片测试欺诈的隐蔽攻击者，再到纯粹的蛮力塞入凭证活动。在作为购物机器人和礼品卡攻击前兆的大批量内容搜刮的推动下，对影子API的攻击在2022年4月激增，并在全年持续上升。   顶级威胁2：API滥用 根据CQ Prime威胁研究团队阻止的36亿次攻击，2022年上半年缓解的第二大API安全威胁是API滥用，即攻击者针对正确编码和清点的API。这一发现强调了使用像OWASP这样的行业标准列表作为起点的必要性，而不是最终目标。最受阻的攻击表明了攻击者正在使用的策略。   30亿针对运动鞋或奢侈品的购物机器人 2.9亿次礼品卡检查攻击 试图在流行的约会和购物应用程序上创建约2.37亿个假账户   顶级威胁3：邪恶的三位一体。凭证填充、影子API和敏感数据暴露 基于1亿次攻击，API2（破坏用户认证）、API3（数据过度暴露）和API9（资产管理不当）的综合使用标志着两件事：攻击者正在对每个API的工作方式、它们之间的互动方式以及预期结果进行详细分析，开发人员需要在遵循API编码最佳实践方面保持永远的警惕。 Cequence安全公司威胁研究部主任William Glazier说：”我们的分析和发现是基于野外的真实攻击。我们的发现强调了IT和安全领导对正确编码的API以及有错误的API如何被攻击的全面了解的重要性。仅200亿的样本量就意味着各行业的企业很有可能受到这些类型的威胁影响。” 此外，报告强调，了解攻击者用来利用风险的战术、技术和程序（TTPs）的重要性，以及攻击者将如何应对抵抗。这意味着不仅要确保API不容易受到OWASP API安全10强的影响作为起点，而且要研究什么可以被定义为API10+，这个类别包含了一个完美编码的API可能被滥用的许多不同方式。   转自 E安全，原文链接：https://mp.weixin.qq.com/s/-9hMCDpT-Wuwm6C98jRZ_g 封面来源于网络，如有侵权请联系删除