安全性测试

• 认证与授权

• Session和cookie

• 文件上传漏洞

• SQL 注入

• XSS 跨站攻击

• DDoS拒绝服务攻击

-认证和授权

• 认证的目的是为了认出用户是谁，而授权的目的是为了决定用户能够做什么。

• 认证：Authentication （who am I ?）

• 认证实际上就是一个验证凭证的过程。

• 多因素认证的强度要高于单因素的认证，但是在用户体验上，多因素认证或多或少会带来一些不方便的地方。

• 密码策略：长度、复杂度，要经过不可逆的加密后保存在数据库中。

• 多因素认证：支付宝

• 登录失败的错误提示消息不应该明确告知是用户名不存在还是密码错误，避免客户端使用暴力破解方式。

• 必须要登录成功后才能访问的页面中都需要用Session 对客户端进行验证，确认当前Session 已经登录过，否则访问该页面时应该自动跳转到登录页面。避免客户端直接在URL 地址栏输入某个地址进行访问，绕开登录验证。

• 登录失败后的限制策略，比如连接5 次登录失败，应该暂停用户登录，并将该信息发送给系统管理员，并告知客户端的IP 地址。

• 登录时应该使用图片验证码，包括后续的一些表单提交的动作，都要使用图片验证码。避免使用工具发送数据包，目前图片验证码是被证明最可靠的防攻击手段之一。

• 授权：Authorization （what can I do?）

• 某个主体对某个对象需要实施某种操作，而系统对这种操作的限制就是权限控制。

• 用户只能访问被授权的模块和功能。

• 用户不能通过直接输入URL 地址的方式进行越权访问。

• 权限的控制只能由系统管理员来维护，其它用户不能做任何修改。

• 权限控制要细，最好细到增删查改这种功能上，并且不同模块有不同的权限。

-Session和Cookie

• 对客户端生成Session ID 时最好与IP 地址进行绑定，避免非法客户端获取到别人的Session ID 后来冒充合法用户。

• Cookie 的信息由于是保存在客户端，是公开的，所以对于关键信息需要加密处理。

• Cookie 的作用域需要定义清楚，不能一味的全部定义成 / ，这样很有可能站点虚拟目录之间的Cookie 信息互相影响，产生冲突。除非我们的站点只有一个虚拟目录。

• 一些重要的具有控制功能的数据不能保存在Cookie 当中，而必须将它保存在Session 中，避免人为地篡改Cookie 非法获取到系统控制权。

-Session测试

• Session 不能过度使用，会加重服务器维护Session 的负担。

• Session 的过期时间设置是否合理。

• Session 过期后是否客户端是否生成新的SessionID。

-文件上传漏洞

• 对文件类型进行过滤，比如只能允许上传图片或压缩文件。不能允许用户上传可执行程序或代码

• 见案例：访问secure中的两个php文件

• apache\bin\php.ini disable_function=phpinfo system

• 不能单纯只是以文件的后缀名来进行类型的判断

• 不能单纯只是在客户端使用Javascript 对文件类型进行判断，而应该在服务器端进行

• 文件上传的大小必须有限制

-SQL注入

• 注入攻击的本质，是把用户输入的数据当成代码执行。

• 两个关键条件：

    - 用户能够控制输入

    - 原本程序要执行的代码，拼接了用户输入的数据。

• 攻击演示：http://localhost:8008/secure

-SQL注入防治

• 不要信任用户的输入。对用户的输入进行校验，可以通过正则表达式，或限制长度；

• 不要使用动态拼装SQL，可以使用参数化的SQL 或者直接使用存储过程进行数据查询存取。

• 不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

• 不要把机密信息直接存放，加密敏感信息。

• 应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装

• 将服务器设置修改为支持自动将单引号和双引号进行转义。

• SQL 注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用SQL 注入检测工具如IBM 的AppScan 等。

-DDoS拒绝服务攻击

• DDos攻击原理就是模拟真实用户来使用系统，但是模拟的量是非常大的，这样通过利用大量合理的请求造成资源过载，导致服务不可用，从而导致系统无法为真正用户提供服务。

• DDoS攻击，基本原理均是基于网络协议来进行的。