先列一下安全测试设计的技能列表（本内容来源于网络，经过自己整理和亲身体会，挑出了感觉对自己有帮助的技能供大家参考）：
A、前期
1、了解什么是hacker，这点看似没什么关系，但作为测试最基本的素质，就是要”换位思考“，你要明白应该以什么角色去测试要负责的系统；搞明白hacker的基本行为模式和动机，可以更好的帮我们制定出消减威胁的措施和方案；
2、一些基础命令，包括DOS命令，以及UNIX / Linux下的命令。
3、远程扫描、远程刺探技术。包括通过系统自带命令的信息刺探以及使用工具扫描等。
4、密码破解。了解现在的密码破解的适用范围，以及操作技巧等等。
5、溢出攻击。溢出工具的使用方法。
6、注入攻击。注入攻击只是一个简称，这里还要包括XSS、旁注、远程包含等一系列脚本攻击技巧。
7、学会各种编译工具的使用方法，能编译ShellCode。
8、学会手动查杀任何木马、病毒，学会分析Windows操作系统，以使自己百毒不侵。
B、中期
1、学习所有Windows下服务器的搭建步骤（ASP、PHP、JSP）。
2、掌握例如Google hacker、cookies 、网络钓鱼、社会工程学等。
3、学习HTML、JavaScript、VBScript。
4、学习标准SQL语言，以及大多数数据库的使用。
5、学习ASP，并拥有发掘ASP脚本漏洞的能力。
6、学习PHP，并拥有发掘PHP脚本漏洞的能力。
7、学习JSP，并拥有发掘JSP脚本漏洞的能力。
8、学习掌握最新脚本的特性以及发掘漏洞的方法。
C、后期
1、确定自己的发展方向
2、学习C语言，并尝试改写一些已公布的ShellCode。
3、学习C++，尝试编写一个属于自己的木马（如果你想自己编写木马的话）。
4、学习汇编
5、研究Linux系统内核。
6、学习缓冲区溢出利用技术。
7、ShellCode技术。
8、堆溢出利用技术、格式化串漏洞利用技术、内核溢出利用技术、漏洞发掘分析。
(如果觉得有什么不对或者纰漏，还望各位不吝赐教)
*下面是后文要用到的术语说明和解释：
|
名词 |
解释 |
| 分类 |
针对测试点的测试优先级分类，分为S1，S2，S3三类： S1类为必须满足的，是核心功能，如果没有此功能产品不可用或存在重大安全隐患； S2类为竞争类需求，这些需求的实现能提升产品的竞争力，满足大部分客户的安全需求； S3类为优势类需求，这些需求的实现能使我们的产品比竞争对手的产品更具安全优势 |
| 不满足原因 | 如果不满足，需要写清楚不满足的原因；如果是部分满足，需要写清楚哪些是满足的，哪些是不满足，不满足的具体原因是什么； |
| 测试结果定义分类 | 根据测试结果对满足度进行说明，值为“满足”、“部分满足”、“不满足”、“未测试”、“不涉及” |
| 操作员帐号 | 业务系统分配给局方或者厂家人员用于对本业务系统进行业务运作、系统管理以及维护的帐号，如营业厅操作员的帐号等。 |
| 程序帐号 | 由程序使用的帐号，例如在某程序中实现SFTP自动传输文件的功能，那么在这段程序中使用的、为了实现SFTP自动登录的帐号即为程序帐号。 |
| 最终用户帐号 | 属于业务范畴的帐号，如手机号、eMail 用户帐号等。 |
| 安全敏感国家 |
指美国、加拿大、澳大利亚、新西兰、瑞士和EEA欧洲经济区，包括这些敏感国家的海外领土和属地。 其中，当前EEA经济区覆盖30个欧洲国家，包括：法国、意大利、荷兰、比利时、卢森堡、联邦德国、爱尔兰、丹麦、英国、希腊、葡萄牙 、西班牙、奥地利、芬兰、瑞典、波兰、拉脱维亚、立陶宛、爱沙尼亚、匈牙利、捷克、斯洛伐克、斯洛文尼亚、马耳他、塞浦路斯、保加利亚、罗马尼亚、挪威、冰岛、列支敦士登。 |
| 贸易禁运国 |
目前贸易合规领域最需要关注的区域主要是美国定义的禁运国家，包括： 伊朗，北苏丹；古巴；叙利亚；北朝鲜 |
| 客户网络数据 |
指所有权归属客户或第三方的、来源于客户网络或者与客户网络特征有关的数据，包括：来源于客户网络的个人数据、客户网络规划数据、客户网络运行数据、客户网络运营管理数据、客户网络技术服务数据、客户网络安全方案数据、客户网络资源数据等。客户网络含客户测试网络、客户商用前网络、客户商用网络。从法律角度来看，未经客户授权接入访问客户网络数据或超出客户授权范围，采集、转移、存储、使用和处置上述网络数据可能会构成侵权或违约。
不在上述定义范围内的来源于客户的其他数据，如客户经营管理制度、客户培训资料、客户项目运营流程及规定等，需遵从双方保密协议要求、当地商业秘密保护相关法律法规来收集、处理和保存。 |
| 原始通信内容 | 通信双方（只要其中一方涉及自然人）之间的实际通信内容，包括语音类、短信/彩信类、传真类、数据业务（如即时消息、Email、视频通信、网页浏览等）类等 |
| 合法监听敏感信息 | 指合法监听相关的事件信息，如监听目标（通信参与方）、监听时间、通信时间、通信时长等，不包括通信内容 |
| 非信任网络 | 信任网络与非信任网络通常是相对而言的，信任网络通常是指对该网络内的所有设备和用户的行为是可信的网络，如同一信任域内的设备，非信任网络则通常指该网络内的设备和用户行为不可控或存在较大安全风险的网络，如Internet、intranet、与第三方SP/CP的接口等 |
| 匿名化 | 指对个人数据进行的更改（例如单向散列、截短、替换等，如需保留个人数据真实值与替换值之间的对应关系，可以使用对称加密或映射表方式，但密钥/映射表必须由产产品对应的客户控制），使原来有关个人的信息不再能归属到一个可识别的自然人，或推理这种归属需要耗费过多、不相称的时间、费用和精力。来源：《德国个人数据保护法》 |
| 安全删除 | 指对数据删除之后不可恢复，或者恢复需要付出过多、不相称的时间、费用和精力。例如：对RAM（内存）用新的数据覆盖或下电；对磁盘分区进行低格、对磁盘文件重写三次或以上、对磁盘进行消磁、粉碎；对CD进行物理粉碎等。来源：参考德国合作项目顾问建议 |
| 未公开接口 | 可绕过系统安全机制（认证、权限控制、日志记录等）对系统或数据进行访问的功能（如客户无法管理的固定口令/隐藏账号机制、不记录日志的非查询操作等）及产品资料中未向客户公开的命令/外部接口（如隐藏命令/参数、隐藏端口等接入方式） |
| 远程访问 | 通过Internet或局域网远距离访问设备的接入方式 |
| 受限公开 | 对于涉及产品知识产权、高危操作、可外部调用的内部接口等不期望向所有客户人员公开的内容，不在正式发布的面向所有客户的产品资料中公开，仅主动向客户/政府特定人员公开或仅在客户要求时再公开（与客户签署保密协议），以规避因实现细节过度公开而导致的安全风险。在正式发布的面向客户的产品资料中需注明受限公开资料的获取方式/途径。 |
| 增值服务 | 欧盟2002年58号文——任何要求对数据流（traffic data）或数据流以外的位置数据进行处理的服务，不包括为了必要的通信传输和计费目的所需要处理的数据流。 |
| CPI资料 | Customer Product Information，交付给客户的产品资料包。 |
| 身份认证 |
验证用户身份的真实性。认证方法有基于用户所知道的、基于用户所拥有的、基于用户个人特征。 常见的用户身份认证有：口令认证、智能卡认证、动态口令认证、数字证书认证、生物特征认证等。 |
| 个人数据 | 单独使用该数据或者结合其他信息可以识别某个活着的自然人的数据，包括：最终用户姓名、账号、主叫和被叫号码、通信记录、话单、通信时间、定位数据、即时消息、好友关系、在网盘上存储的个人文件（相片、音频、视频、记事本）等。在法律上，判断某类信息是否是个人数据不是绝对的，必须结合场景与处理目的来判断。 |
| SSL 协议 |
SSL(Secure Socket Layer) 位于应用层和传输层之间，它可以为任何基于 TCP 等可靠连接的应用层协议提供安全性保证。 SSL 协议实现的安全机制包括： 1、 数据传输的机密性：利用对称密钥算法对传输的数据进行加密。 2、 身份认证机制：基于证书利用数字签名方法对服务器和客户端进行身份验证，其中客户端的身份认证是可选的。 3、 消息完整性验证：消息传输过程中使用基于 MD5 或 SHA 的 MAC 算法来检验消息的完整性。 |
| TLS 协议 |
TLS 协议设计的具体目标是解决两个通信实体之间的数据的保密性和完整性等，总体目标是为了在因特网上统一 SSL 的标准。因此，在协议构成方面，TLS 几乎与SSL协议一样，主要分为 TLS 记录协议与TLS握手协议。TLS 记录协议与 SSL 记录协议基本一致，字段的内容也基本相同。TLS 记录协议也有4种类型的客户：握手协议、警告协议、改变密码规格协议和应用数据协议等。为了便于 TLS 的扩展，TLS 记录协议还支持额外的记录类型。 TLS 建立会话协商的参数、握手协议过程等与 SSL 一致。 |
| 加密协议 | FTP、HTTP、Telnet 协议都是以明文传输的应用层协议，传输过程中存在被窃听的安全隐患，SFTP/FTPS、HTTPS、SSH 是分别与之对应的加密应用层协议。 |
| 初始密钥 | 用来导出主密钥的密钥。一般为操作员输入或者写死在代码中，写死在代码中时必须遵循本基线中“加密解密”相关的要求。公司开发的加密库，其中包含了密钥导出函数：PKCS5-deriveKey(…)，可以直接调用该函数导出加密的密钥。Java 中请参考类 PBEKeySpec。 |
| 主密钥 | 用来加密（使用对称算法）工作密钥的密钥。一般是使用密钥导出算法对初始密钥进行计算而得出。某些场景下，主密钥就是工作密钥，但一般不建议。 |
| 工作密钥 | 用来加密（使用对称算法或者 HMAC 算法）业务中敏感数据的密钥。一般是随机生成的。某些场景下，是由用户/操作员输入、然后使用密钥导出算法计算得到。 |
| 敏感数据 | 敏感数据的具体范围取决于产品具体的应用场景，产品应根据风险进行分析和判断。典型的敏感数据包括口令、银行帐号、大批量个人数据、用户通信内容和密钥等。 |
| 个人数据 |
单独使用该数据或者结合其他信息可以识别某个活着的自然人的数据，包括：最终用户姓名、账号、主叫和被叫号码、通信记录、话单、通信时间、定位数据、即时消息、好友关系、在网盘上存储的个人文件（相片、音频、视频、记事本）等。在法律上，判断某类信息是否是个人数据不是绝对的，必须结合场景与处理目的来判断。 比如系统同时采集如下几种信息： 1.联系信息：姓名、email、电话、住址、账单地址等 2.唯一标识：身份证号、社保号、驾照、指纹、护照 3.统计信息：年龄、性别、种族、宗教信仰、犯罪记录 4.职业信息：公司、行业、工作头衔 5.医疗保健信息：计划、供应商、历史、保险、遗传信息 6.金融信息：银行、信用卡银行卡、购买记录、信用记录 7.在线活动信息：IP地址、cookie、网页浏览数据、用户联系人名单、登录的信任状等 8.种族、民族 9.政治观点 10.宗教信仰 11.身体、精神健康状况 12.性取向 13.犯罪史 14.是否有被诉讼记录 |
| EEA | EEA（欧盟经济保护区）：当前EEA经济区覆盖30个欧洲国家，包括：法国、意大利、荷兰、比利时、卢森堡、联邦德国、爱尔兰、丹麦、英国、希腊、葡萄牙 、西班牙、奥地利、芬兰、瑞典、波兰、拉脱维亚、立陶宛、爱沙尼亚、匈牙利、捷克、斯洛伐克、斯洛文尼亚、马耳他、塞浦路斯、保加利亚、罗马尼亚、挪威、冰岛、列支敦士登。 |
| PAN | Primary Account Number:主账号 |
| SNMP团体串 | 起密码作用的文本串，用于鉴权在管理站点和SNMP代理之间的信息发送。存在于SNMP管理和SNMP代理之间传送的数据包里 |
| 强加密 | 强加密算法是基于业界测试和接受的算法，并具有强密钥长度及正确的密钥管理措施。目前业界接受的加密算法标准有：AES（128位及更高版本），TDES（最小双长度密钥），RSA（1024及更高版本），ECC（192位及更高版本，ElGamal（1024位及更高版本）。 |
应用安全测试设计
*写作格式说明
一、父类需求分类
1. 次级需求分类：该子类需求的解释（这里附需求“分类”，参考上表第一条）
（1）该类需求的测试细化点一（附可能引入的最早阶段）
（2）该类需求的测试细化点二（附可能引入的最早阶段）
tips：如果该细化点设计思路较难、会给出一些我自己思考或网上搜集整理的解决办法，以及相关的工具、技术参考等等。
一、账号管理
1. 账号唯一性：系统中的帐号名称具有唯一性（S1类）
（1）操作员帐号、程序帐号、最终用户帐号唯一；（引入阶段：设计）
（2）是否有可能绕过系统的账号唯一性校验；（引入阶段：设计和开发）
tips：
开启webscarab/burpsuit/fiddler之类的代理工具；
访问账号注册/创建界面；
篡改通过页面校验的新账号为其它已存在账号、然后放通，看能占用已存在账号的权限并使用自己创建的密码。
2. 帐号不能写死在代码中，须提供可管理（或配置）机制。（引入阶段：设计和开发）
tips：
通过访谈获取开发常用账号定义关键字；收集产品常用账号；打开Search and Replace，使用前两步中的关键字搜索代码，根据搜索结果分析是否存在硬编码账号。任何实际帐号都不能写死在代码中，所有账号均可管理（或可配置）；
二. 身份认证：
1. 当用户访问受限资源或请求需要鉴权的操作时，必须先对提出该操作请求的用户成功地进行认证（引入阶段：设计）
检查应用程序是否提供认证机制（例如：用户名/口令认证、密钥认证、证书认证、智能卡认证、USB Key认证、动态口令认证、生物特征认证、IP认证等）来保护受限访问的资源。最典型的认证措施就是：提供登录界面/页面，需要访问者输入用户名、口令[、验证码]，身份认证通过后，才能访问系统的受限资源。
2. 身份认证必须在服务端进行（引入阶段：设计和开发）
（1）对于C/S软件系统的用户最终认证处理过程放到服务端进行。此处“客户端/服务端”软件系统是相对于单机版软件系统而言的。不允许以客户端验证的结果作为用户最终认证结果，必须在服务端进行最终的认证处理（如果采用集中认证，那么对用户的最终认证就是放在集中认证服务端进行）。
（2）B/S 应用中，对用户的最终认证处理过程不允许仅仅通过脚本或其他形式在客户端进行验证，必须在应用服务器进行最终认证处理（如果采用集中认证，那么对用户的最终认证就是放在集中认证服务器进行）。
tips：设计思路如下：
○在未连接服务器端的情况下是否能认证成功；
○
在客户端提交正确的账号口令，但是拦截不发送到服务器端，是否能认证成功；
○
分析整个认证过程，在客户端提交正确账号口令，但是拦截后发送错误的账号口令到服务器端，但模拟服务器回复正确的登录请求给客户端，观察客户端功能是否开启
○
分析整个认证过程，只发送最后一步消息提交到服务器端，观察认证是否通过
○
分析整个认证过程，观察是否有可利用之处
（好吧，这句纯粹为了凑字数…请大家帮忙补充^_^）
（3）服务器端的认证不能被客户端关闭
tips：用burpsuite截取到的码流如果存在的非用户名口令验证码以外的字段：无论删除或是修改这些字段都不会影响服务器认证
3. 认证失败不能提示详细错误原因（操作员帐号、最终用户帐号都要检查）
tips：可以提示：“用户名或者口令错误，登录失败”；不能提示：“用户名不存在”、“口令错误”等等。
4. 为了防止暴力破解，必须使用验证码；且验证码是随用户名、密码同时提交到服务器端进行校验。
tips：或者多次登录失败后，必须提供验证码。说明：要参照下文的“
锁定策略
”，验证码和锁定策略都没有的情况才会成为安全问题。
这里容易漏测的地方是控制台。如果该系统的控制台有必要启用，则必须满足本文提到的所有安全策略。
5. 验证码的机器识别率必须低于5%（现在网上有许多开源的验证码识别工具，可以尝试一下）
6. 3次登录/认证失败后使用验证码时，原认证表单失效
tips：此测试点仅针对”多次登录失败后，才提供验证码”场景
1、启动burpsuite，并配置get和post请求的拦截；
2、访问登录/认证界面，输入正确的帐号错误的密码提交；
3、将WebScarab/burpsuite_v1.4.01拦截的表单内容记录下来，并点击“Accept Changes”放通（此时拦截信息不包含验证码）；
4、错误访问三次之后，登录/认证界面弹出验证码；
5、使用WebScarab/burpsuite_v1.4.01拦截，并将内容替换成步骤3中记录下来的表单内容，修改错误的密码为正确的密码，点击“Accept Changes”
备注：本用例属于产品必须根据实际情况定制的用例，用例设计思路如下：
1、继续使用原来不带验证码的消息；
2、客户端清空错误次数；
3、绕过业务处理错误次数的客户端参数（如部分产品根据session、ip等记录错误提交次数，可以通过设置session、ip为变量绕过这一判断）
4、拦截次数刷新请求（如部分产品通过客户端提交单独的错误次数，或者错误次数达到了由客户端提交申请旧登录请求失败/新登录请求生效的消息）
7. 验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现（引入阶段：开发）
验证码模块生成的随机数不能在客户端的静态页面中的网页源代码里出现。在客户端网页上点击鼠标右键、选择“查看源文件”时，必须看不到验证码模块生成的随机数。
8. 验证码内容不能与客户端提交信息相关联
验证码内容不能与客户端提交的任何信息相关联。在使用验证码生成模块时不允许接收来自客户端的任何参数，例如：禁止通过getcode.jsp?code=1234 的 URL 请求，将 1234 作为验证码随机数。
9. 验证码字符串要求是随机生成（对于 java 语言可以使用类 java.security.SecureRandom 来生成安全的随机数。）
10. 验证码在一次使用后立即失效
11. 验证码检验通过后才进行用户名和密码的检验
tips：
1、访问所有带有验证码的登录页面；
2、开启WebScarab，配置对GET、POST和PUT请求及响应进行拦截（即同时勾选“intercept requests”和“intercept respones）；并在浏览器中配置代理服务器IP为127.0.0.1，端口为8008；
3、填入错误的用户名和口令，填入错误的验证码，提交表单；
4、查看系统响应消息及返回的提示信息。
三. 强口令策略
1. 口令长度应可配；（引入阶段：设计）
2. 口令包含的字符、也就是复杂度可配；（引入阶段：设计和开发）
3. 修改自己的口令需验证旧口令；（引入阶段：设计和开发）
4. 界面上的口令不能明文显示；（引入阶段：设计和开发）
tips：这里的明文不光指文本框里面，还包括页面源代码和浏览器/客户端的内存中。可以用内存查看工具检测。
5. 口令输入框不支持拷出功能；（引入阶段：设计和开发）
6. 口令在本地存储时必须加密；（引入阶段：设计和开发）
7. 存储口令的文件/数据库表用户的访问权限控制；（引入阶段：设计和开发）
8. 提供账号口令清单；（引入阶段：资料和开发）
9. 在 B/S 应用中，从服务器端的会话信息中获取修改口令的用户帐号（引入阶段：设计和开发）
tips：也就是说，修改口令的帐号只能从服务器端的会话信息中获取，而不能由客户端指定。可以分析WebScarab拦截的修改口令的请求中是否包含操作员帐号和可能被猜解的身份标识。
10. 非运营商需求中明确要求有修改其它账号权限的超级管理员账号不可以修改其它账号的密码（引入阶段：设计和开发）
11. 操作员不可修改自身帐号以外帐号的口令（引入阶段：设计和开发）
12. 口令不能和用户名相同（引入阶段：设计和开发）
13. 内置账号口令管理（引入阶段：设计、资料和开发）
tips：
1、收集应用所使用的所有内置账号（系统初始化安装后所存在的帐号，包括OS、DB、应用本身的初始帐号等等。）
2、检查所有内置帐号的缺省口令是否符合复杂度的要求（是否满足口令长度、口令包含字符、口令不能和用户名相同、等等基本要求）。
3、检查客户资料中是否提醒用户修改。
四. 会话管理（引入阶段：开发）
1. 防止会话固定：在 B/S 应用中，用户名和口令认证通过后，必须更换会话标识，以防止会话固定（session fixation）漏洞。
tips：
1、启动burpsuite，并配置对GET、POST和PUT请求进行拦截；
2、访问登录页面，输入用户名、口令、验证码，登录，通过burpsuite拦截登录请求，查看并记录其中的jsessionid信息；
3、登录成功后，再访问任意功能菜单，并通过burpsuite拦截登录请求，查看并记录其中的jsessionid信息；
4、比较步骤2和步骤3获得的jsessionid是否一致。（也就是登录前和登录后，会话标识是否一致）。
2. 会话中不允许修改的信息作为会话状态的一部分在服务器端存储和维护
说明：在 B/S 应用中，会话过程中不允许修改的信息，必须作为会话状态的一部分在服务器端存储和维护。会话过程中不允许修改的信息，例如，当用户通过认证后，其用户标识在整个会话过程中不能被篡改。禁止通过隐藏域或URL重写等不安全的方式存储和维护。对 JSP 语言，就是应该通过 session 对象进行存储和维护。
tips：
1、登录系统；
2、逐个访问各功能菜单，查看URL或页面源文件（以hidden关键字，在源文件中查找隐藏域）是否包含用户标识、商品价格等不允许客户端修改的信息；
3、尝试通过burpsuite拦截并修改步骤2发现的不允许客户端修改的信息（比如：把用户标识改为其他用户，或者把商品价格改为低价格），然后提交给服务器；
4、查看后台数据库的相关数据，检查步骤3的篡改是否起作用。
注：咨询开发设计，会话中除session以外的信息的用途，并尝试会话中除session以外的所有信息。
四. 认证失败后处理（引入阶段：设计）
1. 连续登录失败锁定帐号
注：如果已经做了验证码防止帐号口令的暴力破解，那么，不强制遵循本条要求。
2. 连续登录失败锁定策略的“允许连续失败的次数”可配置
3. 连续失败次数指同一个帐号从最后一次登录成功以来登录失败的次数的累积值
tips：
1、连续N-1次使用错误的口令登录使帐号锁定；
2、使用另一个账号口令正常登录业务系统并退出；
3、使用步骤1中的账号再次错误登录
4、使用另外一台机器，尝试登录步骤1中的账号
4. 锁定时长可配置
5. 连续登录失败锁定策略执行并在锁定时间超时后自动解锁（在锁定时间内，仅能允许应用安全管理员角色所属帐号手动解锁该用户）
五. 权限鉴别
（
引入阶段：设计和开发
）
1. 纵向越权防范：可以从以下几个方面考虑
在 B/S 应用中，对于每一个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是否合法、用户是否被授权执行这个操作，以防止URL越权。防止用户通过直接输入URL，越权请求并执行一些页面或servlet。
（1）基于URL链接的纵向越权
（2）基于页面文件的纵向越权
（3）基于action、dwr等其他形式的的纵向越权
（4）通过客户端修改权限控制字段：
针对B/S和C/S的Web应用：
·以超级管理员/高级用户身份登录应用系统；
·启动burpsuite，并配置对GET、POST请求进行拦截；
·访问一些低级用户没有权限访问的资源，检查burpsuite拦截下来的请求中是否存在可能代表权限的参数，将这些参数和参数值及该资源的URL链接记录下来；（如http://www.example.com/modify.do，它的参数里面有类似privilege、privilegecode、userid、id、level、levelid等等都有可能是权限控制字段，部分产品的权限控制字段或用户关键标识信息可能在Cookie中）
·访问一些低级用户没有权限访问（主要是低级用户不可见）的资源，检查burpsuite拦截下来的请求中是否存在可能代表这些资源标识的参数（如低级用户可见的资源为http://www.example.com/viewbook.do，不可见的资源为http://www.example.com/modifybook.do，这是用URL本身来标识资源。如http://www.example.com/book.do?op=modify，这是用op参数来标识资源，常见可疑参数类似menu、menuid、action、res、resource、interface等等），将这些参数及参数值记录下来；
·停止burpsuite拦截功能；
·超级管理员/高级用户退出应用系统的登录；
·以低级用户身份登录应用系统；
·启动burpsuite，并配置对GET、POST请求进行拦截；
·访问应用系统任意资源，在burpsuite拦截的请求中，修改URL地址为步骤3中的URL地址，修改/构造可能代表权限的字段为步骤3中的权限字段的值（如level的参数值由2修改为0），检查低级用户是否能成功访问这些资源；
·访问应用系统任意资源，在burpsuite拦截的请求中，修改URL地址为步骤4中的URL地址，修改/构造可能代表权限的字段为步骤4中的权限字段的值，检查低级用户是否能成功访问这些资源
注：不用记录步骤7之前的cookie中的session，可以尝试修改cookie中代理权限和用户级别的字段，但本测试不需要将步骤7之前的session/jsession覆盖步骤7之后的request中。
（5）绕过按键/页面元素限制的纵向越权：查找系统中是否存在管理员可用而在普通用户页面中为灰色(不可用)的按键/页面元素。如有，将对应的按键/页面元素源代码改为可用，此时页面上对应的按键/页面元素即变为可用、再正常使用此按键/页面元素,查看服务器是否响应普通用户的越权请求。
2. 横向越权防范 （横向越权，例如：部门经理A和B分别只能查看部门A和B内部人员的信息，部门经理A查询部门人员A1的信息，提交的参数包含A1的工号A001，这时，部门经理A将A001改为B001（部门B的员工工号），越权访问B部门人员的信息，这就是横向越权。）
六. 禁止使用未向客户公开的接口
（
引入阶段：设计和开发
）
1. 禁止留有后门：禁止存在可绕过系统安全机制（认证、权限控制、日志记录）对系统或数据进行访问的功能。
tips：
1、查看系统的设计文档、用户手册，检查系统存在可绕过系统安全机制（认证、权限控制、日志记录）对系统或数据进行访问的功能。
2、结合开发人员的访谈，检查系统是否存在可绕过系统安全机制（认证、权限控制、日志记录）对系统或数据进行访问的功能，例如：固定密码、隐藏帐户、隐藏命令、隐藏参数、隐藏软参，隐藏接口、调试端口/命令等。
*这点对于测试来讲实际操作起来有些困难，尤其是对于不懂编程的测试员，很容易漏测。大家有什么好的方法可以补充。
（1）禁止空口令
（2）对后台命令、命令行工具、重要文件增加权限控制及管理机制
（3）基于URL链接的绕过安全机制对系统或数据访问
（4）基于页面文件的绕过安全机制对系统或数据访问
tips：
此测试点根据不同Web控制台Web应用存放目录不同，以下以JBOSS为例：
该应用发布两种服务http://IP:PORT/Web应用/***.***
http://IP:PORT/monitor/test.html
1、登录Web服务器后台，访问Web应用所在的目录
~/jboss/server/default/deploy/smap.ear>ls
default.war META-INF monitor.war
其中deploy下smap.ear为产品应用，default.war和 monitor.war目录分别存放以上两个URL使用到的文件，http://IP:PORT/monitor/test.html中monitor为服务名，后面的test.html可被替换拼接URL，
http://IP:PORT/frameset/login.action的服务名为空，拼接URL时直接替换frameset/login.action
2、查找default.war和 monitor.war目录以及其子目录存在的文件（find . -name “*html”，蓝色字体可替换为*bat,*dat，*lic等 ）
3、根据查询到的文件列表，尝试构造通过Web访问的URL，不经登录直接通过预览器访问这些文件：
a.~/jboss/server/default/deploy/smap.ear/monitor.war>ls
db.jsp test.html WEB-INF
则可通过http://IP:PORT/monitor/db.jsp以测试db.jsp
b.~/jboss/server/default/deploy/smap.ear/default.war/license>ls
license.dat
则可通过http://IP:PORT/license/license.dat以测试license.dat
（5）基于action等其他形式的绕过安全机制对系统或数据访问
（6）对于现网维护期间不会使用的命令/参数、端口等接入方式，必须删除。
（7）接口认证（禁止不经认证直接访问系统的接口）
2. 禁止隐秘访问方式
（1）非查询操作日志记录：保证每一个非查询操作有日志记录。
3. 禁止不可管理的认证/访问方式
（1）用户清单与密码修改指南
（2）对于人机接口以及可远程访问的机机接口，不得存在用户无法修改的口令（含程序中的硬编码口令）。
4. 禁止使用隐藏或未文档化的接入方式
（1）控制台安全测试
tips：产品根据实际情况进行用例设计，测试设计思路如下：
方式一：根据端口构造访问入口
1、登录服务器查看系统开启端口（或者使用nmap扫描）
2、根据端口对应的服务类型，使用对应的协议访问该端口
3、B/S架构的采用http://ip:port/的方式访问该port（C/S根据实际情况使用测试桩或者模拟器）
4、观察步骤2、3的结果，如果访问成功，则检查其是否有防暴力破解策略；如果没有访问成功，观察返回结果，如果不是因为端口问题导致的响应失败，则继续尝试构造登录入口。由于不同的应用可能目录有所差异，如果访问不到，可以登陆后台服务器以find命令查找，比如find / -name “*console*”，find / -name “*admin*”，看看实际的URL应该是什么，再次尝试。也可以从网上搜索获取类似路径。
方式二：根据系统类型&配置等信息设计
1、搜集业务所在的操作系统的维护端/控制台/管理入口信息
2、搜集业务所在的平台的维护端/控制台/管理入口信息
3、搜集业务所加载外部包/库/模块/容器的维护端/控制台/管理入口信息
4、搜集业务第三方部件的维护端/控制台/管理入口信息
5、尝试构造访问
备注：常见的控制台访问入口（如有发现新的，请补充刷新）：
Tomcat控制台URL：http://www.example.com/manager/html
Jboss控制台URL：http://www.example.com/jmx-console/
Jboss控制台URL：http://www.example.com/web-console/
WebSphere控制台URL：http://www.example.com/ibm/console/logon.jsp
WebLogic控制台URL：http://www.example.com/console/ （一般console的端口为7001）
Apache控制台URL：http://www.example.com/server-status
Axis2控制台URL：http://www.example.com/axis2-admin/
iSAP控制台URL：http://www.example.com/admin/login.jsp
Virgo控制台URL：http://www.example.com/admin
uniportal控制台URL：http://www.example.com/mc/zh/login.jsp
Resin3.0控制台URL：http://www.example.com/admin_manage/
Resin3.1及更新版本的控制台URL：http://www.example.com/resin-admin/
“普元”管理控制台URL：http://www.example.com/eosmgr/
在浏览器地址栏中输入Web服务器对应的URL。
七. 权限管理
（
引入阶段：设计和开发
）
1. 采用基于角色的帐号权限管理模型
tips：以系统管理员登录系统，访问系统的权限管理模块，检查系统的权限管理是否基于以下步骤：
1、创建角色
2、为角色分配权限
3、创建帐号并指定其所属角色（注意，权限不能直接和账号相关联）
4、帐号自动继承角色所拥有的权限
2. 授权和用户角色数据存放在服务器端
在测试过程中，通过burpsuite代理拦截各种get和post请求，查看cookie和隐藏域中是否包含角色、权限、系统及其他敏感信息。
*注：本测试用例主要是为了检查权限关键数据存放位置。
八. 敏感数据
（
引入阶段：开发
）
1. 禁止在代码中存储明文的敏感数据：用Search and replace或者Fortify扫描代码中的username,admin,passwd,password,userid等开发常用关键字，确保代码中没有明文敏感数据。
2. 敏感数据加密传输
tips：
1.在非信任网络之间进行敏感数据的传输采用安全传输通道或者加密后传输，有标准协议规定除外。
2.避免密文与密钥一起传输、传输口令的SHA256摘要(数据库中存储的也是SHA256摘要)等等实际不能达到防止黑客攻击(重放攻击)效果的设计
3.在非加密传输通道中传输的密文，被wireshare抓包后获取后可以直接使用也不满足本用例要求（例如登录时不知口令原文直接在消息体里放密文也可以登录成功。）
说明：系统不同节点间的通信如果中间网络经过Internet，则需要考虑敏感数据加密传输
（1）安全传输协议：
所使用的传输协议的版本符合以下要求：SNMPv3、SSH V2、SSL3.0、TLS1.0 及以上版本。
注：SSH协议为1.99表示同时支持V1和V2，产品需默认使用V2
3. 使用带服务器端证书的 SSL 传递敏感数据
tips：
只提供本地接入或本地登录，用来做设备管理使用的场景可以不测，windows嗅探工具使用Wireshark，Suse使用tcpdump， solaris使用snoop。
1、启动Wireshark进行嗅探；
2、访问操作员登录页面，输入用户名和口令进行登录；
3、查看Wireshark的嗅探记录，选择目的IP为服务器IP）的记录，右键并点击“Follow TCP Stream”，检查是否能够看到明文的口令/密码。
4. 禁止在 URL 中携带会话标识
由于浏览器会保存 URL 历史记录，如果 URL 中携带会话标识，则在多人共用的 PC 上会话标识容易被其他人看到，一旦该会话标识还在其生命有效期，则恶意用户可以冒充受害用户访问 Web 应用系统。
5. 对银行账号等敏感数据的访问要有认证、授权和加密机制。
（
引入阶段：设计
）
九. 隐私保护
（
引入阶段：设计和开发
）
1. 个人数据过滤或匿名化处理
tips：
1.检查系统是否存在非正常业务流程之外的出于于测试、维护、定位目的的采集并存储个人数据、导出个人数据的场景
场景包含不限于：日志、消息跟踪、导出工具、维护工具、维护界面、过程文件等
2.检查这些个人数据采集和处理模块是否有安全保护机制：
（1）调用这些功能是否需要先通过认证：web管理和接口通过认证，脚本工具通过权限控制，其他场景根据实际情况分析
（2）是否有日志记录这些功能的调用处理过程；
（3）web管理和接口：不具备调用权限的普通用户是否能非法调用这些功能；脚本工具至少-非同组用户不可读写和执行
3.检查个人数据存储是否有安全保护机制：
（1）物理/内存数据库：用户认证授权
（2）文件：权限控制根据业务需求，如果同组用户必须读取也可以容许，至少保证其他用户无法读取；
（3）其他形式：根据产品实际情况分析保护机制
4.检查个人数据需要导出客户网络时有匿名化机制
2. 个人数据处理功能公开
tips：
满足以下条件之一：
1、系统不存在涉及个人数据的采集/处理的功能。
2、允许产品正常业务（建立通信连接及计费）的需要，采集、处理、存储个人数据，但必须提供必要的安全保护机制，导出客户网络有匿名化机制，以防止个人数据被泄漏、丢失、破坏。
必须在产品CPI（客户资料）中对产品涉及用户隐私的功能进行描述和声明：
– 描述：该功能处理用户个人数据的目的、范围、处理方式、时限
– 声明：要求客户使用该功能时遵从当地适用的法律法规。
十. 加密解密
1. 禁止使用没有专利的安全标准加密算法
（
引入阶段：设计和开发
）
tips：
已经被证明不再安全的公开加密算法包括：DES、RC2、MD5、SHA1、HMAC-MD5、HMAC-SHA1；
对称加密算法建议使用：AES；
密钥交换算法建议使用：DH；
数字签名算法建议使用：DSA、ECDSA；
非对称算法建议使用：ECC、RSA；
HASH（哈希）算法建议使用：SHA；
HMAC（基于哈希的消息验证码）算法建议使用：HMAC-SHA；
建议的各算法建议采用如下的加密强度：
| 加密算法 | 最小强度 | 建议的默认强度 | 要求更高强度时建议的 |
| AES | 128 | 128 | 192、256 |
| DH | 1024 | 1024 | 2048 |
| DSA | 1024 | 1024 | 1024 |
| ECC | 192 | 192 | 216 |
| ECDSA | 192 | 192 | 216 |
| RSA | 1024 | 1024 | 2048 |
| SHA | 224 | 256 | 384、512 |
| HMAC | HMAC-SHA224 | HMAC-SHA256 | HMAC-SHA384、HMAC-SHA512 |
*注：如需要与第三方系统对接或兼容老系统，产品不得不使用不安全密码算法时，应在产品CPI资料中提示风险。
2. 禁止写死传输密钥
（
引入阶段：设计和开发
）
测试方法：
1根据对系统所有接口得了解，分析那些接口涉及敏感数据密文传输（或者结合红线条目“口令加密存储”“禁止私有算法”用例一起测试：检查产品数据库、配置文件、内存、脚本等中所有加密场景（口令加密、文件加密等）梳理该场景是：仅用于本地加密还是用于敏感数据加密传输。），检查用于敏感数据加密传输的算法之密钥是否可配置
2.检查代码中密钥敏感字符串（key、sharekey、encrypt、enc、dec、decrypt等）。
并结合开发人员人工访谈&分析，并且确认初始密钥是否使用工具生成。
预期结果：
用于敏感数据加密传输的密钥，禁止硬编码在代码中，需要加密保存在配置文件或者数据库中。
3. 密钥不能明文存储
十一. 业务安全
1. 不使用不安全的服务和协议
系统的管理功能和近端维护终端、网管维护终端间，支持使用合适的安全协议（如SSH v2/TLS1.0/SSL3.0/IPSec/SFTP/ SNMPv3等）；支持关闭不安全协议（FTP、Telnet）。
tips：
1、参考被测系统的设计文档或者登陆被测操作系统，检查是否使用Telnet、FTP、NFS、Samba、RPC、TFTP、r 服务、Netbios、X-Windows、Snmp V1.0/V2.0 等不安全的服务和协议：
a.Telnet、FTP、TFTP、NFS、r 服务(rlogin/rsh等)：SUSE使用chkconfig命令，AIX使用lssrc -a命令
b.SUSE和AIX：X-Windows：netstat -an|grep 端口是否开启(注：请查看/etc/services中X Window System对应实际端口)
c.Netbios：cmd—>nbtstat -A 被测服务器ip或者cat /etc/services查看该服务监听的端口是否开启）
d.Samba：SUSE上对应SMB、NMB服务
e.检查通信矩阵中是否含以上服务
2、如果存在则关闭这些服务和协议，观察被测系统是否仍正常运行。
注：支持多操作系统的都要测试
2. 跨站请求伪造防范：
对于B/S应用：
1、检查系统是否有“自动登录/记住我”功能
2、检查重要的管理事务或重要的交易事务如充值、余额
、添加用户、开启业务等，是否有二次认证
3、检查重要的管理事务或重要的交易事务如充值、余额
、添加用户、开启业务等，按要求输入相应的数据，并提交；通过burpsuite拦截请求，查看整个交互过程中（有可能一个操作涉及多个步骤）客户端提交参数是否包含随机信息或者动态口令、验证码的信息。
3. 管理功能和业务功能相互独立部署
十二. 协议与接口防攻击
1. 关闭非必须的端口：
tips：
1.登录被测主机通过如下命令扫描端口
tcp端口扫描：
netstat -an|grep tcp(WINDOWS使用 netstat -an|findstr “TCP”)
udp端口扫描:
netstat -an|grep udp(WINDOWS使用 netstat -an|findstr “UDP”)
或者通过Nmap对各服务器进行端口扫描：
tcp端口扫描：
Nmap -P0 -sS -n -p 1-65535 -oX tcp.xml -sV 服务器IP
udp端口扫描:
Nmap -P0 -sU -n -p 1-65535 -oX udp.xml -sV
服务器IP
SCTP扫描：
nmap -sY -scan_delay 250 -p 1-65535 -v -n -oX SCTP.xml 服务器IP
2.排查系统是否涉及以下单机测试环境不能测试的端口-如果可被NMAP扫描出的话也需要公开：
使用find . -name “*” | xargs grep -i “port”命令搜索服务器上由于业务特性未开启暂未启动的端口
如果系统涉及集群则检查数据库RAC双机端口、双机管理软件端口、集群软件端口
如若产品还集成别的第三方组件端口也需要公开
3.确认每个端口的使用场景
4.将步骤一、二中端口与通信举证文档对比
备注：Linux环境下使用nmap扫描UDP端口时间过长，可以通过如下操作解决：
echo “0” > /proc/sys/net/ipv4/icmp_ratemask
5 关于通讯矩阵
1） 通讯矩阵Authentication Mode列检查：安全域最低需要IP认证，如果在跨安全域需要安全认证方式，标准的协议不支持认证需要说明。
2） 通讯矩阵目的端口（监听）列检查：同一目的端口在所属平面列既是管理平面又是业务平面不行
3） lsof -i -n|egrep ‘COMMAND|LISTEN’ 扫描运行环境，*:port和0.0.0.0:port均代表端口所有IP监听，需要安全理由。
2. 管理访问接入认证要求
管理通信端口测试步骤：
预置条件：产品通信矩阵描述正确
1、梳理通信矩阵文档中：所有平面中涉及的可以对系统或系统数据进行管理（增删改）的端口
2、剔除协议标准定义中无认证机制的
3.检查管理端口是否有接入认证机制
管理通信协议测试步骤：
1.根据产品描述or其他设计文档，梳理产品内部接口/对外接口中属于可以对系统或系统数据进行管理（增删改）的接口协议
2.检查管接口协议是否有接入认证机制
注：口令认证是最小的接入认证机制
常见的非标准协议或者产品需要定制开发接口的管理端口和协议举例：MML、SOAP、HTTP/HTTPS、本公司自研协议管理访问接入认证要求
3. 近端访问认证要求(设备外部可见的能对系统进行管理的物理接口必须有接入认证机制。)
tips：1、检查设备是否存在能对系统进行管理的物理接口（如串口、USB接口、管理网口等）；
2、如果存在，检查这些物理接口是否是外部可见的；
3、如果外部可见，访问这些接口，检查是否有接入认证机制；
4. 协议畸形报文攻击测试（健壮性测试，Codenomicon）
十三. 安全日志
1. 对安全事件及操作事件记录日志
tips：1、分别进行以下操作：
1、登录和注销；
2、增加、删除用户和用户属性（帐号、口令等）的变更；
3、用户的锁定和解锁（管理员解锁和自动解锁），禁用和恢复；
4、角色权限变更；
5、系统相关安全配置（如安全日志内容配置）的变更；
6、重要资源的变更，如某个重要文件的删除、修改;对系统配置参数的修改；
对系统进行启动、关闭、重启、暂停、恢复、倒换；
对业务的加载、卸载；
软件的升级操作，包括远程升级和本地升级；
对重要业务数据（特别是与财务相关的数据，包括：卡号、余额、话单、费率、费用、订单、出货、帐单等）的创建、删除、修改；
所有帐户的命令行操作命令。
2、检查系统是否对以上所有操作记录相应的日志记录,包括用户ID(包括关联终端、端口、网络地址或通信设备）、时间、事件类型、被访问资源的名称、访问结果等。
注:根据实际情况，分别测试以上活动中成功和失败的场景
十四. Web安全开发
1. 输入校验：
tips：1、必须对所有用户产生的输入进行校验，一旦数据不合法，应该告知用户输入非法并且建议用户纠正输入。
说明：用户产生的输入是指来自 text、password 或 textareas 表单域的数据；必须假定所有用户产生的输入都是不可信的，并对它们进行合法性校验。
2、必须对所有服务器产生的输入进行校验。
说明：服务器产生的输入是指除用户产生的输入以外的输入，例如来自 hidden fields、selection boxes、check boxes、radio buttons、cookies、HTTP headers、热点链接包含的 UR L参数的数据或客户端脚本等；必须假定所有服务器产生的输入都是被篡改过的、恶意的，并对它们进行合法性校验，如果不合法，说明有人恶意篡改数据。举例：假如用户资料填写表单中的“性别”为必填项，用 radio button（‘男’和‘女’对应实际值分别为‘1’和‘0’）来限制用户的输入，如果应用程序收到的“性别”值为‘2’，那么可以断定有人恶意篡改数据。
3、不能依赖于客户端校验，必须使用服务端代码对输入数据进行最终校验。
说明：客户端的校验只能作为辅助手段，减少客户端和服务端的信息交互次数。
4、禁止未经严格输入校验、直接使用客户端提交的参数动态构建xpath语句。
2. 防止SQL注入：百度百科里有详细的解释，这里偷个懒，就不多说了。
3. 文件上传限制：防止攻击者上传JSP、PHP等获取WebShell控制服务器。
4. 上传、下载路径限制：
建议对写/上传文件的路径或文件名采用随机方式生成，或将写/上传文件放置在有适当访问许可的专门目录。对读/下载文件采用映射表（例如，用户提交的读文件参数为1，则读取file1，参数为2，则读取file2）。防止恶意用户构造路径和文件名，实施目录跨越攻击。
5. web可访问的文件约束
禁止将敏感文件（如日志文件、配置文件、数据库文件等）存放在Web内容目录下。
说明：Web内容目录指的是：通过Web可以直接浏览、访问的目录，存放在Web内容目录下的文件容易被攻击者直接下载。应该放到Web浏览不到的目录（如：WEB-INF）。
6. 删除调试代码
归档的程序文件中禁止保留调试用的代码。
说明：这里的“调试用的代码”是指开发过程中进行临时调试所用的、在Web应用运行过程中不需要使用到的Web页面代码或servlet代码。例如：在代码开发过程中为了测试一个添加帐号的功能，开发人员临时编写了一个JSP页面进行测试，那么在归档时，该JSP页面必须删除，以免被攻击者利用。
十五. Webservice安全
1. 对 Web Service 接口的调用要进行认证
认证就是确定谁在调用 Web Service，并且证实调用者身份。可以用WSDigger，是一款开源免费的工具。不过有些应用用不了…，如果大家有更好的办法、请赐教^_^
2. 对 Web Service 提交的参数进行输入校验
十五. DWR安全防护
1. 关闭DWR 调试功能
tips：
1、在被测应用所在服务器上检查是否应用到dwr：
find ./ -name “dwr.*”
如果存在dwr.xml和dwr.jar两个文件，则说明应用存在DWR，进行下一步
2、 检查对应的web.xml有没有如下配置，如果有则表明网站肯定使用了DWR，再执行步骤3
<servlet-name>dwr-invoker</servlet-name>
3、检查该web.xml中dwr对应debug值是否为false：
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
2. 对DWR接口的调用必须进行认证，对DWR提交的参数进行输入校验，对DWR接口的调用必须进行鉴权（无法越级访问）
很遗憾，市面上没发现有专门针对dwr接口的测试工具；公司内部使用的东西还不让外泄…
*至此，应用安全测试部分结束。接下来准备一下、开始写《软件安全测试之系统安全测试》