阅读 751

有趣的代码攻防战

写在前面

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

漏洞大盘点

代码漏洞

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

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

1、XSS

1.1、反射型 XSS(非持久性跨站攻击)

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

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

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

当然,一般的 XSS 攻击不会这么简单的就让你弹个窗,甚至可能弹出你的cookie信息。

1.2、存储型 XSS(持久性跨站攻击)

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

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

1.3、DOM Based XSS(基于 Dom 的跨站点脚本)

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

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

如何去防护 XSS

基于上面漏洞产生的原因,我们若要想防御该种攻击,就需要从源头抓起(用户输入),制定一套合理且安全的 XSS 过滤规则。 以下介绍一些过滤方法

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

该种方法是一种非常简单的过滤方法,仅仅是通过转义的方式将一些 HTML 标签和属性转义,比如 < 转义成 &lt ;, 这样像的脚本就运行不了。当然简单的过滤方式也就代表很容易就会被绕过。 另外如果需要使用含有富文本的功能时,使用这样的过滤就会使富文本失去作用。

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

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

2、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片段了,比如删库,跑路之类的~

3、操作系统命令注入

操作系统命令注入。

比如: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信息,进而进行操作。

  • 1、首先用户A请求登陆了服务器B,这时服务器 B 响应了用户A,并且会返回唯一标识的该用户的 cookie 信息。
  • 2、用户A在未退出服务器B时(即仍与服务器 B保持会话状态),访问了带有恶意脚本的服务器 C,服务器 C 响应给用户 A 一个恶意页面,并且通过恶意脚本伪装用户 A 向服务器 B 发送请求,此时服务器 B 误以为是用户 A 请求,故响应并返回了用户 A 的 cookie 信息。
  • 3、服务器 C 收到用户 A 与 服务器 B 的cookie信息后,保存起来,并利用该信息伪装成用户 A 去访问服务器 B,再进行相应的破坏~

尾声

这部分内容,其实并非是对深层技术的讨论。只是最近无意中看到这部分的内容,感觉很有趣就收集起来写了这篇文章,算是忙碌的工作之中娱乐一下吧~

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

个人公众号:IT面试填坑小分队

关注下面的标签,发现更多相似文章
评论