我今年近期的工作中作为系统架构师身份,对一个现有系统的框架从架构设计的伸缩性和安全性等方面进行了评估,发现了以下安全性问题。
它的现系统的ticket的生成是用以下代码生成的:
package com.xxx.sna.server.utils;
import org.apache.commons.codec.digest.DigestUtils;
import org.apache.commons.lang.BooleanUtils;
public class TicketBuilder {
private static final String ENCRYPT_KEY = "!@$%6*He(8HJ79dsFGKD";
/**
* 取得随机密钥
*
* @return
*/
private static final String getEncryptKey() {
return ENCRYPT_KEY;
}
/**
* 生成Ticket
*
* @param account
* @return
*/
public static final String generateTicket(String account) {
return DigestUtils.md5Hex(account + getEncryptKey());
}
/**
* 匹配Ticket
*
* @return
*/
public static final boolean match(String account, String ticket) {
return generateTicket(account).equals(ticket);
}
public static void main(String[] args) {
// System.out.println(TicketBuilder.generateTicket("roymax"));
// System.out.println(TicketBuilder.match("roymax",
// generateTicket("roymax")));
System.out.println(BooleanUtils.toInteger(true));
System.out.println(BooleanUtils.toInteger(false));
}
}
大家有没发现什么问题呢?
下面是我发现问题后对此的相关对话记录:
Wooce 2009-03-09 18:31:12
我觉得SNA的cookie里没有跟具体会话有关的信息, 就是说,只要登录一次,这次登录的cookie完全可以用来伪造为下次登录使用?
XXX 2009-03-09 18:33:39
嗯,用到cookie是有一点安全隐患
Wooce 2009-03-09 18:35:26
只要cookie里是能保存每次登录都不同的session id, 那么,既能解决我下午所说的问题, 又能保证比较好的安全性, 对不对?
XXX 2009-03-09 18:37:23
我查一下代码,现在保存的sna_ticket值应该是每次登录都不同才对
Wooce 2009-03-09 18:38:25
不是啊。
public static final String generateTicket(String account) {
return DigestUtils.md5Hex(account + getEncryptKey());
}
Wooce 2009-03-09 18:38:56
getEnryptKey()又返回每次都一样的:
private static final String ENCRYPT_KEY = "!@$%6*He(8HJ79dsFGKD"
Wooce 2009-03-09 18:39:17
所以, sna_ticket值每次登录都会是一样的,:)
XXX 2009-03-09 18:39:17
嗯,知道了~~~~~~呵呵,这代码改过
XXX 2009-03-09 18:40:06
是的,只要每次登录的值不同就可以
Wooce 2009-03-09 18:43:43
+系统当前时间+user id+随机串,然后再加密, 就保证每次和每个用户都不同了, 就可以完全把sna_ticket当session id用了
分享到:
相关推荐
在SSO场景下,当用户首次登录SSO服务端(sso-server)时,服务端会生成一个唯一的识别码,通常称为Ticket Granting Cookie(TGC)。这个TGC被加密并存储在用户的浏览器中,作为用户身份的凭证。 Ticket则是SSO过程...
SSO的核心是中央认证服务(CAS),它负责处理用户的登录请求并生成一个安全的票据(Ticket Granting Ticket, TGT)。当用户尝试访问受保护的应用时,应用会重定向用户到CAS进行身份验证。如果用户已经登录,CAS会...
一旦验证成功,服务器会生成一个票据(Ticket),并将用户重定向回原应用,应用通过验证这个票据来确认用户的身份,从而允许其访问。 在这个Demo中,我们有两个Web应用,SSOWebDemo1和SSOWebDemo2,它们都需要共享...
XXL-SSO是一个专为分布式环境设计的单点登录(Single Sign-On,简称SSO)框架,旨在简化用户在多个相互信任的应用系统之间的身份验证流程。用户只需进行一次登录,即可无限制地访问所有关联的系统,极大地提高了用户...
SSO的核心在于票据(Ticket)的概念,当用户首次登录时,服务器会生成一个安全的票据,并将其返回给客户端。客户端在后续请求中携带这个票据,服务器通过验证票据来确认用户的身份。C#中,我们可以利用.NET ...
SSO主要依赖于票据(Ticket)的概念,当用户成功登录到一个系统时,服务器会生成一个唯一的票据,并将其发送给客户端。后续访问其他系统时,客户端会携带这个票据,通过验证票据的合法性来实现免登录。 在基于SSM和...
一旦认证成功,CAS会为用户生成一个Ticket Granting Ticket(TGT),这个TGT存储在用户的浏览器cookie中。当用户尝试访问其他受保护的应用时,应用会将TGT传递给CAS进行验证,如果验证通过,CAS会为该应用生成一个...
3. **Service Ticket**:用户请求访问其他应用时,会携带TGT到CAS服务器,CAS会验证TGT并生成一个Service Ticket,这个Service Ticket是为特定服务而生成的,然后将Service Ticket发送给客户端。 4. **服务验证**:...
一旦验证成功,CAS会生成一个票据(Ticket),并将其返回给用户,用户再用这个票据去访问其他应用,而无需再次登录。 2. SSO的实现方式: - **基于Cookie的SSO**:最常见的实现方式,通过设置共享的Cookie在各个...
1. **票据(Ticket)机制**:用户成功登录后,SSO服务器会生成一个安全的票据,通常称为ST(Service Ticket)或TGT(Ticket Granting Ticket),用于后续的访问验证。 2. **中央认证服务(CAS)**:一种常见的SSO...
SSO是通过一个中心认证服务(CAS,Central Authentication Service)来完成的,这个服务验证用户的身份后,会生成一个票据(ticket),用户拿着这个票据就可以访问其他已经与CAS集成的应用系统,而不需要再次输入...
一旦验证成功,CAS将生成一个票证(Ticket),该票证随后被用于后续的请求,证明用户已通过身份验证,无需再次登录。 **二、WebSphere Application Server SSO配置步骤** 1. **选择SSO类型**:WebSphere支持多种...
在实际开发中,还需要考虑安全性问题,如防止CSRF攻击、保护敏感信息传输等。此外,为保证高可用性,Memcached集群的配置也很重要,可以采用复制或分片策略来提高数据的可靠性和读写性能。 综上所述,"sso.zip_sso_...
- 用户在认证系统中提供登录信息,系统验证后,若信息正确,会生成一个唯一的认证凭据,即ticket。 - 用户随后访问其他应用系统(如系统2或系统3)时,将携带这个ticket。 - 应用系统接收到请求并检测到ticket,...
4. 验证成功后,SSO服务器生成一个票据(Ticket Granting Ticket,TGT)并存储在服务器端,同时向用户返回一个服务票据(Service Ticket,ST)。 5. 用户携带ST返回原始应用。 6. 应用向SSO服务器验证ST,验证通过则...
在实际操作中,SSO的优势在于提高了用户体验,减少了登录的繁琐过程,同时也强化了安全性,因为所有验证都集中在一个地方。然而,这也带来了一定的风险,比如AC的安全性直接影响到所有SP,因此对AC的保护尤为重要。 ...
SSO(Single Sign-On)是一种身份验证机制,它允许用户在一个系统上登录后,无需再次认证即可访问其他相互信任的系统。这个"SSO Demo 例子"是一个教学资源,旨在帮助初学者理解并实践SSO的实施过程。下面将详细阐述...
4. SSO服务器验证成功后,生成TGT并存储在服务器端,同时创建一个服务票证(Service Ticket,ST)发送回客户端。 5. 客户端收到ST后,将其提交给原始应用。 6. 应用验证ST的有效性,通过后允许用户访问受保护资源。 ...
3. **生成Service Ticket (ST)**:登录成功后,SSO服务器会生成一个一次性使用的票据——Service Ticket(ST),并将用户重定向回原申请访问的应用系统。 4. **应用系统验证ST**:接收到来自SSO服务器的重定向后,...
9. **监控与日志**:为了保证服务的稳定性和安全性,SSO服务端程序应包含日志记录和监控功能,以便追踪和诊断问题。 10. **异常处理与错误重定向**:当用户认证失败或发生其他错误时,服务端需能够正确处理这些情况...