从国家等级化保护的要求里面，对于应用系统自身的等级化措施和防范是非常关注的。等保本身的来源有很多方面，比如说国际上的ISO15408，包括14799等，在等保2005年出的最新几版里面其实不包括安全管理的内容。06年出的等保里面就把安全管理，安全策略制度放到比较高的位置。
    信息安全的保障不仅仅是指技术层面的一些问题，更重要的是一个企业或者一个单位在人员组织结构的定义，工作职责的定义，包括在整个构架设计里面相关的安全策略制度的执行，策略制度的一些要求。另外一块指的是技术层面的问题，最重要一个环节的是运行维护方面的。应用系统也好，或者是操作系统，或者是人员也好，针对日常工作和操作的要求，包括维护，相对是非常关键的。这次峰会的课题是软件安全，所以说今天讲得更多是在软件系统上，包括在应用程序上的一些安全性的标志和作用。
    今天会讲一个针对已经正在使用，或者已经准备开发的这套应用系统来讲应该怎么评估，怎么发现它存在的安全缺陷和风险，怎么做一个比较好的安全应用自身体系规划，保证业务系统的安全性。
    在应用系统的安全评估方面原来也做了很多，应用方面有几大块。从等保的角度来讲，等级有1、2、3、4、5，其实最关心的是应用系统自身的等级。在座的各位如果自身企业做过等保的定级大家就清楚，定级的指标其实很关键的一点是看应用自身的级别。应用级别的高级就决定了这个企业所在等保的高低。
    从应用角度来讲包括三种：第一种是生产性业务，第二种是生产管理性业务，第三种是纯粹的管理性业务。生产性业务是跟生产相关的，比如说电力的一次系统或者二次调度系统都属于生产性系统。生产管理性系统是指资金保障系统，经销纯系统，企业自身和管理相关的业务。纯粹的管理性系统是比如说邮件系统，Web系统或者是对外宣传的制度颁布系统，都属于管理性系统或者是人事系统。
    根据自身属性的不同，在评估上面，或者是应用在风险检查的要点上面也是完全不一样的。
    下面讲的主要是在应用系统自身怎么发现它存在的缺陷，这个题目会讲有一些技术性的内容在里面和等保的环节里面紧扣第二部分，系统自身的安全性应该怎么通过技术的手段去发现。
 
一、 应用系统风险评估
    首先看一下一个应用系统如何去评价它的安全风险，以及它当前的安全漏洞。
    评估方法：要知道一个业务系统，或者自身的系统存在的安全问题，首先要明确为什么要检查这个业务系统，检查哪些方面，用什么依据检查。首先要知道这个业务的目标和安全的目标是什么。业务的目标非常明确，如果是一个生产系统，对时时性的要求是非常高的。对于它的保密性和完整性要求也是非常高的。确定的目标是这个业务最关心的是保密性还是可用性，还是完整性？要确定这样一个主体目标。
    第二个目标是确定安全目标，安全目标对于一些国家政府企业，或者是行业性大用户来讲，可以用国家等级化保护的安全目标级别定义安全目标。首先要有一个根据，比如说达到国家等级三级的应用系统。
    这个应用系统从应用层面、网络层面、从应用自身层面和附属层面、管理层面达到三级不同的指标首先要量化出来。应该跟国家等保的应用要求有一个差距性的分歧性指标要确定好。应用系统的评估第一个环节是应用系统的概述，首先要对应用系统自身的作用，包括它的一些开发的文档和操作的文档，对于这个应用使用不同权限人员的权限职责，用的数据的存放格式和方法一定要有详细的了解。如果对这个系统自身不清楚，不明白的话，是很难了解这个系统自身存在的安全问题的。
    应用系统的分解：一个应用系统组成，第一是承载平台，网络平台，第二是系统平台，第三是应用平台，第四是数据库平台。从这个角度来讲是从技术层面划分。从另外一个层面来分解是数据流，要看这个数据在创建的时候是由谁来创建的。创建的时候有两个入点，一个是人为的输入创建的，一个是因为系统的自身分解得到的数据。得到这个数据来源以后要知道它的输入点和输出点。这个数据分别在通过网络，通过系统，通过Web，中间件和外部数据库到最终存储过程当中，整个数据流环境是否面临完整性、保密性和可用性之间的安全风险和缺陷。所以说要对数据流进有一个详细的分解。这个是应用评估里面非常关键的一个环节。讲什么叫等保里面的定级，或者讲什么叫做信息资产，比如说信息资产也好，资产最核心的属性是数据属性，信息其实就是指数据。对于一个应用系统来说，其实保护的就是数据。如果你对于自身的这套系统，或者对自身的这套应用，数据本身传递过程，或者产生和使用过程非常不清晰的话，做应用评估或者是应用的安全性分析肯定是一个表面的分析，不能深层次的分析它的安全性。
    我们也做过比较多的应用安全的分析，比如人民银行互联网的应用，阿里巴巴的支付宝。要分析这种支付系统，或者是相关数据的检查是非常关键的。需要对数据本身的属性，传递过程，对它的权限控制或者是输入，输出点不清晰造成的问题进行分析。所以有很大部分的应用安全不是存在于代码设计的不安全，或者是在控制的系统层面的漏洞导致的，是因为对数据流的安全性没有做好完整的分析。
    威胁确认：大家知道风险、漏洞和威胁是三个要素。威胁是指什么？很多时候做应用的检查和做系统的检查，评估是完全不一样的。比如说系统的扫描，或者是系统的风险检查，一般是从漏洞引出威胁。这是什么样的概念？首先要知道这个系统，比如说Windows的缓存溢出漏洞，首先是通过扫描器，或者是人工评估的方法找到漏洞，根据漏洞再去分析是否存在越权访问的威胁，或者是普通用户越权到高级管理员权限反映的威胁。
    在应用的风险评估来讲，首先是判断威胁的可能性，这个威胁的可能是怎么产生的，有多少种威胁，根据威胁再看是否这个威胁存在是有依据的。这个依据就是说有没有这个漏洞，然后再做漏洞分析，最后根据威胁和漏洞确定风险。根据应用的评估来讲首先是确定威胁，然后再看威胁是不是有这个漏洞引出这个威胁，最后再做整体的风险分析。这个评估的方法和检查方法是跟设备的检查完全不一样的。
    根据威胁来看，就是根据常见的一些威胁定义。对于应用来说，第一层威胁是开发威胁，第二层是数据传递过程面临风险的威胁，第三是承载平台的威胁，第四是管理上的威胁。对于漏洞来讲就是细节性的，比如说在开发过程的漏洞可能会是源代码的泄漏，开发的不规范导致的漏洞，开发人员在里面内置一些恶意***或者后门程序导致的漏洞。根据漏洞和威胁得到风险。
    风险：风险也不是简单的说根据漏洞和威胁具体的名称得到一个风险的名称，是可以具体量化计算出来的。这个计算的做法会有一个矢量图给大家介绍一下。
    根据风险得到的就是应用的加固建议：这也是分成几个层次：
1、应用平台的加固建议
2、应用代码开发程序的加固建议
3、数据传输过程当中控制不合理加固建议
    使用人员和应用的维护人员的一些管理制度和约束要素求的加固建议。
    最后得到整体信息系统的安全性。
    当前有60%—70%的***并不是集中在系统和网络层面的，大部分的***现在都是在应用层面的。比如说很多网站遭受***，因为是应用自身程序开发程序的不安全，或者是比如说前台和后台之间，中间件的连接，或者有的就是没有中间件，两层的网络结构或者是应用结构导致的安全性。应用的安全是整个信息安全化，包括从国际的角度来讲都是最关注的一个层次。
 
二、应用系统完全分析
    对于一个应用系统来讲，其实安全性是十个方面，如果自身对于一个应用系统平台自身来讲分为：
1 、身份验证
    比如说级别越高的，三级以上的应用系统一定要有双证书认证。双证书认证首先要通过用户的账号名和密码进行认证，第二种是通过CA证书，通过加密传输用证书的方式认证，或者是通过动态口令卡，或者是通过USB key这种密钥的方式认证。这种二次证书认证在三级以上的系统都是要做的。二级以下的基本上用口令和账号密码认证都可以达到要求。口令和账号认证对于应用来说也是非常重要的。为什么？因为发现有很多开发的供应商，或者是一些自身用户开发人员，很多时候为了简单是把用户名和密码放在一个文件里面，在这个文件的传输过程当中也没有对这个文件进行加密传输。一些政府单位还有大的行业用户都会有这种问题的存在，这种威胁性非常大。通过IE浏览器，如果它还有目录泄密漏洞控制不严格，可以通过IE浏览器检查整个Web服务器里面的文件目录的话，这个文件就可以马上拿到。拿到以后通过用户名和密码浏览这个应用，或者是对这个应用里面的数据库进行修改。
2、授权
    一个应用系统的关键是它的使用者。使用者的授权非常重要的，如果授权不合理，一般从几个层次来讲，在网络层来说，授权也就是一种访问控制，整个访问控制，网络系统应用和数据它本身包含的大小范围是不一样的。网络的访问控制一定要用组或者是一个部门，是比较大的。不能把一个网络的访问控制限制到每一个人都有网络控制的要求，这样的话整个系统和整个平台是没有办法使用的。对于系统层面的访问控制，需要归类，比如说管理员要分成是不是可以进行配置管理的，还是可以进行一些参数修改的管理员，对于数据库的管理员只能针对数据库进行管理，不能针对整个系统进行控制。应用的访问控制一般来讲是基于角色，它的使用要求来分类的。应用访问控制最好是指定到单个用户都有单独的授权。这是在等保里面在三级以上或者是四级有特别的要求。有的人觉得使用方便，把这个部门设成一个组，这个组里面的人都用相同的账号，相同的权限。其实这是不合理的。从应用的角度，网络和系统是不一样的，对于网络来说是采用划大的区来分类，对系统来说是设置不同的权限，对于应用来说是不同的人要有不同的授权。授权在访问控制要求上是比较严格的。
    授权的意义：一个应用系统不能单纯的存在。一个企业不可能只有一个业务系统，他会有很多的业务系统和业务程序，所以整个授权最好建立统一的用户账号，或者是用户授权的平台。一旦用户一次性登录以后，针对不同的应用系统，统一进行授权管理，而不是每次登录一个新的业务系统重新进行一次新的授权，这样控制的难度也比较大，使用性也是比较麻烦的。所以说建立统一的用户认证和授权平台也是将来应用发展的一个比较大的趋势。
3、输入和输出的数据验证
    一旦一个数据输入的时候，一定要保证这个数据是真实的，里面是健康的，没有带一些恶意的程序。有一些网站，特别是像BBS论坛，一些大的邮件供应网站，这些网站自身在输入的验证方面做得比较缺乏，所以说很容易让一些具有不同类型的文件都可以上传。有一些***或者恶意人员可以上传一些***程序，或者是具有可执行权限的网站链接。比如说经常说的跨站***是怎么样产生的？比如说一些著名的邮件系统都是存在跨站***的问题。他可以让用户上传一个页面，这个页面上传以后，又可以直接调用到另外一台机器上去。比如说一个电子商务平台，在上面发布一个信息，说钢材现在是5万块钱一吨，人家感觉价格很低，都会点。在点击的时候，这个链接就转到***指定的Cookie的系统，每次上网都会有一个Cookie信息。这样就可以把全部上网人的Cookie全部捕获下来。只要这个人在这个电子商务平台用户名和密码有认证的话，通过这个平台上去以后，Cookie信息就是认证的唯一手法。这个过程当中，***就可以用这个Cookie和电子商务平台网站交易了。这就是绕过用户名和认证的方法。这就是在输入位置上面很多应用开发商不太注意，没有控制输入的要求和控制文件的类型，或者是输入一些特殊字符导致这种***行为。
4、配置管理
    2000年的时候，网站或者BS结构刚刚开始盛行的时候，一般都是用两层结构做一些BS的开发。比如说前台用ASP，通过ASP的直接查询调用数据库，这种方式是非常不安全的。为什么？你的用户名和密码肯定是存放在数据库里一个表单，或者就是一个明文的文件，或者是简单加密的一个文件，这是很容易破谜的。
    如果是用两层的方式，本身在数据库查询和调用过程中，每一次查询要调用一次数据库，对于应用来说速度会非常慢。可以跳过前台的Web直接对后台进行操作。原来有很多的公司在开发过程当中这块做得比较差。
    最近几年BS结构由两层结构变成三层结构。对于三层结构来讲安全性就要大大的高于两层结构的安全性。它是通过中间件调用后台数据库的，中间件里面本身每一个组件，结构方式本身都是模块化的。你要通过模块化的方式了解模块是怎么编译的，这对于***或者是有恶意***行为的人来说是非常困难的。所以用三层结构安全性会高很多，但是还是会存在漏洞。因为调用过程当中不知道调用的方法，但是他可以知道用的方式。自身的编程的方式，可以用<、>、‘’，设置一些特殊的字符串。***者通过IE可以利用这个漏洞进入数据库，也可以导致数据库的被更新或者是被篡改。
    所以配置管理当中非常重要的就是开发规范的管理，以及在整个结构的安全性，Web前台当中的应用处理，后台的数据库和备份。Web浏览器整个环节应该进行怎样合理的安全保护和措施。
5、敏感数据
    等保里面关注应用系统的等级，最主要的是因为存放数据的安全性。如果数据的安全性越高，安全等级就越高。如果数据的安全要求越低，它所存在的应用等级要求越低。敏感数据是指对这个数据是否有一些机密性的要求要进行归类。如果有这些核心业务系统正在使用的用户，或者是在座的各位要帮第三方做应用检查的时候，最主要的是要了解这个用户有多少敏感数据，敏感数据在传递当中，当前的传输方法，以及备份的方法，被调用的方法是否合理，是否具有安全问题。一个四级的应用和一个二级的应用系统很有可能是把数据放在同一个数据库里。对于混合放入不同等级，放在同一个设备上的存储问题怎么进行有效的保护和分类，隔离这是很关键的。
    在帮用户做一些应用分析和检察的时候，经常会发现这个问题，不同等级的敏感数据放在同一个数据库里面，如果不是放在同一个数据库里面很有可能是放在同一个网段里面。在单级以上或者四级应用数据和低级别的数据放在一个区域里面，这样的话，低级别的保护措施必须以高级别的要求去做，不能因为它的要求是二级系统的，就用二级的要求去做。如果不能把它们隔离开，还是要放一个整体的环境里，或者同一个数据库，那二级的保护措施不可以有，一定要用最高级别的要求去做。
6、会话管理
    现在还有很多企业在开发的时候，Cookie信息是明文的，这个一定要改变。因为Cookie里面存放了很多的信息，比如说服务器的配置信息，版本信息，包括用户账号口令连接以后本身产生的一个特殊字符段都是在Cookie里面被包含的。所以如果Cookie信息拿走以后，一些***者专门有一个软件叫“还原Cookie信息”，你的Cookie文件可以很快的被他还原出来。他就知道这台主机的所有连接情况和信息情况。一旦拿了别人的Cookie信息，把Cookie文件放到IECookie文件夹里面，如果用户是在登录的状态，拿到用户Cookie信息就可以直接登录，不需要再认证用户名和密码。这个Cookie信息就认为***者是合法用户，直接可以登录，不需要再输入验证的用户名和密码，这个问题就很重要。在会话管理里面一定要设置，不允许同时存在两个相同的Cookie信息，是从两个不同的IP过来的。
7、加密
    对于应用的加密，在等保里面四级上面就有严格的要求，从Web端到浏览器，一个用户的IE浏览器到应用的Web前端，这个连接过程必须是要加密的。从后台的应用处理端到数据库的存储端的连接是必须要加密的。很多用户说对于应用的加密有没有很好的技术？加密有一个很大的问题是还原，如果加密以后数据还原出现问题，可能用户的数据放在数据库的类型和位置就会有偏差，这是一个问题， 第二个问题是，加密以后应用速度还会有影响。怎么通过合理的技术进行加密？在座如果做过开发的话就会比较清楚。在开发的模块里面自身是带有加密功能的，怎么能保证还原的可靠性，包括使用的可用性和速度，根据加密的算法不同和加密的长度不同可以做一个合理的分配。
    加密可以从浏览器到Web服务器端可以做很好的证书方式。这种证书相对来说做得都是比较合理的，在存储自身的安全性上面也是不错的。如果真正要做四级以上的业务系统，要做传输加密的方式可以用证书的方式，这是比较有效的手段。而且证书的规模对于特别大的应用来说，或者是在整个范围比较广，使用用户比较多的情况，用证书是最好的，比如说网上银行，银行会给用户一个令牌卡，通过用户名动态方式来连接。发现用户越来越多以后，这种方式是不可取的。因为用动态令牌会有延迟。一旦延迟以后，在这个点输入密码以后，到那边已经过了1分钟，匹配密码已经变了。所以系统认为输入是错的，还要重输，因为有的时候网络速度比较慢，过去以后可能对方的密码生成服务器已经把密码更换掉了。所以系统认为用户密码是不匹配的，如果连续三次不匹配，系统就把用户账号锁定10分钟或者多长时间。这样用户的正常交易就会受影响，特别是一些大企业的客户，就会投诉，因为觉得总是连不上。
    后来网上银行或者银企通就采用证书的方式。证书的方式没有密码会变化的匹配的概念，只是一个加密传输过程。加密传输过程用CA证书是双向认证。如果用过网银的都知道，我没有申请证书的话，只是用网银查一下卡上有多少钱，不进行配置交易的话，只需要用普通的网银方式。你点到普通网银以后，http就会转成https，这不是对银行进行保护，是对用户进行保护。为什么？https的s表示需要认证这个网银是不是真正由这家银行做的网银系统，还是由***做的假的网站进行保护的。大家可以试一下自己的网银，如果转成https以后，在右下方会显示这个证书的颁发机构是谁，说明这个网站是受到这个颁发机构认证的，会有一个标志出来，通过这种方式保护客户，让客户知道网银是授权的合法网站。如果要进行网上交易的时候，银行会给用户一个USB key。USB key保护是双向的，是保护连接的用户得到银行授权，是可以进行网络交易的。保护银行，或者是保护其他用户不会通过非法账号把钱给诈取掉。所以说这是双向认证。
    现在网银第三种的加密方式又有改变，有很多是发手机密码的方式进行认证。通过手机发短消息过来一个密码，通过输入这个密码进行网上交易。这种方式也是存在缺陷的。手机密码产生的字符一般是6位，如果6位的字符，银行发的要么是字母要么就是数字，如果要破译的话还是有可能性的这就是为什么如果用手机进行网银的话一定会限制交易数额的，一般不会超过5万。但是用证书交易可以是无限交易的。
    在加密的过程当中，比如说像传输过程，可以看一下金融行业和一些大的企业自身的财务系统。这些用户加密的做法也是国际和国内比较领先的做法。包括信用卡组织Visa和Master，自身的安全设计都是有一个标准的，叫做PCI-DSS标准，是由信用卡组织颁发的信息安全的技术标准。这个标准里面非常详细的说明，一个有网上交易平台，或者资金管理平台的系统，应该怎么做安全详细的技术。如果能够把这份文档看透的话，你们看到在业务系统上面是一个安全的专家了。因为里面对于怎么样保护一个应用系统的安全写得非常详细。
8、参数管理
    在开发过程当中，一些特殊字符的参数必须要过滤掉。很多开发人员非常不注意开发的安全性，经常会用一些小于号，大于号，引号代替一些字母的组合。觉得这样用简单，而且是这个系统可以识别的，但是用这种符号最容易导致跨站脚本的***行为。参数管理上这方面一定要注意。
9、异常管理
    一些非正常的输入管理，包括网络传输过程当中发现流量异常，或者是输入的字符和要求的字符不匹配的时候，如何进行有效阻断和控制的管理。
10、审核与日志记录
    应用系统里面很多时候大家会忽略系统日志的等级这个模块。其实在等保里面到三级以上就是审计级，二级以上其实就已经有要求，但是三级以上对审计的要求是非常严格的。要求把所有的登录，失败的等级，成功的等级全部要记录，包括对于数据库查询的一些记录也需要等级下来。需要记录整个应用系统自身的连接过程，点过哪些URL的连接，也要审计。在应用系统的审计这块往往也是开发商或者自身的系统开发人员会忽略的一点。在为用户提供应急响应和紧急处理的时候，一个业务系统一般被黑掉以后，首先查的就是日志。如果这个业务系统自身日志记录得不全，或者是功能本身就不完备的话，有时候在找***的行为，或者怎么被***的，是很难找到的。在记录哪些日志和记录什么样的日志。
    一个应用系统分为四个部分：
    首先是外部，就是浏览器、用户端，客户端。通过必要的防护手段进入Web前台服务器的应用。通过应用中间件程序可以对应用进行与后台数据库的连接，进行调用处理。后台数据库对数据进行处理和存储作用。一般来说审计是审计应用系统和数据库连接的调用过程。第二个审计是在前段，是在这个位置主要是针对用户登入和登出的情况进行审计，审计主要是在这两点。防止Cookie或者异常行为的***，一般是在Web这块做一个过滤的程序代码。大家常见的有一些应用防火墙，或者是应用的软件防火墙装在Web服务器上，主要的功能是进行用户认证和一些IE的非法调用，异常字符串的过滤和审计，和整个的结构。
    数据传输、处理安全评估：
    需要看一个系统的安全性，首先不是看操作平台，系统平台和网络平台。最主要是了解这个系统有多少人会使用这个业务系统，管理部门是哪个部门，使用部门是谁，IT的管理部门或者相关的人员是谁。首先要知道相关的应用系统的使用者，管理者是谁。需要看使用者会从哪些边界过来。比如说内网的边界过来到Web的界面，还是通过外部的边界，还是通过第三方，合作伙伴的来源过来的，首先要知道来源的根本点在哪里。了解清楚以后要看，对于一个人事系统内部的一个普通人事人员，他的权限如果只是看人事的考勤表，要看考勤表的数据在输入端，包括考勤表在整套业务系统传递过程当中是否会面临泄密，或者被第三方篡改，或者是导致可用性的问题。另外要看人事人员除了考勤单以外，能不能通过其他的方法，获得别的部门。比如说财务主管，比如说人事主管的工资表的数据会不会被普通的人员拿到。这就要看人事经理对于工资表的传递过程当中是通过同一个交换机，文件又是明文传输的话，是不是可以用一些引流的方式。这个人事人员在他的机器上面装一个监听器，再装一个网端欺骗的工具，是否可以把这个数据全部拿到自己的机器上，这要一步一步分析数据流。
    分析数据流的工作是非常有逻辑性，对于安全本身的技能和知识掌握情况是非常关键的。如果数据流你分析不彻底的话，核心的业务系统还是不能做好安全的。数据流的分析主要是看内部员工有没有可能获得他不应该获得的数据，以这个为重点检查。对于数据流分析另外一个重要看的是外部人员能不能通过一些非法数据，通过一些非法的***或者手段，获得核心的机密数据。
    最重要的还是看内部人员。比如说在这个上面，一个普通的人事人员和他的主管都是通过相同的路径对这个应用进行管理和使用的，在这个过程当中肯定会有数据的交叉，或者数据的共同传输时间点，这个时候很难保证数据不会被泄密。怎么解决这个问题？可以通过核心数据传输是加密的，考勤表是内部公开数据不进行加密，通过这种方式有效的进行保护。
    对于一个人事系统来说， IT部门人员可以对这个业务系统哪个环节都可以进行管理，进行配置，这就是非常大的缺陷。前一阶段做过一个很大的国内公司。在做应用调查的时候，到业务使用部门，用户说自身的业务部门不安全，他们是知道的，而且很清楚知道有哪些弊端。比如说营销人员可以很容易的修改一些销售数据，但是又提出来最担心的是IT人员。他们IT管理部门的人员，可以对这个业务系统进行从头到尾的配置和管理，进行修改。如何控制IT人员对这个业务系统的使用过程也是很重要的。在一些关键的结点装一些审计设备针对IT人员配置和管理的审计，系统涉及、数据库审计、网络流量审计。这都是针对IT人员对系统的威胁进行的控制。
三、应用安全扫描
    除了数据流以后，还要采取一些技术性的手段，看看平台自身是否有安全问题。会用扫描工具或者是人工评估的方法。扫描工具从系统或者网络设备来讲，大家用过很多。这些扫描工具的特点是扫描系统层和网络层，一般来说针对应用的扫描是有专门的工具的。主要是看你在调用过程当中会不会存在一些应用的安全性问题。比如说跨站问题，比如说有一个特殊的链接，或者是可执行文件。点击这个可执行文件或者是链接就把***种到这个Web浏览器上。
    有一次评估一个很大的行业用户，主网站就出现过类似的问题。这个主网站上面被人种了一个“灰鸽子”，这是一种隐性的***程序。他被种的特点是，只要有人点击了这个网站以后都会被种植“灰鸽子”的后台程序。一旦被种植以后，使用过这个网站的人再去银行的话，可以把网上银行的卡号和输入的账号，密码全部通过“灰鸽子”传递到***那里。这个网站是一个很大的行业主网，出现这个问题以后，很多用户的客户端都被种了“灰鸽子”。正常的防病毒软件是杀不出这个病毒的需要用专门的“灰鸽子”查杀工具查了以后找到的，找到以后马上把主网站停掉，否则上的人越的，被种的人越多。这就是因为它有跨站脚本的问题。
    现在用三层结构，一般网页都是以数据库文件形式，数据库的数据形式存在的，他直接连接数据库把主页的内容改掉了。把主页内容改掉以后，主页的内容就变成他们想写的情况。
    程序代码注入：内制一些可执行程序或者是后门程序，如果开发的程序对于数据的存储或者上传是不严谨的话，很容易把一些变相带有病毒代码的文件感染。现在上一些BBS和一些小网站的时候不严格，经常有人会把图片文件里面隐藏一个病毒***程序进去，把它包装成一个图片文件。这样一般的防病毒软件是很难查杀出来的。在这个过程当中，网站是允许上传图片文件。传上去以后只要你点开这个图片就可以自动解开这个病毒代码或者是***程序，然后直接种到你的Web浏览器上的。所以在检查应用程序的时候，不是说在开发过程要检查安全，最主要的是开发完成了，系统正常使用的过程当中，要有专人定期的对上传的文件和代码进行检查，包括静态文件也要检查，现在很多行为都是通过静态文件传的。
    比如有一个外企，很多的图片，包括静态文件不是由他自己传的，是由专门收集信息的第三方公司帮他上传文件。第三方公司的人员自身有一些想法，他种植了一些***上去。如果第三方的公司自身安全性很差，主机被人种了***，他再做上传文件的时候就会把这种病毒上传上去。做网站应用维护人员，自身的计算机保护也是非常关键的。自身的安全性很差，就会把病毒、***或者一些恶意的程序，通过个人计算机带入到你的应用程序中去。
    网站程序原始码暴露也是非常严重的，还有一些注入和命令框等。
四、应用源代码安全审计
    这次的赞助单位，比如说Fortify本身就是做代码审计的工具。做代码审计不光是做安全审计，还有代码自身功能性和缺陷性审计。Fortify做安全代码的审计来讲，他会检查代码里面开发自身的一些特殊字符是否合理，每一个页面链接过程当中是否存在空隙，是否会被其他人内嵌一些其他的页面，是否存在跨站的注入问题，或者是Http包头被人修改都会去查。如果是人工去查的话没有时间，一些大的检查肯定是通过专业的软件测试工具去做的。
    敏感数据的保护主要是怎么防范用户的用户名账号，这就是一个敏感数据。另外在传递过程当中的一些敏感数据业务的保护。在达到三级以上或者四级的话，建议在整个传输过程当中要通过加密的方式连接，这样就保证敏感数据只能在授权的范围内，授权的人员可以拿到。非授权人员拿到了得到的也是乱码，这点要做好。
    这是一个企业的财务系统，用户名和登录这块用的是http，是明文的。可以做了一个尝试，用一个专门的×××专门做网络嗅探。为什么可以成功？因为它的文件是明文的。在这个地方可以看到，在输入的时候用户名可以直接拿到。在做应用程序的开发过程当中一定要注意的一点是，在登录用户认证的页面绝对不应该是使用明文的，要进行双向的认证，或者是动态口令卡，或者是USB key做二次认证都是可以的。
    授权：如果授权不合理的话，有的时候特别不注意的是，很多的程序文件或者是目录文件是放在Web服务器上面。Web服务器上针对文件自身的保护是所有人可以读这个文件。这点恰恰可以在IE浏览器上被利用，可以把所有的文件浏览。做得更不注意的一些用户，直接对Web服务器上存在的文件夹普通的用户可以修改文件夹或者添加用户，那非法人员可以直接通过http或者是Web方式的http往文件夹里面传送***程序、病毒或者是代码。如果有执行权利的话，可以通过这个文件夹直接执行这个程序。如果没有这个权利，可以设置成只要机器启动以后会自动启动这个恶意程序。在Web服务器上对于文件夹的权限控制和管理就会导致问题的产生。
五、威胁和风险分析
    DREAD模型是专门分析风险存在的等级，原来做风险评估的模型是用漏洞的可利用性，乘以威胁造成的严重后果，加上资产本身的价值得到风险的高低，这个是针对设备而言的。针对应用来讲，需要看的是评价它潜在的损失会有多大，第二是看重现性，第三是可利用性，第四是受影响的用户，第五是可发现性，根据这五个因素看它的风险。一般分为三个层次，得到风险的高低级别。
    通过这个计算以后，这个模型是非常切合自身应用的特点设计的五个因素，这也是在一些国际标准里面常用的应用风险模型的方法。
六、 Web 宏观架构模型和关键安全控制
    现在大部分都是DS结构，对于DS结构的业务系统来说，应该怎么进行有效的安全规范和保护才是最有价值的？应该做应用系统的安全到底应该考虑哪些方面是最好的？
第一，管理控制。管理上面的安全性，一个应用系统要用好，对于使用者的管理要求，对于IT管理人员的要求，以及对于一些特殊事情的紧急响应和审计是非常重要的。
第二，用户身份控制。
第三，网络安全控制
第四，系统安全控制
第五，应用安全控制
第六，数据安全控制
    通过这个图来讲，把一个应用可以分成几个大的区，一个是不可信任区，Web远端这块。Web应用服务器是可以让远端用户直接调用的区域，比如说像Web前台的Web服务器。第二个是数据服务器，比如说它有两块一个是应用调用服务器和数据库服务器，由这两个部分组成。最后一个是内部的安全。如果不想和这个受性端连接，受性端一端是外部的网站，内部核心的生产系统一定要有效的隔离。隔离的时候通过防火墙，应用的防火墙或者是IPS，IPS这些方式进行有效的隔离。具体的保护措施就有很详细的相关的一些方法，这边就不详细介绍了。
七、 Web 层
    对于Web层面输入输出验证需要做哪些方面，访问控制需要怎么做，异常处理怎么做，就不详细讲了。
    敏感数据：尽量避免存储机密，如果这个业务系统的等级是比较低的，低等级的业务系统就不要在上面存放一些高机密的数据，因为它的保护措施不到位，你放了高机密的数据很容易就被泄密。
    不要在代码中存储机密。什么叫代码中的机密？比如说有的人喜欢在代码程序里面加一些备注，这个代码是指什么意思，和哪个连接。可以通过漏洞拿到代码的话，就可以知道整个应用的结构，如果注释得很清晰这个程序结构就完全清楚了。这种注释不应该放在代码里面，应该是放在单独的文件。
    有的人是把账户名和密码做成一个文本文件，这是不允许的。不要用纯文本的形式存放用户名和密码，这点很重要。
    现在常用的手段是把用户名和账号密码的认证放到中间件的一个模块里面，这是最好的。另外一种是放在数据库当中的一个字段里面，这种安全性也不是太糟。最差的是把它做成文本文件放置。
    对数据进行加密或确保通道的安全。比如说在四级以上要求整个应用系统都是要进行加密的。
    不要在永久性Cookie中存储敏感数据。一般的IE浏览器都有一个Cookie字段，如果跟后台连的话会有一些是永久的信息。Web浏览器的浏览，自身应用程序的版本和补丁，连接的一些特殊特征都会在Cookie信息里面放。有一些人会把一些内置的认证参数，或者是Web和客户端认证的特殊字符都会放到Cookie里面。这样别人拿到你的特殊认证字符以后就可以自己伪造一个Cookie，这个就很危险。
    不要使用HTTP—GET协议传递敏感数据。一些非法人员也可以把HTTP包头，往里面放一些数据信息。
 
    本文主要内容整理自上海柏安安全公司首席安全顾问张照龙先生在 2008中国软件安全峰会上的演讲，欢迎 下载本文资料。
浏览更多精彩文章>>
订阅软件安全电子期刊>>