干货|SRC漏洞挖掘经验

先谈个人经历,我虽然很早前就像挖掘SRC来锻炼自己,但真正实现起来大概也是2月初的时候。一开始在几大SRC平台,如顺丰SRC,小米SRC等装了两下,真的不知道从何入手。而且,SRC提交这事从来都是前人吃肉后人喝汤的局面,对于这样的平台,综合考虑自身的实力因素,打算先放弃挖掘这样的SRC。然后我在补天SRC开始挖掘,专属SRC的性质与前者一样,所以我先从公益SRC入手。

我是觉得公益SRC对于大佬的吸引力没那么大,对于我等菜鸡可能还能捞点菜汁吃。首个漏洞发现大概在挖掘的第二天发现的,但提交时显示名称已存在,看来大概率是已经被人发现的了,有点失望。因此,说说个人鸡贼的一面:

  • 我是从第二页公益SRC开始挖掘,因为第一页的一般都是新提交了漏洞刷新上去的,等于被人挖掘了一遍。但有些是新上架的SRC,所以我还是在服务器跑了一个检测脚本,随时发现新情况。
  • 我进入页面,首先也是先看一个报告页的"整体趋势",如果近期有新报告的,我也不看了。因为这种说明近期也有人挖掘了一遍。
  • 另外我还会看厂商漏洞情况,如果是提交了很多但没有修复多少的,我也不看了。因为这种大概率挖到重复漏洞,提交也没用。

没办法,总要"功力"点,但我挖掘的每一个SRC都会认真的看每一个点。整个补天的公益SRC,等我逐个看完也够呛的。

思路

首先是熟能生巧。我一开始挖洞时,也是看了很多网上的技巧并自己吸收,但做起来总是感觉无能为力。但现在这几天觉得越发轻松,一个网站会不会有洞,有没有隐藏的接口等,都能在几分钟内得出结论。

因为之前算是做过几个渗透测试的项目,所以对于挖洞我也是有一定的了解的。自始至终我都把关注重点放在"交互"上,这个思路也没有错。与ctf不同,每个生产环境都可能独一无二,很难在ctf中找到相似的例子。而且,关键也在于"信息收集"上。

 

流程

浏览器:谷歌(搜索引擎)、火狐(配合bp抓包)

工具:fiddler(抓js交互包)、bp(抓包、重包)

脚本;自己写的垃圾扫描器,有什么不好用的地方当场改进,挺好的。其他漏扫几乎没用过。

1.首先对应的企业网址点击"提交漏洞"按钮可以看,这个也是我首次提交报告时发现的,一开始我还怕会不会"攻击"了非授权页面,总是心惊胆战的。

2.然后我会进入网站看看,浏览器左下角会显示各个链接的url,重点关注那些带?的。如果整个网站都没几个功能,就几个展示页面,这种我就...(跳4算了,都没什么好看的)

3.跟进链接,然后就开始抓包了。等到我挖洞的时候,我才发现,即使一个网站url是:?id=123,但真正起交互的反而是后续的js刷新,即访问一个url会抓到好几个交互,第一个GET请求并不起交互作用。我发现很多网站真的很喜欢用js来发送请求,真的无语,随便就控制住了。

4.开始谷歌hack大法:

- site:domain.com filetype:xls|doc|pdf

- site:domain.com inurl:admin|login|manage

- site:domain.com intitle:管理|后台|登录

- site:domain.com intext:登录|后台、管理|error|debug

总能搜索出一点有价值的东西。搜索filetype并不是真的想看他泄露了什么敏感资料(但我真的看到有啊~),复制链接,开始网上访问,总是能找到403或"管理页面",这样的url总是暴露了使用了什么cms,如wp-content/xx/xx/,另外偶尔还能自动跳转到管理员登录页面,这又是新的发现了。

5.根据网站性质选择侧重点:

zf网站: 一般都是jsp,数据处理比PHP严禁很多,但语句有错总会返回报错信息。SQL整型的话添加不了什么字母构造payload,但可以试试整型溢出看一下SQL执行语句。

电商平台:一般会有注册登录的功能,可以尝试注册,然后修改头像昵称什么的,另外可以关注优惠券,cookie,越权等,但我遇到的很多都是用dedecms,防护做的很好。

自己diy的网站:这种看不出来是cms的,可能是自己写的前端或自己公司运营的,要么做的很棒,要么就很烂。真的可以每个功能点都试一下,也没什么好说的。但可以重点关注目录跳转。

6.这里是api的故事,如果抓包抓到返回的数据是json的话,我就会折腾上很久。每个参数都fuzz一下,看看能不能返回点什么有价值的信息。

7.说点其它的,事实上目录保护这点很多网站都没做好,总是跳转到后台编辑处,隐藏上传点等。另外,还有在生产环境中开启debug的,真的...

更新

近期越挖越累,越来越觉得自己菜。我发现自己只会挖掘一些SQL注入,信息泄露,文件上传还有已知组件缺陷的漏洞,对于某些隐藏透露的点,如报错、类型限制等,有时候感觉是洞但挖掘不了,有种无从下手的感觉。

个人收获

我感觉我并不能在这篇文章里把我是如何挖洞的说清楚,而且很多时候靠经验与知识点。
挖洞与学习新知识并不冲突,令人意外的是,挖洞遇到一些cms并去查相关cve,能记得特别劳。然后我把其中一些操作简单的都写成poc了,也方便自己。

然后说说改变的话,现在一天打开差不多10个网站进行挖掘,差不多都能肉眼识别cms了,无语。

然后期待能在挖洞中得到乐趣与知识吧。

 

### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值