zoukankan      html  css  js  c++  java
  • WEB服务端安全---认证会话与访问控制

    一、认证与会话管理

      认证:简而言之就是通过一定的凭证认出用户是谁。认证过程中按凭证数量可简单分为 ‘单因素认证’、‘双因素认证’或多因素认证。一般来说,多因素认证强度更高,但是用户体验上会比单因素认证麻烦些。

      1、单因素认证(密码认证)

      密码是最常见的认证手段,持有正确密码的人被认为是可信的。其优势在于使用成本低,认证过程实现起来简单,但属于一种比较弱的安全方案,可能被猜出。因此密码的设定需要一定的策略。

      目前还没有标准的密码策略,可以看看OWASP(开放式Web应用程序安全项目)推荐的一些最佳实践做一些密码策略的总结:

      密码长度:

        普通密码要求长度为6位以上;

        重要的密码要求长度为8位以上;

      密码复杂度:

        密码区分大小写;

        密码为大写字母、小写字母,字数,特殊符号中两张以上的组合;

        不要有连续的数字 如:1234546abcd

        尽量避免出现重复的字符

      除此之外还要注意不要使用用户公开的数据或与隐私相关的数据作为密码。

      密码保存

      密码要以不可逆的加密算法,或单向散列函数算法,加密后存储在数据库中。

      目前黑客广泛使用的破解MD5后密码的方法是 ’彩虹表‘。彩虹表思路是尽可能多的手机多的密码明文和明文对应的MD5值,这样只需要查询MD5值就可能找到MD5值对应的明文。为了避免密码哈希值泄露后,黑客能够通过彩虹表查询出密码明文,在计算密码明文的哈希值时,增加一个“Salt”。可以增加明文的复杂度,使彩虹表这一类的攻击失效如: MD5(username + password + salt) 其中 salt 为随机字符串,需要保到服务器相关位置,妥善保管。

      2、多因素认证

        很多重要的系统,如网上银行和网上支付平台在用单一的密码认证明显是不够的,一般都需要采用双因素或多因素认证。如支付宝提供的认证手段:除了支付密码外,手机动态口令、数字证书、宝令、支付盾、第三方证书等都可以用于用户认证。这些不同认证手段可以相互结合,使得证书的过程更安全。

        多因素认证提高了攻击的门槛,比如 一个支付交易使用了密码和数字证书认证双因素认证,攻击者除了盗取到密码外还必须想办法在用户电脑上完成支付,这样大大提高了攻击的成本。

      3、session与认证

        密码证书等认证手段,一般都是用于登录过程的。当完成登录后,用户访问网站的页面不可能每次都去使用登录认证手段进行认证,因此当用户认证后就需要替换一个对用户透明的凭证。这个凭证就是SessionID。

        当用户登录完成后,在服务器端就会创建一个新的会话(Session),会话中保存用户的信息和状态。服务器端维护所有在线用户的Session,此时的认证,只需要知道是哪个用户在浏览当前页面即可。为了告诉服务器应该使用哪个session 浏览器需要把当前用户持有的SessionID告知服务器。

        最常见的做法就是把SessionID加密后保存在Cookie中,因为Cookie会随着HTTP请求头发送,且受到浏览器同源策略的保护。 

        SessionID一旦在生命周期中被窃取,就等同于账户失窃。

        Session劫持就是一种通过窃取用户SessionID后,使用该SessionID登录进目标账户的攻击方法。此时攻击者实际上是使用了目标账户的有效Session。

        如果SessionID是保存在Cookie中的,则这种攻击可以称为Cookie劫持。

        SessionID除了可以保存在Cookie中外,还可以保存在URL中,作为请求的一个参数。 但是这种方式的安全性难以经受考验。

        在生成SessionID时,需要保证足够的随机性,比如采用足够强的伪随机数生成算法。

        Session Fixation攻击

        卖车,不换锁的例子。 

        这个没有换“锁”而导致的安全问题,就是Session Fixation问题。

        在用户登录网站的过程中,如果登录前后用户的SessionID没有发生变化,则会存在Session Fixation问题。

        解决Session Fixation的正确做法:在登录完成后,重写SessionID

      

        Session保持攻击

        Session如果一直未能失效,会导致什么问题呢? 

          a 如果攻击者能一直持有一个有效的Session,而服务器对于活动的Session也一直不销毁的话,攻击者就能通过此有效Session,一直使用用户的账户,成为一个永久的“后门”

        攻击者如何永久地持有一个Session? 

          a 攻击者可以通过不停地发起访问请求,让Session一直“活”下去。

          b Cookie是可以完全由客户端控制的,通过发送带有自定义Cookie头地HTTP包。

          c 有一种做法是服务器端不维护Session,而把Session放在Cookie中加密保存。 

             Cookie的Expire时间是完全可以由客户端控制的。 

              ① 篡改这个时间,并使之永久有效,就有可能获得一个永久有效的Session,而服务器端完全无法察觉。

              ② 攻击者甚至可以为Session Cookie增加一个Expire时间,使之持久化地保存在本地,变成一个第三方Cookie。

        如何对抗这种Session保持攻击? 

          a 在一定时间后,强制销毁Session

          b 当用户客户端发生变化时,要求用户重新登录。 如IP、UserAgent等信息。

          c 每个用户只允许拥有一个Session。

      4、单点登录(Single Sign On,SSO)

        单点登陆,希望用户只需要登录一次,就可以访问所有的系统

        SSO的优点:在于风险集中化,就只需要保护好这一点。

        SSO的缺点:因为风险集中了,所以单点一旦被攻破的话,后果会非常严重,影响的范围将涉及所有使用单点登录的系统。降低这种风险的办法:在一些敏感的系统里,再单独实现一些额外的认证机制。

        目前最为开放和流行的单点登录系统时OpenID。

          OpenID模式仍然存在一些问题

          OpenID的提供者服务水平也有高有低

    二、访问控制

      访问控制也可以说是权限控制,是某个主体对某个客体需要实施某种操作,而系统对这种操作的限制就是权限控制。

      在一个安全系统中,确定主题的身份是 ’认证‘ 解决的问题;而客体是一种资源,是主体发起请求的对象。在主体对客体的操作过程中,系统控制主体不能 无限制 的对客体进行操作,这个过程就是 访问控制。

      1、垂直权限管理

        垂直权限管理实际就是 基于角色的权限管理(RBAC模型)。

        不同角色的权限有高低之分。高权限角色访问低权限角色的资源往往是被允许的,而低权限角色访问高权限角色资源通常是被禁止的。若一个本属于低权限的用户通过一些方法能够获得高权限角色的能力,则发生了“越权访问”。在配置权限时,应当使用“最小权限原则”,并使用“默认拒绝”的策略,只对有需要的主体单独配置“允许“的策略。这在很多时候能够避免发生”越权访问“。

      2、水平权限管理

        水平权限管理可以看成 基于数据的访问控制

        相对于垂直权限管理来说,水平权限问题处在同意角色上,系统只验证了能访问数据的角色,既没有对角色内的用户进行细分,也没有对数据的子集做细分,因此缺乏一个用户到数据的对应关系。

      3、OAuth

        OAuth 是在不提供用户名和密码的情况下,授权第三方应用访问web资源的安全协议。可实现不同网站之间的互通。

        常见应用OAuth的场景,一般是某个网站想要获取一个用户在第三方网站中的某些资源或服务。

        OAuth 目前已到了OAuth2,具体原、流程、应用可具体学习。

  • 相关阅读:
    Sql inner join
    转:MySQL 的show processlist
    session cookie
    集群和分布式
    设计模式
    Web性能优化——缓存
    关于 java 里面的路径
    1分钟看懂log4j 配置自己想要的日志信息
    spring @bean 的理解
    如何用iptables实现NAT(转)
  • 原文地址:https://www.cnblogs.com/yimingwang/p/10077636.html
Copyright © 2011-2022 走看看