-
一个安全测试的checklist（转）
2008-12-01 10:04:43
1. 不登录系统，直接输入登录后的页面的url是否可以访问2. 不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/download?name=file是否可以下载文件file
3. 退出登录后按后退按钮能否访问之前的页面
4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位
5. 重要信息（如密码，身份证号码，信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息
6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面
7. url里不可修改的参数是否可以被修改
8. 上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行
9. 注册用户时是否可以以'--,' or 1=1 --等做为用户名
10. 传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（','and 1=1 --,' and 1=0 --,'or 1=0 --）时是否可以正常处理
11. 执行新增操作时，在所有的输入框中输入脚本标签（<scrīpt>alert("")</scrīpt>）后能否保存
12. 在url中输入下面的地址是否可以下载：http://url/download.jsp?file=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd
13. 是否对session的有效期进行处理
14. 错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等
15. ID/密码验证方式中，同一个账号在不同的机器上不能同时登录
16. ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定
17. 新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能
-
网站安全性测试（转）
2008-12-01 10:03:48
一个完整的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服务器的目录访问权限，将这种隐患降低到最小程度。
-
ASP.NET中如何防范SQL注入式攻击(转贴)
2008-12-01 10:02:37
一、什么是SQL注入式攻击？所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：
⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：站长资讯网：http://www.net118.com
System.Text.StringBuilder query = new System.Text.StringBuilder(
)`'E$j0x!K$p-f'Z7pb0N230007
m+apb o e230007"SELECT * from Users WHERE login = '")51Testing软件测试网T'Rs.{-H,Q X)M
51Testing软件测试网*nN:j6D^Xz [
.Append(txtLogin.Text).Append("' AND password='")51Testing软件测试网L uE!l9{ b/|+UI-X
51Testing软件测试网!f'Our5cH+`0Q)I!v
.Append(txtPassword.Text).Append("'");⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
二、如何防范？
好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。
⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理
