Api 디자인 4 요소

https 프로 토 콜 을 제외 하고 통용 되 는 알고리즘 과 규범 을 더 해서 전송의 안전성 을 확보 할 수 있 습 니까?이 동시에 Api 디자인 이 고려 해 야 할 네 가지 요소: 인터페이스 디자인, 안전 보증, 서명 처리, 중복 방지 디자인;이 네 시 에 어떻게 착수 합 니까?본 고 는 일부 총 결 연 구 를 가지 고 이 네 가지 측면 을 중심 으로 전개 되 었 다.
목차

token 소개

timestamp 프로필

sign 소개

중복 제출 방지

사용 절차

token 프로필Token: 영패 access token 을 방문 하여 인터페이스 에 사용 하고 인터페이스 호출 자의 신분, 증빙 을 표시 하 며 사용자 이름과 비밀번호 의 전송 횟수 를 줄인다.일반적인 상황 에서 클 라 이언 트 (인터페이스 호출 자) 는 먼저 서버 측 에 인터페이스 호출 계 정 을 신청 해 야 합 니 다. 서버 는 appId 와 key 를 제공 합 니 다. key 는 매개 변수 서명 에 사용 되 고 key 가 클 라 이언 트 에 저장 되 는 것 을 주의 하 며 안전 처 리 를 하여 유출 을 방지 해 야 합 니 다.
Token 의 값 은 보통 UUID 입 니 다. 서버 에서 Token 을 생 성 한 후에 token 을 key 로 해 야 합 니 다. token 과 관련 된 정 보 를 value 로 캐 시 서버 (redis) 에 저장 합 니 다. 요청 이 오 면 서버 에서 이 Token 이 존재 하 는 지 캐 시 서버 에 조회 하고 저장 하면 인 터 페 이 스 를 호출 합 니 다. 인터페이스 로 돌아 가 는 오류 가 없습니다. 보통 차단기 나 필 터 를 통 해 이 루어 집 니 다.Token 은 두 가지 로 나 뉜 다. API Token( ) 사용자 로그 인 이 필요 없 는 인터페이스, 예 를 들 어 로그 인, 등록, 기본 데이터 획득 등 을 방문 하 는 데 사용 된다.인터페이스 토 큰 을 가 져 오 려 면 appId, timestamp, sign 으로 바 꿔 야 합 니 다. sign = 암호 화 (timestamp + key) USER Token (사용자 토 큰) `: 사용자 가 로그 인 한 후의 인터페이스 에 접근 하 는 데 사 용 됩 니 다. 예 를 들 어 제 기본 정보 가 져 오기, 저장, 수정, 삭제 등 입 니 다.사용자 토 큰 을 가 져 오 려 면 사용자 이름과 비밀 번 호 를 바 꿔 야 합 니 다. Token : token 은 일회 성 일 수도 있 고 한 동안 유효 할 수도 있 으 며 구체 적 으로 어떤 것 을 사용 하여 업무 수 요 를 볼 수 있 습 니까?일반적인 상황 에서 인 터 페 이 스 는 https 프로 토 콜 을 사용 하 는 것 이 좋 습 니 다. http 프로 토 콜 을 사용 하면 Token 체 제 는 해 킹 될 가능성 을 줄 이 는 것 일 뿐 군 자 를 막 을 수 밖 에 없고 소인 을 막 을 수 없습니다.일반적으로 token, timestamp, sign 세 개의 매개 변 수 는 인터페이스 에서 동시에 매개 변수 로 전달 되 고 모든 매개 변 수 는 각자 의 용도 가 있 습 니 다.
timestamp 프로필timestamp: 타임 스탬프 는 클 라 이언 트 가 인 터 페 이 스 를 호출 할 때 대응 하 는 현재 시간 스탬프 입 니 다. 타임 스탬프 는 DoS 공격 을 방지 하 는 데 사 용 됩 니 다.해커 가 요청 한 url 을 DoS 공격 으로 납 치 했 을 때 인 터 페 이 스 를 호출 할 때마다 인 터 페 이 스 는 서버 의 현재 시스템 시간 과 인터페이스 에서 전 달 된 timestamp 의 차 이 를 판단 합 니 다. 이 차이 가 설정 한 시간 (5 분) 을 초과 하면 이 요청 은 차단 되 고 설 정 된 시간 초과 범위 내 에서 DoS 공격 을 막 을 수 없습니다.timestamp 메커니즘 은 DoS 공격 시간 을 줄 이 고 공격 시간 을 단축 시 킬 수 있 습 니 다.만약 해커 가 시간 스탬프 의 값 을 수정 했다 면 sign 서명 메커니즘 을 통 해 처리 할 수 있다.DoS
DoS 는 서 비 스 를 거부 해 DoS 를 일 으 키 는 공격 행 위 를 컴퓨터 나 네트워크 가 정상 적 인 서 비 스 를 제공 하지 못 하도록 하기 위 한 DoS 공격 이 라 고 하 는 데 니 얼 오 브 서비스의 줄 임 말이다.가장 흔히 볼 수 있 는 DoS 공격 은 컴퓨터 네트워크 대역 폭 공격 과 연계 성 공격 이 있다.DoS 공격 이란 의도 적 으로 네트워크 프로 토 콜 이 실현 하 는 결함 을 공격 하거나 공격 대상 의 자원 을 야만 적 인 수단 으로 잔인하게 소모 하 는 것 을 말한다. 목표 컴퓨터 나 네트워크 가 정상 적 인 서비스 나 자원 접근 을 제공 하지 못 하 게 하고 목표 시스템 서비스 시스템 이 응답 을 정지 하거나 붕괴 시 키 는 것 을 목적 으로 하 며 이 공격 에는 목표 서버 나 목표 네트워크 장치 에 침입 하 는 것 이 포함 되 지 않 는 다.이러한 서비스 자원 은 네트워크 대역 폭, 파일 시스템 공간 용량, 열 린 프로 세 스 또는 허용 되 는 연결 을 포함한다.이런 공격 은 컴퓨터 의 처리 속도 가 아무리 빠 르 고 메모리 용량 이 아무리 크 며 네트워크 대역 폭 의 속도 가 아무리 빨 라 도 이런 공격 이 가 져 오 는 결 과 를 피 할 수 없다.
Pingflood: 이 공격 은 짧 은 시간 안에 목적 호스트 에 대량의 ping 패 키 지 를 보 내 네트워크 가 막 히 거나 호스트 자원 이 소 진 됩 니 다.Synflood: 이 공격 은 여러 개의 무 작위 소스 호스트 주소 로 목적 호스트 에 SYN 패 키 지 를 보 냅 니 다. 대상 호스트 의 SYN ACK 를 받 은 후에 응답 하지 않 습 니 다. 그러면 목적 호스트 는 이러한 소스 호스트 에 대량의 연결 대기 열 을 만 들 었 고 ACK 를 받 지 못 해 이 대기 열 을 유지 하고 있 기 때문에 자원 의 대량 소 모 를 초래 하여 정상 적 인 요청 에 서 비 스 를 제공 하지 못 합 니 다.Smurf: 이 공격 은 하위 네트워크 의 방송 주소 에 특정 요청 (예 를 들 어 ICMP 응답 요청) 이 있 는 가방 을 보 내 고 원본 주 소 를 공격 하고 자 하 는 호스트 주소 로 위장 합 니 다.하위 네트워크 의 모든 호스트 가 라디오 패키지 요청 에 응답 하여 공격 당 한 호스트 에 게 패 키 지 를 보 내 호스트 가 공격 을 받 게 합 니 다.Land - based: 공격 자 는 가방 의 소스 주소 와 목적 주 소 를 대상 호스트 의 주소 로 설정 한 다음 에 이 가방 을 IP 사기 방식 으로 공격 당 하 는 호스트 에 게 보 냅 니 다. 이 가방 은 공격 당 하 는 호스트 가 자신 과 연결 을 시도 하여 순환 에 빠 져 시스템 성능 을 어느 정도 낮 출 수 있 습 니 다.Ping of Death: TCP / IP 의 규범 에 따라 가방 의 길 이 는 최대 65536 바이트 입 니 다.비록 한 가방 의 길 이 는 65536 바이트 를 초과 할 수 없 지만, 한 가방 이 나 누 어 진 여러 부분의 중첩 은 할 수 있다.호스트 가 65536 바이트 이상 의 가방 을 받 았 을 때 Ping of Death 의 공격 을 받 았 습 니 다. 이 공격 은 호스트 의 다운 을 초래 할 수 있 습 니 다.Teardrop: IP 패 킷 이 네트워크 에서 전 달 될 때 패 킷 은 더 작은 세 션 으로 나 눌 수 있 습 니 다.공격 자 는 두 단락 (또는 그 이상) 의 패 킷 을 보 내 TearDrop 공격 을 실현 할 수 있다.첫 번 째 가방 의 오프셋 은 0 이 고 길 이 는 N 이 며 두 번 째 가방 의 오프셋 은 N 보다 적다.이러한 데이터 세그먼트 를 통합 하기 위해 TCP / IP 스 택 은 이례 적 인 커 다란 자원 을 분배 하여 시스템 자원 의 부족, 심지어 기계 의 재 시작 을 초래 할 것 이다.PingSweet: ICMP Echo 를 사용 하여 여러 호스트 에 문의 합 니 다.
sign 프로필
nonce: 랜 덤 값 은 클 라 이언 트 가 랜 덤 으로 생 성 한 값 으로 매개 변수 로 전달 되 며 랜 덤 값 의 목적 은 sign 서명 의 다 변성 을 증가 하 는 것 입 니 다.무 작위 값 은 일반적으로 숫자 와 자모의 조합 이 고 6 자리 길이 이 며 무 작위 값 의 구성 과 길 이 는 고정된 규칙 이 없다.sign: 일반적으로 매개 변수 서명 에 사용 되 며, 매개 변수 가 불법 으로 변경 되 는 것 을 방지 합 니 다. 가장 흔히 볼 수 있 는 것 은 금액 수정 등 중요 한 민감 한 매개 변수 입 니 다. sign 의 값 은 일반적으로 모든 비 어 있 는 매개 변 수 를 승 속 에 따라 정렬 한 다음 + token + key + timestamp + nonce (난수) 를 연결 한 다음 에 특정한 암호 화 알고리즘 을 사용 하여 암호 화 시 켜 인터페이스 에 있 는 매개 변수 sign 으로 전달 합 니 다.sign 을 요청 머리 에 넣 을 수도 있 습 니 다.인 터 페 이 스 는 네트워크 전송 과정 에서 해커 에 게 납치 되 고 그 중의 매개 변수 값 을 수정 한 다음 에 인 터 페 이 스 를 계속 호출 합 니 다. 매개 변수 값 이 수정 되 었 지만 해커 는 sign 이 어떻게 계산 되 었 는 지 모 르 기 때문에 sign 이 어떤 값 으로 구성 되 었 는 지 모 르 고 어떤 순서 로 연결 되 었 는 지 모 릅 니 다. 가장 중요 한 것 은 서명 문자열 중의 key 가 무엇 인지 모 릅 니 다.따라서 해커 는 매개 변수의 값 을 변경 할 수 있 지만 sign 의 값 을 수정 할 수 없습니다. 서버 가 인 터 페 이 스 를 호출 하기 전에 sign 의 규칙 에 따라 sign 의 값 을 다시 계산 한 다음 에 인터페이스 가 전달 하 는 sign 매개 변수의 값 과 비교 합 니 다. 만약 에 똑 같이 매개 변수 값 이 변경 되 지 않 았 음 을 나타 내 고 다 르 면 매개 변수 가 불법 으로 변경 되 었 음 을 나타 내 고 인 터 페 이 스 를 실행 하지 않 습 니 다.
중복 제출 방지
일부 중요 한 작업 에 대해 클 라 이언 트 가 중복 제출 하 는 것 을 방지 해 야 합 니 다 (예 를 들 어 비 멱 등 중요 한 작업). 구체 적 인 방법 은 첫 번 째 제출 을 요청 할 때 sign 을 key 로 redis 에 저장 하고 시간 초과 시간 을 설정 하 는 것 입 니 다. 시간 초과 시간 은 Timestamp 에서 설정 한 차이 와 같 습 니 다.같은 요청 이 두 번 째 로 접근 할 때 redis 에 이 sign 이 존재 하 는 지 확인 합 니 다. 존재 하면 중복 제출 되 었 음 을 증명 하고 인 터 페 이 스 는 더 이상 호출 되 지 않 습 니 다.만약 에 sign 이 캐 시 서버 에서 만 료 시간 이 되 어 삭제 되 었 다 면 이 url 이 서버 를 다시 요청 할 때 token 의 만 료 시간 과 sign 의 만 료 시간 이 계속 되 고 sign 만 료 는 token 만 료 를 의미 합 니 다. 그러면 같은 url 재 방문 서버 는 token 오류 로 인해 차단 되 었 습 니 다.이것 이 바로 sign 과 token 의 만 료 시간 이 일치 해 야 하 는 이유 입 니 다.중복 호출 메커니즘 을 거부 하여 URL 이 다른 사람 에 게 캡 처 되 어도 사용 할 수 없 도록 합 니 다 (예 를 들 어 데 이 터 를 캡 처 하 는 것).
어떤 인터페이스 에 중복 제출 을 방지 해 야 하 는 지 설명 을 사용자 정의 해서 표시 할 수 있 습 니 다.주의: 모든 안전 조 치 를 사용 하면 너무 복잡 할 때 가 있 습 니 다. 실제 프로젝트 에서 자신의 상황 에 따라 재단 을 해 야 합 니 다. 예 를 들 어 서명 체제 만 사용 하면 정보 가 변경 되 지 않 거나 특정한 방향 으로 서 비 스 를 제공 할 때 Token 체제 만 사용 하면 됩 니 다.어떻게 재단 하 는 지 는 프로젝트 의 실제 상황 과 인터페이스 안전성 에 대한 요구 에 달 려 있다.
사용 절차
인터페이스 호출 자 (클 라 이언 트) 는 인터페이스 제공 자 (서버) 에 게 인터페이스 호출 계 정 을 신청 합 니 다. 신청 이 성공 하면 인터페이스 제공 자 는 인터페이스 호출 자 에 게 appId 와 key 매개 변수 클 라 이언 트 에 매개 변수 appId, timestamp, sign 을 가지 고 서버 측의 API token 을 호출 합 니 다. 그 중에서 sign = 암호 화 (appId + timestamp + key) 클 라 이언 트 는 apitoken 은 로그 인 없 이 접근 할 수 있 는 인터페이스 에 접근 합 니 다. 사용자 가 로그 인 해 야 할 인터페이스 에 접근 할 때 클 라 이언 트 는 로그 인 페이지 로 이동 합 니 다. 사용자 이름과 비밀 번 호 를 통 해 로그 인 인 인 인 터 페 이 스 를 호출 하면 로그 인 인 인 인 터 페 이 스 는 usertoken 으로 돌아 갑 니 다. 클 라 이언 트 는 usertoken 을 들 고 로그 인 해 야 접근 할 인터페이스 sign 에 접근 하 는 역할 을 합 니 다.클 라 이언 트 가 서버 를 호출 할 때 sign 인 자 를 전달 해 야 합 니 다. 서버 가 클 라 이언 트 에 응답 할 때 도 sign 을 되 돌려 서 클 라 이언 트 가 되 돌아 온 값 이 불법 으로 변경 되 었 는 지 확인 할 수 있 습 니 다.클 라 이언 트 가 전 하 는 sign 과 서버 측 이 응답 하 는 sign 알고리즘 이 다 를 수 있 습 니 다.