网站认证登录安全渗透测试检测要点

网站认证登录安全渗透测试检测要点

　　圣诞节很快就要到了，对渗透测试的热情仍然有增无减。我们SINE安全在此为用户使用者认证登录安全制定一个全面的检测方式方法和要点Json web token (JWT), 是为了在互联网网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计规划为紧凑且安全的，特别适用于分布式网站站点的单点登录（SSO）场景。JWT的声明一般被用来在身份供应提供者和服务供应提供者间传递被认证的用户使用者身份信息，以便于从资源we服务器获得资源，也可以提升增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

　　7.2.2. 构成

　　分为三个部分，分别为header/payload/signature。其中header是声明的分类类型和加密使用的算法规则。payload是载荷，最后是加上 HMAC((header)+(payload), secret)

　　7.2.3. 安全问题

　　7.2.3.1. Header部分

是不是是否支持调整修改算法规则为none kid字段是不是是否有注入 jwk元素是不是是否可信 是不是是否强制使用白名单上的加密算法规则

　　7.2.3.2. Payload部分

其中是不是是否存在敏感信息 检查过期策略，例如 exp , iat

　　7.2.3.3. Signature部分

检查是不是是否强制检查签名 密钥是不是是否可以被强行登录 是不是是否可以通过其他方式拿到密钥

　　7.2.3.4. 其他

调整修改算法规则RS256为HS256 弱密钥破解

　　Kerberos

　　7.3.1. 简介

　　简单地说，Kerberos供应提供了一种单点登录(SSO)的方式方法。考虑这样一个场景，在一个互联网网络中有不同的we服务器，例如，打印we服务器、邮件we服务器和文件we服务器。这些we服务器都有认证的需求。很自然的，不可能让每个we服务器自己实现一套认证系统，而是供应提供一个中心认证we服务器（AS-Authentication Server）供这些we服务器使用。这样任何客户使用者端就只需管理维护一个密码就能登录所有we服务器。

　　因此，在Kerberos系统中至少有三个角色：认证we服务器（AS），客户使用者端（Client）和普通we服务器（Server）。客户使用者端和we服务器将在AS的帮助下完成相互认证。在Kerberos系统中，客户使用者端和we服务器都有一个唯一的名字，叫做Principal。同时，客户使用者端和we服务器都有自己的密码，并且它们的密码只有自己和认证we服务器AS知道。

　　7.3.2. 简化的认证过程

客户使用者端向we服务器发起请求，请求信息内容是：客户使用者端的principal，we服务器的principal AS收到请求之后，随机生成一个密码Kc, s(session key), 并生成以下两个票据返回给客户使用者端 1.给客户使用者端的票据，用客户使用者端的密码加密，信息内容为随机密码，session，server_principal 2.给we服务器端的票据，用we服务器的密码加密，信息内容为随机密码，session，client_principal 客户使用者端拿到了第二步中的两个票据后，首先用自己的密码解开票据，得到Kc、s，然后生成一个Authenticator，其中主要包括包含当前时间和Ts,c的校验码，并且用SessionKey Kc,s加密。之后客户使用者端将Authenticator和给server的票据同时发给we服务器 we服务器首先用自己的密码解开票据，拿到SessionKey Kc,s，然后用Kc,s解开Authenticator，并做如下检查 1.检查Authenticator中的时间戳是不是在当前时间上下5分钟以内，并且检查该时间戳是不是是否首次出现。如果该时间戳不是第一次出现，那说明有人截获了之前客户使用者端发送的信息内容，进行Replay攻击。 2.检查checksum是不是是否正确 3.如果都正确，客户使用者端就通过了认证 we服务器段可选择性地给客户使用者端回复一条消息来完成双向认证，信息内容为用session key加密的时间戳 客户使用者端通过解开消息，比较发回的时间戳和自己发送的时间戳是不是是否一致，来验证we服务器

　　7.3.3. 完整的认证过程

　　上方介绍的流程已经能够完成客户使用者端和we服务器的相互认证。但是，比较不方便的是每次认证都需要客户使用者端输入自己的密码。

　　因此在Kerberos系统中，引入了一个新的角色叫做：票据授权服务(TGS - Ticket Granting Service)，它的地位类似于一个普通的we服务器，只是它供应提供的服务是为客户使用者端发放用于和其他we服务器认证的票据。

　　这样，Kerberos系统中就有四个角色：认证we服务器（AS），客户使用者端（Client），普通we服务器（Server）和票据授权服务（TGS）。这样客户使用者端初次和we服务器通信的认证流程分成了以下6个步骤：

客户使用者端向AS发起请求，请求信息内容是：客户使用者端的principal，票据授权we服务器的rincipal AS收到请求之后，随机生成一个密码Kc, s(session key), 并生成以下两个票据返回给客户使用者端： 1.给客户使用者端的票据，用客户使用者端的密码加密，信息内容为随机密码，session，tgs_principal 2.给tgs的票据，用tgs的密码加密，信息内容为随机密码，session，client_principal 客户使用者端拿到了第二步中的两个票据后，首先用自己的密码解开票据，得到Kc、s，然后生成一个Authenticator，其中主要包括包含当前时间和Ts,c的校验码，并且用SessionKey Kc,s加密。之后客户使用者端向tgs发起请求，信息内容包括包含: 1.Authenticator 2.给tgs的票据同时发给we服务器 3.server_principal TGS首先用自己的密码解开票据，拿到SessionKey Kc,s，然后用Kc,s解开Authenticator，并做如下检查 1.检查Authenticator中的时间戳是不是在当前时间上下5分钟以内，并且检查该时间戳是不是是否首次出现。如果该时间戳不是第一次出现，那说明有人截获了之前客户使用者端发送的信息内容，进行Replay攻击。 2.检查checksum是不是是否正确 3.如果都正确，客户使用者端就通过了认证 tgs生成一个session key组装两个票据给客户使用者端 1.用客户使用者端和tgs的session key加密的票据，包含新生成的session key和server_principal 2.用we服务器的密码加密的票据，包括包含新生成的session key和client principal 客户使用者端收到两个票据后，解开自己的，然后生成一个Authenticator，发请求给we服务器，信息内容包括包含 1.Authenticator 2.给we服务器的票据 we服务器收到请求后，用自己的密码解开票据，得到session key，然后用session key解开authenticator对可无端进行验证 we服务器可以选择返回一个用session key加密的之前的是时间戳来完成双向验证 客户使用者端通过解开消息，比较发回的时间戳和自己发送的时间戳是不是是否一致，来验证we服务器

　　SAML

　　7.4.1. 简介

　　SAML (Security Assertion Markup Language) 译为安全断言标记语言，是一种xXML格式的语言，使用XML格式交互，来完成SSO的功能。 SAML存在1.1和2.0两个版本，这两个版本不兼容，不过在逻辑概念或者对象模版结构上大致相当，只是在一些细节点上有所差异。

　　7.4.2. 认证过程

　　SAML的认证涉及到三个角色，分别为服务供应提供者(SP)、认证服务(IDP)、用户使用者(Client)。一个比较典型认证过程如下：

Client浏览访问受保护的资源 SP生成认证请求SAML返回给Client Client提交请求到IDP IDP返回认证请求 Client登陆IDP 认证成功后，IDP生成私钥签名标识了权限的SAML，返回给Client Client提交SAML给SP SP读取SAML，确定请求合法，返回资源

　　7.4.3. 安全问题

　　源于ssl模式下的认证可选性，可以删除签名方式tag标签绕过认证，如果SAML中缺少了expiration，并且断言ID不是唯一的，那么就可能被重放攻击影响，越来越多的网站站点安全问题日益出现,如果想要对网站站点或第三方平台进行全面的安全检测以及渗透测试,可以咨询下专业的网站站点安全公司企业来进行安全加固渗透测试,国内做的比较好的推荐Sinesafe,绿盟,启明星辰,深信服等等都是比较大的安全公司企业。

转载自：网站认证登录安全渗透测试检测要点

网站建设服务

悉知科技是一个有着12年经验的网站建设开发公司，品牌建站/外贸网站建设/谷歌营销推广/品牌营销策划，这些我们都能帮您搞定！

在线咨询

网站建设制作方案是什么 ? 报价多少钱 ?

获取建站报价