安全测试基础

安全测试基础

 

一般来说，版本功能测试完成，对应的用例也实现了自动化，性能、兼容、稳定性测试也完成了以后，我们就需要考虑到系统的安全问题，特别是涉及到交易、支付、用户账户信息的模块，安全漏洞会带来极高的风险。

 

一．安全测试原则与常见的安全威胁：

1.安全需求：

※认证:对认证的用户的请求返回

※访问控制：对未认证的用户的权限控制和数据保护

※完整性：用户必须准确的收到服务器发送的信息

※机密性：信息必须准确的传递给预期的用户

※可靠性：失败的频率是多少？网络从失败中恢复需要多长时间？采取什么措施来应对灾难性的失败？（个人理解这个地方应该更偏向于容错容灾测试的范畴）

※不可抵赖：用户应该能证明接收到的数据来自特定的服务器

2.常见的安全威胁：

3.常见的安全测试内容：

权限控制

SQL注入

URL安全测试

XSS（跨站脚本攻击）

CSRF（跨站请求伪造）

URL跳转漏洞

Session与Cookie测试

其他安全测试

 

接下来，我们以一个C#实现的下常见的MVC架构网站为例，来分析具体的各个安全测试角度。

 

二.权限控制

权限控制相对来说比较简单，功能测试的过程中也接触过不少，主要就是考虑以下方面：

1.用户权限：我们假设存在两个用户A,B；其中A的权限级别很高，B的权限级别则很低：

只有A能进行的操作，B能不能进行操作；

只有A能看到的页面，B能不能看到；

2.页面权限：

必须登录才能看到的页面，不登录直接访问能否看到？

必须A-B-C的页面，能否直接A-C？

通常来说单纯的权限控制页面测试不复杂，但是因为权限控制和后续的URL跳转、Session等方面结合的比较紧密，所以单独提出来。

 

三.SQL注入

1.SQL注入原理

以Sql Sever为例，C#提供了两种操作数据库的方法，以实现Sql Sever的查询功能为例(Mysql只需要将Sql对象替换为MySql对象即可)：

A.直接使用传入的Sql进行数据库操作：

  publicstaticDataSet QuerySql(string sSql)

        {

            DataSet ds = newDataSet();

            try

            {

               Open();

                SqlDataAdapter mDataAdpter = newSqlDataAdapter(sSql, conn);

               mDataAdpter.Fill(ds);

            }

            catch (SqlException ex)

            {

                thrownewException(ex.Message);

               DataBaseException = ex.Message;

            }

            finally

            {

               conn.Close();

            }

            return ds;

        }

 B.使用SqlParameter对象，对参数进行格式化，分离控制语句与执行语句：

  

 publicstaticDataSet QuerySql(string sSql, SqlParameter[] Params)

        {

            DataSet ds = newDataSet();

            SqlCommand comm = newSqlCommand();

            try

            {

               Open();

               comm.Connection = conn;

               comm.CommandType = CommandType.Text;

               comm.CommandText = sSql;

               comm.Parameters.Clear();

 

                foreach (SqlParameter p in Params)

                {

                   comm.Parameters.Add(p);

                }

                SqlDataAdapter mAdapter = newSqlDataAdapter(comm);

               mAdapter.Fill(ds);

            }

 

            catch (SqlException ex)

            {

               DataBaseException = ex.Message;

                thrownewException(ex.Message);

            }

            return ds;

        }

 

接下来我们来看以下场景：

用户登录，账号密码存在User表中，该表字段为ID，Name，PassWord三个字段，验证用户登录时直接传用户输入的用户名与密码给数据库，如果我们直接采用方式一，那么代码实现如下：

//获取传入的用户UserName与PassWord

string sql = \"SELECT *FROM User WHERE UserName = \'\"+UserName+\"\' ANDPassWord = \'\"+PassWord+\"\'\";

//其他处理代码

假设我们的账户名称是admin，密码是123，那么构造出的sql就是：

SELECT * FROM User WHEREUserName = ’admin’ AND PassWord = ’123’

执行结果看起来没有问题，但是如果这个时候我们输入的密码是 ‘’or 1=1时，那么实际执行的SQL就变成了：

SELECT * FROM User WHEREUserName = ’admin’ AND PassWord = \'\'\'\' OR 1=1

（这里输入两个分号是因为构造sql的时候就已经是分号了，在sql sever中查询的字符串中带有分号则是需要再加一个分号进行转义）

由于1=1恒等式的存在，这条sql会直接查询出整个表的数据；就算没有相关权限，服务器也会认为是一个有效用户进行处理。

如果我们再进一步，输入密码‘’or 1=1;drop table User

那么结果会是什么样呢？User这个表会直接被删除掉！这个时候网站就会因为User表不存在而报错，产生严重的异常。

综上所述，SQL注入的原理就是通过构造符合SQL语法的参数传入程序，通过执行SQL语句进而执行攻击的操作；原因是程序完全信任了传入的数据，致使非法数据能够入侵系统。

 

2.解决方案：

在了解了SQL注入原理后，我们可以做出针对性的一些措施，如：

尽量避免使用动态构造SQL，而是使用SqlParameter对参数进行格式化或使用框架提供的一些功能，分离控制语句与执行语句；

对传入的字符进行转义处理，’和%、_、[]等通配符进行转义处理，保证执行SQL的时候这些字符是正确在字符串内进行处理的；

在前端表单或控件中增加验证，保证传入后台的数据是合法的；

数据库权限控制，只给对应功能需要的权限，比如登录页面只能进行查询，不赋予其执drop、update、delete、truncate等操作的权限。

 

四.URL安全测试：

1.MVC下的URL构成：

1).使用Get方式的URL构造方式：

~/控制器名/调用的方法?入参1=参数1&……&入参n=参数n，例如：

http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB

可以看到，在不经过处理的情况下，Get方式生成的URL可以看到数据和参数

2).使用Post方式的URL构造方式：、

~/控制器名/调用的方法，入参则放在报文实体主体部分中，例如：http://localhost:12688/Order/OrderList

通过接口测试手段可以获取到访问的入参：

{

        \"OrderType\":\"0\",

        \"QueryType\":\"1\"

}  

 

URL安全测试主要是基于URL的构成方式进行的测试，很多时候会涉及到和其他方向的交叉；了解各个原理后，就能比较全面的考虑问题了。

2.参数检查：主要就是检查URL或者主体报文中的参数

使用Get方式时，URL中显示的参数正确；敏感参数如用户名、密码不应被显示；

使用Post方式时，敏感参数应该进行加密处理

极端但是比较安全的处理方式是URL只显示网站地址，

3.根据URL的构成方式直接篡改URL：

我们回过头去看这个URL：

http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB   

这个URL的内容是的查询某个用户提交的某个申请的明细，URL的传入的ID为要查询的申请，EmployeeID是从Session中取的当前登录用户的ID。

那么我们可以基于以下场景篡改URL进行验证：

用户未登录时，直接输入该网址进行访问（涉及到登录验证）；

其他用户登录时，输入这个网址（涉及到权限控制）

构造ID和EmployeeID为SQL注入的参数，然后访问（涉及到SQL注入）

以及稍后会涉及到的XSS、Session、Cookie等场景。

 

五.XSS

跨站脚本攻击（Cross Site Scripting），为了和层叠样式表css区分，简写为XSS。

1.原理

攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的。

例：

存在一个文本控件，其中value1from来自用户的输入：

<input type=\"text\" name=\"address1\" value=\"value1from\">

直接输入 \"/>，那么实际执行的语句：

<input type=\"text\" name=\"address1\" value=\"\"/><script>alert(document.cookie)script>- \">

也可以将内容放到URL中进行访问：

http://localhost:10344/AbnormalPunch/ApplySubmit?ID=

我们可以看到，输入的内容直接改变了程序的执行代码，导致程序执行结果为攻击者想要的。

2.类型：

反射型XSS：需要欺骗用户进行操作才能触发XSS代码，主要威胁个体用户

持久性XSS：代码储存在服务器中，用户访问时即可直接触发XSS代码，威胁大量用户

3.解决思路：对数据进行html编码处理，保证用户输入的数据不会改变程序代码

将重要的cookie标记为http  only,这样的话Javascript 中的document.cookie语句就不能获取到cookie了.

只允许用户输入我们期望的数据。 例如：　年龄的textbox中，只允许用户输入数字。而数字之外的字符都过滤掉。

过滤或移除特殊的Html标签， 例如: