安全人员须知的TOP20漏洞编码安全规范（二） - 网安 - 专业的网络安全产业、社区、知识平台

11. 代码注入

Ø 风险描述

web应用代码中，允许接收用户输入一段代码，之后在web应用服务器上执行这段代码，并返回给用户。由于用户可以自定义输入一段代码，在服务器上执行，所以恶意用户可以写一个远程控制木马，直接获取服务器控制权限，所有服务器上的资源都会被恶意用户获取和修改，甚至可以直接控制数据库。

Ø 漏洞示例

以上代码允许用户注入任意的代码，若其中args[0]参数设置如下，则将允许恶意用户创建任意文件。

Ø 规范要求

1、写死需要执行的命令，或通过白名单、预设命令的方式，限制可以执行的命令。

2、输入验证，对于进入执行代码的参数进行检查，检查参数长度及包含特殊字符，当发现非法字符，拒绝请求。

3、字符转义，对特殊字符进行转义。

12. XML注入

Ø 风险描述

XML注入攻击，和SQL注入的原理一样，都是攻击者输入恶意的代码来执行自身权限以外的功能。XML是存储数据的一种方式，如果在修改或者查询时，没有做转义，直接输入或输出数据，都将导致XML注入漏洞。攻击者可以修改XML数据格式，增加新的XML节点，对数据处理流程产生影响。

Ø 漏洞示例

下面是一个保存注册用户信息为XML格式的例子

可以看到，这段代码没有进行任何的过滤操作。一个普通用户注册后，会产生这样一条数据记录：

攻击者输入自己email时，可以输入如下代码：

最终用户注册后，数据就变成了：

可以看到，多出了一条role=“admin_role”的管理员lf，达到攻击目的。

Ø 规范要求

1、对用户提交的数据在保存和展示前对特殊字符进行转义，防止XML注入攻击。例如：

& --> &

< --> <

> --> >

" --> "

' --> '

在XML保存和展示之前，对数据部分，单独做转义即可

13.密码安全

Ø 风险描述

密码安全问题主要存在明文密码、弱密码、密码硬编码等问题。此类问题均容易导致密码的泄露。恶意攻击者可直接读取获得明文账号密码，导致其他相关联系统应用口令泄漏，扩大入侵范围。

Ø 漏洞示例

存在安全漏洞代码如下:

如果有一个具备中间件服务器机器访问权限的人，看到了这个例如applicationContext.xml的文件，并且打开该文件，就会知道数据库的用户名和密码是什么。

下面是对该漏洞的处理：

首先，我们需要将配置文件抽取到property中来：

将上面的第一个代码修改为第二个代码，第一个类是负责抓取jdbc.properties中的属性并且填充到dataSource当中来，这样，我们就可以将所有的注意力都集中在jdbc.properties上了。然后扩展PropertyPlaceholderConfigurer父类PropertyResourceConfigurer的解密方法convertProperty：

然后将上面完成的类替换配置文件中的PropertyPlaceholderConfigurer：

处理后的jdbc.properties里面的文件内容就变成如下所示了:

Ø 规范要求

1、配置文件中涉及到需要用户验证的密码字段采用加密后保存，禁止明文或使用弱加密算法对密码进行加密。

2、涉及密码的配置，需要把密码设置具备一定的强度，大小写数字特殊字等最少3类型8位以上，并且不能包含与用户名一样的字符串。

3、程序代码中涉及到使用密码的地方，密码引用不得直接写入到程序中，需把密码写入相应的配置文件中。

4、对硬编码密码进行模糊化处理，将密码获取途径分散到其他系统或文件各处，增加直接获取密码难度。

14.敏感数据未加密

14.1.密码明文传输

Ø 风险描述

数据加密主要应用于数据存储及数据传输过程中，敏感数据未加密进行存储或传输，容易导致数据泄露，恶意攻击者可嗅探到明文传输的敏感数据，从而窃取相关信息。

Ø 漏洞示例

某登录页面输入账号密码登录，利用burpsuite抓包：

发现密码在传输过程当中未进行任何加密处理，直接已明文形式进行传输，这样很容易被第3方监听并获取明文的密码。

Ø 规范要求

建议采用不可逆的加密方式对密码进行加密如MD5。禁止明文或使用弱加密算法对密码进行加密，密码设置应具备一定的强度，大小写数字特殊字等最少3类型8位以上，并且不能包含与用户名一样的字符串。

14.2.配置文件密码明文存储

Ø 风险描述

恶意攻击者在获取一定读取权限下可获取到数据库配置文件的账号密码明文信息，通过该信息，攻击者可对数据库进行恶意操作，甚至可能导致其他系统被控制，扩大被入侵的范围。

Ø 漏洞示例

某系统配置文件中密码以明文方式存储：

在这里，很明显能看到数据库的账号密码是明文。

Ø 规范要求

禁止明文或使用弱加密算法对密码进行加密，密码设置应具备一定的强度，大小写数字特殊字等最少3类型8位以上，并且不能包含与用户名一样的字符串。

15.弱加密算法

Ø 风险描述

一些低强度的密码算法，如DES、RC2等已经可以很容易的在短时间内被人所破解，其它一些容易被误用的“密码算法”，如base64、escape、urlencode等，其实并不是密码算法，只是简单的编码而已，不能起到密码算法保护信息的作用。

Ø 漏洞示例

以“古典密码算法”为例：

public class Caesar {
public static void encode(String PlainText, int Offset) {
  String CipherText = "";
  for (int i = 0; i < PlainText.length(); i++) {
   if (PlainText.charAt(i) == 32)
CipherText += (char)(32);
   else if (PlainText.charAt(i) >= 'a' && PlainText.charAt(i) <= 'z')   
    CipherText += (char)('a' + ((PlainText.charAt(i) - 'a' + Offset) % 26));
   else if (PlainText.charAt(i) >= 'A' && PlainText.charAt(i) <= 'Z')
    CipherText += (char)('A' + ((PlainText.charAt(i) - 'A' + Offset) % 26));
   else if (PlainText.charAt(i) >= '0' && PlainText.charAt(i) <= '9')
    CipherText += (char)('0' + ((PlainText.charAt(i) - '0' + Offset) % 10));
  }
  System.out.println("Ciphertext: " + CipherText);
 }

由于在算法中同一字符每次都是映射到另一字符，因此，只要获取到一定数量的明文和加密后的密文，就可以清楚的还原出每个字符的映射关系。并且可以通过映射关系，可以写出解密程序，如下所示：

public static void decode(String CipherText, int Offset) {
  String PlainText = "";
  for (int i = 0; i < CipherText.length(); i++) {
   if (CipherText.charAt(i) == 32)
PlainText += (char)(32);
   else if (CipherText.charAt(i) >= 'a' && CipherText.charAt(i) <= 'z')
if((CipherText.charAt(i) - Offset) < 'a'){
 PlainText += (char)('z' - ('a' - (CipherText.charAt(i) - Offset)) + 1);
 }else{
 PlainText += (char)('a' + ((CipherText.charAt(i) - 'a' - Offset) % 26));
 }
   else if (CipherText.charAt(i) >= 'A' && CipherText.charAt(i) <= 'Z')
if((CipherText.charAt(i) - Offset) < 'A'){
 PlainText += (char)('Z' - ('A' - (CipherText.charAt(i) - Offset)) + 1);
 }else{
 PlainText += (char)('A' + ((CipherText.charAt(i) - 'A' - Offset) % 26));
 }    
   else if (CipherText.charAt(i) >= '0' && CipherText.charAt(i) <= '9')
if((CipherText.charAt(i) - Offset) < '0'){
 PlainText += (char)('9' - ('0' - (CipherText.charAt(i) - Offset)) + 1);
 }else{
 PlainText += (char)('0' + ((CipherText.charAt(i) - '0' - Offset) % 10));
 }
  }
  System.out.println("PlainText: " + PlainText);
 }

Ø 规范要求

推荐使用的安全算法

对称算法：3DES密钥长度128及以上，切k1,k2,k3互不相等。

对称算法：AES密钥长度128及以上。

非对称算法：RSA密钥长度1024及以上。

哈希算法：SHA2密钥长度256及以上。

消息认证码算法：HMAC-SHA2密钥长度256及以上。

16.文件包含

Ø 风险描述

通过文件包含函数特性去包含任意文件时，由于要包含的这个文件来源过滤不严，从而可以去包含一个恶意文件，而攻击者可以构造的这个恶意文件可以达到执行任意代码、控制网站、甚至控制服务器的目的。

Ø 漏洞示例

以PHP本地包含文件为例，缺陷代码如下：

程序本意是获取action并引入action里的功能函数，这里上传头像image.jpg，然后包含进来发现在页面显示了phpinfo的信息

上传的头像image.jpg代码改为一句话木马：

上传成功后，使用菜刀连接，成功getshell, 可以下载、修改服务器的所有文件。

Ø 规范要求

1、如果是PHP代码则设置allow_url_fopen和 allow_url_include属性为0ff。

2、涉及到的危险函数：（如include()，include_once()，require()，require_once()）当使用这些函数时，要求程序员包含文件里的参数尽量不要使用变量，如果使用变量，就一定要严格检查要包含的文件名，过滤危险字符，绝对不能由用户任意指定。

17. Cookie 安全

Ø 风险描述

Cookie作为用户身份的替代，其安全性有时决定了整个系统的安全性，Cookie的安全性问题主要如下所述：

（1） Cookie欺骗

Cookie记录了用户的帐户ID、密码之类的信息，通常使用MD5方法加密后在网上传递。虽然经过了加密处理，但是截获Cookie的人不需要知道这些字符串的含义，只要把别人的Cookie向服务器提交，并且能够通过验证，就可以冒充受害人的身份登陆网站，这种行为叫做Cookie欺骗。非法用户通过Cookie欺骗获得相应的加密密钥，从而访问合法用户的所有个性化信息，包括用户的E-mail甚至帐户信息，对个人信息造成严重危害。

（2）Cookie截获

Cookie以纯文本的形式在浏览器和服务器之间传送，很容易被他人非法截获和利用。任何可以截获Web通信的人都可以读取Cookie。Cookie被非法用户截获后，然后在其有效期内重放，则此非法用户将享有合法用户的权益。例如，对于在线阅读，非法用户可以不支付费用即可享受在线阅读电子杂志。

Ø 漏洞示例

有一个后台登录页面（login.asp）的源代码

登录页面的两个Cookies值分别为cmsname和cmsid

网页会把输入的管理员帐号和管理员ID分别赋值给cmsname和cmsid这两个cookies值，如果密码正确就会跳转到后台首页，并添加上述的两个cookies值。检查用户登录状态的文件，源代码如下：

可以看到，网页虽然有验证用户登录状态，但只仅仅验证了Cookies的内容，只要两个Cookies的内容都对得上，就能访问后台首页，这样，就会产生Cookies欺骗漏洞。

Ø 规范要求

1、设置认证COOKIE时，增加Cookie httponly这个属性。如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息

2、增加Secure这个属性。当该属性设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该cookie信息，所以不会被窃取到Cookie 的具体内容。就是只允许在加密的情况下将cookie加在数据包请求头部，防止cookie被带出来。secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取cookie后进行攻击。

18.会话超时设置

Ø 风险描述

浏览器和服务器之间创建了一个Session，若没有做会话超时设置，当客户端长时间（休眠时间）没有与服务器交互的情况下，服务器也没有将此Session销毁，若攻击者获取此会话，就能一直利用该会话，进行与服务器的交互。

Ø 漏洞示例

下面一段存在漏洞的代码中，没有对session做一个失效的处理。

修复后的代码如下所示，用户在登录的时候，首先会让之前的session失效，然后又获取新的seesion。

Ø 规范要求

设置空闲会话强制超时时间，时间不能设置过长，建议设置为5分钟。

设置Session超时时间方式：

方式一：

在web.xml中设置session-config如下：

即客户端连续两次与服务器交互间隔时间最长为2分钟，2分钟后session.getAttribute()获取的值为空

API信息：

session.getCreationTime() 获取session的创建时间

session.getLastAccessedTime() 获取上次与服务器交互时间

session.getMaxInactiveInterval() 获取session最大的不活动的间隔时间，以秒为单位120秒。

方式二：

在Tomcat的/conf/web.xml中session-config,默认值为：30分钟

方式三：

在Servlet中设置

HttpSession session = request.getSession();session.setMaxInactiveInterval(60);//单位为秒

19.日志处理

Ø 风险描述

日志处理是由于在全局过滤的时候没有考虑日志文件内容，当一些敏感内容通过日志文件保存下来的时候，或者说木马病毒代码通过日志记录下来时，可以通过日志文件查看或执行。导致敏感信息泄露，甚至被上传webshell，导致攻击者可以随时进入后台，对文件进行操作。

Ø 特殊字符

Php木马:

Asp木马：<%execute(request("value"))%>

Aspx木马：<%@ Page Language="Jscript"%>

还有password,passwd(密码),phone(电话号码),ip等。

Ø 漏洞示例

以某后台数据库为例，先执行语句setglobalgeneral_log='on'，把general log设置为ON

再执行SET global general_log_file='D:/phpStudy/WWW/cmd.php'，修改日志文件名。

然后执行一条sql语句。

用然后菜刀进行连接。

还有就是日志记录敏感账号密码等信息：

在代码100行处，直接将用户名密码明文形式记录在日志中。

Ø 规范要求

对日志文件中的敏感内容进行转义，凡是从日志文件中输出的内容都要进行验证。而且对于一些敏感信息，如电话号码，密码，ip地址等内容都要进行加密保存。

20.未配置全局过滤器

Ø 风险描述

在系统庞大的系统下，很多漏洞是具有通用性的，如XSS、SQL，未授权访问、任意文件上传下载等，如若一个地方出现，在未配置全局危险字符过滤器的情况下，通常其他地方也会出现同样的安全漏洞。

Ø 漏洞示例

在该配置文件中，只配置了编码过滤器，而没有配置全局危险字符过滤器。

Ø 规范要求

1、根据业务需求配置健壮的全局危险字符过滤器，对用户所有输入输出进行过滤检查，如检查异常则跳转到制定的error页面。

2、使用xml配置文件的方式记录配置信息，配置信息包含是否开启校验、是否记录日志、是否中断请求、是否替换脚本字符等。