一条SQL注入引出的惊天大案2:无限战争

前情回顾:

经过黑衣人和老周的合作,终于清除了入侵Linux帝国的网页病毒,并修复了漏洞。不曾想激怒了幕后的黑手,一场新的风雨即将来临。

详情参见:一条SQL注入引出的惊天大案

风云再起

小Q是Linux帝国网络部负责TCP连接的公务员。

一直以来工作都很轻松,加班也少,但自从小马哥到Linux帝国开设了nginx公司,小Q的工作量一下就大了起来,经常加班,为此小Q背后没少抱怨。

一大早,nginx按时启动,绑定了80端口监听,开始了今天的营生。

没过多久,今天的第一个客户来了。

小Q还是如往常一样,收到这个带有SYN标记的数据包后,创建了一个连接请求块,然后将其放入80端口归属的连接请求队列中,回复了一个带有SYN和ACK标记的数据包后,开启了一个定时器,等待第三次握手的完成。

没等多久,这个客户就发来了回信,三次握手完成。小Q把这个连接请求块转移到了80端口对应的连接就绪队列中,并按下了铃铛。

听到铃声的nginx线程从epoll_wait函数中醒来,调用accept函数,从队列中拿到了这个新来的客户,开始服务。

这就是小Q的日常,他已经干这份工作太久了,轻车熟路。

很快到了深夜,小Q准备打个盹儿,这么晚估计是没有活干了。

没想到刚躺下,就来了一个连接请求,小Q揉揉惺忪的睡眼,准备来处理,然后接着很快来了第二个,第三个,第四个······

奇怪的是,每一个客户只发送了一个SYN就没了音讯,眼看着连接请求队列里的请求块越来越多,最后实在没有空间安放新的请求块,小Q开始意识到情况不妙,拉响了帝国安全警报······

全军出击

十分钟前······

“快醒醒,有消息来了“,还在sleep的阿D被唤醒了。

“上峰总算想起我了,我来到Windows帝国都快一个月了,一直没有指示,只是让我保持静默,我都憋坏了。”,阿D伸了伸懒腰,起身调用recv函数取到了消息:

读完消息后,阿D使用原始套接字构造了一个TCP数据包,将SYN标记点亮,伪造了一个源IP地址,将其发送了出去。

经过一通路由转发,这个数据包终于来到Linux帝国,却迟迟没有人来接待,侧目望去,原来,已经有数不清的TCP包堵在门口,还有无数类似的TCP包正在源源不断的涌入……

SYN Flood

此刻,帝国高层正在召开紧急会议。

防火墙:“现在有无数的网络连接进来,为了帝国的安全,我只好先关闭了网络,把那些数据包挡在外面。”

小马哥:“需要赶紧采取措施,恢复正常,我们nginx公司每秒钟都在丢失大量的客户,这是一笔巨额损失!”

帝国安全部长:“小Q,你把当前的形势介绍一下,大家一起来出谋划策。”

小Q:“好的。TCP的三次握手想必诸位都有所了解,收到SYN数据包后,我需要准备一个数据块来存储客户端的信息,敌军正是瞄准了这一点,给我发送大量SYN数据包,我就需要分配大量的数据块,直到把帝国空间耗尽。”

小马哥:“抱歉,我打断一下,你为何不及时把无效的数据块释放掉,腾出空间呢?”

小Q:“当然有,我有一套超时机制,超时以后第三次握手还没来,我就会给释放掉。但现在问题是敌军声势浩大,刚刚腾出的空间马上又会被挤占。”

小马哥:“那简单,你把超时时间调小一点,尽快释放无效的数据块不就行了!”

小Q:“要是太小了,正常的用户因为网络原因,时延比较大的,这不就误伤了吗?”

小马哥:“嗯,这个你们自己权衡一下,取一个合适的值,如今也没有其他办法,赶紧恢复生产才是!”

安全部长:“小Q,先这样试试看”

小Q:“行吧,我这就去”



······半小时后······



小Q:“大人,我已经按照指示执行,不过网络连接越来越多,这一招恐怕支撑不了太久,还是早做打算才是。”

安全部长:“WAF公司呢,你们有什么办法没有?”

WAF公司黑衣人:“大人,我们关注的业务在于web应用安全,此次的SYN Flood,实非我等擅长。”

现场陷入了久久的沉默……

良久,防火墙打破了沉默:“小Q,为何非得在收到第一次握手SYN数据包后就建立数据块?如果把数据块的建立时间放在第三次握手之后呢?”

小Q:“如果一开始不用建立数据块占用空间,那确实解决了大麻烦!不过,不建立数据块,那如何把客户端的信息保存起来呢?”

防火墙:“保存什么信息?”

小Q:“客户端的IP、端口、序列号这些啊。”

防火墙:“这些信息在第三次握手来的数据包中也有啊,不用提前存起来嘛!”

小Q:“说的也是,唉,还是不对,第三次握手我得校验对方发来的ACK是不是我在第二次发给他的序列号+1,如果我提前不分配数据块把我发给他的序列号存起来,到时候就没办法校验了呀!不行,还是得提前存下来!”

防火墙:“有没有什么办法,不用提前存,也能做校验呢?”

小Q:“这,这怎么做?”

防火墙:“有了!第二次发给客户端的序列号,如果不是一个随机值,而是根据客户端信息和其他信息综合计算出来的一个哈希值,收到第三次握手的时候,我们拿到客户端答复的ACK,再重新计算一次哈希值,如果哈希值+1=ACK,那就能对得上,反之就是错误的包,直接丢弃!”

还没等小Q回过神,安全部长起身鼓掌:“妙哉!这真是一个绝妙的点子!小Q,就按这个办法,赶紧去办!”

绝处逢生

小Q回到工作岗位,按照防火墙提供的思路修改了策略。随后,通知防火墙重新打开网络码头,但究竟效果如何,小Q心里还是捏了一把汗。

网络恢复的一刹那,无数TCP SYN数据包涌了进来,这一次,小Q不再分配数据块,只是快速计算了一个哈希值作为序列号,回复给了客户端。小Q忙的满头大汗,但看到存储空间总算没有疯狂增长,小Q心里长舒了一口气。

收到消息的会议室里响起了热烈的掌声!

安全部长:“本次经历值得牢记,我们给这个方案取个名字吧,告知比特宇宙其他的帝国,帮助大家一起抵抗黑暗势力的侵扰。”

WAF黑衣人抢先发言:“我觉得这个方式关键点在于把校验信息的存储从服务器放到了客户端,有点类似web技术中的Cookie。要不咱们就叫做SYN Cookie吧!”

防火墙:“嗯,这个名字好,总结的很到位”

一个小时后,疯狂的TCP SYN数据包潮水逐渐退去,Linux帝国终于恢复了往日的宁静,nginx公司的业务也恢复了正常。小Q抬头一看,天边已经微亮,这漫长的夜晚总算是熬过去了。

未完待续·······

彩蛋

“大人,Linux帝国有防火墙、WAF一帮人守卫,我们的攻击没有起到什么效果。”

“你以为他们真的是靠自己的本事胜利的吗?这次只是给他们点教训,我们的游戏才刚刚开始。”

欲知后事如何,请关注后续精彩......

精彩回顾:

一条SQL注入引出的惊天大案

内核地址空间大冒险:系统调用

闯荡Linux帝国:nginx的创业故事

一个HTTP数据包的奇幻之旅

远去的传说:安全软件群雄混战史

我是一个流氓软件线程

产品vs程序员:你知道www是怎么来的吗?

比特宇宙-TCP/IP的诞生

我是一个IE浏览器线程

我是一个杀毒软件线程

我是一个explorer的线程

原文地址:https://www.cnblogs.com/xuanyuan/p/12185799.html

时间: 2024-10-08 20:48:40

一条SQL注入引出的惊天大案2:无限战争的相关文章

一条短信控制你的手机! Android平台的SQL注入漏洞浅析

14年11月笔者在百度xteam博客中看到其公开了此前报告给Google的CVE-2014-8507漏洞细节——系统代码在处理经由短信承载的WAP推送内容时产生的经典SQL注入漏洞,影响Android 5.0以下的系统.于是对这个漏洞产生了兴趣,想深入分析看看该漏洞的危害,以及是否能够通过一条短信来制作攻击PoC. 在断断续续的研究过程中,笔者发现了SQLite的一些安全特性演变和短信漏洞利用细节,本着技术探讨和共同进步的原则,结合以前掌握的SQLite安全知识一同整理分享出来,同各位安全专家一

sql注入总结

本实验测试是基于sqli-labs的实验环境 环境配置:php+mysql 环境搭建请参考 http://www.freebuf.com/articles/web/34619.html Sql注入定义: 就是通过把sql命令插入到web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行的sql命令的目的 sql注入分类: 基于联合查询 基于错误回显 基于盲注,分时间盲注和布尔型的盲注 基于user-agent 基于feferer 基于cookie 二次注入 宽字节注入 注入一个网站

SQL注入-攻入Apple ID钓鱼网站实录

之前写的一篇利用SQL注入方式攻击钓鱼网站的文章,现在在博客园再分享一下. 下午,朋友发了一条朋友圈,内容大概这样: 大体就是她的iPhone丢了,收到了钓鱼短信,多么熟悉的套路,如下: 还好她比较机智,发现是个钓鱼网站,地址如下: http://www.apple-icloudid.com.cn 当时看到这件事后,想到之前有巨巨顺势搞定钓鱼网站,所以我也想小试牛刀一下,看看能否攻入钓鱼网站后台. 在试了几轮PHP常见后台地址后,比如/admin,/index.php/admin,均未奏效,索性

[转载]我的WafBypass之道(SQL注入篇)

现在位置: 首页 > 文章 > Web安全 > 正文 我的WafBypass之道(SQL注入篇) 2016 /11/23 16:16 6,444 评论 3 条 [本文转自安全脉搏战略合作伙伴先知技术社区 原帖地址  安全脉搏编辑huan9740整理发布] 0x00 前言 去年到现在就一直有人希望我出一篇关于waf绕过的文章,我觉得这种老生常 谈的话题也没什么可写的. 很多人一遇到waf就发懵,不知如何是好,能搜到的各 种姿势也是然并卵. 但是积累姿势的过程也是迭代的,那么就有了此文,用来

什么是SQL注入?(理解)

SQL注入攻击是黑客对数据库进行攻击的常用手段之一.一部分程序员在编写代码的时候,没有对用户输入数据的合法性进行判断,注入者可以在表单中输入一段数据库查询代码并提交,程序将提交的信息拼凑生成一个完整sql语句,服务器被欺骗而执行该条恶意的SQL命令.注入者根据程序返回的结果,成功获取一些敏感数据,甚至控制整个服务器,这就是SQL注入.

那些年我们一起挖掘SQL注入 - 2.全局防护Bypass之UrlDecode

0x01 背景 现在的WEB程序基本都有对SQL注入的全局过滤,像PHP开启了GPC或者在全局文件common.php上使用addslashes()函数对接收的参数进行过滤,尤其是单引号.遇到这种情况我们就需要找一些编码解码的函数来绕过全局防护,这篇文章讲urldecode()的情况,同样大牛请自觉绕道~漏洞来源于乌云:http://www.wooyun.org/bugs/wooyun-2014-050338 0x02 环境搭建 看背景我们使用了低版本的easytalk程序,版本为X2.4①源码

通过SQL注入实施DDOS攻击的方法

在这之前,我先介绍一下此方法的思路和原理,以便让大家更好地理解这种攻击方法.我们知道,如果一个网站存在sql注入漏洞,那么我们就能让网站数据库执行我们的sql语句,并得到相应的输出(当然,有些情况下是没有回显的).所以我们有了一个思路:构造一条足够复杂的sql语句,让数据库去执行,以此来消耗Web服务和数据库的资源,耗尽服务器资源,我们甚至也可以让数据库达到其最大连接数,让数据库不能再去回应其它合法用户的连接请求. 目前,整个思路已经很清晰了,我们可以开始构造复杂的sql语句了. sql为我们提

jdbc mysql crud dao模型 sql注入漏洞 jdbc 操作大文件

day17总结 今日内容 l JDBC 1.1 上次课内容总结 SQL语句: 1.外键约束:foreign key * 维护多个表关系! * 用来保证数据完整性! 2.三种关系: * 一对多: * 一个客户可以对应多个订单,一个订单只属于一个客户! * 建表原则: * 在多的一方创建一个字段,作为外键指向一的一方的主键!!! * 多对多: * 一个学生可以选择多个课程,一个课程也可以被多个学生选择! * 建表原则: * 创建第三张表,第三张表中放入两个字段,作为外键分别指向多对多双方的主键! *

如何使用PDO查询Mysql来避免SQL注入风险?ThinkPHP 3.1中的SQL注入漏洞分析!

当我们使用传统的 mysql_connect .mysql_query方法来连接查询数据库时,如果过滤不严,就有SQL注入风险,导致网站被攻击,失去控制.虽然可以用mysql_real_escape_string()函数过滤用户提交的值,但是也有缺陷.而使用PHP的PDO扩展的 prepare 方法,就可以避免 sql injection 风险. PDO(PHP Data Object) 是PHP5新加入的一个重大功能,因为在PHP 5以前的php4/php3都是一堆的数据库扩展来跟各个数据库的