最近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接收到
数据和摘要的密文后，用Alice的公钥解密摘要，然后再用数据计算一个摘要。如果2份摘要相同，则
可以确认数据确实是Alice发送的。