-
2021-02-10 10:01:50
文章目录
简介
我们知道Java中Collection接口下的很多集合都是线程不安全的, 比如 java.util.ArrayList不是线程安全的, 因此如果在使用迭代器的过程中有其他线程修改了list,那么将抛出ConcurrentModificationException,这就是所谓fail-fast策略。
这一策略在源码中的实现是通过 modCount 域,modCount 顾名思义就是修改次数,对ArrayList 内容的修改都将增加这个值,那么在迭代器初始化过程中会将这个值赋给迭代器的 expectedModCount。在迭代过程中,判断 modCount 跟 expectedModCount 是否相等,如果不相等就表示已经有其他线程修改了 list
注意到 modCount 声明为 volatile,保证线程之间修改的可见性。modCount和expectedModCount
modCount和expectedModCount是用于表示修改次数的,其中modCount表示集合的修改次数,这其中包括了调用集合本身的add, remove, clear方法等修改方法时进行的修改和调用集合迭代器的修改方法进行的修改。而expectedModCount则是表示迭代器对集合进行修改的次数。
设置expectedModCount的目的就是要保证在使用迭代器期间,list对象只能有这一个迭代器对list进行修改。
在创建迭代器的时候会把对象的modCount的值传递给迭代器的expectedModCount:
private class ListItr implements ListIterator<E> { private Node<E> lastReturned; private Node<E> next; private int nextIndex; private int expectedModCount = modCount;
如果创建多个迭代器对一个集合对象进行修改的话,那么就会有一个modCount和多个expectedModCount,且modCount的值之间也会不一样,这就导致了moCount和expectedModCount的值不一致,从而产生异常:
public E next() { checkForComodification(); if (!hasNext()) throw new NoSuchElementException(); lastReturned = next; next = next.next; nextIndex++; return lastReturned.item; }
上面的代码中的checkForComodification会检查modCount和expectedModCount的值是否一致,不一致则抛出异常。
final void checkForComodification() { if (modCount != expectedModCount) throw new ConcurrentModificationException();
modCount是如何被修改的
// 添加元素到队列最后 public boolean add(E e) { // 修改modCount ensureCapacity(size + 1); // Increments modCount!! elementData[size++] = e; return true; } // 添加元素到指定的位置 public void add(int index, E element) { if (index > size || index < 0) throw new IndexOutOfBoundsException( "Index: "+index+", Size: "+size); // 修改modCount ensureCapacity(size+1); // Increments modCount!! System.arraycopy(elementData, index, elementData, index + 1, size - index); elementData[index] = element; size++; } // 添加集合 public boolean addAll(Collection<? extends E> c) { Object[] a = c.toArray(); int numNew = a.length; // 修改modCount ensureCapacity(size + numNew); // Increments modCount System.arraycopy(a, 0, elementData, size, numNew); size += numNew; return numNew != 0; } // 删除指定位置的元素 public E remove(int index) { RangeCheck(index); // 修改modCount modCount++; E oldValue = (E) elementData[index]; int numMoved = size - index - 1; if (numMoved > 0) System.arraycopy(elementData, index+1, elementData, index, numMoved); elementData[--size] = null; // Let gc do its work return oldValue; } // 快速删除指定位置的元素 private void fastRemove(int index) { // 修改modCount modCount++; int numMoved = size - index - 1; if (numMoved > 0) System.arraycopy(elementData, index+1, elementData, index, numMoved); elementData[--size] = null; // Let gc do its work } // 清空集合 public void clear() { // 修改modCount modCount++; // Let gc do its work for (int i = 0; i < size; i++) elementData[i] = null; size = 0; }
- 也就是在对集合进行数据的增删的时候都会执行modcount++, 那么如果一个线程还在使用迭代器遍历这个list的时候就会发现异常, 发生 fail-fast(快速失败)
fail-fast(快速失败)和fail-safe(安全失败)比较
Iterator的快速失败是基于对底层集合做拷贝是浅拷贝,因此,它受源集合上修改的影响。java.util包下面的所有的集合类都是快速失败的
而java.util.concurrent包下面的所有的类都是使用锁实现安全失败的。
快速失败的迭代器会抛出ConcurrentModificationException异常,而安全失败的迭代器永远不会抛出这样的异常。
fail-fast解决什么问题
fail-fast机制,是一种错误检测机制。
它只能被用来检测错误,因为JDK并不保证fail-fast机制一定会发生。只是在多线程环境下告诉客户端发生了多线程安全问题.
所以若在多线程环境下使用fail-fast机制的集合,建议使用“java.util.concurrent包下的类”去取代“java.util包下的类”。如何解决fail-fast事件
ArrayList对应的CopyOnWriteArrayList进行说明。我们先看看CopyOnWriteArrayList的源码:
public class CopyOnWriteArrayList<E> implements List<E>, RandomAccess, Cloneable, java.io.Serializable { ... // 返回集合对应的迭代器 public Iterator<E> iterator() { return new COWIterator<E>(getArray(), 0); } ... private static class COWIterator<E> implements ListIterator<E> { private final Object[] snapshot; private int cursor; private COWIterator(Object[] elements, int initialCursor) { cursor = initialCursor; // 新建COWIterator时,将集合中的元素保存到一个新的拷贝数组中。 // 这样,当原始集合的数据改变,拷贝数据中的值也不会变化。 snapshot = elements; } public boolean hasNext() { return cursor < snapshot.length; }
- CopyOnWriteArrayList是自己实现Iterator, 并且CopyOnWriteArrayList的Iterator实现类中,没有所谓的checkForComodification(),更不会抛出ConcurrentModificationException异常
- CopyOnWriteArrayList在进行新建COWIterator时,将集合中的元素保存到一个新的拷贝数组中。这样,当原始集合的数据改变,拷贝数据中的值也不会变化。
更多相关内容 -
Windows操作系统----安全机制----Token
2021-12-09 12:04:30简介 Token结构体是访问权限检查中的代表主体身份的核心数据结构,Windows 10 x64平台下的结构见最后。 我们比较关注其中的特权位图和三个代表主体身份的Sid数组:UserAndGroups...模拟允许此线程与安全对象交互时用.简介
Token结构体是访问权限检查中的代表主体身份的核心数据结构,Windows 10 x64平台下的结构见最后。
我们比较关注其中的特权位图和三个代表主体身份的Sid数组:UserAndGroups,RestrictedSids,Capabilities。
进程主令牌和模拟令牌
每一个进程有一个主要的令牌,它描述了与当前进程相关的用户帐户的安全上下文。默认情况下,系统用主令牌当一个进程的线程与一个安全对象相互作用时。此外,一个线程可以模拟一个客户端帐户。模拟允许此线程与安全对象交互时用客户端的安全上下文。一个正模拟客户端的线程拥有一个主令牌和一个模拟令牌。
用函数:OpenProcessToken 来接收一个指向一个进程的主令牌句柄。用OpenThreadToken函数来得到一个指向线程模拟令牌的句柄。
Privileges位图
特权在用户态是通过LUID来表示,在内核结构体_TOKEN中是使用三个位图来表示:
kd> dt _SEP_TOKEN_PRIVILEGES
nt!_SEP_TOKEN_PRIVILEGES
+0x000 Present : Uint8B
+0x008 Enabled : Uint8B
+0x010 EnabledByDefault : Uint8B
分别代表当前的主体可以选用的特权集合(Present)、已经打开的特权集合(Enabled)和默认打开的特权集合(EnabledByDefault),后两个集合应该是Present集合的子集。
与代表主体身份的Sid数组不同,特权集合的表示简单,而且没有任何保护。从用户态通过API只能打开或者关闭某一项已经存在的特权,而不能增加可选的特权,换句话说,用户态只能修改Enabled特权集合,而不能修改Present特权集合;从内核态可以直接修改Present特权集合,比如给普通进程增加SeAssignPrimaryTokenPrivilege特权,以便为子进程显式指定令牌,而不是继承当前进程的令牌,可以达到扩大子进程权限的效果。
代表主体身份的Sid数组
三个代表主体身份的Sid数组分别是:
UserAndGroups:
代表着主体的普通用户身份和组身份,是不可或缺的成员;
RestrictedSids:
可选成员,如果不为空,则代表着当前的令牌是受限令牌,受限令牌通过从普通令牌中过滤掉一些比较敏感的身份转化而来,受限令牌中的UserAndGroups成员与普通令牌相同,但是RestriectedSids成员不为空,里面保存着过滤后的身份子集;由于在访问权限检查时,三个身份Sid数组要同时进行检查,只有结果都通过才允许该次访问,因此通过增加代表着受限制的权限集合的RestrictedSids成员,既达到了限制令牌权限的目的,又在UserAndGroups成员中保留了原有令牌的完整身份信息。
Capabilities:
可选成员,仅用于AppContainer,其中的Sid代表着与App相关的身份,比如拥有连接网络、访问当前位置等权限的身份。
这三个Sid数组都关联了哈希信息,以保护其完整性,因此,即使从内核态直接修改,也会因为无法通过完整性验证而失败。不过好在哈希的算法非常简单,下面展示的就是Windows 10 x64平台下面该算法的C++演示代码:浅析Windows的访问权限检查机制 – 绿盟科技技术博客
UAC与关联令牌
当用户登录Windows时,操作系统会为用户生成一对初始令牌,分别是代表着用户所拥有的全部权限的完整版本令牌(即管理员权限令牌),以及被限制管理员权限后的普通令牌,二者互为关联令牌;此后,代表用户的进程所使用的令牌都是由普通令牌继承而来,用来进行常规的、非敏感的操作;当用户需要进行一些需要管理员权限的操作时,比如安装软件、修改重要的系统设置时,都会通过弹出提权对话框的形式提示用户面临的风险,征求用户的同意,一旦用户同意,将会切换到当前普通令牌关联的管理员权限令牌,来进行敏感操作。通过这种与用户交互的方式,避免一些恶意程序在后台稍稍执行敏感操作。
关联令牌是通过Logon Session来实现的,下图展示了其大致原理:
Token结构
下面展示的是Windows 10 x64平台下的构成。
kd> dt nt!_TOKEN +0x000 TokenSource : _TOKEN_SOURCE +0x010 TokenId : _LUID +0x018 AuthenticationId : _LUID +0x020 ParentTokenId : _LUID +0x028 ExpirationTime : _LARGE_INTEGER +0x030 TokenLock : Ptr64 _ERESOURCE +0x038 ModifiedId : _LUID +0x040 Privileges : _SEP_TOKEN_PRIVILEGES +0x058 AuditPolicy : _SEP_AUDIT_POLICY +0x078 SessionId : Uint4B +0x07c UserAndGroupCount : Uint4B +0x080 RestrictedSidCount : Uint4B +0x084 VariableLength : Uint4B +0x088 DynamicCharged : Uint4B +0x08c DynamicAvailable : Uint4B +0x090 DefaultOwnerIndex : Uint4B +0x098 UserAndGroups : Ptr64 _SID_AND_ATTRIBUTES +0x0a0 RestrictedSids : Ptr64 _SID_AND_ATTRIBUTES +0x0a8 PrimaryGroup : Ptr64 Void +0x0b0 DynamicPart : Ptr64 Uint4B +0x0b8 DefaultDacl : Ptr64 _ACL +0x0c0 TokenType : _TOKEN_TYPE +0x0c4 ImpersonationLevel : _SECURITY_IMPERSONATION_LEVEL +0x0c8 TokenFlags : Uint4B +0x0cc TokenInUse : UChar +0x0d0 IntegrityLevelIndex : Uint4B +0x0d4 MandatoryPolicy : Uint4B +0x0d8 LogonSession : Ptr64 _SEP_LOGON_SESSION_REFERENCES +0x0e0 OriginatingLogonSession : _LUID +0x0e8 SidHash : _SID_AND_ATTRIBUTES_HASH +0x1f8 RestrictedSidHash : _SID_AND_ATTRIBUTES_HASH +0x308 pSecurityAttributes : Ptr64 _AUTHZBASEP_SECURITY_ATTRIBUTES_INFORMATION +0x310 Package : Ptr64 Void +0x318 Capabilities : Ptr64 _SID_AND_ATTRIBUTES +0x320 CapabilityCount : Uint4B +0x328 CapabilitiesHash : _SID_AND_ATTRIBUTES_HASH +0x438 LowboxNumberEntry : Ptr64 _SEP_LOWBOX_NUMBER_ENTRY +0x440 LowboxHandlesEntry : Ptr64 _SEP_LOWBOX_HANDLES_ENTRY +0x448 pClaimAttributes : Ptr64 _AUTHZBASEP_CLAIM_ATTRIBUTES_COLLECTION +0x450 TrustLevelSid : Ptr64 Void +0x458 TrustLinkedToken : Ptr64 _TOKEN +0x460 IntegrityLevelSidValue : Ptr64 Void +0x468 TokenSidValues : Ptr64 _SEP_SID_VALUES_BLOCK +0x470 IndexEntry : Ptr64 _SEP_LUID_TO_INDEX_MAP_ENTRY +0x478 VariablePart : Uint8B
欢迎关注我的微博:大雄_RE。专注软件逆向,分享最新的好文章、好工具,追踪行业大佬的研究成果。
-
BLE安全机制从入门到放弃
2019-09-05 20:13:41BLE安全机制从入门到放弃 原文作者: Jayden Huang 原文链接: https://jaydenh215.github.io/2019/05/14/BLE安全机制从入门到放弃/ 网上介绍BLE安全机制的文章大多只关注业务概念,如:配对加密是什么,绑定过程是...BLE安全机制从入门到放弃
原文作者: Jayden Huang
原文链接: https://jaydenh215.github.io/2019/05/14/BLE安全机制从入门到放弃/
网上介绍BLE安全机制的文章大多只关注业务概念,如:配对加密是什么,绑定过程是什么;而忽略了其中涉及到的信息安全知识,如:使用了加密和认证有什么用,不用又会怎么样。让新人读了有种云里雾里,知其然而不知其所以然的感觉。这里结合涉及到的信息安全知识,换一个角度来认识BLE安全机制。
前言
标题中的“放弃”有点调侃的意思,是指读者在读完之后,可以不依赖别人,靠自己读蓝牙核心规范加深认识,这样收获也会更多,也是这篇博文的目标。
为了易于理解,会对蓝牙核心规范的算法进行裁剪,但是原理是不变的,标准算法应参考蓝牙核心规范。
最后,这是博主的一得之见,欢迎各位指正。目录
- 密码技术初探
- 对称密码
- diffie-hellman密钥交换算法
- 椭圆曲线diffie-hellman密钥交换算法
- 消息认证码
- 认证加密CCM
- 信息安全小结
- ble安全机制初探
- ble40安全机制
- ble42安全机制
- 总结
- 参考资料
密码技术初探
在介绍密码技术之前,我们先给参与信息交互的对象赋予名称,方便举例和记忆。
下图是重要角色一览表:
Alice和Bob分别是两家银行,Bob银行通过网络向Alice银行发送了一条500元的汇款请求:从账户B-6789向账户A-1234汇款500元。当然,会有人在网络中尝试攻击银行间通信,妄想用非法手段牟利,其中就有这样一个分工明确的组织,由以下成员组成:
- Eve
- 窃听不同银行之间的消息,从中获取重要信息,如获知“从账户B-6789向账户A-1234汇款500元”。
- Mallory:
- 篡改不同银行之间的消息,如修改汇款请求为“从账户B-6789向账户A-1234汇款5000000元”。
- 伪装成Bob银行,以Bob银行名义发送一条新的汇款请求给Alice银行。
从上述例子可知消息面临的威胁有:窃听、篡改和伪装,对应的安全特性为:机密性、一致性、是否已认证。
“威胁”和“安全特性”的关系可以这样描述:
- 如果消息没有加密,消息则不具有机密性,无法防止他人窃听;
- 如果发送者发送的消息和接收者的消息是不同的,说明消息被篡改过,不具有一致性;
- 如果没有对消息进行认证,无法保证消息来自正确发送者而不是伪装者。
存在威胁,就会有对应的解决方法,下面会针对每个威胁介绍对应的密码技术。
对称密码
算法一般指复杂步骤,加密算法指的是用明文生成密文的步骤,解密的步骤称为解密算法,两者统称为密码算法,密码算法需要用到密钥。
所谓对称密码(symmetric cryptography)技术,即加密和解密时用的是同一个密钥,加密和解密的算法一般是公开的,如AES128。
对称密码应用图:
对称密码解决的问题
如上图所示
- Bob创建一条汇款请求消息;
- 用密钥key对它加密;
- 将加密后的消息发给Alice;
- Alice收到密文;
- Eve窃听到了加密后的消息,由于没有密钥key,无法解读内容;
- Alice用密钥key对消息解密;
- Alice获得一条汇款请求消息。
对称密码技术可以解决窃听的威胁。
对称密码无法解决的问题
对称密码技术可以解决窃听的威胁,但是有一个前提,就是在这之前发送者和接收者要有相同的密钥key,所以一定要先给接收者配送密钥,有以下几种方式:
- Bob通过网络先将key发送给Alice,但容易被Eve截取到;
- Bob乘坐交通工具将密钥key亲手交给Alice,或者其他网络以外的方式配送密钥,这种方式成本高维护麻烦,称为带外(Out-Of-Band)配送;
- 用diffie-hellman密钥交换算法解决;
- 用椭圆曲线diffie-hellman密钥交换算法解决。
diffie-hellman密钥交换算法
先不管DH密钥交换算法是什么,我们现在关注问题是:在Eve窃听网络的情况下,如何解决Bob配送key给Alice的问题?
密码界的前辈们从数学角度上找到了答案:利用这个数学难题,Bob和Alice可以在Eve窃听的情况下,协商出一个密钥,而Eve不知道密钥是什么。
最好解决配送问题的办法就是不配送,通过协商获得相同的密钥,是不是很神奇,话不多说,我们看看是怎么实现的。
离散对数问题
背景知识:mod符号表达的意思是求余数,如表达式5 mod 7的计算思路为:5除以7等于0,余数为5,所以5 mod 7 = 5。
现有离散对数问题如下,请问满足公式的x是多少:
为了求x,我们可以运用上面提到的背景知识来做计算,像下面这样依次尝试一遍,就可以得到x = 9。
例子的数字较小,所以很快就找到答案了,当数字很大时,计算x就会变得非常耗时,快速求出离散对数的算法到现在还没被发现,所以可以得到这样的一个简单结论:
对于上图公式,已知G、p、Y的时候,很难求出x。接下来我们看看如何具体利用这个数学问题来协商出密钥的。
diffie-hellman密钥交换算法应用
在DH中,我们将Y称为公钥(public key),将x称为私钥(private key),则有以下结论:已知G、p、公钥的时候,很难求出私钥。
如上图所示- Bob和Alice选择一个公开的G和p,Eve当然也知道这个公开的G和p;
- Bob和Alice分别随机生成各自的私钥sb和sa;
- Bob和Alice根据G、p以及各自的私钥,生成公钥pb和pa;
- Bob和Alice互发公钥pb和pa,Eve窃听到了pb和pa;
- Bob和Alice计算出共享密钥DHkey。
Eve能计算出DHkey吗?
对比三个角色最后的“已知信息”可知,只要Eve知道任一私钥(sb或sa),它就能容易算出DHkey,而这时候问题就变成了:Eve在已知G、p、公钥情况下,是否能求出私钥,这也就是我们上面提到的离散对数问题,这是很难做到的。
diffie-hellman密钥交换算法解决的问题
因为DH密钥交换算法利用了“离散对数问题”的复杂度,所以就算Eve一直窃听,Bob和Alice也能协商出一个共享密钥,而Eve却因为复杂的数学问题而没办法算出共享密钥,也就解决了对称密码中的配送问题。
椭圆曲线diffie-hellman密钥交换算法
DH是利用了“离散对数问题”的复杂度来实现密钥的安全交换的,如果将“离散对数问题”改为“椭圆曲线上的离散对数问题”,这样的算法就叫椭圆曲线diffie-hellman密钥交换(ECDH)。
两者密钥交换总体流程相同,只是利用的数学问题不同而已,ECDH能够用较短的密钥长度实现较高的安全性。
椭圆曲线diffie-hellman密钥交换算法应用
ECDH中的数学问题可以这样简单定义:
已知椭圆曲线上的点Y、基点G的时候,很难求出x。其中算术符号*表示的不是普通的乘法,而是一种在椭圆曲线上的特殊算法。在ECDH中,我们称Y为公钥(public key),x为私钥(private key)。
如上图所示- Bob和Alice选择一条密码学家推荐的椭圆曲线,选择曲线上的一个基点G;
- Bob和Alice分别随机生成各自的私钥sb和sa;
- Bob和Alice根据G以及各自的私钥,生成公钥pb和pa;
- Bob和Alice互发公钥pb和pa,Eve窃听到了pb和pa;
- Bob和Alice计算出共享密钥DHkey。
椭圆曲线diffie-hellman密钥交换算法无法解决的问题
DH和ECDH都能解决密钥配送问题,结合对称密码技术,就能保证消息的机密性,防止被窃听了,但是对于篡改和伪装的攻击,却无能为力。为了解决剩下这两个威胁,就要靠其他技术手段了。
如上图所示,Mallory不需要知道密文是什么意思,但是他可以修改密文,导致Alice解密出预期以外的内容。
如上图所示,Mallory夹在Bob和Alice之间并伪装他们。对于Mallory来说,DHkey是赤裸裸的,所以Bob和Alice互发的消息是没有机密性的,这种攻击也称为中间人攻击(MITM)。消息认证码
消息认证码(MAC)技术是检查信息一致性并进行认证的技术,发送者通过MAC算法可以输出一个MIC值,接收者通过校验MIC值不仅可以判断消息一致性,还能判断消息是否来自正确的发送者。
MAC技术有以下几种重要性质:- 正向快速:给定明文、MAC算法和密钥key,在有限时间和有限资源内能计算出MIC。
- 逆向困难:给定MIC、MAC算法和明文,在有限时间内很难(基本不可能)逆推出密钥。
- 输入敏感:原始输入信息修改一点信息,产生的MIC看起来应该都有很大不同。
- 冲突避免:很难找到两段内容不同的明文,使得它们的MIC一致(发生冲突)。即对于任意两个不同的数据块,其MIC相同的可能性极小;对于一个给定的数据块,找到和它MIC相同的数据块极为困难。
MAC技术与对称加密技术有一个显著差异:加密解密是双向的,可以互相推导,而认证只能单向;加密是为了解密,MAC设计是无法解。
消息认证码解决的问题
消息经过CMAC算法之后,为何Mallory无法篡改消息和伪装呢?
消息一致性检查和认证示意图:
-
Mallory如果想篡改明文,那就同时也要篡改MIC,否则无法通过Alice的校验,但是应该将MIC改成多少呢?因为Malloyr没有共享密钥,所以他也不知道MIC应该是什么。如果想篡改MIC,那就同时也要篡改明文才能通过Alice的校验,由于MAC算法的逆向困难性质,Mallory不知道明文应该是什么。
-
Bob用CMAC算法认证一条消息并发给Alice,并要求Alice也用CMAC算法认证并返回一条消息给Bob。若Mallory伪装成Alice,由于没有认证密钥,无法返回通过Bob校验的消息。
消息认证码无法解决的问题
没错,要使用MAC技术,首先要有相同的认证密钥,又回到了之前的密钥配送问题,具体这里采用哪种方式解决配送密钥问题,视实际情况而定。
消息认证码攻击方式
对于MAC算法来说,应保证不能根据MIC和明文推测出通信双方所使用的密钥。但实际上用穷举法是可以推测出来的,如果使用密码学安全的、高强度的伪随机数生成器生成密钥,就会使得破解时间需要很长以至在现实中几乎不可能破解。而如果密钥是人为选定的,就会大大增加被推测出来的风险。
认证加密CCM
其实上文一直在有意无意的强调一个事情,那就是加密和认证是独立的两个概念。加密能防止窃听,认证能防止篡改和伪装。前辈们用一种密码技术将两者融合起来——CCM(Counter with CBC-MAC)。
通过查阅资料,以我的战五渣水平只能理解到这一程度:
- 发送方先对明文使用MAC技术,然后对称加密成密文;
- 接收方先用对称加密技术解密密文,然后用MAC技术校验明文;
- 发送方和接收方需要至少一个共享随机数和一个共享密钥,随机数可以公开,密钥不可以公开。
上图只是个人猜测的CCM应用示意图,有可能是不对的,因为不是术业专攻方向,没有深入研究,秉着求真精神,觉得应该提醒大家,避免误导。
放上图的目的是:加密和认证可以做在一个算法中,而且BLE就是这么用的。
信息安全小结
威胁、安全特性、密码技术关系图:
总结:- 为了解决窃听问题,采用对称密码技术;
- 为了解决对称密码技术的加密密钥配送问题,采用配送密钥技术;
- 为了解决篡改问题,采用消息认证码技术;
- 为了解决伪装问题,采用消息认证码技术;
- 为了解决消息认证码技术的认证密钥配送问题,采用配送密钥技术。
Tips:无论消息认证码技术还是对称密码技术,都需要用到配送密钥技术,而不同的配送密钥技术本身,也会涉及到认证强度的问题。比如希望用ECDH来解决消息认证码的认证密钥配送问题,但是ECDH本身认证强度为零,所以它也需要消息认证码技术来证明ECDH过程中没有出现篡改或者伪装攻击,即又要使用消息认证码技术,导致进入了死循环。所以需要选择合适的密钥配送技术,常见的有:邮箱验证码、手机短信验证码、NFC、目测法等。
ble安全机制初探
在介绍ble安全机制之前,我们先给参与信息交互的对象赋予名称,方便举例和记忆。
ble重要角色一览表:
背景知识:简单来说ble设备可分为两种角色,一种是主机角色(master),另一种是从机角色(slave),有以下几种差异:1. 建立连接前
-
主机能进入扫描状态、发起连接状态,不能进入广播状态;
-
从机能进入广播状态,不能进入扫描状态和发起连接状态;
-
一定是由主机发起连接,从机只能被连接。
2. 建立连接后 -
一定是由主机发起配对,但是从机能够请求主机发起配对;
ble各个状态示意图:
-
广播状态:设备正在往空中发送广播包,谁都可以收得到;
-
扫描状态:设备正在接收空中的广播包,看看谁在发,发什么;
-
发起连接状态:设备指定与另外一个设备发起连接;
-
明文数传阶段:两个已连接设备之间,用明文传送数据包;
-
配对阶段:两个已连接设备之间,运用密码技术生成各种安全强度的密钥;
-
加密过程:两个已连接设备之间,使用配对阶段输出的密钥,或者绑定阶段提供的密钥,衍生出最终用于加密底层数据包的密钥;
-
密文数传阶段:两个已连接设备之间,用密文传送数据包;
-
绑定阶段:用“绑定”这个词特定描述配对阶段中的第三阶段,该阶段交换绑定信息,有了绑定信息下次需要密文数传可以跳过配对阶段。
除了展示两种角色的异同,我觉得有必要通过上图澄清几个概念,加深大家的理解:
- 复杂密码技术是运用在已连接之后的配对阶段,所以不存在配对失败,导致ble无法正常建立连接,至多是配对失败,导致连接断开。
- 连接后,不一定要启动配对,如果明文数传已经满足应用要求,就没必要启动配对了。
ble4.0安全机制
从用户角度提出问题:我现在对密码技术有初步了解了,也知道ble安全机制的一些背景知识,评估下来连接之后的明文数传风险太大,我要用到密文数传,ble提供什么样的解决方案呢?
上图是ble4.0安全机制简单示意图,是上一节“建立连接后”的细节展开,观察方式从上到下为角色的时间轴,从左到右分别是不同的角色,空白地方的文本为传递的数据,虚线为可选项,双斜杠为不展开讨论的内容。对于密文数传,ble提供解决方案分四种情况:
-
首次连接无绑定
首次连接,配对输出临时密钥(STK),加密过程用STK衍生出会话密钥(sessionKey)和随机数(IV)用于CCM认证加密,后面都是密文数传。
-
首次连接有绑定
首次连接,配对输出临时密钥(STK),加密过程用STK衍生出会话密钥(sessionKey)和随机数(IV)用于CCM认证加密,后面都是密文数传,进入绑定阶段,从机将长期密钥(LTK)发送给主机保存。
-
第二次连接且首次连接无绑定
第二次连接,配对输出临时密钥(STK),加密过程用STK衍生出会话密钥(sessionKey)和随机数(IV)用于CCM认证加密,后面都是密文数传。
-
第二次连接且首次连接有绑定
第二次连接,跳过配对阶段,加密过程使用之前绑定的LTK衍生出会话密钥(sessionKey)和随机数(IV)用于CCM认证加密,后面都是密文数传。
由下往上读图,回答用户提出的问题:
ble4.0选择CCM给明文数据认证加密,想要使用CCM,就需要一个密钥和一个随机数用于CCM认证加密,所以ble有一个“加密过程”负责输出一个密钥(sessionKey)和一个随机数(IV),而加密过程又需要一个密钥来产生sessionKey,所以ble有一个“配对阶段”来输出一个临时密钥(STK)给加密过程,或者在绑定阶段输出一个长期密钥(LTK)给加密过程下一次连接时候使用。
TK配对码的生成和配送
ble4.0的TK配对码生成和配送方式有多种,常用的两种TK配对码的生成和配送方式是:JustWorks和Passkey,他们有以下差异:
-
JustWorks模式时,生成的TK是000000,因为这是公开的,没有配送的意义,配送目的是为了防止通信双方以外的第三方获得密钥,由于现在认证码是公开的,就没配送的意义了,而且由于认证码泄露,这种模式不能提供篡改和伪装保护。
-
Passkey模式时,TK的生成方式和配送方式如下:通信其中一方如Alice随机生成TK为142536,通过显示屏/短信/NFC等蓝牙以外的输出数据的方式,将配对码告知给Bob’s User,Bob’s User通过键盘往Bob设备输入142536,使得Bob和Alice拥有一个共享认证密钥,而针对蓝牙基带攻击的第三方Mallory不知道,从而提供篡改和伪装保护。
下面来看一下图,Passkey模式是怎么做到认证保护的。
认证保护示意图:
通过正常认证过程,可以发现Bob和Alice只在空中交互了两次,所以Mallory的攻击时机有两个,第一个是Bob和Alice交换MIC的时刻,另一个是在Bob和Alice交换明文的时刻。分两种攻击行为
- 篡改MIC或者明文其中一项,属于篡改攻击。
- 如果篡改MIC,那就是在未知明文和TK的情况下,凭空捏造一个EMIC,而且这个EMIC还要能够通过后续校验,这个几乎不可能。MIC是果,明文和TK是因,因果倒置不可能吧。
- 如果篡改明文,那就是给定MIC,基于MAC算法且未知认证密钥TK的情况下,推导出另一份明文,根据MAC算法性质,这个是很难做到的。
- 同时篡改MIC和明文,属于伪装攻击,也叫MITM攻击。
- 因为伪造认证码EMIC和伪造明文Erand是Mallory提供的,计算过程可能是EMIC = MAC(EK, Erand),而真实配对码TK和伪造配对码EKEY只有百万分之一的几率是相同的,所以看作是不相同的,也即EK != TK,根据MAC的输入敏感性质,EMIC != MAC(TK, Erand),最终认证失败。
ble4.0真的足够安全吗?
我们先列出ble4.0安全机制各个密钥的安全依赖关系:
CCM -> sessionKey -> STK(LTK) -> TK
可以看到,最终的源头是TK认证码,只有保证TK足够安全,密文才能保证安全,也就是说不能让非法分子获得TK,否则他们就能够将密文解密了。
一般我们依靠MAC算法本身的性质,可以保证认证密钥不被推算出来,但是但是这些性质的前提是:认证密钥是使用密码学安全的、高强度的伪随机数生成器生成的,而且这些密钥位数很多,以至于无法穷举。
而实际TK的取值是000000~999999,最多只有100万种可能性,先抓取配对阶段(phase2.2)中用到的明文、MIC,再通过穷举的方式,就可以推算出TK了。
我们分析一下,如果在整个安全机制过程中,一直存在窃听者Eve,那么我们会面临什么威胁。
Tips:在这里也顺带分析静态配对码和动态配对码的区别,静态配对码是指每次输入都是固定的TK值,动态配对码是指每次输入都是动态产生的TK值,其实核心规范里面没有提过静态配对码,但是很多人会希望有如下功能:在一个设备预设一个配对码为123456,然后配对阶段时另一个设备输入配对码123456则通过认证,否则不通过,其实对于ble来说,由于TK可以被破解,所以静态配对码没有起到安全保护作用。
- 如果是静态配对码,Eve推算出首次连接TK,从而推算出STK,从而推算出sessionKey,从而破解CCM,从而窃取绑定过程中的LTK。
- Bob和Alice首次连接,因TK和STK被破解,所有阶段被破解,可任意窃听和篡改;
- Bob和Alice第二次连接,因LTK被窃取,所有阶段被破解,可任意窃听和篡改;
- 伪装Bob或者Alice与对方首次连接,因为TK是静态配对码,通过认证,伪装成功。
- 如果是动态配对码,Eve推算出首次连接TK,从而推算出STK,从而推算出sessionKey,从而破解CCM,从而窃取绑定过程中的LTK。
- Bob和Alice首次连接,因TK和STK被破解,所有阶段被破解,可任意窃听和篡改;
- Bob和Alice第二次连接,因LTK被窃取,所有阶段被破解,可任意窃听和篡改;
- 伪装Bob或者Alice与对方首次连接,因为TK是动态配对码,之前破解的TK用不上,无法通过认证,伪装失败。
总结出几个观点:
-
因为“加密”都依赖于认证码TK,而TK容易被穷举破解,加密则形同虚设。
-
上面描述的威胁,首先是窃听成功,才能篡改成功,问题是出在了窃听上。正常情况下对于密文的处理,CCM需要先解密,后认证。如果Eve没有窃听成功,乱篡改Bob发出的CCM认证加密过的密文,那么Alice解密出来的数据几乎不可能通过后续认证的。正是因为Eve窃听成功,知道篡改哪部分内容,所以才会造成威胁。解决窃听问题,就能同时解决篡改问题了。
-
TK是不安全的,以至于如果使用静态配对码而不是动态配对码,就无法解决伪装问题,如果认证码不像TK那样范围窄,静态配对码技术本身也没什么问题,但是最好还是定期更新。
上面总结的也是ble4.2安全机制里面做的一部分改善,比如增加破解TK的难度,引入ECDH解决窃听问题。
ble4.2安全机制
上一节,我们分析了ble4.0的安全“漏洞”, 接下来简单说一下ble4.2作出的应对措施。
-
无法改变的前提:
- 配对码是6个字节。
-
可能的攻击方式:
- Eve窃听整个过程,从而破解TK,下一次可以伪装Bob和Alice主动发起连接认证。
- Eve窃听整个过程,从而破解TK,从而得到STK,然后窃取LTK。
- Mallory发起MITM攻击,即使攻击失败,包含整个TK信息的MAC和MIC会被Mallory获得。(虽然我不知道有什么用)
-
提出对应解决的方案:
- 动态认证码;
- ECDH保证机密性;
- 将TK拆成20bit,每次认证一个bit,攻击失败只会暴露1个bit,不会暴露整个TK。
BLE4.2与BLE4.0的安全机制区别主要体现在“配对阶段”的phase2,在这个阶段引入了ECDH,下面展开passkey模式的phase2(包括phase2.1~2.3)。
在“Authentication Stage1”过程,可以发现Bob和Alice只在空中交互了三次,所以Mallory的攻击时机有三个:- 交换公钥的时刻
- 交换MIC的时刻
- 交换明文的时刻。
后两个攻击方式,在BLE4.0已经分析过了,至于第一个攻击时机,因为公钥是也是MAC算法里面的一个参数,所以它也不能被随意篡改,如果改了后面的Ea和Eb校验就不通过了,即给ECDH也提供了MITM保护。
Tips:这里之所以可以提供MITM保护的实质是人的参与,通过观察的方法获得配对码,绕开了蓝牙空中传输来获得配对码,从而不会受到第三者攻击。
对比BLE4.2和BLE4.0的主要区别:
-
BLE4.2没有STK,在配对过程直接生成LTK,因为LTK在配对阶段就已经强制生成了,加密过程直接使用LTK,BLE4.2的绑定阶段(phase3)不会发送LTK。
-
LTK是DHkey衍生出来的,DHkey是第三方无法窃听也无法破解出来的,所以可以保证后面用CCM加密后数据的机密性。
BLE4.2完美解决了BLE4.0的安全漏洞。
总结
文章提到的只是BLE常见的一些概念,其他如:签名(Signed)、授权(Authorization)之类都没有提及,有兴趣的读者可以去核心规范探索一番。
参考资料里面有许多优秀的书籍和文章,比如密码技术相关知识我是从《图解密码技术》获知的,关于具体的实战抓包分析,吹爆“BLE配对过程详解”这篇文章。
最后最后,感谢您阅读到最后,这是对我最大的鼓励,也希望这篇博文能让您有一点点的收获。
后记
一开始是想将MESH加进来的,但是考虑到还没上过正式的项目去体验过,怕写出来理解的不够透彻,所以还是算了,以后有机会再单独开一篇吧,但是有兴趣的朋友可以私底下一起交流。
参考资料
- 《图解密码技术》
- BLE配对过程详解
- BLE核心规范
- Hash算法总结
- 穷举法破解BLE的TK值
- 密码技术初探
-
等保测评之服务器未配置登录失败锁定策略及登录连接超时自动退出策略
2021-10-13 09:55:10等保测评之服务器未配置登录失败锁定策略及登录连接超时自动退出策略 真是一事未完又来一事哈,昨天收到的等保测评出现了好多的问题,这里将部分问题做一下记录 看看问题 问题如下 测试服务器 主要是测试服务器...等保测评之服务器未配置登录失败锁定策略及登录连接超时自动退出策略
真是一事未完又来一事哈,昨天收到的等保测评出现了好多的问题,这里将部分问题做一下记录
看看问题
问题如下
测试服务器
主要是测试服务器是不是存在这种问题,经过测试问题存在,测试过程这里省略了
问题描述
恶意人员可通过暴力破解的方式获取账户口令。且设备易被非授权人员恶意操作,存在非授权访问的风险。
问题解决
- 一下文件配置完成后不需要重启服务器的哈,直接生效,还有就是在操作时,建议保持一个ssh远程连接到服务器,方便出现错误及时的回滚操作
备份主要涉及的两个重要文件
[root@localhost ~]# cp /etc/pam.d/sshd /etc/pam.d/sshd.bak #这个是ssh的配置文件 [root@localhost ~]# cp /etc/pam.d/login /etc/pam.d/login.bak [root@localhost ~]# ll /etc/pam.d/sshd.bak /etc/pam.d/login.bak ##这个文件里面记录了所有关于登录的配置文件记录 -rw-r--r--. 1 root root 796 10月 13 10:01 /etc/pam.d/login.bak -rw-r--r--. 1 root root 904 10月 13 10:00 /etc/pam.d/sshd.bak
检查是否存在的重要pam模块.so文件
[root@localhost ~]# find /* -name "*pam_tally2.so*" /usr/lib64/security/pam_tally2.so
配置登录失败处理功能策略(服务器终端)
[root@localhost ~]# cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak [root@localhost ~]# vim /etc/pam.d/system-auth [root@localhost ~]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so auth required pam_tally2.so onerr=fail deny=3 unlock_time=40 even_deny_root root_unlock_time=30 ###需要添加的这一行 account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
- deny 指定最大几次认证错误,如果超出此错误,将执行后面的策略。如锁定N秒,如果后面没有其他策略指定时,默认永远锁定,除非手动解锁。
- lock_time 锁定多长时间,按秒为单位;
- unlock_time 指定认证被锁后,多长时间自动解锁用户;
- magic_root 如果用户uid=0(即root账户或相当于root的帐户)在帐户认证时调用该模块发现失败时,不计入统计;
- no_lock_time 不使用.fail_locktime项在/var/log/faillog 中记录用户 ---按英文直译不太明白,个人理解即不进行用户锁定;
- even_deny_root root用户在认证出错时,一样被锁定(该功能慎用,搞不好就要单用户时解锁了)
- root_unlock_time root用户在失败时,锁定多长时间。该选项一般是配合even_deny_root 一起使用的。
终端测试效果如下:
查看安全日志验证:[root@localhost ~]# tail -100 /var/log/secure | grep "max" Oct 13 10:19:17 localhost sshd[2242]: PAM service(sshd) ignoring max retries; 5 > 3
配置登录失败处理功能策略(ssh远程连接登录)
[root@localhost ~]# vim /etc/pam.d/sshd [root@localhost ~]# cat /etc/pam.d/sshd #%PAM-1.0 auth required pam_sepermit.so auth substack password-auth auth include postlogin auth required pam_tally2.so onerr=fail deny=3 unlock_time=40 even_deny_root root_unlock_time=30 ##添加部分 # Used with polkit to reauthorize users in remote sessions -auth optional pam_reauthorize.so prepare account required pam_nologin.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session required pam_namespace.so session optional pam_keyinit.so force revoke session include password-auth session include postlogin # Used with polkit to reauthorize users in remote sessions -session optional pam_reauthorize.so prepare
ssh远程测试效果:
经过测试连续登录3此输入错误的密码后,第四次或之后的40秒内,那怕输入正确的密码,也不会正常的登录
查看安全日志验证:
其他的辅助命令
[root@localhost ~]# pam_tally2 --user root ###其中root为用户,这个是查看当前root用户登录失败了多少次 Login Failures Latest failure From root 4 10/13/21 10:43:06 192.168.211.1 [root@localhost ~]# pam_tally2 -r -u root ##解锁root用户 Login Failures Latest failure From root 8 10/13/21 10:44:54 tty1 [root@localhost ~]# pam_tally2 --user root #再次查看root用户的饿登录失败次数,此时为0 Login Failures Latest failure From root 0
-
深刻理解windows安全认证机制 [ntlm & Kerberos]
2018-07-06 11:46:530x01 为什么要理解windows 安全认证机制:1加深对后续各种漏洞利用的理解深度,还是那句话,要知其然,更要知其所以然,不废话,咱们直接开始0x02 windows认证协议主要有以下两种:12基于ntlm的认证方式,主要用在早期的... -
浏览器安全——Web页面安全&浏览器网络安全(HTTPS)&浏览器系统安全
2021-12-16 15:47:10一、Web页面安全 同源和跨域: 同源: 页面中最基础、最核心的安全策略:同源策略(Same-origin policy)。浏览器默认两个相同的源之间是可以相互访问资源和操作 DOM 的。 什么是同源?如果两个页面拥有相同的协议、... -
Java安全编码
2022-03-21 12:11:32文章目录Java编码安全数据校验规则1.1:校验跨信任边界传递的不可信数据规则1.2:禁止直接使用不可信数据来拼接SQL语句规则1.4:禁止直接使用不可信数据来记录数据规则1.6:验证路径前将其标准化规则1.7:安全的从... -
全网最全安全加固指南
2022-01-03 18:12:38安全加固是配置软件系统的过程,针对服务器操作系统、数据库及应用中间件等软件系统,通过打补丁、强化帐号安全、加固服务、修改安全配置、优化访问控制策 略、增加安全机制等方法,堵塞漏洞及“后门”,合理进行... -
苹果手机让检查Apple ID 电话号码点击后验证失败,连接服务器失败出错
2021-07-31 02:48:56双重认证是一种相对较新的安全保护机制,直接内建于 iOS、macOS、Apple tvOS、watchOS 和 Apple 网站中。它能带给用户更加流畅的使用体验,需要用到一些对安全性有更高要求的功能特性。如果 iCloud 用户拥有至少一部... -
账号安全基本措施
2021-11-24 12:13:30文章目录系统账号清理锁定账户文件 演示如下账号安全的基本措施如何去设置新创建账户的密码有效期如何设置强制在下次登陆时更改密码历史...账号安全基本措施 系统账号清理 将非登录用户的Shell设为/sbin/nologin userm -
网络安全教程(2)
2022-03-15 14:29:124-计算机病毒 4-1认识计算机病毒 4-1-1计算机病毒的概念 ...1983年11月,在国际计算机安全学术研讨会上,美国计算机专家首次将病毒程序在VAX/750计算机上进行了实验,世界上第一个计算机病毒就这样出生... -
网络安全专业名词解释
2022-03-04 16:02:18Burp Suite 是一款信息安全从业人员必备的集成型的渗透测试工具,它采用自动测试和半自动测试的方式,通过拦截HTTP/HTTPS的Web数据包,充当浏览器和相关应用程序的中间人,进行拦截、修改、重放数据包进行测试,是... -
JWT实现接口双重认证,提供安全又不复杂的接口安全能力
2022-03-22 16:22:58避免对cookie的依赖,由于部分用户会使用无痕或者禁用cookie导致jwt存储失败。 先上完整的JWT-class代码(仅供参考) jwt.php 'HS256', //生成signature的算法 'typ'=>'JWT' //类型 ); //使用HMAC生成信息摘要时所... -
接口安全性考虑
2022-03-09 11:49:03接口安全 -
currenthashmap线程安全的原因
2022-03-05 19:56:541 线程安全的hash表初始化 由上文可知ConcurrentHashMap是用table这个成员变量来持有hash表的。 table的初始化采用了延迟初始化策略,他会在第一次执行put的时候初始化table。 可通过sizeCtl保证线程安全。 成员... -
CODING 代码资产安全系列之 —— 构建全链路安全能力,守护代码资产安全
2021-12-01 18:10:00为代码资产管理者提供一个审视安全的基本框架 -
【期末复习】网络空间安全导论
2021-12-31 17:11:54[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2ZTYBA6d-1640941886524)(https://gitee.com/hot-dry-noodles/pic-go/raw/master/img/image-20211231123125850.png)] 物理层: 对于使设备... -
密码学与网络安全—知识点总结
2021-12-23 16:33:34本文为期末考试后结合一些资料整理完成的,涵盖山东大学软件学院信息安全导论的课程主要内容,参考书为《密码编码学与网络安全》。我列居了80个名词概念,20多道经典问答题。 先附上所有知识点的word版与pdf版,并... -
Spring boot中的缺陷和安全漏洞浅析
2019-05-18 09:55:29进行分析,发现里面还是隐藏着很多缺陷和安全漏洞。我选择了几个比较典型的,容易理解的缺陷进行简单分析。 1、创建问题权限问题 上述存在的问题所属的缺陷属于没有使用合适的访问权限创建文件... -
Linux线程安全
2022-01-23 21:25:05文章目录Linux线程互斥进程线程间的互斥相关背景概念互斥量mutex互斥量的接口互斥量实现原理探究可重入VS线程安全概念常见的线程不安全的情况常见的线程安全的情况常见的不可重入的情况常见的可重入的情况可重入与... -
Java 基础 —— 线程安全
2021-05-18 23:48:34一、线程安全问题 线程安全 当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的... -
浅谈暴力破解及验证码安全
2020-09-22 23:19:05文章目录一、暴力破解及验证码安全注意事项二、C/S架构暴力猜解三、B/S架构暴力猜解四、Hydra安装及使用安装参数说明各种用法实例五、防范暴力猜解六、验证码安全工作原理存在的问题图片验证码的生成可能存在如下... -
Tomcat 的类加载机制
2021-10-16 19:14:38当然还有其他原因,如: (1)保证 Web 容器自身的安全不受部署的 Web 应用程序影响,所以 Tomcat 使用的类库要与部署的应用的类库相互独立 (2)保证部分基础类不会被同时加载,有些类库 Tomcat 与部署的应用可以... -
浏览器实战篇----浏览器安全概述
2022-01-17 08:27:01浏览器安全概述1. 揭秘浏览器1.1 同源策略1.2 HTTP首部1.3 标记语言HTMLXML1.4 CSS1.5 脚本JavaScriptVBScript1.6 DOM1.7 渲染引擎WebkitTridentGeckoBlink1.8 Geolocation(地理定位)1.9 Web存储1.10 跨域资源共享... -
网络安全之基础入门(一)
2022-02-26 10:59:42端口是应用程序在计算机中的唯一标识 常用端口: 21/tcp FTP 文件传输协议 22/tcp SSH 安全登录,文件传输和端口重定向 23/tcp Telent 不安全的文本传输 25/tcp SMTP Simple Mail Transfer Protocol (E-mail) 80/... -
2021Web安全面试题大全(附答案详解)看完稳了
2021-10-13 10:32:34人人都有一个进大厂的梦想,而进大厂的门槛也可想而知,所以这里整理了一份安全大厂的面试大全,看完文章如果对你有帮助的话希望能够点赞+收藏+关注!感谢! 本篇文章对于学习Web安全的朋友来说应该是目前最全面的... -
Nacos惊现安全漏洞修复后问题仍旧存在
2021-01-18 11:51:52你好,我是threedr3am,我发现nacos最新版本1.4.1对于User-Agent绕过安全漏洞的serverIdentity key-value修复机制,依然存在绕过问题,在nacos开启了serverIdentity的自定义key-value鉴权后,通过特殊的url构造,... -
什么是线程安全?如何保证线程安全?
2019-05-27 23:22:44什么是线程安全 参考: 《Java并发编程实践》中对线程安全的定义: 当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作... -
如何确保NAS的安全性(你的NAS被攻击了吗?)
2020-05-14 20:27:18你的NAS真的安全了么?本文将从部署、配置和使用三个方面来介绍我们在使用的NAS的过程中怎样才能够保证NAS的使用安全、如何才能确保自己的数据安全。文末有NAS官方关于NAS被攻击后的数据安全策略建议。