接上条博文：
打补丁要及时！！
同时作为安全测试人员也应该时刻地主动关注漏洞的发布资讯，及时的排查存在威胁的安全事件，并反馈给公司相关人员。同时应该注意避免安全漏洞在设计、测试阶段带入生产环境中，造成影响和损失。对于敏感数据的处理，也应该主动去熟悉。
6.3.1这一点笔者深有体会，除了上面提到到由密码强度引发的弱口令问题，在测试阶段生成的测试用户，例如：test、test1、test123用户等等，若没有在测试阶段结束之后及时删除，很可能会导致未授权的登入，造成信息的泄露。除了测试用户外，测试版本系统（非正式上线版本）未删除或禁止访问也很有可能存在风险，譬如后台弱口令、未授权访问等。
第二点是关于白盒测试，笔者在这方面的能力不太行，但是白盒测试确实是安全测试阶段很重要的一环，因为很多安全问题，例如：sql注入、xss、文件上传等，从具体的功能点代码实现入手比手工测试更具有针对性，同时效率也会增强。所以笔者这方面的能提确实还需要加强一波。当然了，自动化的工具毕竟是工具，仅供参考，很多问题的检测需要去手工验证。
变更控制措施要及时记录，否则会有意无意的忽略安全属性或将其设定未不可操作。
第二点测试环境与生产环境要充分分离，这一点真的感触太深了！！可以联系上面的测试用户没有删除或禁用。在之前的对某公司的某次渗透测试里，发现某站点的子域名为测试环境的后台登陆（这一点是在进入后台之后发现的），通过test的用户的弱口令成功进入该后台，后台存在部分的信息泄露但是不多，通过测试，发现存在sql注入点，接着在学长的帮助下绕过了waf、手工注入出了数据库信息，接着通过工具自动化，成功dump出了数据库中的数据，该数据同样适用于生产环境下，没有做到完全分离，威胁系数较高。
有权访问数据的人越少，风险肯定是会降低的。在测试和开发环境中，同样要严格区分开发人员的职能，管理员权限/用户权限。
这一页讲的是关于系统变更方面的一些问题，及时记录变更记录十分重要，同时对经过变更后的系统进行新的安全测试，保证该环境安全性未因实施变更而降低，测试确认现有现行安全控制措施仍然有效。
变更管理流程：
1、更新网络图
2、按照系统标准配置系统，更改所有默认密码并禁用不必要的服务
3、通过必要的控制保护系统
4、未存储敏感验证数据
5、将新系统包含在季度漏洞扫描流程中
重视应用层的安全风险。
第一点编码安全问题是针对开发人员来说的。第二点就是重点了是，注入一直都是被划分为具有最高安全威胁的漏洞，造成注入的最主要的原因是在于没有隔离区分代码与数据，使得hacker可以注入非法的数据达到代码执行的效果。缓冲区溢出同样也是相同的原理，数据段的内容超过数据段的最大长度，从而多余的数据进入代码段，可以被利用执行命令。
所以区分数据和代码的边界尤其的重要。
增强对数据的加密流程，防止明文访问权。同时采用强效加密法对网络流量进行加密。第三个应用程序可能会有意无意中泄露关于其配置或内部工作方式的信息，或通过不正确的错误处理方法泄露专用信息。这一点平时也见的不少，譬如一些框架的绝对路径可能会在错误路径下产生，或者报错时泄露网站的一些绝对路径。或者在登陆的时候，友情提示会提示用户名错误、密码错误、用户不存在等具有隐藏含义的信息，这样攻击者可以利用这些信息对后台用户进行爆破。
高风险漏洞在开发期间识别并解决。
xss漏洞的危害说大不大，但说小不小。大致分反射型与存储型，有的时候有dom蠕虫等，现在很多大厂都不收反射型xss了，还是蛮坑的。不过存储型xss的危害大家都心照不宣。文中解释每当应用程序接收用户提供的数据并在未首先验证或编译内容的情况下将其发送到一个Web浏览器时，便会发生xss。其实就是html注入吧。
一个是目录遍历，有的时候扫下网站目录真的是会有惊喜的哈。特别是针对一些熟悉的框架、cms之类的，会有默认的一些目录。未授权访问的问题也很重要，这两点总体还是体现了信息收集的重要。笔者之前就是通过端口的信息收集，发现了很多未授权访问的后台，一般都集中在8080，8081，8082等。
CSRF其实很好防御，csrf-token+referer头校验。但很多时候referer头只是摆设，根本没有做校验。
前几天给一家公司做测试的时候，他们对这一方面做的很好，将时间戳加入到了cookie中，有效的防止重放和身份盗用。
注意编码的安全规范+漏洞评估和测试+web防火墙的配置与维护
