API安全性讨论

最新推荐文章于 2024-08-08 10:27:10 发布
最新推荐文章于 2024-08-08 10:27:10 发布
阅读量889 收藏 2
点赞数
分类专栏： 1 技术文章 # 2.web安全
原文链接：https://github.com/smodnix/31-days-of-API-Security-Tips/blob/master/README.md
版权

This API Security Tips

-API TIP: 1/31-

较旧的API版本往往更容易受到攻击，并且缺乏安全机制。利用REST API的可预测性质来查找旧版本。看到有api/v3/login？检查是否也api/v1/login存在。它可能更容易受到攻击。

-API TIP: 2/31-

永远不要假设只有一种方法可以对API进行身份验证！现代的应用程序有许多API端点AuthN登录方式：/api/mobile/login| /api/v3/login| /api/magic_link; 等等。查找并测试所有AuthN问题。

-API TIP:3/31-

还记得5到10年前SQL注入曾经非常普遍的时候，并且您可以进入几乎每家公司吗？BOLA（IDOR）是API安全性的新流行。

更多有关BOLA的细节 : https://medium.com/@inonst/a-deep-dive-on-the-most-critical-api-vulnerability-bola-1342224ec3f2

-API TIP: 4/31-

测试Ruby on Rails应用程序并注意到HTTP参数包含URL？开发人员有时会使用"Kernel#open" 功能来访问URLs == Game Over。只需发送管道作为第一个字符，然后发送shell命令（这里会有命令注入）

Learn more about the open function: https://apidock.com/ruby/Kernel/open

-API TIP:5/31-

SSRF用于：

内部端口扫描
利用云服务（例如169.254.169.254）
使用http://webhook.site来显示IP地址和HTTP库
下载很大的文件（Layer 7 DoS）
反射SSRF？公开本地mgmt控制台

-API TIP: 6/31-

批量分配是一件实事。现代框架鼓励开发人员在不了解安全隐患的情况下使用MA。在开发过程中，不要猜测对象的属性名称，只需找到一个返回所有属性名称的GET端点即可。
在这里插入图片描述

- API TIP: 7/31 -

公司向开发人员公开API？这与移动/ Web应用程序使用的API不同。始终单独测试它们。不要以为它们实现了相同的安全机制。

- API TIP: 8/31 -

REST API的Pentest？给它一个机会，并检查API是否也支持SOAP。将内容类型更改为“ application / xml”，在请求正文中添加一个简单的XML，然后查看API如何处理它。

Sometimes the authentication is done in a different component that is shared between REST & SOAP APIs == SOAP API may support JWT

If the API returns stack trace with a DUMPling, it’s probably vulnerable**

- API TIP: 9/31 -

Pentest APIs？BOLA (IDOR) vulnerabilities? HTTP正文/标题中的ID往往比URL中的ID更容易受到攻击。尝试先专注于它们。

-API TIP: 10/31-

利用BFLA（损坏的功能级别授权）？利用REST的可预测性来查找admin API端点！例如：您看到了以下API调用 GET /api/v1/users/<id>
给它一个机会，然后更改为 DELETE / POST to create/delete users.*

- API TIP: 11/31 -

API使用授权标头？忘了CSRF！如果身份验证机制不支持cookie，则会通过设计防止API受CSRF的攻击。

-API TIP : 12/31-

正在测试BOLA（IDOR）？即使ID是GUID或非数字，也请尝试发送数字值。例如：/?user_id=111而不是user_id=inon@traceable.ai 有时候验证机制同时支持和更容易蛮力号码。

-API TIP: 13/31-

*使用批量分配绕过安全机制。例如，“输入密码”机制：

  • POST /api/reset_pass 需要旧密码。
  • PUT /api/update_user
    容易受到MA攻击==可用于更新通行证而无需发送旧的通行证（对于CSRF）*
- API TIP: 14/31 -

在API渗透测试中卡住了吗？扩大攻击面！使用http://Virustotal.com和http://Censys.io查找子/兄弟域。其中一些域可能会公开具有不同配置/版本的相同API。

-API TIP:15/31-

静态资源==照片，视频… Web服务器（IIS，Apache）在授权时会以不同方式对待静态资源。即使开发人员实施了体面的授权，您也很有可能访问其他用户的静态资源。

-API TIP: 16/31-

即使您使用其他Web代理，也始终在后台使用Burp。@PortSwigger的家伙在帮助您管理笔测方面做得非常好。使用“树状视图”（免费版本）功能可查看您已访问的所有API端点。

-API TIP:17/31-

*Mobile Certificate Pinning?

移动证书固定？在开始反向工程和修补客户端应用程序之前，请检查iOS和Android客户端以及它们的旧版本。在其中一个中没有启用固定功能的可能性很大。省时间。

-API TIP: 18/31-

公司和开发人员倾向于将更多资源（包括安全性）投入到主要API中。始终寻找没人能用来找到有趣漏洞的最利基功能。

  • POST /api/profile/upload_christmas_voice_greeting
-API TIP:19/31-

您发现哪些功能更容易受到攻击？ 我将开始：

  • 组织的用户管理
  • 导出为CSV / HTML / PDF
  • 仪表板的自定义视图
  • 子用户创建和管理
  • 对象共享（照片，帖子等）
- API TIP:20/31-

测试AuthN API？
如果您在生产中进行测试，则AuthN端点很有可能具有反暴力保护。无论如何，DevOps工程师倾向于在非生产环境中禁用速率限制。别忘了测试它们:)

此问题的一个很好的例子：Facebook Breach（由@sehacure创建）http://www.anandpraka.sh/2016/03/how-i-could-have-hacked-your-facebook.html

-API TIP:21/30-

在API渗透测试中卡住了吗？扩大攻击面！使用http://archive.com，找到该Web应用程序的旧版本并浏览新的API端点。无法使用客户端？扫描.js文件中的URL。其中一些是API端点。

-API TIP:22/31-

API倾向于通过设计泄漏PII。BE工程师返回原始JSON对象，并依靠FE工程师过滤掉敏感数据。找到了敏感资源（例如receipt）？找到所有返回它的每股收益/download_receipt，/export_receipt等等。

一些端点可能会泄漏用户不应该访问的过多数据。

This is an example for OWASP Top 10 For APIs - #3 - Excessive Data Exposure

-API TIP:23/31-

找到了一种从Web服务器下载任意文件的方法？
将测试从黑盒转移到白盒。下载应用程序的源代码（DLL文件：使用IL-spy；已编译的Java-使用Luyten）阅读代码并查找新问题！

-API TIP:24/31-

在API渗透测试中卡住了吗？扩大攻击面！切记：开发人员经常在非生产环境（qa / staging / etc）中禁用安全机制；利用这一事实绕过AuthZ，AuthN，速率限制和输入验证。

-API TIP:25/31-

找到了“导出为PDF”功能？开发人员很有可能使用外部库在后台转换HTML-> PDF。尝试注入HTML元素并导致“导出注入”。

Learn more about Export Injection: https://medium.com/@inonst/export-injection-2eebc4f17117

-API TIP:26/31-

在API中寻找BOLA（IDOR）？有401/403错误？AuthZ绕过技巧：

  • 用数组包装ID- {“id”:111}>{“id”:[111]}
  • JSON包装{“id”:111}->{“id”:{“id”:111}}
  • 两次发送ID URL?id=&id=
  • 发送通配符 {“user_id”:"*"}

In some cases, the AuthZ mechanism expects a plain string (an ID in this case), and if it receives a JSON instead it won’t perform the AuthZ checks. Then, when the input goes to the data fetching component, it might be okay with a JSON instead of string(e.g: it flattens the JSON)

-API TIP:27/31-

BE服务器不再负责防御XSS。API不返回HTML，而是返回JSON。如果API返回XSS有效负载？- {“name”:"Inon} 很好！保护始终需要在客户端

-API TIP:28/31-

.NET应用程序的Pentest？找到包含文件路径/名称的参数？开发人员有时会使用“ Path.Combine（path_1，path_2）”创建完整路径。Path.Combine具有奇怪的行为：如果param＃2是绝对路径，则param＃1被忽略。
利用它来控制路径

了解更多信息：https : //www.praetorian.com/blog/pathcombine-security-issues-in-aspnet-applications

Leverage it to control the path

Learn more: https://www.praetorian.com/blog/pathcombine-security-issues-in-aspnet-applications

-API TIP:29/30-

API公开了应用程序的基础实现。渗透测试者应利用这一事实更好地了解用户，角色，资源及其之间的相关性，并发现很酷的漏洞和漏洞。始终对API响应感到好奇。

-API TIP:30/31-

在API渗透测试中卡住了吗？扩大攻击面！如果API具有移动客户端，请下载APK文件的旧版本以探索旧的/旧版功能并发现新的API端点。

Remember: companies don’t always implement security mechanisms from day one && DevOps engineers don’t often deprecate old APIs. Leverage these facts to find shadow API endpoints that don’t implement security mechanism (authorization, input filtering & rate limiting)

下载旧的APK版本的android应用程序： https://apkpure.com

-API TIP: 31/31-

找到了limit/ pageparam？（例如：）/api/news?limit=100它可能容易受到第7层DoS的攻击。尝试发送一个长值（例如limit=999999999：），看看会发生什么：）

数据安全（API反爬虫）之「防重放」策略

在大前端时代的安全性一文中讲了 Web 前端和 Native 客户端如何从数据安全层面做反爬虫策略，本文接着之前的背景，将从 API 数据接口的层面讲一种技术方案，实现数据安全。

一、 API 接口请求安全性问题

API 接口存在很多常见的安全性问题，常见的有下面几种情况

  1. 即使采用 HTTPS，诸如 Charles、Wireshark 之类的专业抓包工具可以扮演证书颁发、校验的角色，因此可以查看到数据
  2. 拿到请求信息后原封不动的发起第二个请求，在服务器上生产了部分脏数据（接口是背后的逻辑是对 DB 的数据插入、删除等）

所以针对上述的问题也有一些解决方案：

  1. HTTPS 证书的双向认证解决抓包工具问题
  2. 假如通过网络层高手截获了 HTTPS 加证书认证后的数据，所以需要对请求参数做签名
  3. 「防重放策略」解决请求的多次发起问题
  4. 请求参数和返回内容做额外 RSA 加密处理，即使截获，也无法查看到明文。

关于 HTTPS 证书双向认证和 Web 端反爬虫技术方案均在大前端时代的安全性一文中有具体讲解。接下来引出本文主角：防重放

二、 请求参数防篡改

在之前的文章也讲过，HTTPS 依旧可以被抓包，造成安全问题。抓包工具下数据依旧是裸奔的，可以查看Charles 从入门到精通文中讲的如何获取 HTTPS 数据。

假如通过网络层高手截获了 HTTPS 加证书认证后的数据，所以需要对请求参数做签名。步骤如下

  • 客户端使用约定好的密钥对请求参数进行加密，得到签名 signature。并将签名加入到请求参数中，发送给服务端
  • 服务端接收到客户端请求，使用约定好的密钥对请求参数（不包括 signature）进行再次签名，得到值 autograph
  • 服务器对比 signature 和 autograph，相等则认为是一次合法请求，否则则认为参数被篡改，判定为一次非法请求

因为中间人不知道签名密钥，所以即使拦截到请求，修改了某项参数，但是无法得到正确的签名 signature，这样构造的一个请求，会被服务器判定为一次非法请求。

三、 防重放策略

在工程师文化中，我们要做一个事情，就首先要对这个事情下个定义。我们才能知道做什么、怎么做。

理论上，一个 API 接口请求被收到，服务会做校验，但是当一个合法请求被中间人拦截后，中间人原封不动得重复发送该请求一次或多次，这种重复利用合法请求进行得攻击被成为重放。

重放会造成服务器问题，所以我们需要针对重放做防重放。本质上就是如何区别去一次正常、合法的请求。

3.1 基于 timestamp 的方案

理论上，客户端发起一次请求，到服务端接收到这个请求的时间，业界判定为不超过60秒。利用这个特征，客户端每次请求都加上 timestamp1，客户端将 timestamp1 和其他请求参数一起签名得到 signature，之后发送请求到服务器。

  • 服务器拿到当前时间戳 timestamp2，timestap2 - timestamp1 > 60s，则认为非法
  • 服务端接收到客户端请求，使用约定好的密钥对请求参数（不包括 signature、timestamp1）进行再次签名，得到值 autograph。比对 signature 和 autograph，若不相等则认为是一次非法请求

假如中间人拦截到请求，修改了 timestamp 或者其他的任何参数，但是不知道密钥，所以服务器依旧判定为非法请求。
中间人从抓包、篡改参数、发起请求的过程一般来说大于60秒，所以服务器依旧会判定为非法请求。

基于 timestamp 的设计缺陷也很明显，种种原因下，60秒内的请求，会钻规则漏洞，服务器判定为一次合法请求。

3.2 基于 nonce 的方案

既然时间戳会有漏洞，那么新方案是基于随机字符串 nonce。也就是说每次请求都加入一个随机字符串，然后将其他参数一起利用密钥加密得到签名 signature。服务端收到请求后

  • 先判断 nonce 参数是否能存在于某个集合中，如果存在则认为是非法请求；如果不存在，则将 nonce 添加到当前的集合中
  • 服务端将客户端请求参数（除 nonce）结合密钥加密得到 autograph，将 signature 和 autograph 比对，不相等则认为非法请求

但是该方案也有缺点，因为当次的请求都需要和集合中去搜索匹配，所以该集合不能太大，不然匹配算法特别耗时，接口性能降低。所以不得不定期删除部分 nonce 值。但是这样的情况下，被删除的 nonce 被利用为重放攻击，服务器判定为合法请求。

假设服务器只保存24小时内请求的 nonce，该存储仍旧是一笔不小的开销。

3.3 基于 timestamp + nonce 的方案

根据 timestamp 和 nonce 各自的特点：timestamp 无法解决60秒内的重放请求；nonce 存储和查找消耗较大。所以结合2者的特点，便有了 「timestamp + nonce 的防重放方案」。

  • 利用 timestamp 解决超过60秒被认为非法请求的问题
  • 利用 nonce 解决 timestamp 60秒内的漏网之鱼

步骤：

  1. 客户端将当前 timestamp1、随机字符串和其他请求参数，按照密钥，生成签名 signature
  2. 服务端收到请求，利用服务端密钥，将除 timestamp1、随机字符串之外的请求参数，加密生成签名 autograph
  3. 服务端对比 signature 和 autograph，不相等则认为非法请求
  4. 拿到服务端时间戳， timestamp2 - timestamp1 < 60，则判定为一次合法请求，然后保存 nonce
  5. 服务端只保存60秒内的 nonce，定时将集合内过期的 nonce 删除

该集合不应该直接操作文件或者数据库，否则服务端 IO 太多，造成性能瓶颈。可以是 mmap 或者其他内存到文件的读写机制。根据场景可以选择乐观锁、悲观锁。

其中有一个 timestamp 的问题，服务器会将请求参数中的 timestamp 判断差值，其中一个致命的缺点是服务器的时间和客户端的时间是存在时间差的，当然你也可以通过校验时间戳解决此问题。时间同步请继续看下面部分。

四、 计算机网络时间同步技术原理

客户端和服务端的时间同步在很多场景下非常重要，举几个例子，这些场景都是经常发生的。

  • 一个商品秒杀系统。用户打开页面，浏览各个类目的商品，商品列表界面右侧和详情页都有倒计时秒杀功能。用户在详情页加购、下单、结算。发现弹出提示“商品库存不足，请购买同类其他品牌商品”
  • 一个答题系统，题目是该公司核心竞争力。所以有心的程序员为接口设计了「防重放」功能。但是前端小哥不给力，接口带过去的 timestamp 与服务器不在一个时区，差好几秒。别有用心的竞品公司的爬虫工程师发现了该漏洞，爬取了题目数据。

所以该现象在计算机领域有非常普遍，有解决方案。

  1. 如果精度要求不高的情况下：先请求服务器上的时间 ServerTime，然后记录下来，同时记录当前的时间 LocalTime1；需要获取当前的时间时，用最新的当前时间 (LocalTime2 - LocalTime1 + ServerTime)

    拿 iOS 端举例：

    • App 启动后通过接口获取服务器时间 ServerTime，保存本地。并同时记录当前时间 LocalTime1
    • 需要使用服务器时间时，先拿到当前时间 LocalTime2 - LocalTime1 + ServerTime
    • 若获取服务器时间接口失败，则从缓存中拿到之前同步的结果（初始的时间在 App 打包阶段内置了）
    • 使用 NSSystemClockDidChangeNotification 监测系统时间发生改变，若变化则重新获取接口，进行时同步

  2. 如果需要精度更高，比如 100纳秒的情况，则需要使用 NTP（Network Time Protocol）网络时间协议、PTP （Precision Time Protocol）精确时间同步协议了。

NTP、PTP 不在本文的范畴，感兴趣的可以查看这篇文章

参考：

All of this information is taken from twitter of Inon Shkedy

https://github.com/smodnix/31-days-of-API-Security-Tips/blob/master/README.md

Links:
tangsilian
关注
专栏目录
RESTful API的版本管理、安全性、可用性、文档和测试、监控
程序员光剑
08-06 852
REST (Representational State Transfer) 是一种架构风格，它定义了一组约束条件和原则。它主要用于客户端和服务器之间交换数据，通过一系列的REST API调用来实现服务。REST是基于HTTP协议标准化的一种Web服务接口标准。RESTful API是一种遵循REST规范的API。REST API的版本管理每个新版本的REST API都应该有其文档。RESTful API的版本管理可以有效防止API的过时或废弃，并让开发者清楚地知道自己在使用的哪个版本的API。
API接口安全性设计
ShootCode
04-08 7311
接口的安全性主要围绕Token、Timestamp和Sign三个机制展开设计，保证接口的数据不会被篡改和重复调用，下面具体来看：Token授权机制：用户使用用户名密码登录后服务器给客户端返回一个Token（通常是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。时间戳超时机制：用户每次请求都带上当前时间
API安全问题
whxwkb的博客
05-06 1170
解决方案： 其中防止窃取可以用：RSA非对称加密算法，使用公私钥进行加解密 MD5一般使用加盐（字符串）方法，前后台统一盐。 token授权：主要使用拦截器对所有方法进行校验token，token可以存到redis中加时效校验。能够防止一定得爬虫。 微信、qq、钉钉等的登陆中都使用到了access_token进行校验，在登录时生成传到第三方进行存储。 ...
怎么应对API 成批分配问题？
最新发布
m0_50736744的博客
08-08 533
API 成批分配利用可能导致特权升级、数据篡改、绕过安全机制。对于POST请求，如果请求时body里存在后台不需要的字段，但是响应成功
「译」API 安全最佳实践，不要等出事后“捶胸顿足”
HelloGitHub 的博客
10-26 1158
原文地址：API Security Best Practices[1]原文作者：Mark Michon译者 & 校正：HelloGitHub-小鱼干 & HelloGit...
API接口安全问题浅析
Fly_鹏程万里
02-22 1342
随着互联网的快速发展，应用程序接口(API)成为了不同系统和服务之间进行数据交换和通信的重要方式，然而API接口的广泛使用也引发了一系列的安全问题，在当今数字化时代，API接口安全问题的重要性不容忽视，恶意攻击者利用漏洞和不当的API实施，可能导致数据泄露、身份验证问题以及系统的完整性和可用性受到威胁，本文将探讨API接口安全问题的重要性并介绍常见的安全威胁和挑战，还将探讨如何保护API接口免受这些威胁并介绍一些最佳实践和安全措施。
api的安全问题
weixin_30399797的博客
04-03 111
在给第三方系统提供api时，我们需要注意下安全问题。 比较常见的接口有http接口。以http接口为例。我们需要注意的几点： 1.只有被允许的系统才可以调用api 2.如果http请求被截获。也不能随便修改接口中的参数。 在运维方面，可以添加访问白名单。白名单中有一系列的ip地址。只有白名单中的ip才可以访问api。但是这样会给运维造成麻烦。比如应用的ip可能会变化。 下面说...
从API治理角度看API安全2022企业信息安全峰会（脱敏
11-19
本篇文章将从API治理的角度深入探讨API安全，并结合2022年企业信息安全峰会上的讨论进行分析。 API治理是对API的全面管理，包括设计、开发、部署、监控和维护等各个阶段，其核心目标是确保API的质量、性能、安全和...
开放式API安全防护的七大原则
热门推荐
架构精进之路
01-19 2万+
我是架构精进之路，点击上方“关注”，坚持每天为你分享技术干货，私信我回复“01”，送你一份程序员成长进阶大礼包。 在我们日常工作程序开发过程中，难免会涉及与第三方系统进行数据的交互与...
从S-SDLC视角看API安全.pdf
08-07
问题讨论部分涉及了几个具体的API安全案例，包括API如何被滥用、数据批量和敏感信息泄露的风险以及理想与现实之间的矛盾。例如，开发人员可能由于便利性考虑，或不知道某些API的超级管理员权限，导致API被滥用。或是...
API安全测试的思路与基于Swagger的API自动化安全测试实践.pdf
08-07
本篇文章围绕API安全测试，首先探讨应用安全的基础问题，然后深入讨论传统REST API安全测试，最后基于Swagger工具讲述自动化安全测试的实践。 ### 应用安全基础 在讨论API安全测试之前，我们必须了解应用安全的...
appscan_api_Demo:适用于AppScan演示的小型易受攻击的api
03-31
appscan_api_Demo 适用于AppScan演示的小型易受攻击的api
关于API 的安全性的问题
HUA1211的博客
03-25 478
Salt最近的研究甚至发现，每个客户的平均api数量在过去一年中增长了82%，从2021年7月的89个跃升至2022年7月的162个。Salt Security调查发现，尽管行业正在推动向左移位，但只有22%的行业专业人士将向左移位功能视为最重要的需求，相比之下，41%的人将在运行时阻止攻击的能力视为最关键的属性。当然，这些措施是值得的，但94%的受访者报告了最近的API安全事件，很明显，左移策略并没有达到标准。随着API攻击的数量和复杂性的增加，是时候以不同的方式处理API安全了。还记得左移的缺点吗?
API 的安全性
Anzexi123的博客
02-12 2486
API 的安全性
API安全
fly_miqiqi的博客
03-04 682
文章目录jwt(Json Web Token)引入jwt扩展jwt信息通过refresh_token刷新令牌使用jwt实现ssoCAS vs oauth2API安全API安全的目标CIAAPI的风险和解决防止注入攻击API风险的防范具体流控 429太多请求认证参数效验密码加密Http加密审计日志授权 401认证失败 403认证成功，但授权失败登陆sesison固定攻击 SSO 单点登录（...
API接口的安全性
Sujingkai的博客
04-12 1157
接口的安全性主要围绕Token、Timestamp和Sign三个机制展开设计，保证接口的数据不会被篡改和重复调用，下面具体来看： Token授权机制：用户使用用户名密码登录后服务器给客户端返回一个Token（通常是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。Token是客户端访问服务端的凭证。...
API接口安全
phlf74的博客
08-08 1万+
API接口安全 1      基本概念 API（Application Programming Interface，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。 简单的说，就是通过某一预先定义的渠道读/写数据的方式。 例如： 条形码查询：http://xxxx.com/
浅谈API接口中的安全性
qq_42011355的博客
10-14 1899
前言 在我们平时进行前后端分离项目开发和调用外部功能时，都会使用API接口形式与服务器进行数据通信，而对于网页或者app，只要通过抓包就可以清楚的知道这个请求获取到的数据，数据充满着被盗用、伪造的风险，所以如何保证API调用时数据的安全性是个非常重要的问题。 通常的解决方案有： 1、通信使用https 2、请求签名，防止参数被篡改 3、时间戳超时机制 4、防重放，防止接口被第二次请求，防采集 一、通信使用HTTPS 为了解决在使用HTTP时出现这种情况：用户注册的请求在到达服务器之前，就已经被人截获了，用户
API 接口的安全处理
API
03-16 9397
背景 开放 API 接口如果没有经过安全处理，则很容易出现三类安全问题，包括信息截获、篡改与泄露。 首先是用户密码容易被截获，比如某家公司在开发开放式 API 时，没有对其进行安全控制，那么该公司的客户信息很容易被黑客截获，黑客在掌握客户的用户名、密码等相关信息与资料后，便能够利用客户的身份来登录，使得客户的隐私信息泄露，黑客便可以轻易地盗刷客户信用卡，使得客户承受损伤；其次是表单数据很容易被篡改，比如某家公司所开发的开放 API 并没有进行过防篡改控制，有客户在购买1000 元产品后，其提交表单被黑客利用
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值