安全风险评估-应用系统评估.docx

《安全风险评估-应用系统评估.docx》由会员分享，可在线阅读，更多相关《安全风险评估-应用系统评估.docx（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、安全风险评估之应用系统评估2023年2月目 录1.应用系统评估概述41.1评估的概念41.2评估手段42.评估前的准备52.1确定用户配合人员52.2确定评估的范围52.3获得应用系统组件的清单52.4应用系统评估启动会62.5签署应用系统评估申请63.具体评估步骤63.1认证和鉴别63.1.1是否启用了PKI73.1.2是否启用了组织统一要求的PKI73.1.3认证进程是否适当73.2用户账户管理73.2.1用户ID唯一性检查73.2.2不活动用户是否禁用83.2.3不必要的内置用户是否禁用83.2.4用户ID是否有默认的或者弱口令83.3数据保护83.3.1敏感数据不适当地存储83.3.2

2、敏感数据传输中没有适当的保护93.3.3使用未经验证的加密算法93.4安全审核93.4.1安全相关事件记录93.4.2日志将满没有警告103.4.3日志存在未授权删除、修改、泄露等漏洞103.5应用操作103.5.1基于角色的访问控制没有加强责任分离103.5.2应用在执行操作之前没有进行授权103.5.3进程运行的权限过高103.5.4应用没有对session的限制113.5.5应用修改在应用的范围之外的文件113.5.6用户绕过用户界面直接修改资源113.6影响控制113.6.1网络架构不适当113.6.2没有灾难恢复计划113.6.3备份或者备份程序不完备123.6.4没有确保应用日志可

3、以长时间保存的流程123.6.5敏感数据未经修改地直接导入测试环境123.7代码安全123.7.1应用的进程在终止前没有从内存或者磁盘中删除临时对象123.7.2应用没有充分验证用户输入123.7.3应用直接暴露出错信息133.7.4应用失败能够导致不安全的状态131. 应用系统评估概述1.1 评估的概念应用系统评估，是风险评估中必须的一个子项。它是指将应用系统作为一个单位，对该应用系统所面临的脆弱性、安全隐患进行检查的过程。应用系统评估和网络架构评估、网络访问控制评估、数据流评估等不同，它关注的是应用系统的自身的安全，主要从“应用代码或程序”层面进行评估。111.2 评估手段在应用系统安全评

4、估中，应尽可能采用以下多种方式，对应用系统进行全面的安全检测。如果某些情况下，有些方式不能采用或无法实现，比如源代码审核、配置文件检查等，可考虑通过其他方式来进行验证其现状，比如渗透测试。1) 应用系统文档检查检查应用系统的开发和维护文档，特别注意其中的和安全相关的部分。2) 评估访谈和应用系统的开发人员、系统管理员、普通用户（抽查）进行访谈，了解系统的在开发和使用过程中的详细信息。如果回答否，则结果为否；若回答是，则应尽可能实际上机验证。访谈前，评估人员需根据系统的情况，准备对应的访谈表。3) Checklist检查根据应用系统的操作系统，对应相应的checklist检查项，对应用系统进行安

5、全检查。检查时，可以手工逐项检查，也可以过脚本的方式快速检查。4) 渗透测试对于某些应用系统，在授权的情况下可以适当采用的渗透测试，来检验系统的安全性。比如针对Web网站，可以进行SQL注入、XSS、数据库、暴力破解等渗透测试攻击手段。5) 系统配置状况检查登陆系统，对系统配置进行安全检查。2. 评估前的准备为保证在用户现场的工作效率，评估前应作好以下准备工作。2.1 确定用户配合人员和用户确定能够配合评估工作的人员，需要具有以下能力：l 了解应用系统，能够有效回答评估者的询问；l 能够提供对源代码的访问，并协助分析源代码；l 能够提供应用系统相关的开发、维护文档；l 能够提供超级用户权限的访

6、问界面；l 能够提供普通用户权限的访问界面；最终确定的配合人员，一般包括：系统开发人员、系统管理员、普通用户。2.2 确定评估的范围和用户确定本次应用系统评估的范围，需落实到具体的服务器、应用、软件等。2.3 获得应用系统组件的清单获得应用系统架构范围内的所有组件清单，包括网络拓扑图、IP地址、OS版本、数据库、APP版本、第三方中间件版本、库文件或者其他组件等。2.4 应用系统评估启动会可以考虑召开应用系统评估的启动会，会上由系统开发人员、系统管理员介绍应用系统的基本情况，包括应用系统的基本功能、组件架构、部署情况、使用对象、安全设计思想、业务流程等。同时，通过启动会，也可能获得更多与该应用

7、系统相关的各种技术文档。2.5 签署应用系统评估申请在应用系统评估实施之前，应向用户提交并签署应用系统安全评估申请，以确保用户认可以下问题：l 接受评估过程中可能带来的操作风险；l 对物理、逻辑访问用户应用系统的授权。3. 具体评估步骤通常情况下，对应用系统的评估，应从以下7个方面进行。1) 认证和鉴别2) 用户账户管理3) 数据保护4) 安全审核5) 应用操作6) 影响控制7) 代码安全3.1 认证和鉴别这部分主要测试用户或者进程如何进行身份认证。首先应该识别出应用系统中所有涉及认证和鉴别的行为，然后对它们逐个进行测试。本文主要介绍基于PKI的认证和鉴别测试，如果应用系统使用其他的认证和鉴别

8、方式，可以比照执行。3.1.1 是否启用了PKI检查应用系统是否启用了PKI，如果没有启用，则纪录之。如果说启用，那么对使用了PKI的组件进行实际验证。3.1.2 是否启用了组织统一要求的PKI如果配合人员说“是”，那么进行实际验证。3.1.3 认证进程是否适当列出应用系统中所有客户认证进程的清单，包括Application Server与数据库服务器也构成client/sever关系。认证方式一般有：操作系统、数据库、目录服务、认证设备等。通过查看配置文件、手工测试等方式来验证在认证过程中，是否存在以下问题：l 只使用用户名，不需要口令；l 是否有口令复杂性的策略要求；l 是否有帐户锁定的策

9、略；l 用户口令不能更改；3.2 用户账户管理这部分主要检查保存的用户账户可能存在的安全弱点。首先识别应用系统中用户ID保存在哪里。有些应用系统的用户ID可能保存在多个地方。如果应用系统使用操作系统、数据库的内置账户，那么这部分应该在主机或者数据库安全性评估中已经进行，这里可以标记为NA。3.2.1 用户ID唯一性检查把用户按ID排序，检查是否存在ID重复的情况。把用户按姓名排序，检查是否存在一个姓名多ID的情况。3.2.2 不活动用户是否禁用超过90天没有登陆的用户，是否禁用？3.2.3 不必要的内置用户是否禁用如果common commercial off-the-shelf (COTS)

10、的软件，使用的内置用户，在其他评估中，已经进行了评估，那么这部分可以忽略。需要注意这些不必要的内置用户是否必要？尤其当它们是超级用户的时候。3.2.4 用户ID是否有默认的或者弱口令应该尝试应用系统广为人知的默认口令。或者使用brute force进行弱口令暴力破解。3.3 数据保护本部分主要检查数据在存储、传输过程中的安全性、加密算法的问题。3.3.1 敏感数据不适当地存储敏感数据需要有适当的权限保护，只有管理员、应用或者操作系统进程有权限进行读写。对于账户数据库的本地备份，也应该检查其权限设置。其他用户对敏感数据、尤其是用户账户数据文件的读或者写，都是危险的。可以参考passwdshado

11、w的权限设置。口令需要被加密，可以查看配置文件是否启用了加密功能。如果认证数据是可读的，看看它是否明文，或者脆弱的加密方式。也可以审核源代码，检查对加密函数的过程调用，启用了什么样的加密功能。如果应用系统中使用key进行认证，列出server中key的清单，并抽样检查。注意key文件的权限，一般用户或者进程不应该有写的权限。识别是否有不必要的用户或者应用进程（它在用户的背后读）对keys有读的权限。对于非公开的用户数据，询问配合人员它们存储在何处，及如何保护。用户的权限不应该超过最小授权的原则。注意全局权限，或者非管理员的组权限。3.3.2 敏感数据传输中没有适当的保护数据可以分成可以分成I&

12、A和非I&A数据。所有的I&A数据在存储、传输过程中必须进行加密。检查系统是否使用telnet、ftp、basic http等协议进行明文验证。如果是，那么是否在低层次的协议中进行了加密？比如IPSEC、L2TP、PPTP或者链路层加密。如果应用和数据库在同一台机器上，那么传输过程中无需加密。对于非I&A数据，也应该根据重要性、是在内网还是internet传输，来考虑其安全性。3.3.3 使用未经验证的加密算法列出应用系统中所有使用加密组件的清单，比如文件加密、VPN、SSH等。检查是否使用了未经验证的加密算法。这样的加密算法，安全性无法保证。3.4 安全审核3.4.1 安全相关事件记录对于以

13、下安全相关的事件，应该有详细的纪录：l 启动和关闭；l 认证事件；l 授权用户对数据的受控访问；l 不成功的访问企图；l 删除数据；l 应用配置更改；3.4.2 日志将满没有警告检查应用文档或者询问用户是否有此功能？通过配置文件确认之。3.4.3 日志存在未授权删除、修改、泄露等漏洞检查日志文件的权限，是否存在以上问题。3.5 应用操作3.5.1 基于角色的访问控制没有加强责任分离应该考虑以下分离：l 日志管理者其他管理者；l 设置访问控制规则的人员访问数据、编写程序的人员；如果应用中实施了分开，则可能使用的安全配置界面不同，或者使用不同的账号登陆。3.5.2 应用在执行操作之前没有进行授权授

14、权机制可能包括文件权限、数据库、应用代码等。如果是在应用代码中，让开发者locate to相关代码，细细检查。如果使用文件权限、数据库的方式，注意Everyone、 world、 public、guest等用户或者组。3.5.3 进程运行的权限过高识别应用运行使用的账户。l Windows中可以在“服务”中查看；l Unix在ps ef；l n-tier结构，可能看连接数据库所使用的账户。如果使用administrator、uid=0、sa或者system等权限，都是安全隐患。搜索文件系统，看看有没有以运行进程所使用的用户为所有者的文件或者目录。若有，则它能改写这些文件了。3.5.4 应用没有

15、对session的限制询问配合人员每个用户或者进程ID会话数目的限制；以及会话空闲的最大时间。可以检查配置文件、源代码进行验证。许多时候，配置文件、源代码可能都看不到。这些和DoS攻击有关。有时候测试会比较困难，比如idle limits太长；这也可以作为一个结果记录下来。3.5.5 应用修改在应用的范围之外的文件搜索最近一周、一天内修改过的文件。看看有没有在应用的范围之外的文件。3.5.6 用户绕过用户界面直接修改资源检查系统开放的服务、防火墙或者路由器的访问控制措施，从而确定“威胁界面”的大小。如果是Web应用，可以尝试是否存在授权机制绕过的问题。可以询问管理员是否存在直接修改数据库的问题

16、。3.6 影响控制3.6.1 网络架构不适当应该通过DMZ、内部访问控制等措施，减小应用中一台服务器被攻击对其他系统的影响。3.6.2 没有灾难恢复计划如果该应用是整个灾难恢复计划中的一部分，确保计划中包含详细的指导。3.6.3 备份或者备份程序不完备确保对应用数据、底层OS和应用组件都进行了备份。3.6.4 没有确保应用日志可以长时间保存的流程建议保存至少半年以上。3.6.5 敏感数据未经修改地直接导入测试环境敏感数据，必须修改后，才能在测试环境中运行。3.7 代码安全这部分检查都需要审视应用代码，并且最好在测试系统上进行验证。3.7.1 应用的进程在终止前没有从内存或者磁盘中删除临时对象应

17、该从内存中释放临时对象，也应该保证数据库的连接被关闭。可以进入程序进行选定的动作，然后退出，搜索最新创建的文件。在windows下，可以使用搜索。在unix下：# touch -t 200301211020 /tmp/testdatefile# find / -newer /tmp/testdatefile3.7.2 应用没有充分验证用户输入询问配合人员应用的测试计划。检查测试计划中包含对无效输入的检查，包括脚本标签、查询字串、SQL命令、无效的数据类型和大小等。可以进行查询字串伪造、脚本嵌入、SQL injection、无效的输入大小或者类型等等攻击。划中是否包含了对缓冲区溢出的测试。可以输入大量的数据进行测试：l 在数字字段输入非常巨大的数字；l 正数、负数测试；l 对文本字段进行超过1M数据的输入；l 对于web的查询字符串，至少输入500个字符；如果出错，说明没有进行边界检查。3.7.3 应用直接暴露出错信息应用应该有出错处理进程，不能仅仅依赖内部系统的错误处理功能。如果应用不处理错误，而仅仅被底层系统处理，这是一个问题。尤其是，错误信息中不能包含变量名、变量类型、SQL字串、或者源代码等。这会导致进一步的攻击。3.7.4 应用失败能够导致不安全的状态检查测试计划中是否包含了对应用失效的测试。CSNA论坛 菜鸟人飞2011年7月