HTML本地存储漏洞检测技巧

本篇文章向大家介绍《HTML本地存储漏洞检测方法》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

答案：HTML本地存储漏洞核心在于敏感数据（如认证令牌、PII）的明文存储与XSS等攻击结合导致泄露。检测需从数据内容、流向和逻辑三方面入手，通过浏览器开发者工具审查键值、篡改权限标识、注入XSS payload；结合代码审计追踪setItem/getItem的数据源与用途，排查客户端授权绕过风险；利用SAST/DAST工具自动化识别XSS与敏感信息泄露，并通过渗透测试模拟组合攻击，验证实际危害。

HTML本地存储（localStorage和sessionStorage）的漏洞检测，核心在于识别应用程序是否在这些客户端存储中不当地存放了敏感数据，或者在处理存储数据时存在跨站脚本（XSS）等安全缺陷，导致数据泄露或功能滥用。这不仅仅是看有什么数据，更要看这些数据如何被使用，以及在何种场景下可能被攻击者利用。

解决方案

要系统地检测HTML本地存储的漏洞，我们需要结合手动检查、代码审计和自动化工具，从数据内容、数据流向和应用逻辑三个维度进行深入分析。这就像侦探破案，既要查看现场（浏览器存储），也要审阅案宗（代码），还要模拟犯罪（渗透测试）。

localStorage和sessionStorage存储了哪些敏感信息会引发漏洞？

说实话，每次我看到一些应用把用户凭证、认证令牌甚至部分个人身份信息（PII）直接塞进localStorage或sessionStorage，心里都会咯噔一下。这就像把银行卡密码写在便利贴上，然后贴在电脑屏幕旁边，虽然方便，但风险显而易见的。

具体来说，以下几类信息是存储在本地存储中最容易引发安全漏洞的“雷区”：

1. 认证令牌（Authentication Tokens）和会话ID（Session IDs）： 这是最常见的。比如JWT（JSON Web Tokens）或者其他形式的会话标识符。如果这些令牌被存储在localStorage，意味着它们长期存在，一旦发生XSS攻击，攻击者可以轻易地窃取这些令牌，进而劫持用户会话。sessionStorage相对好一点，因为它在浏览器会话结束时会清除，但XSS的即时风险依然存在。我甚至见过直接把密码哈希值存进去的，虽然哈希了，但如果应用逻辑不严谨，或者哈希算法被破解，依然是巨大的风险。
2. 个人身份信息（PII）： 用户的姓名、邮箱、电话、地址等，甚至是支付信息的一部分。这些信息一旦被窃取，可能导致隐私泄露，甚至被用于钓鱼或其他欺诈行为。虽然很多应用会声称“仅用于提升用户体验”，但数据一旦离开服务器，进入客户端，其安全保障等级就大大降低了。
3. 敏感配置或应用状态： 比如用户的权限级别（isAdmin: true）、某些关键功能的开关状态。如果这些信息被攻击者篡改，可能会导致权限提升或功能绕过。我曾遇到过一个案例，前端通过localStorage存储一个role字段，后端仅仅是根据这个字段来渲染UI，而真正的权限校验却是在后端完成的。但如果前端逻辑依赖这个字段来决定某些操作是否可见，那攻击者就可以通过修改这个值来“解锁”UI上的功能，虽然后端会拦截，但这种误导性本身就是一种缺陷。
4. API密钥或敏感配置参数： 有些开发者为了方便，会将一些用于调用第三方服务的API密钥或者其他敏感的配置参数直接存储在本地。这无疑是给攻击者开了一扇门，一旦密钥泄露，可能导致第三方服务被滥用，产生经济损失或数据泄露。

这些信息的共同点是，它们对用户或系统具有重要价值，并且一旦被未经授权的实体获取或修改，就可能导致严重的后果。本地存储本身没有加密机制，也不是为存储敏感数据而设计的。它更适合存储非敏感的用户偏好、缓存数据等，并且即使是这些，也需要警惕XSS的风险。

如何通过浏览器开发者工具检查localStorage和sessionStorage的安全问题？

浏览器开发者工具，简直是前端安全测试的“瑞士军刀”。它能让你直接窥探应用在客户端的“内心世界”。检查localStorage和sessionStorage的安全问题，我的步骤通常是这样的：

1. 打开开发者工具： 这不用多说，F12或者右键“检查”就行。
2. 导航到“Application”选项卡： 在这里，你会看到左侧有一个“Storage”部分，下面有“Local Storage”和“Session Storage”。点击你想要检查的域名，就能看到存储在其中的键值对。
3. 初步数据审查：
   • 看键名： 扫一眼键名，有没有一眼看上去就“很敏感”的词，比如token、jwt、session、user、password、creditCard、api_key等等。这些都是高风险信号。
   • 看值： 仔细查看对应的值。它们是明文吗？如果是JSON，展开看看里面的内容。有没有个人信息？有没有看起来像加密字符串但实际上是base64编码的明文？（很多“加密”只是编码，一解码就露馅了）。
   • 数据量： 如果某个键的值特别大，比如存储了整个用户对象，那更需要警惕，因为XSS攻击者可以轻松地把这些数据打包发送出去。
4. 尝试篡改数据： 这是非常关键的一步。
   • 修改权限标识： 比如，如果看到一个键叫isAdmin，值是false，尝试把它改成true。然后刷新页面或者尝试执行只有管理员才能进行的操作。如果应用逻辑仅仅依赖这个客户端的值来决定权限，那么恭喜你，你可能发现了一个客户端授权绕过漏洞。当然，一个设计良好的应用会在后端进行严格的权限校验，但这不影响我们尝试。
   • 修改用户ID： 如果有userId或类似的键，尝试改成其他用户的ID。看看刷新后，应用是否会显示其他用户的信息。这可能导致水平权限绕过。
   • 注入XSS Payload： 这是一个更高级的测试。如果你发现应用会把用户输入存储到本地存储中，并且在其他地方又会把这个存储的值渲染到页面上，那么你可以尝试输入一个XSS payload（例如：）到某个输入框，让它被存储。然后，访问应用中会渲染这个值的地方，看是否会弹窗。如果弹窗了，说明存在存储型XSS，而本地存储就是这个XSS的存储介质。
5. 观察应用行为： 在操作这些存储数据后，多刷新页面，多点击不同功能，看看应用逻辑是否受到影响。有时候漏洞不会立即显现，而是在特定操作后才触发。

我个人经验是，很多时候，通过这种手动审查和篡改，就能发现不少低级但影响不小的安全问题。这就像是站在攻击者的角度，去思考如何利用这些暴露在客户端的数据。

除了手动检查，还有哪些更深入的代码审计和自动化检测方法？

仅仅依靠浏览器开发者工具的表面检查是不够的，尤其对于复杂应用或深层逻辑缺陷，我们需要更深入的手段。这就像我们已经看了犯罪现场，现在需要去翻阅嫌疑人的日记和作案工具。

1. 代码审计（Static Application Security Testing - SAST的思维）：

代码审计是发现本地存储漏洞最直接也最彻底的方法之一。我的做法通常是：

• 搜索关键词： 在整个前端代码库中搜索localStorage.setItem、sessionStorage.setItem、localStorage.getItem、sessionStorage.getItem。这些是所有操作本地存储的入口点。
• 追踪数据流：
  • 写入（setItem）： 对于每一个setItem操作，分析它存储的是什么数据。这些数据来源是哪里？是用户输入？是后端返回的敏感信息？还是前端生成的配置？特别关注那些直接将用户输入未经处理就存入本地存储的代码。
  • 读取（getItem）： 对于每一个getItem操作，分析读取出来的数据被用在了哪里。
    • 渲染到DOM： 如果数据被用于innerHTML、document.write、jQuery的html()等方法，并且没有经过严格的HTML实体编码或净化，那么就存在存储型XSS的风险。我见过不少应用，把用户评论存到localStorage，然后直接innerHTML出来，这就是典型的XSS漏洞。
    • 用于API请求： 如果读取出来的令牌或ID被用于构建API请求头或请求体，那么这些令牌或ID的安全性就至关重要。
    • 用于逻辑判断： 如果getItem的值被用于决定用户权限、功能可见性等关键业务逻辑，那么需要确保这些判断在后端也有严格的校验，防止客户端篡改绕过。
• 关注认证和授权逻辑： 任何依赖本地存储作为唯一认证或授权凭证的逻辑都是极其脆弱的。理想情况下，认证令牌应该存储在HttpOnly的cookie中，以防止XSS攻击窃取。如果非要用本地存储，也必须辅以强大的后端校验机制，并且令牌本身应有严格的有效期和刷新机制。
• 敏感信息加密： 如果确实需要在本地存储敏感但非关键的数据，有没有进行客户端加密？虽然客户端加密并非万无一失（密钥通常也存在客户端），但至少能增加攻击者获取明文的难度。通常，不建议在本地存储敏感信息。

2. 自动化检测工具（Dynamic Application Security Testing - DAST）：

自动化工具在发现一些模式化的漏洞方面非常高效，但对于逻辑漏洞的发现能力有限。

• Web漏洞扫描器（如Burp Suite, OWASP ZAP）：
  • XSS检测： 这些工具可以爬取应用，识别所有输入点，并尝试注入各种XSS payload。如果它们能检测到某个payload被存储在本地存储中，并在后续请求中被执行，就会报告存储型XSS漏洞。它们也能帮助发现反射型XSS，如果反射型XSS能将数据写入本地存储，那也值得关注。
  • 敏感信息泄露： 有些工具可以配置规则，扫描HTTP响应和本地存储，查找信用卡号、社会安全号、API密钥等敏感信息模式。
  • 代理分析： 在使用这些工具作为代理时，可以观察HTTP请求和响应，看是否有敏感数据在传输过程中被发送到客户端，并随后被存储在本地存储中。
• SAST工具： 专业的SAST工具（如SonarQube、Checkmarx、Fortify等）可以对代码进行深度静态分析，它们有能力识别出localStorage.setItem后接着innerHTML的这种典型XSS模式。它们通常会提供详细的报告，指出代码中的潜在漏洞点和数据流向。不过，这类工具部署和配置相对复杂，且可能存在误报。

3. 渗透测试（Penetration Testing）：

渗透测试是最高级别的检测方法，它结合了前两者的思路，并加入了人工的智慧和经验。

• 模拟攻击场景： 渗透测试人员会站在攻击者的角度，系统地尝试利用本地存储中的数据。比如，如果发现一个XSS漏洞，他们会尝试编写一个JavaScript代码，去窃取localStorage中的所有令牌，然后发送到自己的服务器。
• 组合攻击： 有时，本地存储的漏洞本身不致命，但结合其他漏洞（如CSRF、不安全的CORS配置）可能会产生更大的危害。渗透测试人员会尝试将这些漏洞串联起来，构建复杂的攻击链。
• 业务逻辑漏洞： 自动化工具很难发现业务逻辑漏洞。但渗透测试人员可以通过修改本地存储中的数据，尝试绕过业务流程、提升权限或访问未经授权的功能。

总的来说，一个健壮的安全检测流程，应该是从代码编写阶段就引入SAST，开发和测试阶段结合DAST和手动审查，最后在上线前或定期进行专业的渗透测试。本地存储虽然方便，但它的安全性边界和使用场景，开发者必须牢记于心。

本篇关于《HTML本地存储漏洞检测技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！