07-网络安全

网络安全

Web应用安全威胁类型

由于可能会有未知的安全问题，所以最好保留Web网站的详细的日志信息

• 验证攻击：来确认某用户、服务或应用身份的攻击手段
• 授权攻击：用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段
• 客户侧攻击：用来扰乱或探测Web站点用户的攻击手段（比如绕过）
• 命令执行攻击：在Web站点执行远程命令的攻击手段（比如SQL注入）
• 信息泄露：用来获取Web站点具体系统信息的攻击手段
• 逻辑性攻击：用来扰乱或探测Web应用逻辑流程的攻击手段

三层安全防御机制

通常情况下应用程序必须合适用户提交的用户名和密码是正确的才能登入，否则禁止登入

具体步骤是，用户进行登入，登入后服务器会为客户端分配Session写入Cookie中，后续操作会将登入状态写入Cookie中

验证机制

• 使用弱密码：使用常用的常用字典词汇为密码，纯数字，用户名和密码相同，使用默认密码，被记录在常用密码字典中的密码

  解决方案：禁止用户使用弱密码

• 容易被暴力破解：由于登入功能的公开性，攻击者可以试图批量的猜测用户的密码或用户名，从而冒充真正的用户

  解决方案：

  1. 使用有效的验证码（服务端判断）
  2. 使用复杂度较高的验证码
  3. Cookie和会话检测（登入错误限制次数限制）
  4. 你知道什么和你有什么的双因子验证（比如我知道密码，我有手机验证码）

• 忘记密码功能模块：忘记密码功能模块跳过了身份验证，攻击者可以跳过身份认证

  解决方案：

  1. 由用户设置密保问题（服务端判断）
  2. 由用户注册时设置的邮箱或手机号进行验证用户身份（使用明文传输邮箱或手机可能会被中间人劫持修改，但是也不要过分依赖MD5加密）

• 多级登入机制：

  • 由于多级登入限制，程序会认为到达后一级登入认证时会完成了前一级认证，攻击者若绕过前级别认证直接到后级认证认证通过

  • 程序会认为这多级登入认证的过程中用户不会改变，攻击者可以在中途切换为权限较高的用户进行攻击

  • 多级登入的认证的手段过于简单或是在客户端判断等

  解决方案：

  1. 限制攻击者绕过前面认证
  2. 每次认证中确认用户的权限
  3. 提高多级登入验证复杂度

会话管理机制

由于用户登入成功后，登入状态会会被写入Cookie中，服务器端会缓存对应从Session，所以攻击者可以不需要验证机制就可以伪装成用户

• 会话令牌（SessionID）使用用户的用户名或电子邮件地址转化而来，或使用其他相关信息创建，只是使用简单的加密或模糊处理，甚至未加密
• 会话令牌（SessionID）容易被猜到，有规律可循，攻击者可以枚举出大量的令牌找出有效的令牌
  • 隐含序列的规律：枚举出每个令牌，两两相减，若有等于类似的值，即可猜测出下一个真正的令牌
  • 依赖时间戳：攻击者会枚举出大量令牌，直到真实用户登入，发现令牌有跳号现象，即可在一定范围内枚举出真正的令牌
  • 生成的随机数强度不够：由于计算机中的随机数生成算法不能做到完全随机，叫做伪随机数
• 会话的寿命过长，攻击者攻击成功的概率就会越大
• 没有设置有效的结束会话的操作（未设置登出操作），或会话结束不彻底（只是客户端清除了Cookie，服务端未清除）

解决方案：

1. 会话令牌尽量使用复杂的方式生成，并设置一些随机数，而且也要加密处理
2. 令牌使用HTTPS进行传输，若使用HTTP，应该将Cookie标记为secure，防止用户浏览器通过HTTP传送
3. 设置软会话过期时间，若用户在一定时间内没有操作则Session失效；或设置硬会话过期，不管用户是否操作，在一定时间内都要求用户重新验证身份
4. 提供完善的会话终止功能

访问控制机制

• 未设置访问控制，仅仅是将某些资源或功能的访问路径公布给具有相应权限的人
• 基于标识符的访问控制，通过在get、post请求时或cookie中多添加一个了访问控制的参数
• 对于静态文件未具备权限验证功能，比如付费资源仅仅是一个连接，任何人都可以下载，而未在下载前进行判断是否有权限下载

解决方案：

1. 增加访问权限控制，权限标识要存储在服务端的Session中
2. 对于静态文件可以采用程序读取静态文件内容返回给客户端，进而判断用户权限

常用的攻击手段

SQL注入

原理

用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想知道的一些数据，也就是说用户在提交表单的时，该表单字段是SQL语句的一部分，攻击者就可以修改这个字段为SQL的部分语句达到他想达到的目的，比如在用户登入时用户密码后追加'or' 1=1或--注释一部分查询的内容

攻击者可以使用SQL的盲注，进一步探知数据库的结构，最严重的情况下，攻击者可以使用SQL注入读取甚至修改数据库中所有数据，也就是脱库

防御方法

参数化查询SQL（SQL预处理语句）：在建立查询结构，用户输入预留占位符，然后在为指定占位符的内容

XSS跨站脚本攻击

原理

允许攻击者将代码植入到可提供给其他用户使用的页面中（页面注入HTML或js），而其他用户在观看网页时，这些恶意的脚本就会执行，从而得到其他用户的Cookie等内容

XSS分类

• 反射式XSS：非永久性XSS，出现在服务器直接使用客户端提交的数据（未存储到数据库中），也未做无害化处理（没有处理HTML控制字符）的返回给客户端，比如HTML表单提交数据，URL数据
• 存储式XSS：永久性XSS，出现在服务器直接使用客户端提交的数据，但是存入到了数据库中，也未做无害化处理的返回给客户端，比如用户信息字段，上传文件名字段等
• 基于DOM的XSS：也属于非永久性的XSS，出现在客户端使用用户表单的数据作为DOM的内容，也未做无害化处理的在页面中直接显示出来

防御方法

1. 前端输入验证：即表单验证，数据长度限制
2. 前端输出编码：在用到用户输入内容时，使用HTML实体替换哪些HTML控制字符
3. 后端响应编码：与前端输出编码一样，使用HTML实体替换哪些HTML控制字符

CSRF跨站请求伪造攻击

原理

很类似XSS攻击手段，CSRF是通过伪装成受信用户的请求来利用受信的网站，要知道每个网站的登入状态信息会存放到Cookie中自动的发送；假如A站有CSRF漏洞，我已经在A站点通过了身份认证，这时我A站点已经是登入状态，再去访问由在A站点或其他站点发布的带有CSRF攻击内容，攻击者就可以在我不知情的情况下，通过向A站点发送伪装成我发送的请求

防御方法

1. 对敏感操作多增加一些确认操作
2. 对敏感操作要求用户重新验证省份（对于用户来说可能有些复杂，需要在安全和便利性之间做取舍）
3. 使用Token：在用户每次打开要保护的页面时生成一个随机的Token存放到用户的Session中，提交请求时服务端检查提交的Token是否与Session中的一致，不一致时返回一个错误信息给用户
   • 对于要保护的表单中增加一个隐藏字段，从服务器端获取存放这个Token
   • 对于要保护的URL，增加一个参数来存放这个Token