java - 关于"api接口的sign的设计"的一点点疑惑
阿神
阿神 2017-04-18 09:30:03
0
3
1102

**感谢mcfog和yc8332的回答
按照mcfog的回答
如果sign的算法公开的话, sign不就没有校验功能了吗, 恶意攻击的人也可以根据该算法生成sign了**

刚读了一篇相关的博文, 有一点不明, 请大家解惑,谢谢

文中讲到sign是根据用户"请求的所有参数,包括timestamp还有token", 然后通过加密算法生成的sign.
然后他说在验证sign的时候是通过相同的加密规则生成一个sign, 看是否与请求的sign相同.

我的疑惑来了:

  1. 用户是怎么知道合法的sign是什么, 是在用户登录成功后, 和token一起返回给客户端的吗?

  2. 如果是的话这个token和sign在客户端和服务器端一般是怎么保存的, 是都存放在cookie中和session中?

  3. 每次请求的参数和时间戳一定是不同的, 怎么会能"根据用户请求的url参数, 重现出原来加密出的sign", 加密的原始素材只有token没变, 而其他的都变了, 怎么一样呢.

博文的原文如下:

"将所有用户请求的参数按照字母排序(包括timestamp,token),然后根据MD5加密(可以加点盐),全部大写,生成sign签名,这就是所说的url签名算法。然后登陆后每次调用用户信息时,带上sign,timestamp,token参数。"

"根据用户请求的url参数,服务器端按照同样的规则生成sign签名,对比签名看是否相等,相等则放行。(自然url签名也无法100%保证其安全,也可以通过公钥AES对数据和url加密,但这样如果无法确保公钥丢失,所以签名只是很大程度上保证安全)"

阿神
阿神

闭关修行中......

모든 응답(3)
黄舟

로그인은 저장되지 않고 동적이며 제출된 매개변수에 따라 암호화됩니다. 주로 중간자 공격이나 데이터 무결성을 방지하는 데 사용됩니다.

阿神

1. 부호의 알고리즘은 서버에 의해 공개됩니다. 클라이언트는 요청할 때마다 부호를 스스로 계산합니다.
2. 계산될 때마다 서명합니다. 컨텍스트가 부족하고 그것이 무엇인지에 대한 설명이 없습니다. 다음 두 가지일 수 있습니다

  1. 일반적으로 "비밀"이라고 알려진 개인 문자열은 서버가 클라이언트에게 발행하는 문자열입니다. 클라이언트는 이 문자열을 유출로부터 보호해야 하며, 클라이언트의 법적 신원을 확인하기 위해 매번 서명에 참여하는 데 이 문자열을 사용해야 합니다. 클라이언트는 일반적으로 구성에 배치되며 서버에는 일반적으로 다른 클라이언트의 비밀 값을 유지하기 위한 데이터베이스가 있습니다

  2. 일반적으로 "액세스 토큰"으로 알려져 있으며 로그인 인터페이스 요청을 통해 클라이언트가 얻은 세션 ID와 유사한 문자열로 로그인 상태를 나타냅니다.

공격자가 요청을 변조/위조하는 것을 방지하기 위해 일반적으로 서명 요소에는 공격자가 획득하기 어려운 요소가 하나 이상 포함되어 있습니다. 가장 일반적인 요소는 양측이 합의한 비밀입니다.

재생 공격을 방지하려면 데이터 패킷에 고유한 요청 시퀀스 번호/밀리초 시간 및 기타 유형의 요소를 포함하고 서버 측에서 중복 제거 처리를 수행하는 것이 가장 좋습니다

3, 서버가 요청을 받은 후 처리 방법을 설명합니다. 부호 알고리즘을 사용하여 수신된 요청의 다양한 매개변수를 통해 부호 값을 계산하고 이를 클라이언트가 제출한 부호 값과 비교합니다. 클라이언트가 올바르게 계산했습니다.

제안: 제목 책에서는 너무 많이 읽었고 너무 적게 수행했습니다. 특히 OAuth와 같은 여러 실제 API 인터페이스에 연결하면 기본적으로 이러한 내용을 이해할 수 있습니다.

洪涛

공개란 자신의 사람들에게 공개하는 것을 의미합니다. 이것을 걱정하고 싶다면 세상에 안전한 것은 없습니다. 처리도 안 돼요

최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿