http://blogread.cn/it/article.php?id=4933&f=sr
http://blogread.cn/it/article.php?id=4934&f=sinat
最近CSDN等网站被脱库的事情，闹得沸沸扬扬。身为程序员，我觉得软件开发人员自身安全意识的强弱和
安全知识的多寡会直接影响到所开发系统的安全性。从这个角度来分析，系统做的不安全有三种原因：
A. 不知道存在安全隐患
B. 使用了不适当的安全措施
C. 知道存在安全隐患，但是为了简单（也可能别的原因），置之不理。
你属于哪一种呢？
如果你属于前两种情况，请继续往下看。本文是从软件工程师的角度来写的，但是我觉得其中的一些知识，
对其他IT从业人员也有益处。因此命名为“IT从业人员需要知道的安全知识“。
00 - 系统架构
我们首先从系统的架构入手，来看一下和安全密切相关的特征。下图是现在最常见的系统架构模式。
Fig.1
- 多用户系统(Multi-User System)
现在的应用系统，多数都允许多个不同的用户同时登录系统,进行各自的操作互不影响。对于多用户系统
必须要有访问控制的几个功能：
A. 用户身份的识别，即认证。
B. 不同的用户授予不同的权限。
C. 根据用户的权限，进行访问控制。
- 远程访问
不论是C/S还是B/S架构的系统，用户都是通过网络连接来访问系统。应用系统在为合法用户提供服务的
同时同时，也将自己暴露在了各种威胁的面前。
A. 大多数的系统中，不对客户端使用的主机做任何的限制。因此客户端主机的安全性不可控。如果用户
使用了不安全的主机，认证凭证等敏感信息很容易泄漏。
B. Internet一个开放的、不安全的网络，甚至很多内部网络的安全状况也令人担忧。数据在这些不安全
的网路中传输时可能被窃听和篡改。
C. 因为通过Internet提供服务，服务器直接暴露在不安全的网路环境中。因此攻击者可以直接访问到服
务器，网络层面(TCP/IP)的攻击很容易得逞。
- 关系数据库系统
应用系统的数据通常存放在关系型数据库中. 数据库本身自成系统， 在很多方面降低了应用系统的复
杂性。但是也引入了一些安全隐患。
A. 因为应用服务器连接数据库是自动完成的，就需要将用户名和密码等认证凭证配置到应用程序中。
这会给密码管理造成一定的麻烦。
B. 由于数据模型不同，很难将应用系统中的用户权限和数据库中的用户权限一一对应。很多情况下，
多个应用系统的用户共用一个数据库系统的用户来访问数据库中的数据。这就为恶意用户非法访问数
据提供了 可能性。
01 - 数据的安全
数据作为应用的核心，通常要在用户和服务器之间进行传输和存储，因此在诸多环节上都面临着威胁。
- 客户端的潜在威胁和对策
前面已经说了，通常的情况下用户可以使用任意的电脑访问系统，这些机器的安全性是不可控的。
威胁1: 客户端存储的信息被盗,如：HTTP的Cookie，页面缓存等.
对策:
A. 安全级别高的应用系统，要使用专用的客户端设备进行访问。
B. 不要将不必要的信息，存放在客户端机器上。曾经碰到过，程序员将密码明文的存储到HTTP的Cookie中。
C. 清空客户端的缓存和Cookie信息。
D. 加密存储敏感信息。
威胁2: 键盘输入被记录(Keystroke_logging)
Keystroke logging不光被黑客使用，它也经常被用来做审计和用户行为分析。如很多的输入法软件记
录用户的输入内容， 并且发送到服务器端，用来做用户行为分析。这里面具有很高的商业价值。不光是输
入法，现在一些Android和IOS上的免费应用，表面上靠广告赚钱，实际上更多的盈利靠卖用户的信息。
对策: 虚拟键盘(Virtual Keyboard)
恶意分子常常用此方法，来盗取用户的ID和密码，以及银行卡号等隐私信息。我们可以在应
用系统中内嵌一个虚拟键盘,通过鼠标来完成敏感信息的输入。如下图所示：
Fig.2(来自Wikipedia)
- 网络传输的潜在威胁和对策
威胁: 窃听(Sniffing)
窃听是很常见的一种网络威胁。数据在网络中传输的过程中，很容易被窃听。
对策1: 安全通道
最简单的方法就是建立一个安全通道，应用系统中的所有数据都在安全通道中传输。
A. HTTPS
B/S架构的系统可以通过HTTPS来建立安全通道。只需在Web访问器上进行配置，不需要对应用做修改。
B. SSL/TLS
C/S架构的系统可以通过OpenSSL提供的SSL/TLS的API，来建立SSL Socket。
C. VPN(Virtual Private Network)
和软件开发关系不大。
使用安全通道将对所有数据加密，而且能够抵抗多种攻击。但是会显著的降低系统的性能。
对策2: 加密
如果只有很少的一部分数据需要加密，可以在应用层进行加密。
- 服务器端的威胁和对策
威胁1: 合法用户泄密
很多的应用系统中都设置有超级用户，一旦恶意人员拥有了超级用户，就控制了整个系统。
对策: 三权分立和最小权限原则
在后面的授权部分介绍.
威胁2: 数据被盗
对策1: 阻止数据被盗的措施
这些措施和应用程序本身无关。
对策2: 加密
一旦数据被盗，加密就是最后一道防线了。
02 - 密码学小知识
- 密码学误区
从上一节中可以看出，密码学对于数据的安全是至关重要的。但是由于密码学知识的缺乏，
软件开发中往往容易出现一下的错误：
A. 使用自制的密码算法
很多开发人员会认为，如果算法不公开就很难破解。但是多数自制的算法都是通过简单的置换、
移位或逻辑运算来实现的，并没有使用专业的方法进行验证，因此并不可靠。
“一切秘密在密码中”，是现代密码学的一个基本观点。因此公开算法，不会影响其安全性。
B. 更有甚者，为了避免存储密钥，使用公开的非密码算法来做密码算法使用。
曾经碰到有个程序员将Base64作为加密算法来使用。将数据用Base64编码3次产生密文。
C. 使用过时的密码算法
随着时间的推移，有些密码算法已经被证明不再安全了。但是仍然被广泛使用，如:DES,RC4等。
D. 直接使用非对称算法进行数据的加解密操作
不存在安全问题，只是效率很低。
- 对称密码算法
只有一个密钥，既用于加密，也用于解密。
A. AES, 密钥长度128, 192, 256bits.（推荐）
B. 3DES, 有效密钥长度168bits
C. Blowfish, 密钥长度32-448bits
D. IDEA, 密钥长度128bits
OpenSSL 库中提供了各种密码相关算法的实现。
- 摘要算法(Digest Algorithm)
也称加密Hash算法，用来产生一个Hash值。
A. SHA1, 摘要长度160bits(推荐)
B. MD5, 摘要长度128bits
- 摘要算法的特点：
A. 单向性
摘要算法是单向函数，可以从明文计算出摘要。但不能从摘要推导出明文。
B. 唯一性
不同的明文，计算出的摘要也不同
同样的明文，计算出的摘要始终相同。
C. 明文可以是任意长度， 摘要的长度始终固定。
当我们提到加密和密文，意味着我们可以从密文中解密出明文。而提到摘要算法和摘要则意味着我
们没办法从中得到明文数据。在密码学中加密算法和摘要算法有着截然不同的用途。
- 非对称密码算法
有一对密钥，用其中的一个密钥加密数据，就必须用另一个密钥才能解密数据。
A. RSA,密钥长度任意，推荐>=2048bits
B. DSA,密钥长度任意，推荐>=2048bits bits/span>
C. 加解密速度很慢
OpenSSL 库中提供了各种密码相关算法的实现。
无论是对称还是非对称密码算法，都是密钥长度越长，越难破解。
- 公钥(证书)体系基础
因为非对称算法的性能很低，公钥体系同时使用了对称密钥算法、非对称密钥算法和
摘要算法。充分利用各自的优点，达到安全、高效的目的。
A. 对称算法用来做数据加密。
B. 摘要算法用来做数据摘要。
C. 非对称算法用来做对称算法的密钥加密分发，和数据摘要的签名.
D. 私钥和公钥
在一对密钥中，使用者自己保留其中一个，不让任何人知道，称之为私钥(Private Key)。另外
一个密钥公开给所有人。这个密钥称为公钥(Public Key)。
E. 加密解密的过程如下图所示：
Fig.3(图片来自http://218.108.81.184/wljr/wljrdzja/zy/new_page_09a.htm)
假设Alice发送私密数据给Bob。Alice先用对称算法将数据加密，密钥是一个随机串。然后用Bob
的公钥对对称算法的密钥加密，最后将密文数据发送给Bob. Bob收到密文后，用自己的私钥解密
对称算法的密钥，然后用对称算法的密钥解密数据。因为只有Bob拥有私钥，所以只有Bob能解密数据。
F. 数字签名和认证过程如下图所示：
Fig. 4(图片来自http://218.108.81.184/wljr/wljrdzja/zy/new_page_09a.htm)
假设Alice发送数据给Bob, Bob如何能够知道数据确实是Alice发送过来的呢？Alice先用摘要算
法对数据进行摘要，然后用自己的私钥对摘要加密。最后发送数据和摘要的密文给Bob。Bob接收到
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查到，需要了解详细内容的朋友可以上去浏览。
数据和摘要的密文后，用Alice的公钥解密摘要，然后再用数据计算一个摘要。如果2份摘要相同，则
可以确认数据确实是Alice发送的。