有趣的代码攻防战

2022-04-16 21:35:33

有趣的代码攻防战
image

写在前面

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

漏洞大盘点

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卡的所有内容都可以拿到了）

暴力攻击

臭名昭著-DoS攻击

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

最常见的DoS攻击有对计算机网络的带宽攻击和连通性攻击。带宽攻击指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。连通性攻击指用大量的连接请求冲击计算机，使得所有可用的操作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求。

哈希碰撞攻击

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

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

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

代码漏洞

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

注入式（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 ;， 这样像<script>xxx</script>的脚本就运行不了。当然简单的过滤方式也就代表很容易就会被绕过。
另外如果需要使用含有富文本的功能时，使用这样的过滤就会使富文本失去作用。

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

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

有趣的代码攻防战
image

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命令注入，程序利用字符串拼接生成运行逻辑都是个可能的风险点！

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

有趣的代码攻防战
image

网络传输

防不胜防 - 中间人攻击

中间人攻击原理大概是用户在正常上网的时候，同网段的恶意用户对其进行欺骗。恶意用户向局域网广播:我是路由器，然后正常用户(电脑无防御)收到以后认为恶意用户就是路由器，然后向恶意用户发送数据包，恶意用户可以截获数据包，再向路由器发送正常用户的数据包，路由器将返回的数据包在给恶意用户，恶意用户在给正常用户，恶意用户就形成了中间人的效果，可以向返回的数据包注入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面试填坑小分队
上一篇：记一次凉凉的小米前端面试（应届内推）


下一篇：Office 365 允许 distribution group接收外部邮件