点赞再看，养成习惯，微信搜一搜【敖丙】关注这个互联网苟且偷生的程序员。

本文 GitHub https://github.com/JavaFamily 已收录，有一线大厂面试完整考点、资料以及我的系列文章。

开场白

张三最近天气很热心情不是很好，所以他决定出去面试跟面试官聊聊天排解一下，结果刚投递简历就有人约了面试。

我丢，什么情况怎么刚投递出去就有人约我面试了？诶。。。真烦啊，哥已经不在江湖这么久了，江湖还是有哥的传说，我还是这么抢手的么？太烦恼了，帅无罪。

暗自窃喜的张三来到了某东现场面试的办公室，我丢，这面试官？不是吧，这满是划痕的Mac，这发量，难道就是传说中的架构师？

张三的心态一下子就崩了，出来第一场面试就遇到一个顶级面试官，这谁顶得住啊。

你好，我是你的面试官Tony，看我的发型应该你能猜到我的身份了，我也话不说，我们直接开始好不好？看你简历写了多线程，来你跟我聊一下ThreadLocal吧，我很久没写代码不太熟悉了，你帮我回忆一下。

我丢？这TM是人话？这是什么逻辑啊，说是问多线程然后一上来就来个这么冷门的ThreadLocal？心态崩了呀，再说你TM自己忘了不知道下去看看书么，来我这里找答案是什么鬼啊…

尽管十分不情愿，但是张三还是高速运转他的小脑袋，回忆起了ThreadLocal的种种细节…

面试官说实话我在实际开发过程中用到ThreadLocal的地方不是很多，我在写这个文章的时候还刻意去把我电脑上几十个项目打开之后去全局搜索ThreadLocal发现除了系统源码的使用，很少在项目中用到，不过也还是有的。

ThreadLocal的作用主要是做数据隔离，填充的数据只属于当前线程，变量的数据对别的线程而言是相对隔离的，在多线程环境下，如何防止自己的变量被其它线程篡改。

你能跟我说说它隔离有什么用，会用在什么场景么？

这，我都说了我很少用了，还问我，难受了呀，哦哦哦，有了想起来了，事务隔离级别。

面试官你好，其实我第一时间想到的就是Spring实现事务隔离级别的源码，这还是当时我大学被女朋友甩了，一个人在图书馆哭泣的时候无意间发现的。

Spring采用Threadlocal的方式，来保证单个线程中的数据库操作使用的是同一个数据库连接，同时，采用这种方式可以使业务层使用事务时不需要感知并管理connection对象，通过传播级别，巧妙地管理多个事务配置之间的切换，挂起和恢复。

Spring框架里面就是用的ThreadLocal来实现这种隔离，主要是在TransactionSynchronizationManager这个类里面，代码如下所示:

private static final Log logger = LogFactory.getLog(TransactionSynchronizationManager.class);

	private static final ThreadLocal<Map<Object, Object>> resources =
			new NamedThreadLocal<>("Transactional resources");

	private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =
			new NamedThreadLocal<>("Transaction synchronizations");

	private static final ThreadLocal<String> currentTransactionName =
			new NamedThreadLocal<>("Current transaction name");

  ……

Spring的事务主要是ThreadLocal和AOP去做实现的，我这里提一下，大家知道每个线程自己的链接是靠ThreadLocal保存的就好了，继续的细节我会在Spring章节细说的，暖么？

除了源码里面使用到ThreadLocal的场景，你自己有使用他的场景么？一般你会怎么用呢？

来了来了，加分项来了，这个我还真遇到过，装B的机会终于来了。

有的有的面试官，这个我会！！！

之前我们上线后发现部分用户的日期居然不对了，排查下来是SimpleDataFormat的锅，当时我们使用SimpleDataFormat的parse()方法，内部有一个Calendar对象，调用SimpleDataFormat的parse()方法会先调用Calendar.clear（），然后调用Calendar.add()，如果一个线程先调用了add()然后另一个线程又调用了clear()，这时候parse()方法解析的时间就不对了。

其实要解决这个问题很简单，让每个线程都new 一个自己的 SimpleDataFormat就好了，但是1000个线程难道new1000个SimpleDataFormat？

所以当时我们使用了线程池加上ThreadLocal包装SimpleDataFormat，再调用initialValue让每个线程有一个SimpleDataFormat的副本，从而解决了线程安全的问题，也提高了性能。

那……

还有还有，我还有，您别着急问下一个，让我再加点分，拖延一下面试时间。

我在项目中存在一个线程经常遇到横跨若干方法调用，需要传递的对象，也就是上下文（Context），它是一种状态，经常就是是用户身份、任务信息等，就会存在过渡传参的问题。

使用到类似责任链模式，给每个方法增加一个context参数非常麻烦，而且有些时候，如果调用链有无法修改源码的第三方库，对象参数就传不进去了，所以我使用到了ThreadLocal去做了一下改造，这样只需要在调用前在ThreadLocal中设置参数，其他地方get一下就好了。

before
  
void work(User user) {
    getInfo(user);
    checkInfo(user);
    setSomeThing(user);
    log(user);
}

then
  
void work(User user) {
try{
	  threadLocalUser.set(user);
	  // 他们内部  User u = threadLocalUser.get(); 就好了
    getInfo();
    checkInfo();
    setSomeThing();
    log();
    } finally {
     threadLocalUser.remove();
    }
}

我看了一下很多场景的cookie，session等数据隔离都是通过ThreadLocal去做实现的。

对了我面试官允许我再秀一下知识广度，在Android中，Looper类就是利用了ThreadLocal的特性，保证每个线程只存在一个Looper对象。

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

面试官：我丢，这货怎么知道这么多场景？还把Android都扯了出来，不是吧阿sir，下面我要考考他原理了。

嗯嗯，你回答得很好，那你能跟我说说他底层实现的原理么？

好的面试官，我先说一下他的使用：

ThreadLocal<String> localName = new ThreadLocal();
localName.set("张三");
String name = localName.get();
localName.remove();

其实使用真的很简单，线程进来之后初始化一个可以泛型的ThreadLocal对象，之后这个线程只要在remove之前去get，都能拿到之前set的值，注意这里我说的是remove之前。

他是能做到线程间数据隔离的，所以别的线程使用get（）方法是没办法拿到其他线程的值的，但是有办法可以做到，我后面会说。

我们先看看他set的源码：

public void set(T value) {
    Thread t = Thread.currentThread();// 获取当前线程
    ThreadLocalMap map = getMap(t);// 获取ThreadLocalMap对象
    if (map != null) // 校验对象是否为空
        map.set(this, value); // 不为空set
    else
        createMap(t, value); // 为空创建一个map对象
}

大家可以发现set的源码很简单，主要就是ThreadLocalMap我们需要关注一下，而ThreadLocalMap呢是当前线程Thread一个叫threadLocals的变量中获取的。

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

public class Thread implements Runnable {
      ……

    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

    /*
     * InheritableThreadLocal values pertaining to this thread. This map is
     * maintained by the InheritableThreadLocal class.
     */
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
  
     ……

这里我们基本上可以找到ThreadLocal数据隔离的真相了，每个线程Thread都维护了自己的threadLocals变量，所以在每个线程创建ThreadLocal的时候，实际上数据是存在自己线程Thread的threadLocals变量里面的，别人没办法拿到，从而实现了隔离。

ThreadLocalMap底层结构是怎么样子的呢？

面试官这个问题问得好啊，内心暗骂，让我歇一会不行么？

张三笑着回答道，既然有个Map那他的数据结构其实是很像HashMap的，但是看源码可以发现，它并未实现Map接口，而且他的Entry是继承WeakReference（弱引用）的，也没有看到HashMap中的next，所以不存在链表了。

static class ThreadLocalMap {

        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
        ……
    }    

结构大概长这样：

稍等，我有两个疑问你可以解答一下么？

好呀，面试官你说。

为什么需要数组呢？没有了链表怎么解决Hash冲突呢？

用数组是因为，我们开发过程中可以一个线程可以有多个TreadLocal来存放不同类型的对象的，但是他们都将放到你当前线程的ThreadLocalMap里，所以肯定要数组来存。

至于Hash冲突，我们先看一下源码：

private void set(ThreadLocal<?> key, Object value) {
           Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);
            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal<?> k = e.get();

                if (k == key) {
                    e.value = value;
                    return;
                }
                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }
            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

我从源码里面看到ThreadLocalMap在存储的时候会给每一个ThreadLocal对象一个threadLocalHashCode，在插入过程中，根据ThreadLocal对象的hash值，定位到table中的位置i，int i = key.threadLocalHashCode & (len-1)。

然后会判断一下：如果当前位置是空的，就初始化一个Entry对象放在位置i上；

if (k == null) {
    replaceStaleEntry(key, value, i);
    return;
}

如果位置i不为空，如果这个Entry对象的key正好是即将设置的key，那么就刷新Entry中的value；

if (k == key) {
    e.value = value;
    return;
}

如果位置i的不为空，而且key不等于entry，那就找下一个空位置，直到为空为止。

这样的话，在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该位置Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置，set和get如果冲突严重的话，效率还是很低的。

以下是get的源码，是不是就感觉很好懂了：

 private Entry getEntry(ThreadLocal<?> key) {
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e;
            else
                return getEntryAfterMiss(key, i, e);
        }

 private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
            Entry[] tab = table;
            int len = tab.length;
// get的时候一样是根据ThreadLocal获取到table的i值，然后查找数据拿到后会对比key是否相等  if (e != null && e.get() == key)。
            while (e != null) {
                ThreadLocal<?> k = e.get();
              // 相等就直接返回，不相等就继续查找，找到相等位置。
                if (k == key)
                    return e;
                if (k == null)
                    expungeStaleEntry(i);
                else
                    i = nextIndex(i, len);
                e = tab[i];
            }
            return null;
        }

能跟我说一下对象存放在哪里么？

在Java中，栈内存归属于单个线程，每个线程都会有一个栈内存，其存储的变量只能在其所属线程中可见，即栈内存可以理解成线程的私有内存，而堆内存中的对象对所有线程可见，堆内存中的对象可以被所有线程访问。

那么是不是说ThreadLocal的实例以及其值存放在栈上呢？

其实不是的，因为ThreadLocal实例实际上也是被其创建的类持有（更顶端应该是被线程持有），而ThreadLocal的值其实也是被线程实例持有，它们都是位于堆上，只是通过一些技巧将可见性修改成了线程可见。

如果我想共享线程的ThreadLocal数据怎么办？

使用InheritableThreadLocal可以实现多个线程访问ThreadLocal的值，我们在主线程中创建一个InheritableThreadLocal的实例，然后在子线程中得到这个InheritableThreadLocal实例设置的值。

private void test() {    
final ThreadLocal threadLocal = new InheritableThreadLocal();       
threadLocal.set("帅得一匹");    
Thread t = new Thread() {        
    @Override        
    public void run() {            
      super.run();            
      Log.i( "张三帅么 =" + threadLocal.get());        
    }    
  };          
  t.start(); 
} 

在子线程中我是能够正常输出那一行日志的，这也是我之前面试视频提到过的父子线程数据传递的问题。

怎么传递的呀？

传递的逻辑很简单，我在开头Thread代码提到threadLocals的时候，你们再往下看看我刻意放了另外一个变量：

Thread源码中，我们看看Thread.init初始化创建的时候做了什么：

public class Thread implements Runnable {
  ……
   if (inheritThreadLocals && parent.inheritableThreadLocals != null)
      this.inheritableThreadLocals=ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
  ……
}

我就截取了部分代码，如果线程的inheritThreadLocals变量不为空，比如我们上面的例子，而且父线程的inheritThreadLocals也存在，那么我就把父线程的inheritThreadLocals给当前线程的inheritThreadLocals。

是不是很有意思？

小伙子你懂的确实很多，那你算是一个深度的ThreadLocal用户了，你发现ThreadLocal的问题了么？

你是说内存泄露么？

我丢，这小子为啥知道我要问什么？嗯嗯对的，你说一下。

这个问题确实会存在的，我跟大家说一下为什么，还记得我上面的代码么？

ThreadLocal在保存的时候会把自己当做Key存在ThreadLocalMap中，正常情况应该是key和value都应该被外界强引用才对，但是现在key被设计成WeakReference弱引用了。

我先给大家介绍一下弱引用：

只具有弱引用的对象拥有更短暂的生命周期，在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。

不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

这就导致了一个问题，ThreadLocal在没有外部强引用时，发生GC时会被回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。

就比如线程池里面的线程，线程都是复用的，那么之前的线程实例处理完之后，出于复用的目的线程依然存活，所以，ThreadLocal设定的value值被持有，导致内存泄露。

按照道理一个线程使用完，ThreadLocalMap是应该要被清空的，但是现在线程被复用了。

那怎么解决？

在代码的最后使用remove就好了，我们只要记得在使用的最后用remove把值清空就好了。

ThreadLocal<String> localName = new ThreadLocal();
try {
    localName.set("张三");
    ……
} finally {
    localName.remove();
}

remove的源码很简单，找到对应的值全部置空，这样在垃圾回收器回收的时候，会自动把他们回收掉。

那为什么ThreadLocalMap的key要设计成弱引用？

key不设置成弱引用的话就会造成和entry中value一样内存泄漏的场景。

补充一点：ThreadLocal的不足，我觉得可以通过看看netty的fastThreadLocal来弥补，大家有兴趣可以康康。

好了，你不仅把我问的都回答了，我不知道的你甚至都说了，ThreadLocal你过关了，不过JUC的面试才刚刚开始，希望你以后越战越勇，最后拿个好offer哟。

什么鬼，突然这么煽情，不是很为难我的么?难道是为了锻炼我？难为大师这样为我着想，我还一直心里暗骂他，不说了回去好好学了。

总结

其实ThreadLocal用法很简单，里面的方法就那几个，算上注释源码都没多少行，我用了十多分钟就过了一遍了，但是在我深挖每一个方法背后逻辑的时候，也让我不得不感慨Josh Bloch 和 Doug Lea的厉害之处。

在细节设计的处理其实往往就是我们和大神的区别，我认为很多不合理的点，在Google和自己不断深入了解之后才发现这才是合理，真的不服不行。

ThreadLocal是多线程里面比较冷门的一个类，使用频率比不上别的方法和类，但是通过我这篇文章，不知道你是否有新的认知呢？

絮叨

另外，敖丙把自己的面试文章整理成了一本电子书，共 1630页！目录如下，还有我复习时总结的面试题以及简历模板

现在免费送给大家，在我的公众号三太子敖丙回复 【888】 即可获取。

我是敖丙，你知道的越多，你不知道的越多，我们下期见！

人才们的 【三连】 就是敖丙创作的最大动力，如果本篇博客有任何错误和建议，欢迎人才们留言！

---

文章持续更新，可以微信搜一搜「 敖丙 」第一时间阅读，关注后回复【资料】有我准备的一线大厂面试资料和简历模板，本文 GitHub https://github.com/JavaFamily 已经收录，有大厂面试完整考点，欢迎Star。

作者Colin Lynch
物联网（IoT）是一个术语，用来描述微控制器加入了无线连接，形成互联互通的状态。这些是为大多数消费和工业电子产品提供动力的芯片或设备。连接性为新功能增加了很多空间，但也带来了明显更高的安全风险。

物联网中使用什么芯片？
物联网在微控制器上运行，而不是微处理器。微处理器是用于驱动服务器、个人电脑和电话的芯片。事实上，这两类芯片的名称和某些功能是相似的，这可能会让人感到困惑。它们之间的关键区别在于规模。

iPhone 11的中档选择价格约为1500美元（在撰写本文时），由苹果的仿生学微处理器提供动力，该处理器由估计43亿个晶体管制成。一个有根据的猜测，芯片的成本可能是100-200美元。Arm M0是一种经常用于物联网应用的中端微控制器，具有蓝牙功能的版本价格约为2美元，使用10至15万个晶体管。该微控制器的成本降低了50倍，晶体管数量减少了28,667倍。

这个例子只是说明问题，因为有不同类别的设备，其尺寸和成本范围很广。但你可以想象，有些事情你用微控制器是做不到的，比如说，运行一个手机。也可以说，微处理器永远不会被用来执行一个微控制器可以管理的功能。

在微处理器和微控制器的芯片设计方法上还有一个区别。微处理器总是被推到更强大的位置，而微控制器则被设计成以最小、最经济的方式执行一个简单的功能。每一个额外的芯片功能都要衡量其在成本、尺寸和功耗方面的效用。虽然这种方法为进入新的消费市场提供了动力，但它也带来了安全挑战。

世界上的微控制器远远多于微处理器。估计各不相同，但半导体供应商在2019年的微控制器出货量约为250亿，是微处理器单位出货量的20倍。当按美元价值进行市场比较时，这一事实往往被掩盖。

为什么微控制器是一个安全问题？
物联网安全
与微控制器中可用的内部存储器相比，微处理器可以处理大得多的外部存储器。因此，它们可以运行大得多的应用代码块，其中包括我们在个人电脑和手机上熟悉的所有安全功能。

操作吸尘器或冰箱的单一微控制器根本无法模仿这些安全功能。因此，微控制器对制造商的设计IP来说是一种安全风险。竞争对手可能会为了复制他们的产品而黑掉他们的产品，与黑掉一个微处理器相比，这个过程可能相对简单。仅仅是造假或生产过剩就对公司的收入构成了重大风险，但尽管如此，一旦微控制器被 "连接 "起来，就有可能出现更严重的风险，因为它现在可能面临着外部责任。

物联网的安全风险
一旦你将一个微控制器连接到互联网，这个安全问题就会大大增加。现在，一个自我保护能力有限的简单消费产品可以被用来对全球互联网基础设施发起恶意攻击。随着微控制器所处的互联物联网生态系统变得更加复杂，安全风险的数量也急剧增加。你只需要在这里看到这些攻击的后果。

全球各国政府正在研究如何为这些安全漏洞的责任进行立法。情况很复杂，但可以肯定的是，生产简单连接设备的公司将不得不在其设计中考虑安全问题，这是他们以前没有做过的。此外，设计失误最终导致公众受到安全威胁的责任将直接落在经营这些公司的高管身上。

2019年，在250亿个微控制器单元中，出货时带有连接功能的比例很小。这一趋势正在迅速改变。一个微控制器只要花50美分就可以在其中加入蓝牙。应用范围和市场机会是巨大的。这种将大量轻量级设备的生产与连接相结合的做法是安全问题的核心所在。

如何克服2个主要的安全挑战
01.如果你想保护你的知识产权，你必须对你的设计代码进行加密。
02.如果你想让你的微处理器只与经过验证的来源对话，你必须给它一个独特的ID，并对其进行加密。
物联网安全解决方案
公司如何实施这些解决方案？
今天有一类微控制器实现了上述两种解决方案。我们每天都在我们的SIM卡和信用卡中使用它们。这些具有相同外形尺寸和设计结构的芯片在全球少数大型安全设备中以千万级的数量生产。对它们进行烧录的代码已经发展得很成熟。

然而，物联网制造商的一个问题是，有广泛多样的芯片和应用。体积大，但批量小。市场并不集中于少数公司或少数地区。软件、硬件和烧录服务生态系统仍在发展之中。

安全是一个专业而复杂的课题，立法仍在发展之中。对公司来说，建立强大的安全解决方案以保护他们的客户和自己并不容易，也不便宜。在一个对成本非常敏感的市场中，如何开发一个强大而又具有成本效益的解决方案是一个非同寻常的挑战。

物联网安全
EPS在物联网安全领域能做些什么？
EPS为OEM和CEM提供芯片烧录服务，并在全球所有主要的电子制造市场开展业务。

我们目前正在与选定的软件合作伙伴合作，在2020年向市场推出新的解决方案。我们的目标是选择合适的伙伴，为我们的客户提供全球端到端的安全解决方案。

客户将有能力对他们的数据进行加密，并将其发送给EPS，以便对设备进行批量配置。在我们的烧录中心，匹配的硬件和现场安全将确保我们客户的知识产权得到保护，确保设备不能被仿冒或过度生产。

EPS还将能够为物联网设备添加独特的ID和安全证书。这些将使芯片能够识别来自其制造商的有效代码更新，并将其与恶意攻击区分开来，确保该设备整个生命周期的安全。

我们希望在2020年第一季度宣布合作关系，并在2020年早期提供基于这些合作关系的解决方案。

这将提供解决方案，帮助我们的客户在世界任何地方实现其安全和成本目标。

Colin
关于Colin Lynch
Colin Lynch在半导体和分销行业有超过20年的经验，是EPS的首席执行官。在为EPS工作之前，他曾在NETS担任总经理，在NCR担任项目经理。Colin拥有三一学院的电子工程学士学位和UCD的Smurfit商学院的MBA学位。

如何设计一个安全的物联网产品？您必须考虑的3件事

在此注册: https://www.epsprogramming.com/cn/resources/eps-nuvoton-webinar

加入爱柏电子(EPS Global) 和新唐(Nuvoton)，了解设计安全物联网产品时必须考虑的3个S。

这篇文章是Contrast Security 的CTO和共同创始人，Jeff Williams于2018年末写的一篇文章，对IAST描述的非常清楚，其中谈到的技术，我们今天还在做。对于IAST的深刻理解，非常值得我们学习。

一、介绍

交互式应用安全测试（Interactive application security testing IAST）是一个在应用和API中自动化识别和诊断软件漏洞的技术。如果从名字的缩写来看，插桩（Instrumented）式应用安全测试或许是一个更好的说法。IAST不是一个扫描器，重要的事说两遍，它不是一个扫描器，IAST持续地从内部监控你应用中的漏洞，在整个开发生命周期中，IAST通过你在开发和测试中使用的工具，实时地提供报警。

IAST最显著的特性是它使用插桩来收集安全信息，直接从运行中的代码发现问题，不是源代码扫描（SAST），也不是HTTP 扫描(DAST)。但那并不意味着你要等到产品上线时才使用它，恰恰相反，你可在IDE中，当开始编写和测试第一行代码时，就使用IAST。

了解IAST在完整的应用安全技术策略中的位置非常重要，有两个主要自动化应用安全的方法，你都要考虑到：

在开发时阻止漏洞

IAST自动地发现应用和API的漏洞，这样可以在开发过程早期就进行修复，成本不会那么高。IAST在检测速度，精确度，流程上都比传统的SAST和DAST有优势，某些IAST还包括开源软件安全分析功能。

在生产阶段检测攻击和阻止漏洞利用

RASP在运行时阻止漏洞被利用，而不是像Web 应用防火墙（WAF）那样通过检查网络流量来阻止攻击。RASP并不仅在精确度和扩展性上优于传统的Web防护方法，还能提供在几分钟内将多个业务系统部署新的防护手段的所需架构。（注：RASP也使用插桩的方法，和IAST技术基本一样，有时会把这两个技术等同。）

我们强烈推荐你把IAST加入到认可的应用安全测试技术名单中，它在2010年出现，许多最大的金融、技术和医疗保健公司已经采用了IAST技术。在本文中，我们将探索如何把IAST集成到整个软件生命周期中，实现最经济的漏洞检测。

二、什么是IAST？

交互式应用安全测试使用软件插桩收集安全信息，并直接从运行中的代码发现问题，以实现自动化识别和诊断在应用和API中的软件漏洞。

IAST可以访问代码本身，能够在每行代码执行SAST，而且，IAST可以访问HTTP流量，也能够在每一次请求和响应时，执行类DAST的分析，因此，IAST的规则是SAST和DAST的一个功能合集。

接下来，我们会探索你使用IAST能够做到的事情，IAST的两个主要能力如下：

• 自有代码安全测试：IAST能够自动化地分析应用和API 中的自有代码，找出以前没有发现的（零 day）漏洞，能够识别很宽范围的漏洞，包括并不限于OWASP Top 10，还有其他更复杂的漏洞。
• 开源软件安全测试：IAST也能用来测试开源库和框架的安全性，一般有两个维度。首先，IAST能识别困扰开源软件的已知漏洞（如CVE发布），其次，IAST能识别开源软件中以前未知的（潜在）漏洞。

01 IAST 探头如何工作

通常，IAST使用类似APM工具的技术，使用安全探头对插桩的应用和API进行调试排错，探头从运行的应用中直接检查安全相关的事件，并传递给分析引擎，引擎重新组装这些事件，识别出代码执行中的漏洞特征。

当一个应用或者API被加载到内存中，应用中的插桩是动态执行的。插桩本身很安全，并被广泛应用到日志、性能测试、及其他目的。许多常见的框架已经在运行时使用隐藏的插桩技术，很可能你已经在应用和API中使用过某种形式的插桩。

现代应用常常在运行时组装，使用依赖注入、动态加载、反向控制等其他技术。因为这个原因，源代码分析只能提供一个局部观察，验证安全最好的方法是直接检查运行时应用，IAST支持这种直接的检测。

IAST安全探头能够从应用中实际地提取任何信息。在许多方面，IAST是SAST和DAST的一个合集，包括代码和HTTP流量的分析，但IAST在它的分析中考虑到很多类型的信息，包括：

代码——IAST能访问所有和应用一起部署的源代码和二进制代码。代码探头对应用中每一行代码做二进制的静态分析，包括库和框架。

HTTP流量——IAST能够看到HTTP请求和响应，使用和DAST非常类似的技术，发现和这些流量相关的漏洞。

库和框架——IAST能看到部署的每一个库和框架，分析应用和API如何使用它们。不仅IAST能够根据已知漏洞（CVE）来评估库，也能识别部分或整体隐藏在库里面的未知漏洞。重要的是，因为IAST能精确知道库里面的哪一部分被应用真正调用，它能够过滤掉从未被调用的和库相关的漏洞。

应用程序状态——IAST能够检查程序执行时的应用状态。例如，IAST能看到调用安全方法时使用的参数来发现弱点，如传递“DES”参数给加密密码构造函数。

数据流——从开始进入应用的时候开始，IAST就追踪不信任的输入数据。这是识别最重要的漏洞种类—注入类漏洞的关键。这个技术，有时称之为“污点追踪”，跟踪真实数据在应用中的流动，非常精确。

控制流——IAST了解应用的控制流，能够识别出应用行为中漏洞的特征。例如如果一个应用要求在每个web服务中，采用service（）方法检查访问控制，这个特征将很容易被IAST发现。

后端连接——IAST能够检查围绕着后端连接的所有细节，如数据库、操作系统调用、目录、队列、套接字、电子邮件和其他系统。IAST使用这个信息识别出架构缺陷和安全缺陷。

配置——IAST能访问应用、框架、应用服务器、和平台的配置，保证正确的安全配置。IAST甚至能查询应用组件的运行时配置，如XML解析器。注意某些平台，如.NET，重度依赖配置来实现安全。

02 IAST分析引擎如何工作

IAST 探头生成一个安全相关事件的数据流，导入进分析引擎，这个引擎能强制实施多个规则。

事实上，IAST为一个程序建立了一个安全护栏，如果探头探测到的数据流，表明程序的行为已经违法越过了这些护栏，就会被报告为漏洞。

IAST常常使用多个不同的信息源来证实一个漏洞，例如，当一个暴露的端点，是non-XHR，或者状态正在改变，或者没有包含token检查，就可以确定是一个CSRF（跨站请求伪造）漏洞。IAST能够访问HTTP请求，分析是否一个交易修改了文件或写到存储设备里，评估是否一个控制流包含一个token检查，通过在漏洞分析中，使用所有这三种类型的数据，IAST得出准确的结果，不会漏报也不会误报。

三、我们为什么需要IAST？

问题很简单，我们在应用安全方面，有大量的问题。但应对这些问题的安全专家有限，全世界几乎有2000万的开发人员。传统的工具要求安全专家和应用一起工作，训练工具，解释结果。这些工具80%的费用是有效使用工具的“人的费用“，没有真正的自动化。

01 “工具困境”不起作用

“工具困境”是指你为工作准备的工具都不是很好用，因此，你不得不运行一系列工具，希望能得到一个好的结果。

在安全领域，十余年来，我们一直在尝试这种“混合”的方法，但确实没什么作用。

想像一下，使用SAST，DAST，还有SCA工具的结果去检测CSRF漏洞的情形：

静态分析:

静态分析工具仅仅能尝试检测没有被token检查保护的数据流，不管他们是状态变更还是通过XHR访问。结果或者是花费大量时间的误报，或者是危险的漏报。

动态分析：

DAST工具能够标记不包含CSRF令牌的表单，但无法知道是否他们在状态变更，因此，结果结果或者是花费大量时间的误报，或者是危险的漏报。

开源软件分析：

SCA工具只能标记含有已知漏洞的库，将会错失所有没有被安全专家暴露和发布的安全漏洞。

运行所有这些工具，浪费时间和宝贵的安全技能。但更重要的是，很难关联安全测试结果。静态工具能够报告源代码行数，动态工具报告HTTP请求，开源工具报告库版本号，没有好的方法来关联这些报告。最好的关联工具减少15%-35%发现结果。因此，如果你有两个工具，每份报告了200个发现结果（对于静态工具，一个保守的估计），你会得到缩减后的340个结果。总之，仅仅合并噪音和不精确的报告是不经济的。

02 传统的应用安全工具和现代软件不兼容

现代软件开发速度更快，正在加速发展。许多项目按周、天，甚至小时的频率来部署代码。不幸的是，像SAST、DAST、模糊测试、人工渗透测试、人工代码检查无法跟上现代软件的速度和规模。

传统应用安全工具的最大挑战是：

· 精确性：传统工具的最大问题是精确度。SAST和DAST产生大量的误报（不是真实的漏洞）和漏报（错失真正的漏洞）。工具不精确的时候，安全专家必须执行手动步骤来解决问题，这个流程耗费大量时间，导致软件开发的很大瓶颈。相比传统工具，IAST有一个巨大的信息优势，精确度的提高意味着开发人员能够直接使用结果，不需要专家介入。

· 兼容性：现代应用，特别是API，基于复杂的框架打造，自动把客户端流量和和功能对应到一起，从复杂的数据结构中解析出结果，如XML，JSON，序列化对象。没有大量定制的情况下，SAST无法跟踪这些路径，DAST无法模拟测试要求的复杂流量，IAST对这些问题具有很好的免疫力，因为它只观察运行时的复杂应用和API。

· 速度：现代软件方法，像敏捷和DevOps，进展得非常快。目标是在开发者和上线之间完全自动化。然而传统的工具花费许多小时去执行一个完全的分析（甚至不考虑使用专家分诊，去除误报）。当一个开发人员在他们的IDE环境中编译和测试代码时，IAST提供及时的反馈。IAST还能和QA一起运行测试，如果发现安全问题，能够马上停止编译。

· 扩展：安全工具必须能够使用多个规则，持续分析应用的整个组成。传统的扫描按顺序运行，无法扩展到整个企业。IAST是一个针对应用安全，完全分布式和持续的方法，意味你所有的应用和API能够被持续并行访问，因此你的安全也就能一直保持在最新的状态。

· 流程适合：IAST位于已经存在的开发工具和流程的顶端，不需要额外的步骤。做正常开发和测试时，IAST在后台运行，因为IAST非常精确，能在不了解漏洞的情况下发现它们，不需要专家，任何人都可以使用IAST做安全测试，生成干净的代码。

四、IAST 架构

既然许多人仍然不熟悉IAST，这里有助于说明IAST和其他类型的安全防护如何配合。

上图显示IAST在NIST的Cybersecurity Framework中的位置。IAST完全集中在应用安全这一行。除了检测和识别漏洞，某些IAST实施能帮助识别和分析应用。

网络到应用全栈中的IAST

使用基于插桩的方法来实现安全，并不限于应用层。安全专家已经认识到，我们可以不再只从外部来检测漏洞，外部的视角，并不能提供足够的上下文信息精准地识别漏洞，从内部做漏洞检测更容易，更精确。这种基于插桩的安全测试（和基于扫描的安全测试对比）趋势正在网络到应用的全栈中实现。

IAST是基于插桩的方法保护应用层。许多其他插桩方式的安全产品也都承认插桩的好处。不管在哪一层，直接访问都比从外部视角来测试，有很大的优势。

既然IAST直接把安全搭建在软件栈中，应用在任何环境下都会非常安全，包括在云、PAAS、VM和数据中心中。

五、部署一个IAST方案

对企业组织，IAST是一个能够横跨整个应用和API组件集，建立持续安全测试的有效方法。使用IAST，组织能在所有的应用组件中，持续并行地执行应用安全测试。

01 保护企业的应用组件集 

许多组织仅仅测试应用组件集中的一小部分，一些组织只测试重要的应用，其他组织的策略是测试所有面向外部的应用。更可能的是，你主要的网站没有受到攻击，而是合作伙伴的网站、一个复杂的移动API、或内网的业务应用受到攻击。这就是为什么保护所有应用和API，甚至非webAPI的重要性。

对许多外部和面向公共的应用，许多组织保留安全测试。事实上内部应用和外部应用的概念，取决于工作安全边界。不幸的是，由防火墙和其他网络安全设备建立起来的边界，已经变得千疮百孔，意义不大。例如，一台员工工作站，被攻击者变成内部的跳板，边界变得无关紧要。考虑测试你的整个应用组件集，包括内部应用。

02 在管道中的IAST 

记住，IAST不像一个扫描器，IAST有效地变成了应用的一部分。它能在应用运行的任何地方运行，包括开发人员的IDE，本地测试服务器，QA机器等。作为CI/CD构建的一部分，在容器中，在云中，你代码运行的任何地方。在整个软件生命周期中，你软件运行的任何地方，你都可以使用IAST。在集成和测试环境，在上线环境，尽早的使用IAST有很多好的理由。

下图描述了一个简单开发管道，使用IAST持续的发现漏洞。

你能够选择在软件生命周期中的哪个阶段使用IAST。因为IAST不需要额外的步骤。IAST和所有软件开发的不同方法兼容。特别适合DevOps，DevOps对工具敏感，需要专家贴身服务很长时间。

03 安装和配置 

安装的过程非常简单，一个典型的IAST方案通常包括两部分，IAST代理，和IAST控制台。你在控制台生成一个账户，下载一个IAST代理，执行分析，发送结果给控制台。

第一步是在你的环境中增加IAST代理，和增加一个库一样，设置环境变量，当你使用应用，IAST代理自动在后台做安全测试，重要的是，你不需要攻击应用，得到安全结果。IAST能被任何人使用，甚至刚开始做开发工作的新人。

IAST控制台让你管理整个应用组件集的安全，并行地处理。管理安全策略，配置安全控制，和其他常见开发工具集成，实现漏洞通知。

04 在开发中部署IAST—流程和集成

在开发中，我们的目标是赋能开发人员发现和修复他们自己的漏洞，提交清洁的代码。但我们必须避免拖累他们，或给出误报结果，浪费他们时间。

IAST是实现这些目标的好伙伴，因为他提供即时反馈，定位准确的代码行，在本地环境中测试。IAST可以通过IDE、或者聊天程序、缺陷追踪、其他软件的集成来报警。因为IAST提供精确的代码行，完整的HTTP请求，完整的数据和控制流，开发者的工作变得容易。他们能够修复代码，使用HTTP请求来再测试，验证问题是否解决，提交清洁代码。

05 在CI/CD和QA环境中部署IAST-流程和集成

在QA环境中，我们保证开发人员已经做了正确的事情，消除了任何漏洞。我们有自信在上线之前，消除了漏洞。万一遇到严重的安全漏洞，我们需要有停止构建的能力。但我们不能放慢构建的速度，也不需要安全专家的介入。

IAST非常适合在QA环境中做安全测试，因为它和你正常的自动化和人工测试一起，在后台自动化执行安全测试。在这个环境中，IAST通过其他CI/CD工具提供通知，也能根据审计和合规的要求，出具报告。

06 生产环境部署IAST

在生产环境做安全测试并不是一个很好的主意。理想情况下，你应该在上线之前很久就修复任何安全问题。然而，常常有许多不再主动开发的传统应用，还有第三方产品，只能在生产环境。我们仍然需要持续保证这些应用没有漏洞，我们也希望知道，是否有新的漏洞会影响这些应用。

虽然没有开发和测试环境中使用的这么普遍，IAST也能有效的使用在生产环境。因为IAST不要求源代码。能够在任何可以安装IAST代理的应用中使用，但也要考虑到IAST的性能问题。虽然速度很快，在开发和测试环境中没有被注意到，在生产中，即使几微秒也无法接受。注意，IAST可以配置，如“取样模式”，能明显地改善生产中的性能，并能随着时间提供很大的安全保护。

六、选择一个IAST方案

在这部分，我们会探索一些当你评估IAST解决方案的时候，你要考虑的关键标准。所有IAST产品工作起来都有区别，你要仔细地评估他们，保证他们能在你的环境中工作。

相关部门

在这个选择的过程中，你要考虑多个不同的部门：

安全部门——安全部门，很显然在漏洞管理中，扮演着一个重要的角色。在整个组织的应用和API组件中，IAST是一个主要的漏洞提供者，应用得好，IAST能够帮助开发在早期消除大多数漏洞，不需要安全部门的介入。

开发团队——开发团队有很大的责任，保证应用和API没有漏洞。开发团队经常有使用安全工具的噩梦经历，也许会怀疑IAST能力，因此关键是确保他们理解IAST的优点，得到他们的支持。

DevOps—— DevOps团队一个重要的工作是推动软件快速上线。这和静态及动态扫描都不兼容，因为他们要花费很长时间来扫描，要求大量工作去消除误报。IAST能帮助DevOps团队把自己的安全做好，提供完全自动化的方法，在安全上很自信地推动代码上线。

管理团队——对应用安全的自信能够帮助管理层做出数字化转型的决定，向DevOps转移，或向云上转移。保证IAST作为认可的应用安全测试技术，能帮助业务转型。

技术考虑

语言支持——不同的厂商支持不同的语言，因此你要保证IAST支持你重要的应用和API正在使用的语言。

框架支持——应用框架和语言同样重要，除非IAST支持你正在使用的框架，否则在检测漏洞方面不会有效。

精确度——你会想使用一个包含一系列真实漏洞的应用，来评估精确度。仔细测试IAST的识别能力，没有误报。使用OWASP Benchmark看到操作详情，来衡量应用安全测试工具的好坏。

扩展性——考虑到应用组件集的数量，包括API，内部应用和产品。是否IAST能够扩展到持续分析所有的应用？达到这个水平需要多少人来支持。

规则集覆盖——寻找一个宽泛的规则集，覆盖你关心的攻击。包括CVE。

可见性——IAST有它自己的仪表盘吗？或仅仅是依赖缺陷跟踪系统。输出什么样的报警，通知、报告？有IDE和CI/CD插件支持吗？

安装——大多数IAST产品安装简单，不要求流程变更。安全可以自动化吗，是否可以被增加到容器和镜像里面，可以自动地支持新的应用？

配置——是否IAST要求复杂的配置，来实现精确的分析？常见的安全控制和规则是否容易地添加到IAST里面？

管理和更新——是否有统一管理的方法更新IAST规则和功能？软件更新是自动化的吗？IAST包含企业级特性，如LDAP集成、强认证、企业级访问控制、数据传输和保存加密、完整的安全日志等？

集成—— IAST提供插件，能够和常见的安全及DevOps工具及管道集成吗？对收集到的数据有完整的API吗？这个API也包含管理员操作的功能吗？

IAST能够快速评估，因为在一个非常短的时间内，你就会知道它是否能在你的应用上工作。你可以只在几个应用上部署IAST，运行测试，得出评估结果。

七、在常见的使用场景中应用IAST

在这部分，我们探索如何使用IAST解决常见的安全问题。一般来讲，IAST能够识别和诊断软件本身的漏洞，不是容器，也不是操作系统或者网络攻击。

每个产品都不一样，但因为IAST可以访问代码、HTTP流量、许多其他的安全信息资源，它能解决一个宽范围的漏洞。

注意下列的IAST发现的漏洞名单包括深入到代码的漏洞（传统上只有SAST能够发现），和HTTP流量的漏洞（传统上只有DAST能发现）

注入—SQL 注入，NoSQL注入，反射式跨站脚本，存储式跨站脚本，路径遍历，命令注入，LDAP注入，XPath注入，表达式语言注入，OGNL注入，, Expression Language Injection, OGNL Injection, Hibernate Injection, 头注入, Java 反射注入，日志注入，不安全代码执行，XML 外部实体注入(XXE)

HTTP 头 – Caching, Anti-Clickjacking Controls, HSTS, 不安全Cookie, Response with Insecurely Configured Content-Security-Policy Header, Response with Insecurely Configured Strict-Transport-Security Header, Response With X-XSS-Protection Disabled, Response Without Content-Security-Policy Header, Response Without X-Content-Type Header, Version Header Enabled

解析 - XML External Entities, Untrusted Deserialization, Parameter Pollution, Regular Expression DoS, Unvalidated Redirect, Use of readLine on Untrusted Streams, Trust Boundary Violation, Unchecked Autobinding

认证 – Insecure Authentication Protocol, Unprotected Connection Strings, Session Cookie Has No 'secure' Flag, Session Rewriting, Expired Session IDs Not Regenerated, Forms Auth Protection Mode, Forms Authentication Cross-App Redirect, Forms Authentication SSL, Forms Without Autocomplete Prevention, Hardcoded Password, Session Cookie Has No 'HttpOnly' Flag, HttpOnly Cookie Flag Disabled

授权 – Cross-Site Request Forgery, Server-Side Request Forgery, Verb Tampering Weakness, Role Manager Protection Mode, Role Manager SSL

加密 – Insecure Encryption Algorithms, Insecure Hash Algorithms, Padding Oracle, Hardcoded Cryptographic Key, Weak Random Number Generation, MAC Validation Disabled

弱配置 – Detailed Error Messages, Event Validation Disabled, Header Checking Disabled, Insecure JSP Placement, Large Max Request Length, Overly Long Session Timeout, Request Validation Disabled, Request Validation Mode Disabled, Tracing Enabled, Tracing Enabled for ASPX, Unsafe XML Decoding, Viewstate Encryption Disabled, Viewstate WCF Exception Details, WCF Replay Detection Not Enabled, WCF Service Metadata Enabled, Weak Membership Configuration

有些IAST产品也包含一个强大的规则语言，允许识别白名单（一直要求的代码执行行为特征）和黑名单（不允许的代码行为特征）安全规则。

使用IAST，确保开发人员提交”清洁”的代码

开发人员使用IAST，在开发环境中，当生成和测试代码时，实时地做安全分析。开发人员必须要做的是把IAST代理增加到本地的服务器环境中，一旦IAST安装好了，开发人员可以做日常的工作和测试，自动或者手动，不用再做一次安全测试。开发人员通过他们使用的安全工具，如Eclipse，IDEA，VisualStudio，Slack，Hipchat，Chrome，JIRA，VSTS等，实时地收到安全漏洞通知。

在部署前，使用IAST提供强大保证

IAST也可以用在QA、测试、CI/CD阶段，保证开发阶段没有漏洞。不管是用来做自动化测试的测试服务器，还是CI/CD构建流程的一部分，只要把IAST代理添加到用来做QA的服务器中。对于完全组装的应用，在QA中使用IAST，是一个有效的最后检查手段，因为它会被配置和部署，这里发现的漏洞需要仔细处理。IAST可以配置成自动化生成缺陷跟踪ticker，或停止软件构建。

使用IAST保证API安全

传统的静态和动态工具不擅长测试API安全，这些工具无法处理复杂协议（JSON，XML，二进制，或其他payload），或者架构中用来构建API的复杂数据流和控制流。大多数API使用软件框架，包含自动化payload解析，对象映射（object mapping）。许多使用注释把数据发送到合适的方法。因为IAST从API内部收集安全信息，和常见web应用工作方式一样，能够很容易识别API漏洞。

使用IAST测试开源软件中已知漏洞

虽然开源软件漏洞常常看起来像洪水猛兽，但事实也许比看到的更严重。有几百万个开源库，但只有有限的安全专家在测试他们。IAST根据CVE库，能自动地分析开源软件漏洞。因为IAST能持续运行，并行地遍历整个应用的组件，在几分钟内检测新引入库中的问题，传统的开源软件扫描器需要重新扫描整个企业。除此之外，IAST能精确地告诉你，在开源软件库中到底调用了哪些代码。平均72%的库只包含在应用程序的编译依赖中，从来没有被应用程序真正调用。IAST能节省您升级不真正带来风险的库的工作。

使用IAST来持续审计和合规

IAST工具支持很宽范围的安全标准，包括PCI DSS，HIPPA，NIST 800-53，OWASP Top 10，OWASP ASVS，DISA AppSec STIG。IAST工具能生成报告，证明应用被完全安全测试过，没有漏洞被发现。因为这些报告任何时候都能生成，能显著的加快审计和合规流程。

使用IAST对传统应用的持续保证

传统应用提出了一个特别的应用安全挑战，常常运行很长时间，但没有大量的开发工作。传统安全过程倾向于在部署之前保证安全，也许不会发现新出现的漏洞。而不是像IAST是一个持续的安全方法，因为IAST能持续运行，并行处理，随着扩展覆盖到整个应用的组件集，其独特的定位可以帮助传统应用。

使用IAST测试开源软件中潜在的漏洞

大多数的开源漏洞还没有被检测到，因为IAST测试你整个软件栈，它能在你所使用的库和框架中，发现这些攻击者已经掌握，但研究者还没有发现的“零day”漏洞。你可以选择挑选其他的库，或贡献一个补丁，或使用RASP阻止漏洞被攻击。

使用IAST加强安全编码指南

虽然IAST使用了大量的漏洞规则，它也能加强你组织自身的安全编码指南。你可以生成“正向”的规则，如“每个API必须调用AccessController.isAuthorized（）方法来授权“。IAST能加强这些规则，给与开发人员即时反馈，告诉开发人员组织是如何实现安全的。随着时间推移，组织能使用这个能力，从负面的“阻止漏洞模型”向正向的“使用企业安全控制”模型转变。

八、IAST和DevOps

软件开发项目向DevOps转变过程中，构建和测试软件的流程加速了，使得SAST和DAST越来越难以使用。IAST格外适合DevOps，因为它赋能开发者得到及时和精准的反馈，不要求任何额外的流程步骤，发现和修复他们自己的安全漏洞。这就最小化了安全工作对开发的影响，明显减少了下游的安全工作。

使用IAST,你和以往一样构建、测试、部署代码，唯一的区别是IAST在后台运行，确保你不会引入任何危险的代码或库漏洞。

如上图所示，IAST扩展性好，非常容易的在几百上千个应用上，并行地持续执行应用安全测试。

九、IAST下一步方向？

IAST在市场上表现良好，有多家厂商和许多大规模部署案例，但仍有明显的创新空间，希望厂商们能扩展语言和框架的支持，提高保护能力，甚至增加对于应用安全行业来说全新的技术。