在
解决方法是：
$(“table tbody td”).click(function(e){
if(e.target.nodeName.toUpperCase() == “INPUT”){
alert(“It’s an input!”);
return;
}else{
alert(“It’s not an input!”);
}
});
SQL 注入，永不过时的黑客技术
TalkTalk的信息泄漏事件导致约15万人的敏感信息被暴露，涉嫌造成这一事件的其中一名黑客使用的并不是很新的技术。事实上，该技术的「年纪」比这名15岁黑客还要大两岁。
［译注：TalkTalk是英国电话和宽带供应商，这件信息安全事故发生在2015年10月份，当时这件事情还挺轰动的，上了新闻头条，其中一名黑客年仅15岁。］
这项技术就是大名鼎鼎的SQL注入，所谓SQL注入就是黑客在网站的提交表单数据中输入恶意命令从而获取数据的方法。它曾经被用来窃取世界卫生组织员工的信息，偷过华尔街日报数据，甚至还攻击过美国联邦政府机构。
“这是最简单的黑客技术”，w0rm 告诉 Motherboard［译者注：Motherboard就是这篇文章原文所在网站］，他是一名匿名黑客，声称对华尔街日报的攻击负责。整个攻击过程只用了几个小时。
但是，正因为它是比较简单的技术，同时经常被用来从公司或者政府机构窃取数字信息，所以SQL注入攻击应该相对来说比较容易防范才对。
但为何到了2015年，SQL注入攻击仍然能导致最大规模的信息泄漏事件呢?
有迹可循的最早SQL注入攻击的记录大概是Jeff Forristal在黑客杂志Phrack上发表的文章。Forristal当时是rain.forest.puppy的掌舵人［译者注：rain.forest.puppy是一个安全咨询组织，或者说，是个黑客团队？：）］，他目前在网络安全公司Bluebox，负责移动安全方面的CTO。
“微软声称，你看到的都不是问题，所以不用费心去处理它”
［译者注：这是有人给微软报告SQL server这个漏洞时，微软的回复］
SQL, 全称为结构化查询语言，是一种用来管理数据库的编程语言。本质上说，他就是被网站用来从数据库中提取一些数据来处理或者展示给用户的。
但是Forristal发现，当输入特定的命令时，会导致服务器泄漏信息。“用户可能捎带一些自己的SQL语句”，他写道。
在Phrack的1998年12月份期刊上，Forristal发表了微软的SQL server的一系列SQL注入的问题。当Forristal的同事们向微软反馈此问题时，“他们的回答是：好了，别闹了”，他写道，“他们说，你看到的都不是问题，所依别费心去处理了”
SQL注入发展到今天，已经过去了15年，在OWASP组织每三年发表一次的OWASP的Top 10问题上，SQL注入攻击经常坐上榜首的位置。OWSAP全称是开放式Web应用程序安全项目（Open Web Application Security Project），它是一个监控网站面临哪些安全威胁的非盈利性组织。
Phrack现在的logo
“SQL注入经常是第一威胁，主要反映在相关攻击事件的数量上，同时还有一些其他因素导致它如此频发，” Troy Hunt在Motherboard的一次电话采访中如是说道，Troy Hunt是攻击检测网站haveibeenpwned.com的创始人［译者注：感觉像是一个社工库］。
“当你访问一个网页时，你发出一个请求，然后渲染服务器返回的数据”， Hunt介绍，“举个例子，你看一篇新闻，在地址栏上使用id=‘1’来发出请求时，服务器返回编号为1的文章，把id改成2的时候，服务器返回编号为2的文章”
但是，“使用SQL注入攻击，攻击者可能会将ID字段改成一个其他什么东西，导致服务器做一些意料之外的事情”，Hunt继续说到，比如返回一些隐私数据。
一次攻击也许只返回一条或者一段信息，于是攻击者就“不断重复攻击，一次又一次，想干几次干几次，直到他们获取到所有数据为止”，Hunt说。
显然，这需要一段比较长的时间，所以，黑客一般会使用自动化工具。其中比较具有代表性的事Havij，“这是最流行的脚本小工具，因为它支持Windows操作系统，而且还有个图形界面”， Mustafa AI-Bassam通过在线聊天工具和Motherboard如此描述，他是一名安全研究员，同时还是一名LulzSec黑客组织的前成员。
另一个经常被用到的工具是 sqlmap 。“它可以爬取网站的页面，就像搜索引擎的爬虫，寻找网站中所有输入表单，然后提交一些可能导致MySQL语法错误的数据”， AI-Bassam继续介绍。
当攻击者找到一个攻击点，接下来就很容易自动化开搞了。
sqlmap的界面
“他们会使用Google来搜索那些典型的容易受到SQL注入脚本攻击的URL”， AI-Bassam说。“他们还经常使用脚本来检查所有URL，用自动化的方法来试探是否存在漏洞”
“你甚至可以教一个4岁的孩子来做这种事情［译者注：汗～～我还不如个4岁的孩子］”, AI-Bassam补充道，强调这整个过程简单到令人发指的地步。确实，Hunt就曾经上传过一个视频，视频上显示他是怎么教他3岁的儿子用Havij来实施SQL注入攻击的［译者注：这是真爱啊，我坚决不会让我女儿走上计算机这条不归路］
“你把要攻击的URL输入进来，然后所有数据就出来了”，Hunt向Motherboard介绍道。在YouTube上有太多教程来介绍如何实施SQL注入攻击了。
事实上，已经有很多解决方案被网站开发人员用来防止SQL注入攻击了和避免客户信息或者公司信息泄漏了。而且那些解决方案一经存在好几年了。
所有这些解决方案的核心都是采用“prepared statments” （预编译声明？）: 当SQL语句在数据库中执行是，绝对不能直接执行用户的输入。
如果这些解决方案直接有效，那为何SQL注入攻击还是这么猖獗呢？
“使用prepared staement的好处是它们可以从语义层面上杜绝任何在开发者意料之外的输入，这些输入可以通过构造一些SQL语法，让数据库查询语句从任意一张数据表中获取一条额外的数据”，Mike Schema在给Motherboard的一封email中如此说导，他是雅虎的一名高级经理、软件工程师。
另外一种做法是“使用SQL库对用户输入做一些净化操作”，AI-Bassam建议。简而言之，就是将输入中任何潜在的恶意部分去除掉。
那么，如果SQL注入如此简单，以至于小孩子都能用，而且解决方案又这么直接有效，为什么SQL注入攻击还这么猖獗呢？
“任何一名严谨的程序员都应该知道SQL注入攻击，但是仍然有大量的程序员缺乏经验，所以公司在雇佣某人的是偶，他可能没有受到过任何关于如何消除风险的训练”， AI-Bassam指出。除此之外，“他们的经理们往往只要求开发出能用的软件，而不是安全的软件”。
来自雅虎的Schema也认同这一点，并且补充“有些时候，一些小应用功能有限，要求很快就把东西做出来”，导致开发者经常忽略一些应对各种攻击的工作，尽管他们实施起来也不是很困难。
Hunt不是那么宽容，他也不认同所有的过错都来自于高层管理的压力。相反，他认为现在有网上有这么多教程详细的向开发人员讲解如何避免SQL注入攻击，对，是详细的教程，不仅仅是一些好的建议。“这些年，我看到很多有关如何避免明显的SQL注入风险的教程”，他说到。
随着互联网黑客们不停的在YouTube上分享他们的SQL注入攻击经验，网站的开发者们也没有闲着。“我们有能力的人站出来，分享他们的专业知识，而不仅仅是把自己的事情做好就行了”，Hunt说。
最后，这些网站的安全和他们的数据安全归根到底还是网站开发者自己负责的。这意味着SQL注入攻击和漏洞还会存在，至少在未来一段时间内不会消失。［译者注：估计原作者的意思是安全还是由开发者自己负责，不在于黑客不去攻击，自己开发的时候不注意，还是没办法避免被攻破的～～］
SQL 注入，永不过时的黑客技术，首发于博客 – 伯乐在线。
如何伪造 TCP 握手？
据我们所知，这种攻击是新发现的。询问一下周围的人，几乎都认为TCP握手会对两侧的IP地址进行验证。这种攻击表明实际上并非如此。
在一个方提斯大学的合作项目中，我和Raoul Houkes研究不同的TCP攻击方式，要不就在协议层面，要不就针对具体的实现。我们发现了一种协议方面的攻击，它可以影响到所有正确的协议实现。
客户端A要与B建立连接，TCP握手的过程是这样的：
A：你好，B。我是A。发送序列号（SYN）是5。
B：你好，A。我是B，确认序列号（ACK）是5，发送序列号（SYN）是3。
A：你好，B。我是A，确认序列号（ACK）是3，发送序列号（SYN）是6。我要请求example.net。
B：你好，A。我是B，确认序列号（ACK）是6.发送序列号（SYN）是4。下面是你请求的结果：……
然后，A和B之间就可以相互通信了。对A或者B而言，每发送一个byte，序列号都会相应地增加。这样就可以跟踪是否所有的数据都被对方接收，保证可靠的传输。
在1981年，这种通讯方式被设计出来的时候，安全并没有那么重要。ARPANET适应单一网络，并且他们需要这样一个发送数据的协议：能够进行出错重传，错误校验，并且可以保持包的有序性等等。TCP解决了所有这些问题。
。
目前，这两个数字域，分别叫做发送序列号(SYN)和确认序列号（ACK），用来保证安全可靠的传输。但是，同时也存在两个问题：
- 这两个数字域都只有32字节，无法记录更大的数值。
- 由于它们的双重目的，序号不正确的报文会被丢弃，而不破坏连接。换言之，你可以发送一个ACK不正确的报文，然后再发送一个ACK正确的报文，正确的报文可以被接收。
A向B发送数据包，我们利用上面两个特性来进行攻击，大致过程如下:
A：你好B。我是C。发送序列号（SYN）是5。
B：你好C。我是B。确认序列号（ACK）是5。发送序列号（SYN）是3。
A：你好，B。我是C，确认序列号（ACK）是 1，发送序列号（SYN）是6。我要请求example.net。
B：你好C。我是B，你的报文不正确。请关闭连接。
A：你好，B。我是C，确认序列号（ACK）是2，发送序列号（SYN）是6。我请求example.net。
B：你好C，我是B。这是不正确的。请关闭连接。
A：你好B，我是C，确认序列号（ACK）是3。发送序列号（SYN）是6。我想请求example.net。
B：你好C，我是B，确认序列号（ACK）是6，发送序列号（SYN）是4，以下是你请求的结果……
在上面的案例中，主机A没有收到B的任何消息，B也不知道响应的是一个假的IP地址。主机A伪装成了C的IP地址。
这中攻击的先决条件之一是真正的C没有发送后续报文（或者RST报文），但是这非常容易实现，使用一个并不存在的C(比如0.0.0.0)或者利用防火墙（客户端一般都处于全状态防火墙的后面，或者是NAT, 也或者两者都有）。
B等待C(或者其他客户端)确认消息的时间是有限的。我在Linux4.2内核上做过实验，等待时间是20秒。20秒之后，你需要重新开始（发送下一个SYN），但是这没有什么意义，因为选择的序列号完全是随机的。
这种攻击的成本如何呢？平均而言，平均而言，需要耗费120GB的网络流量（60byte的因特网头，IP头和TCP头的组合）来创建一个虚假连接。也许你很不幸要花费200GB的流量，也可能很幸运只要72GB就够了。
简单调查表明很多VPS系统中1 gbps的带宽花不了多少钱。如果你能充分利用可用带宽，平均而言这种攻击17分钟11秒就够了。
通常你想注入有效载荷，例如，发送一个命令。这个命令需要拼接到已经存在的数据上，使得攻击耗费的流量更大。例如，发送“GET/HTTP/1.0nn”平均下来要花费了152GB或者20分钟。这可以在访问日志中展体现出来，虽然看上去是一个完美的正常连接。
这种攻击的其他案例还包括绕过黑名单或者白名单，比如在某些系统的管理接口上。这从90年代就非常流行，而且现在仍然广泛存在，很多新应用设备还是才用这种方式运行。
概念证明（Proof of concept，简写作PoC）
一个研究项目没有Poc像什么话呢？下面是一些Wireshark的截图，一个dump包，以及用到的代码。
我筛选出了一些192.168.36.17捕获的相关包。第一个包是初始化包，192.168.36.11发送的，伪装的IP是192.168.36.18.。我们的目标主机向虚假IP 192.168.36.18发送响应报文。192.168.36.17开始猜测正确的ACK号。注意，时间从0.x秒增加到8.x秒，这里我把一些尝试过滤掉了。在某一时刻数字从2的32次方（4十多亿）到0，这时因为Wireshark给了我们一个相对的数字。这也意味着我们已经发现了正确的序号。我们向SSH服务器发送确认序列号（ACK）1，服务器收到这个序号后，开始响应。SSH服务器假定拥有的连接都是有效TCP连接。
以下是一些更详细的会话内容：
Server选取的的随机数字是0x0006943f (或者 431167)。
在某一时刻，我们脚本猜测出了0×00069440 (或者 431168)，这是正确的数字，因为我们需要发送我们收到的数字加1。
SSH服务器对此作出了响应，发送了一个标志有效连接开始的标题报文。
原始dump包只有15秒，因为我只在捕获了日志交替之前15秒的事件。感觉15秒时间并不长，但是这有5 544 384（550万）个包，几乎占领十亿字节的一半。如果你想看一下实际效果，可以运行下面提供的攻击代码攻击。
上面的看到的dump包可以点击下面的链接下载：
最后，进行攻击的代码也可以点击下面的链接下载：
作为一个真正的PoC，以上代码是为了这个目的而写的，没有考虑可维护性。
结论
这种攻击很难避免，因为这是TCP协议的本身的特性造成的。只能漫无目的的猜测可能被注入的无效ACK，然后将它作为一个关闭连接的理由，但即便如此还是很容易受到攻击。
为了验证一次连接的双方，需要用到附加的安全验证方式例如TLS。即使证书没有被授权，一些加密的TLS会话还是要进行，因为有些附加的数据需要传送到客户端。这使得证明变得不可行。
经验总结：不要使用基于IP地址的授权，不要相信IP地址白名单，当需要安全验证（或者不可可抵赖）的时候考虑使用安全协议。
作为一个真正的PoC，以上代码是为了这个目的而写的，没有考虑可维护性。