随着网络发展的趋势，对于网站的安全性的要求也越来越高，很多网站都存在被黑客攻击的漏洞，你在网站测试中有做到安全性测试吗？你觉得安全测试应该从哪些方面来检查？欢迎大家讨论交流！


感谢会员judy2sa提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至5月23日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	卖烧烤的鱼	当当购物卡50元	23#
二等奖	jiang860718	300论坛积分	6#
	jacky19840707		18#
三等奖	bzfyhfyh	100论坛积分	3#
	rejoicexu		7#
	hergules		17#

赶上了个沙发，随便说说，

用户认证安全的测试要考虑问题：

1.         明确区分系统中不同用户权限

2.         系统中会不会出现用户冲突

3.         系统会不会因用户的权限的改变造成混乱

4.         用户登陆密码是否是可见、可复制

5.         是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）

6.         用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

系统网络安全的测试要考虑问题

1.         测试采取的防护措施是否正确装配好，有关系统的补丁是否打上

2.         模拟非授权攻击，看防护系统是否坚固

3.         采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ）

4.         采用各种木马检查工具检查系统木马情况

5.         采用各种防外挂工具检查系统各组程序的客外挂漏洞

数据库安全考虑问题：

1.         系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）

2.         系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）

3.         系统数据可管理性

4.         系统数据的独立性

5.         系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

[ 本帖最后由 iori 于 2008-5-16 17:37 编辑 ]

通常用于web优化和抗ddos策略制定。web优化方面不单要测试集中大量访问（尤其是数据库）的峰值，还要提出最优访问状态，测出阀值。
抗ddos方面测试的也有几个，主要对象是数据库和web服务器的压力测试，包括cpu等资源等，存储资源通常也是需要测试的。数据库方面的压力测试主要是大量访问对数据库进行操作的页面来测试，访问方法包括查询、修改和插入。web服务器方面主要是根据收集的用户习惯，确定出使用系统资源较多的页面对脚本进行测试。
通常就这么多，测试前应考虑web server和sql server、中间件、网络等支持的连接数量制定压力范围。
负载测试不是搞破坏，比较忌讳用不专业的ddos瘫痪目标就交差的方法。
安全测试方面应该参照spi的web安全top 10来进行，目前做软件测试人员可能对安全性测试了解不够，测试结果不是很好。如果经验不足，测试过程中可以采用一些较专业的web安全测试工具，如WebInspect、Acunetix.Web.Vulerability.Scanner等，不过自动化web安全测试的最大缺陷就是误报太多，需要认为审核测试结果，对报告进行逐项手工检测核对。对于web安全的测试用例，可以参照top 10来写，如果写一个详细的测试用例，还是比较麻烦的，建议采用安全界常用的web渗透报告结合top10来写就可以了。

真没想到，能是3楼，呵呵。赶的早不如赶的巧。现在有专门做系统和网站安全检测的公司，那里做安全检测的人的技术都很好，大多都是红客。呵呵，所以我们要想做好安全测试，一定要好好学习了。

再补充点，
网站即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?
日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

[ 本帖最后由 bzfyhfyh 于 2008-5-21 14:17 编辑 ]

有流啊！

应用层安全:1.身份鉴别
        网站是否有身份标识和鉴别功能
        网站是否有登录失败处理功能
        网站用户密码复杂度
        是否使用验证码，验证码是否有效，功能是否正确实现
        是否允许不登录直接进入网站管理页面
        网站管理页面是否配备并使用登录失败处理功能
        管理页面是否有超时限制的功能
2.访问控制
        是否提供访问控制机制
        不同权限用户的访问内容是否受到应用系统的限制
        日志是否保存在NTFS分区，是否只有管理员可以访问
3.软件容错
        对用户界面输入的数据是否进行有效性、合法性校验，可否防止SQL注入
        系统异常时是否提供错误类型和异常发生点的信息
4.代码安全
        设计/验收文档和相关证明材料，是否有对应用程序进行恶意代码扫描，确认不存在恶意代码的声明
        是否存在源代码暴露
        是否将站点内容的根目录与服务器操作系统放在不同的磁盘上或逻辑分区上
5.网页防篡改
        是否能够实时监测到网页内容被篡改或被破坏
        当网页被篡改或破坏时，是否能够按设定的安全策略方式（如短信、邮件等）自动报警
        是否能够自动恢复Web服务器上被篡改和破坏的网页文件
        是否能够自动恢复被篡改和破坏的数据库内容
        是否阻止从网站直接访问到文件目录
        Web服务器上的网页文件是否加密存放，以防止不正当的篡改和泄露
        合法网页的发布（增加、修改和删除）是否必须通过自动发布子系统进行
        是否可以绕过防篡改检测机制
        可否阻止连续篡改攻击
6.软件版本及补丁
        Web服务器软件版本，是否及时进行补丁升级
        应用服务器版本，是否及时进行补丁升级
        网站支持软件、插件等是否最新版本，是否及时进行补丁升级
数据安全:
1.数据完整性
2.数据保密性
3.数据备份和恢复

个人认为网站安全测试应分为两部分：安全体制测试和应用与传输安全测试。以下为简单说明：
一.安全体制测试
1.部署与基础结构
网络是否提供了安全的通信。
部署拓扑结构是否包括内部防火墙。
部署拓扑结构中是否包括远程应用程序服务器。
基础结构安全性要求的限制是什么。
目标环境支持怎样的信任级别。
2.输入验证
是否清楚入口点
是否清楚信任边界
是否验证web页输入
是否对传递到组件或web服务的参数进行验证
是否验证从数据库中检索的数据
是否依赖客户端的验证
应用程序是否易受规范化问题的影响
应用程序是否易受SQL注入攻击
应用程序是否易受XSS攻击
3身份验证
是否区分公共访问和受限访问
是否明确服务帐户要求
是否在网络中传递明文凭据
是否实现自己的用户存储
是否使用表单身份验证
是否使用SQL身份验证
是否使用进程帐户
是否使用服务帐户
是否考虑使用匿名Internet用户身份
是否使用原始用户身份
如何保存数据库连接字符串
是否强制使用强帐户管理措施
4授权
是否使用深层防御策略
使用了哪些网关守卫
是否使用基于角色的方法
角色是否提供足够的特权隔离
设计是否使用代码访问安全性
应用程序使用哪些身份
5配置管理
是否支持远程管理
是否保存配置存储的安全
是否隔离管理员特权
6敏感数据
是否存储机密信息
是否在网络中传递敏感数据
是否记录敏感数据
7会话管理
如何交换会话标识符
是否限制会话生存期
如何确保会话状态存储的安全
8加密
是否开发自己的加密技术
是否使用合适的密钥大小来应用正确的算法
如何确保加密密钥的安全性
9异常处理
是否使用结构化的异常处理
是否向客户端公开太多的信息
10审核和日志记录
是否明确了要审核的关键活动
是否考虑过如何流动原始调用者身份
二.应用及传输安全
1注册与登录
2在线超时
3操作留痕
4备份与恢复
5HTTPS和SSL测试
6服务器端的脚本漏洞检验
7防火墙测试

安全测试内容主要有以下：
1。 用户认证机制  比如用户口令模式， 数字证书模式，智能卡模式，人像，指纹，声音模式等等。
       可以围绕以下展开：    未经授权是否可以通过绝对路径访问到需要鉴权的资源（网址）？
                                                登陆是否存在密码输入时显示明文，密码框没有使用标准的？
                                                退出后是否依然能使用鉴权资源的情况？

2。 加密机制。   主要涉及 公钥和私钥加密算法。
3。安全防护策略。 由于TCP/IP协议的脆弱性， 我们通过安全日日志，入侵检测，隔离防护，漏洞扫描等措施。
      测试的内容也就涉及： 模拟非授权攻击 看防护系统是否坚固
                                                采用成熟的网络漏洞检查工具看系统漏洞
                                                有关系统补丁是否打上等等
4。数据备份和修复
      数据是机密的完整的独立的受管理的。
      备份和修复是否及时
      备份和修复是否充分
      数据丢失造成的损失多大等等
5。 防病毒系统
      是否安装有效杀毒软件？是否能多种工具交叉查杀？等等

如何开展安全测试， 谈下测试方法。
1。 功能验证。   安全功能验证的测试方法采用传统的测试方法：白盒黑盒灰盒
2。 漏洞扫描。  主要有拒绝服务漏洞， 本地用户扩权漏洞，远程用户扩权漏洞。
3。 模拟攻击。
       服务拒绝型攻击  EG: 泪滴， SYN洪水， SMURF攻击， UDP洪水等等。
       漏洞木马型攻击  EG: 口令猜测，特洛依木马， 缓冲区溢出等。
       信息收集类技术   EG:扫描
       伪装欺骗型攻击： EG: ARP欺骗， IP欺骗等
       侦听技术  就是获取在网络上传输的信息。

第一部分：代码安全
一. 对跨越站点的脚本攻击的简单防范：
1.控制好权限，尽可能的降低权限。
2.过滤或转换用户提交数据中的HTML代码。使用HtmlEncode 方法对自于用户输入、数据库或本地文件进行处理；UrlEncode 对 URL 字符串进行编码。
3.必须确保来自查询字符串、窗体字段和 cookie 的输入对于应用来说是合法的。将所有的用户输入都认为可能是恶意的，筛选或者清理下游代码的上下文。验证所有的输入是否为已知的有效值，然后拒绝其他所有的输入。用正则表达式验证通过 HTML 窗体字段、cookie 和查询字符串而接收到的输入数据。
4.限制用户提交数据的长度（验证输入）。
二。防止SQL注入
1. 强制测试输入的长度和数据类型，有助于防止恶意造成的缓冲区溢出漏洞。
2. 测试输入内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。
3. 使用 XML时，根据数据的架构对输入的所有数据强制进行验证。
4. 绝不直接使用用户输入内容来拼凑SQL语句。可以使用用户输入内容做为动态SQL语句
5. 坚持使用存储过程来验证用户输入
6.在多层环境中，所有数据都应该在验证之后才允许进入可信区域
7.限制网站应用或者网页只能执行拥有执行存储过程的权限，不能直接读写SQL表和视图。同时刪除不必要的系統的存储过程，另外加上数据库操作日志。
三：防止假冒Referer
四：不用GET，而用POST
五：服务器不能接受用户上传的文件名
六：防止CC攻击，可以启用IP验证或session验证

第二部分：网站服务器和网络安全
上面几个楼都涉及了，我这就不重复了

[ 本帖最后由 smilehe 于 2008-5-20 14:22 编辑 ]

路过，学习了!

安全性测试提到了这么多，如何执行测试不 知道有多少能够真正做到的。

楼上几位提到的比较全面，学习了
一般性企事业单位的网站也最多就是功能的完备性，用户权限的正确性，负载的抗压性上进行测试
对于vss脚本攻击还有其他方面，越是权威的网站要求应该越严格。

我学我学我学学学！！！
感谢大家，也要感谢51testing，提供了这个平台

我也来踩一下，内容，不错。支持下。

这些天心情较沉重，首先为灾民默哀3分钟。

……

有两期没来参与了，这次的话题挺重要。安全问题通常被领导们忽视，尤其一些小型企业以为自己公司规模较小，骇客们不会光顾。殊不知，小型企业正是骇客们经常去的“实践练习”场所！
个人从自己这几年WEB测试的经验里谈几点常人较易忽视之处：
首先要注意一点，安全问题是内部最容易引爆，因为通常个人都潜意识自认为很“安全”，忽略一些细节。
一、系统安全：
1、WEB应用程序集部署及权限问题：
（1）IIS安全：站点、端口、应用程序集过多，应用程序集、访问权限及平台插件、控件较多；
（2）部署过程：
1）测试环境与开发环境应用程序集等同，可能造成DLL冗余出错；
2）FTP服务：Serv-U存在安全漏洞，帐户过多；
（3）目录权限：
1）Web目录文件夹下ASP.NET上传权限完全开放，容易造成木马病毒等入侵；
2）WEB服务器管理员权限是否过多开放，都可能引起内部人员误操作。
2、数据（库）管理：
（1）登录帐户过多；读写权限不明，Owner较多，造成随意修改表结构、数据；
（2）数据的添加/删除、查询/统计、修改/更新很多靠手工操作，带来安全隐患；
（3）内部测试帐户通常具有管理员最高权限（为测试方便），一般亦无强安全密码，SQL标准用户过多，在配置文件里明文登录，权限过高等，都可能存在隐患。

二、内部开发安全：
（1）VSS/CVS管理：每位开发人员的代码签入/签出权限控制及版本控制是否严格，松动的权限会使得版本及其混乱；
（2）代码规范：开发人员一般按照自己喜好编程，对于整个系统没有发现内在的漏洞，诸如内存溢出、频繁使用递归代码等，对于代码的效率产生严重影响；随意修改他人代码，没有注释，对于后续开发带来不便；
（3）脚本漏洞：数据库存储过程及脚本含有不受保护的特定变量，诸如drop、delete等操作命令，使得操作数据库表存在安全隐患；测试人员回归脚本未根据实际需求相应变更遗留隐患等等。

至于网站页面上表单的数据验证、密码口令身份验证等，基本上成熟的开发团队都能考虑到，这里不做详谈。

以上只是一些个人感想，不正之处，还望前辈批评指正。谢谢！

说的理论都很全面，希望能实际点，到底怎么开展执行安全方面的测试 ，还是迷惑。。。

大家都说的很对,可是要有个实例可能更好!

首先分析“安全性”定义：
1.从应用角度分：服务器安全性、操作系统安全性、web服务器安全性、数据资料安全性。
2.从需求角度分：资料完整性安全、资料保密性安全；

有了以上依据我们就可以对安全性进行全面的划分，相应的安全级别越高，花费的成本也是越高的。
例如：所有资料都需要相应的权限才能访问，而且不能接受数据丢失，典型应用：银行业务。那么银行数据安全应是实时备份，且是加密的。
如果是论坛数据，那么只要每天备份就可以了，而且数据安全要求本身也没银行数据安全要求高。
这里体现安全基本越高相对的成本也就越高。

针对以上两点安全性说明，先对系统进行一下简单的划分：
服务器：是否允许短时间宕机（例如意外停电）。
操作系统：对操作系统的稳定性有什么级别的要求？对操作系统防黑客攻击的能力有什么要求（用诺顿防火墙和专业硬件防火墙的效果当然是不一样的）？
web服务器：和操作系统一样考虑。另外结合数据安全性考虑，因为web数据是在网络环境下进行传输的，那么传输过程中数据有被截获、破译的可能，这个也是需要考虑的。而且在web网站内，用户权限的设计也和数据安全性息息相关，需全方位考虑。必要时可考虑对用户操作进行记录。
数据安全性：现在基本上都是用数据库对数据进行存储，那么数据库中是否有敏感数据（不希望被不相干的人看到的，例如企业内部经营数据）数据隔离？对数据完整性要求是什么样的？

有了以上全面、综合的理论分析以后，针对具体的系统设计相关的安全测试用例应该不是很困难的事情了吧。当然具体用例对技术实现也是要考虑的。毕竟一个安全测试人员和一个准黑客哪个更强也不好说。

本人从事网站测试工作已经三年了我个人认为一个完整的Web安全体系测试可以从部署与基础结构，输入验证，身份验证，授权，配置管理，敏感数据，会话管理，加密，参数操作，异常管理，审核和日志记录等几个方面入手

数据加密：某些数据需要进行信息加密和过滤后才能进行数据传输，例如用户信用卡信  息、用户登陆密码信息等。此时需要进行相应的其他操作，如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多，越来越复杂，但一般数据加密的过程时可逆的，也就是说能进行加密，同时需要能进行解密！

登录：      一般的应用站点都会使用登录或者注册后使用的方式，因此，必须对用户名 和匹配的密码进行校验，以阻止非法用户登录。在进行登陆测试的时候，需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制，最多可以尝试多少次登录，哪些页面或者文件需要登录后才能访问/下载等。

超时限制：WEB应用系统需要有是否超时的限制，当用户长时间不作任何操作的时候， 需要重新登录才能使用其功能。

SSL：        越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写，是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。（RSA），在位于HTTP层和TCP层之间，建立用户与服务器之间的加密通信，确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的，任何用户都可以获得公共密钥来加密数据，但解密数据必须要通过相应的私人密钥。进入一个SSL站点后，可以看到浏览器出现警告信息，然后地址栏的http变成https，在做SSL测试的时候，需要确认这些特点，以及是否有时间链接限制等一系列相关的安全保护。

服务器脚本语言：脚本语言是常见的安全隐患。每种语言的细节有所不同。有些   脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。         

          注：黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。这个网站包含了脚本代码（有允许访问根目录的特性）就可能有这个安全隐患。

日志文件：在服务器上，要验证服务器的日志是否正常工作，例如CPU的占用率是否很高，是否有例外的进程占用，所有的事务处理是否被记录等。

目录：       WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当，通过简单的URL替换和推测，会将整个WEB目录完全暴露给用户，这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式，如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限，将这种隐患降低到最小程度。

正在做WEB测试的项目，但公司好像不是很重视网络安全方面的测试，连SQL注入之类的都不做的，所以对这方面不了解，收下来参考咯，谢谢

来踩踩  收益了~