IT从业人员需要知道的安全知识二

ゞ浴缸里的玫瑰 2022-08-01 00:16 182阅读 0赞

# 03 - 认证(Authentication) #

*  认证因子(什么东西可以用来做认证凭证)  
    A. Something you know  
    只有你知道的东西。如：口令。  
    B. Something you have  
    只有你拥有的东西。如：你的银行卡、令牌、手机等。  
    C. Something you are  
    你身体上和别人不一样的东西。如：指纹、视网膜、声音、DNA等。  
    同时使用多种认证因子进行认证是更安全的做法。例如，到银行取钱，需要同时有卡和密码。网银交易，需要USB Key和密码。

我们接触到的系统中，绝大多数只使用了一种认证因子，也是最简单的一种，即口令认证(Something you know)。认证凭证也是数据，也会遭遇‘数据’一节中提到的威胁。因为认证凭证的特殊性，我们通常不使用‘数据’一节中介绍的对策，来保护认证凭证，而是采用专用的方法。

*  基于口令摘要的认证  
    在‘密码学’一节中已经介绍了Hash算法，它的特点非常适合用在认证的过程中。  
    A. 用户发送口令摘要(D1)到服务器  
    B. 服务器从数据库获取用户的口令摘要(D2)  
    C. 服务器验证D1=D2,成功则认证成功。
    
    基于口令摘要的认证有以下几个优点：  
    A. 不需要传输明文口令  
    B. 不能从摘要中得到明文口令  
    C. 服务器端不需要存储明文口令
    
    到此为止，你可能认为口令的传输已经是安全的了，其实不然。  
    威胁：重放攻击(Replay Attack)  
    从上面的认证过程可以看出，认证凭证本质上是口令摘要。尽管没办法获取到明文口令，但是仍然可以  
    通过Sinffing获取到口令摘要，甚至是整个认证过程的数据包。只要伪造一个合法的认证数据包发送到服务器，就能认证成功。
    
    对策：随机的消息认证码(Message Authentication Code)  
    我们可以在每次认证时，用一个随机字符串和口令一起进行摘要。当然这个随机数必须要由服务器来指定,否则无效。认证的过程如下：  
    A. 用户发送认证请求。  
    B. 服务器发送一个随机数(R)给客户端。  
    C. 客户端计算随机数(R)+口令摘要(D)的摘要CP1,并发送给服务器.  
    D. 服务器从数据库获得口令摘要(D2)，计算R+D2的摘要CP2. 如果CP1=CP2,认证成功。

HMAC(Hash-based Message Authentication Code)是基于摘要算法的一个标准消息认证  
算法，很适合用来做认证使用。

威胁：彩虹表攻击(Rainbow Table Attack)  
彩虹表攻击本质上是字典攻击。攻击者首先对口令字典中的所有口令进行摘要，产生一个口令摘要字  
典(Rainbow Table). 然后把获取到的用户口令摘要和彩虹表比对。如果找到了同样的口令摘要，就找到了口令。此方法主要用来攻击存储在服务器端的口令摘要,还原用户口令。

对策：随机串  
和随机的消息认证码机制类似，在服务器端不存储口令的摘要而是(口令+随机串)的摘要。  
A. 也有人用用户的其他信息(如用户名，ID)和口令一起摘要。但是在长度相同时，随机串强度更大。因此如果没有特殊的需求，还是推荐使用随机串。  
B. 有人将口令进行2次或N次摘要后存储。这是一种很不恰当的做法。

随机数和密钥一样，也是越长强度越高。随机数在整个密码学中起到了很重要的作用，因此不能小觑。  
通常系统API或开发语言的库中都提供有获得随机数或字符串的函数。

*  一次性口令(One-Time Password|OTP)  
    本质上讲, 随机的消息认证码是一次性口令。这里还有其他更简单有效的一次性口令方式有：  
    A. 一次性口令令牌  
    Fig.1(来自WikiPedia)  
    B. 手机一次性口令  
    服务器发送一个随机串到用户的手机，用户以这个字符串作为密码进行认证。结合令牌、手机和密码的双因子认证，更为安全可靠。
 *  认证时服务器面临的威胁和对策  
    威胁：口令猜测  
    恶意人员通过猜测用户的口令，来尝试登录。
    
    对策1: 锁定帐号  
    如果用户连续若干次认证失败，就锁定其帐号。只有通过其他途径解锁后才能继续使用。因为可能造成合法用户在一定时间内无法使用(拒绝服务DoS攻击)，所以实现这个功能时要谨慎。
    
    对策2: 告警和警告  
    如果系统的安全要求不高，给用户和管理员发出告警日志就可以了。也要对正在尝试登录的用户发出警告。
    
    威胁：口令字典攻击  
    口令字典是一个庞大的口令库，这些口令是通过各种途径收集到的。攻击者使用字典库中的口令尝试登录,尝试的过程往往通过特殊的软件自动进行，因此可以在很短的时间内尝试很多的口令。
    
    对策1：锁定账户一小段时间  
    操作系统的本地登录，常使用这种方法。
    
    对策2：验证码  
    验证码上展示了一些只有人才能分辨出的内容，如果字母，汉字，图表，地图，数学算式等。可以更好的阻止字典攻击。如下图所示：  
    Fig. 2(图片来自Wikipedia)
    
    对策3：使用良好的密码管理策略  
    A. 要求用户的口令长度,如必须超过10个字符。  
    B. 要求用户口令的复杂度，如必须包含数字、小写字母、大写字母和特殊字符。  
    C. 定期更换密码，如6个月更换一次。  
    D. 更换的密码不能重复使用。如每6个月更换一次密码，被更换的密码在4×6个月内不能再次使用。  
    E. 构建口令字典，验证用户的密码不在口令字典中。

# 04 - 授权 #

通常的系统都是采用基于角色的访问控制模型(Role-based access control model)。系统的操  
作一般可以归为三大类的角色：  
A. 系统的管理角色  
B. 应用用户的操作角色  
C. 审计(日志相关)的角色  
注重安全的系统，要奉行:  
A. 三权分离的原则  
一个用户只能拥有其中一种类型的角色权限。  
B. 最小权限原则  
在用户创建时，应给予0权限或最小权限。只有在用户需要某个权限时才授权。  
很多系统都设置有超级帐号，使用这种帐号可以做任何事情，或者授于管理员过多的权限。这样做肯能涉及到以下的几个问题：  
A. 误操作，导致数据被修改.  
B. 权限滥用。  
C. 帐号被盗，导致整个系统受到威胁.

# 05 - 访问控制 #

威胁：拒绝服务攻击(DoS)  
由于某种特殊的情况出现，导致系统无法为合法的用户提供访问。

对策：高安全意识  
导致DoS的原因有很多，有些是系统、网络层面的，也有来自于应用系统本身的原因。没有一个确切的办法能解决所有的问题。因此我觉的还是要高的安全意识来发现可能的问题。  
A. 网络层面的DoS攻击种类繁多，这和TCP/IP协议本身的实现有关。如果SOCKET的实现不恰当也会引入此类攻击。一个常见的例子是，Socket的等待队列设置的太小。如果有人故意的打开很多的半连接，就会造成其他用户无法连接。  
B. 多用户系统中，意味着这些用户要共享系统的资源。如内存，硬盘等。因此需要从这个方面来注意。当一个用户使用过大的内存或硬盘空间时，可能就造成了其他用户无法使用这些资源，甚至导致系统崩溃。

威胁：不公平的服务  
现在常见的一种情况是，一些恶意的用户通过特殊的软件，来和其他用户抢系统提供的资源。如：特价  
商品，火车票等。从而导致系统不能为其他用户提供公平的服务。  
对策：验证码(同上)

俗话说“病从口入”,软件系统也一样，下面的一些威胁，都是从用户输入开始的。  
威胁：SQL注入(SQL Injection)  
威胁：缓冲区溢出(Buffer Overflow)  
威胁：跨站脚本(XSS)  
此三中攻击手段是目前很常用，杀伤力很大的手段。具体的原理，大家可以在网上找到很多文章。

对策：提高安全意识，对待用户输入紧小慎微  
不要假设用户输入的是正确的数据，不要认为用户都是无知的。据调查多数的攻击行为都来自于内部。因此对用户的输入要进行严格的约束和检查。  
A. 访问控制相关的逻辑信息不要放在客户端。  
B. 不要相信客户端的输入检查程序，必须在服务器端再次做输入合法性检查。

对策：使用专业的软件来阻止攻击  
对用户的输入进行严格的检查也并不一定能有很好的效果。如果系统的安全需求较高，请向安全专家进行咨询。并配以专业的软件来预防此类攻击的发生。

*  数据库系统  
    数据库中存储着系统的核心-数据，而很多攻击者的目标也是这些数据。因此要对数据库做严格的安全措施。  
    A. 系统层面的安全  
    B. 网路层面的安全  
    C. 数据库本身的安全加固  
    这些安全措施和软件开发本身没有太大的关系，因此不在这里详细描述了。  
    D. 值得一提的是，数据库的帐号管理。数据库数据信息被盗的主要威胁来自于SQL注入和特权帐号被滥用。都和帐号管理相关。因此必须根据前面提到的口令管理策略，做好数据库的帐号管理。曾经碰到过程序员将Oracle的口令写入代码中,而导致无法对数据库进行加固的情况。这是非常错误的做法。  
    另外要注意，良好的帐号管理只能减少SQL注入带来的损失，没办法阻止SQL注入的发生，因此还是要从输入检查上入手，去杜绝SQL注入的发生。

# 06 - 后记 #

很多系统在开发的时候对安全问题并不重视，只有出了安全问题后才开始修修补补。随着安全事件的越来越多，要清醒的认识到，安全不是始于系统上线，而是始于需求分析。安全涉及到很多方面的知识，本文没有也不可能详述这些内容，只是希望能够提高大家的安全意识。文中的许多英文术语都可以通过Wikipedia查到，需要了解详细内容的朋友可以上去浏览。

# 07 - 转自 #

1.[IT从业人员需要知道的安全知识一][IT]  
2.[IT从业人员需要知道的安全知识二][IT 1]

[IT]: https://www.baidu.com/s?wd=IT%E4%BB%8E%E4%B8%9A%E4%BA%BA%E5%91%98%E9%9C%80%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84%E5%AE%89%E5%85%A8%E7%9F%A5%E8%AF%86&pn=20&oq=IT%E4%BB%8E%E4%B8%9A%E4%BA%BA%E5%91%98%E9%9C%80%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84%E5%AE%89%E5%85%A8%E7%9F%A5%E8%AF%86&tn=monline_5_dg&ie=utf-8&rsv_pq=8d44b96300001747&rsv_t=f849hF2XefLXmSJFbn3rEivCkQpcyyX%2bn8I5rP9ERlZPpoNieqLiPUxNqP4poaCeWCjR
[IT 1]: http://blogread.cn/it/article/4934?f=wb#original