有趣的代码攻防战

写在前面

今天这篇文章，是一篇关于代码安全的内容。大部份内容可能对于如今来讲都已经很小儿科了。可是我在了解这方面的内容时，着实仍是被这些前辈们脑洞大开的手段所折服。 因此今天就特意盘点了一些比较出名的漏洞问题。

漏洞大盘点

代码漏洞

不安全的代码-注入式攻击

注入式（Inject）攻击是一类很是常见的攻击方式，其基本特征是程序容许攻击者将不可信的动态内容注入到程序中，并将其执行，这就可能彻底改变最初预计的执行过程，产生恶意效果。

一、XSS

1.一、反射型 XSS（非持久性跨站攻击）

通常是利用网站某些页面会直接输出请求参数的特性，经过在 url 的请求参数包含恶意脚本，致使用户打开该 url 的时候，执行恶意脚本。

例：http://localhost:8080/test.jsp?abc= <script>alert(“123”) </script>

用户在访问这个页面的时候，就会触发弹窗。

固然，通常的 XSS 攻击不会这么简单的就让你弹个窗，甚至可能弹出你的cookie信息。

1.二、存储型 XSS（持久性跨站攻击）

该种类型的攻击通常是经过表单输入（好比发布文章、回复评论等功能中）插入一些恶意脚本，而且保存到数据库，待其余用户加载对应的页面的时候，该段脚本就会被加载并执行。

与反射型 XSS 相比，该类的攻击更具备危害性，由于它影响的不仅是一个用户，而是大量用户，并且该种类型还可进行蠕虫传播；就如以前的贴吧和微博事件，用户访问了含有恶意脚本的页面，用户的cookie信息被盗取了，而且马上使用用户的帐户去发表新的帖子或微博同时注入恶意脚本，使得该恶意脚本不断被传播下去。

1.三、DOM Based XSS（基于 Dom 的跨站点脚本）

基于 DOM 的跨站点脚本与前面两种类型有什么区别呢？其实它注入的方式是基于前面两种类型的方式的，只不过是注入的脚本是经过改变DOM来实施的。

采用该种方式有一个好处就是从源代码中不易被发现而已。

如何去防御 XSS

基于上面漏洞产生的缘由，咱们若要想防护该种攻击，就须要从源头抓起（用户输入），制定一套合理且安全的 XSS 过滤规则。 如下介绍一些过滤方法

对 HTML 标签及一些特殊符号进行转义

该种方法是一种很是简单的过滤方法，仅仅是经过转义的方式将一些 HTML 标签和属性转义，好比 < 转义成 &lt ;， 这样像的脚本就运行不了。固然简单的过滤方式也就表明很容易就会被绕过。 另外若是须要使用含有富文本的功能时，使用这样的过滤就会使富文本失去做用。

使用白名单、黑名单的方式进行过滤

白名单、黑名单顾名思义是要定义哪些东西是可经过的，哪些东西不可经过。好比常见<b>、<p>; 、<等等标签，不可经过的好比 javascript、<a>、<script>、<iframe>、onload 等等一些属性，将其进行转义。 固然使用该种方法也有自身的缺点，你并不可能穷举出全部元素，也可能会某些元素在黑名单内，但在某些状况它是须要使用的，这就须要咱们在设计 XSS 过滤器的时候权衡好，取最合理最适合需求的设计。

二、SQL注入

首先，就是最多见的SQL注入攻击。一个典型的场景就是Web系统的用户登陆功能，根据用户输入的用户名和密码，咱们须要去后端数据库核实信息。

假设应用逻辑是，后端程序利用界面输入动态生成相似下面的 SQL，而后让 JDBC 执行。 Select * from use_info where username = “input_usr_name” and password = “input_pwd”

可是，若是我输入的 input_pwd 是相似下面的文本，“ or “”=”

那么，拼接出的 SQL 字符串就变成了下面的条件，OR 的存在致使输入什么名字都是复合条件的。 Select * from use_info where username = “input_usr_name” and password = “” or “” = “” 这个例子，各位小伙伴们应该很容易可以理解到它的攻击性。上面例子中，程序指望用户输入一个数值，但实际输入的则是SQL语句片断。

根据这个套路，咱们就能够注入不少很骚的SQL片断了，好比删库，跑路之类的~

三、操做系统命令注入

操做系统命令注入。

好比：Java 语言提供了相似Runtime.exec(…)的API，能够用来执行特定命令，假设咱们构建了一个应用，以输入文本做为参数，执行下面的命令： ls –la input_file_name

可是若是用户输入是：

input_file_name;rm –rf/* 那将是毁灭性的打击，可是编程语言自己是作了不少的限制，这些操做未必能够真的可以完成攻击，可是这种隐患终究仍是存在的。

预防注入式攻击

在 Java 应用进行数据库访问时，若是不用彻底动态的SQL，而是利用PreparedStatement，能够有效防范 SQL 注入。无论是SQL注入，仍是OS命令注入，程序利用字符串拼接生成运行逻辑都是个可能的风险点！

在数据库层面，若是对查询、修改等权限进行了合理限制，就能够在必定程度上避免被注入删除等高破坏性的代码。

暴力攻击

臭名昭著-DoS攻击

拒绝服务（DoS）攻击，能够说是名声很响的暴力攻击方式。

最多见的DoS攻击有对计算机网络的带宽攻击和连通性攻击。带宽攻击指以极大的通讯量冲击网络，使得全部可用网络资源都被消耗殆尽，最后致使合法的用户请求没法经过。连通性攻击指用大量的链接请求冲击计算机，使得全部可用的操做系统资源都被消耗殆尽，最终计算机没法再处理合法用户的请求。

哈希碰撞攻击

哈希碰撞是一种有趣的攻击方式。对方能够轻易消耗系统有限的CPU和线程资源。从这个角度思考，相似加密、解密、图形处理等计算密集型任务，都要防范被恶意滥用，以避免攻击者经过直接调用或者间接触发方式，消耗系统资源。

好比在Java中，有一个有趣的攻击方式：

攻击者能够事先构造大量相同哈希值的数据，而后以Json数据的形式发送给服务器端，服务器端在将其构建成为 Java 对象过程当中，一般以Hastable或HashMap等形式存储，哈希碰撞将致使哈希表发生严重退化，算法复杂度可能上升一个数量级（HashMap1.8以后在红黑树结构的优化，也是应对此问题的优化），进而耗费大量CPU资源。冲突多了，就会极大的下降get的性能，形成极严重的卡顿，甚至服务器崩掉~

Android-WebView

addJavascriptInterface接口引发远程代码执行漏洞

此问题在4.2之后的版本被修复了

咱们Native和Js互相通信，可能会这么写咱们本地的Java代码：

webView.addJavascriptInterface(new JSObject(), "mJSObject");
复制代码

这段代码是否是挺正常的？的确挺正常呐。若是咱们用民主富强文明和谐的眼光去看，的确没问题。不过若是咱们怀着一颗搞破坏的心呢？ 咱们既然能拿到这个Java对象，那么对于咱们来讲，咱们可使用反射随心所欲了。（这个问题，乌云曾给出过明确的漏洞描述）

function execute(cmdArgs){
    for (var obj in window) {
        if ("getClass" in window[obj]) {
            alert(obj);
            return  window[obj].getClass().forName("java.lang.Runtime")
                 .getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);
        }
    }
}
复制代码

不需多解释吧，这是当前很著名的WebView漏洞问题。

• 1，WebView添加了JavaScript对象，而且当前应用具备读写SDCard的权限。
• 2，JS中能够遍历window对象，找到存在“getClass”方法的对象的对象，而后再经过反射的机制，获得Runtime对象，而后调用静态方法来执行一些命令，好比访问文件的命令.
• 3，再从执行命令后返回的输入流中获得字符串，就能够获得文件的信息了。（理论上SD卡的全部内容均可以拿到了）

网络传输

防不胜防 - 中间人攻击

中间人攻击原理大概是用户在正常上网的时候，同网段的恶意用户对其进行欺骗。恶意用户向局域网广播:我是路由器，而后正经常使用户(电脑无防护)收到之后认为恶意用户就是路由器，而后向恶意用户发送数据包，恶意用户能够截获数据包，再向路由器发送正经常使用户的数据包，路由器将返回的数据包在给恶意用户，恶意用户在给正经常使用户，恶意用户就造成了中间人的效果，能够向返回的数据包注入html代码，达到劫持用户网站的效果，不过如今大部分的网站都是https且双向认证，比较难获取到用户发送数据包中的帐号密码。

CSRF攻击

CSRF，全名：Cross site Request Forgery（跨站域请求伪造）。通常的攻击方式是，经过请求伪造盗取用户的cookie信息，进而进行操做。

• 一、首先用户A请求登录了服务器B，这时服务器 B 响应了用户A，而且会返回惟一标识的该用户的 cookie 信息。
• 二、用户A在未退出服务器B时（即仍与服务器 B保持会话状态），访问了带有恶意脚本的服务器 C，服务器 C 响应给用户 A 一个恶意页面，而且经过恶意脚本假装用户 A 向服务器 B 发送请求，此时服务器 B 误觉得是用户 A 请求，故响应并返回了用户 A 的 cookie 信息。
• 三、服务器 C 收到用户 A 与 服务器 B 的cookie信息后，保存起来，并利用该信息假装成用户 A 去访问服务器 B，再进行相应的破坏~

尾声

这部份内容，其实并不是是对深层技术的讨论。只是最近无心中看到这部分的内容，感受颇有趣就收集起来写了这篇文章，算是忙碌的工做之中娱乐一下吧~

这里是一帮应届生共同维护的公众号，内容是咱们在从应届生过渡到开发这一路所踩过的坑，以及咱们一步步学习的记录，若是感兴趣的朋友能够关注一下，一同加油，一同努力~！~！