怪我咯2017-04-18 10:57:00
합법과 불법을 어떻게 정의하시나요? SSO 프레임워크에서는 토큰이 있으면 옆으로 이동하고, 제3자인 경우에는 반드시 appid와 appsecret이 필요합니다. 승인이 필요한 경우에도 AccessToken을 가져와야 합니다. 가장 간단한 방법은 신뢰할 수 있는 IP만 통과하도록 IP 인터셉터를 작성하는 것이지만, 일반적으로 상대방이 토큰이나 앱 비밀을 제공하는 경우에는 기본적으로 사용됩니다. 합법적이죠?
高洛峰2017-04-18 10:57:00
API를 설계할 때 RESTful API의 보안을 보장하려면 세 가지 주요 측면을 고려해야 합니다.
1. 제한된 리소스에 대한 로그인 인증
2. 요청에 대한 신원 인증
3. 민감한 데이터 암호화
1. 제한된 리소스에 대한 로그인 인증
이 프로세스는 이 글의 초점이 아니며 기본 프로세스는 다음과 같습니다.
클라이언트가 계정 정보(사용자 이름 + 비밀번호)를 서버에 제출합니다.
서버가 성공적으로 확인하고 저장을 위해 AccessToken을 클라이언트에 반환합니다
3. 제한된 리소스에 액세스할 때 클라이언트는 AccessToken을 가져와 액세스할 수 있습니다.
2. 인증 요청
요청에 서명 및 인증이 이루어지지 않은 경우 fiddler 등의 도구를 통해 쉽게 데이터를 캡처하고 변조하여 제출하고 대규모 일괄 호출을 할 수 있습니다. 많은 양의 데이터와 시스템 리소스가 소모되고 심지어 정상적으로 사용할 수도 없기 때문에(물론 GateWay를 통해 전류가 제한될 수 있음) 시스템에 대한 서명 인증을 수행해야 합니다. 요구.
URL 형식
URL:schema://domain/path?query&imei×tamp&sign
매개변수 설명
서명 방법
sign=signature(path?query&imei×tamp&SIGN_KEY)
검증 과정
인증 로직
1. 처음에는 서버에 각 App 버전의 SIGN_KEY가 있고, 클라이언트에는 해당 버전의 SIGN_KEY가 있습니다
2. 암호화하여 서명 받기
3. 요청을 보낼 때 서명과 함께 서버에 보냅니다.
4. 서버는 먼저 타임스탬프가 유효한지 확인합니다. 예를 들어 5분 전의 서버 타임스탬프가 있는 요청입니다. ;
5. 그런 다음 해당 버전의 SIGN_KEY를 가져와서 서명이 유효한지 확인하세요
6. 재생 공격을 방지하려면 서명이 Redis에 저장되어 있는지 확인해야 합니다. 존재하지 않으면 redis에 저장하세요(5분간 캐시)
데이터 변조를 방지하는 방법
여기서 서명 매개변수에는 원래 요청의 모든 매개변수가 포함됩니다. 매개변수가 변경되면 부호 값이 달라지므로 변조할 수 없습니다.
재생 공격 방지 방법
서명 알고리즘에는 imei(고유 장치 ID) 및 타임스탬프 매개변수도 있고 서명 알고리즘은 되돌릴 수 없는 알고리즘(예: md5 또는 sha1)이므로 각 일반 요청에 대한 서명 값은 반복하지 않습니다. 이때 서버는 재생 공격 시 검증 및 필터링을 위해 5분 기호 값을 저장할 수 있으며, 5분을 초과하는 요청은 타임스탬프 검증을 통해 직접 필터링됩니다.
요약
이렇게 하면 데이터 변조 및 재생 공격을 방지하기 위해 요청 인증이 이루어지지만, 앱 키(SIGN_KEY)의 안전한 저장이 필요하다는 장점이 있습니다. 구현하지만 비밀번호 키를 안전하게 보관해야 하는 책임과 이를 정기적으로 업데이트해야 하는 부담이 있다는 단점이 있습니다.
3. 민감한 데이터 암호화
1) SSL 인프라(예: HTTPS)를 배포합니다. 민감한 데이터의 모든 전송은 SSL을 기반으로 합니다.
2) 일부 민감한 데이터(예: 계좌번호 + 비밀번호)만 암호화하고, 데이터 변조를 방지하기 위해 임의의 숫자를 암호화 솔트로 추가합니다.
PHPz2017-04-18 10:57:00
RSA 암호화 알고리즘을 사용하여 요청 데이터의 매개변수를 json으로 변환한 다음 서버 RSA 인증서를 사용하여 json을 암호화합니다.
