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

圣诞节很快就要到了，对渗透测试的热情仍然有增无减。我们SINE安全在此为用户认证登录安全制定一个全面的检测方法和要点Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该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)的方法。考虑这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（AS-Authentication Server）供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。

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

7.3.2. 简化的认证过程

客户端向服务器发起请求，请求内容是：客户端的principal，服务器的principal

AS收到请求之后，随机生成一个密码Kc, s(session key), 并生成以下两个票据返回给客户端

1.给客户端的票据，用客户端的密码加密，内容为随机密码，session，server_principal

2.给服务器端的票据，用服务器的密码加密，内容为随机密码，session，client_principal

客户端拿到了第二步中的两个票据后，首先用自己的密码解开票据，得到Kc、s，然后生成一个Authenticator，其中主要包括当前时间和Ts,c的校验码，并且用SessionKey Kc,s加密。之后客户端将Authenticator和给server的票据同时发给服务器

服务器首先用自己的密码解开票据，拿到SessionKey Kc,s，然后用Kc,s解开Authenticator，并做如下检查

1.检查Authenticator中的时间戳是不是在当前时间上下5分钟以内，并且检查该时间戳是否首次出现。如果该时间戳不是第一次出现，那说明有人截获了之前客户端发送的内容，进行Replay攻击。

2.检查checksum是否正确

3.如果都正确，客户端就通过了认证

服务器段可选择性地给客户端回复一条消息来完成双向认证，内容为用session key加密的时间戳

客户端通过解开消息，比较发回的时间戳和自己发送的时间戳是否一致，来验证服务器

7.3.3. 完整的认证过程

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

7.4.3. 安全问题

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