PHP 작성 APP 인터페이스의 보안 문제에 대한 토론

이 문제를 논의하기 전에 먼저 확인해야 할 점은 인터넷 코더로서 프런트엔드든 백엔드든 http 요청에 대한 어느 정도 이해가 있어야 하고, http의 특성을 알아야 한다는 것입니다. , http에 요청과 응답이 무엇인지, 쿠키와 세션이 있는 이유, 웹사이트에 인증 코드의 의미와 필요성을 명확하게 이해하세요. APP 인터페이스의 보안을 논의하는 것은 HTTP 요청의 보안을 논의하는 것이기 때문입니다.

저는 일반적으로 APP 인터페이스를 일반 인터페이스, 양식 인터페이스, 멤버 인터페이스의 세 가지 범주로 분류합니다. 이 기사에서는 멤버 인터페이스에 중점을 둡니다.

공통 인터페이스

는 일반적으로 뉴스 목록 가져오기GET http://Example.com/index.php?module=news&action=list와 같은 GET 요청입니다. 수집이나 폭력적인 쿼리를 방지하기 위해 당사 PC에서는 일반적으로 다음과 같은 처리를 수행합니다.

1. 본 사이트가 다른 사이트에서 file_get_contents되는 것을 방지하기 위해 user_agent를 식별해야 합니다. 브라우저를 통해 접속하지 않으면 직접 표시되지 않습니다.
   
2. 다른 사람이 user_agent를 위조하여 접속하면 단위 시간당 IP 방문 횟수로 크롤러가 제어되며, 다른 IP가 1분에 두 번 이상 사용되는지 확인하는 알고리즘을 작성할 수 있습니다. 방문하여 처리합니다. 그러나 특정 커뮤니티나 기업이 특정 IP의 외부 네트워크를 사용하는 상황이 발생하게 되는데, 이로 인해 막다른 골목에 이르게 되므로 이를 처리하기 위해서는 브라우저의 쿠키에 협조해야 합니다.
   요약: 요청 헤더가 위조될 수 있고, IP ​​주소가 변경될 수 있으며, 쿠키가 삭제될 수 있습니다. 기본적으로 PC 측에서는 이러한 문제를 예방하기 어렵습니다. 예를 들어 타오바오, 디앤핑 등 주요 사이트에서 데이터를 자주 수집합니다.

APP에서는 이 문제를 어떻게 처리합니까? Dianping APP의 http 요청 패키지를 가져와서 살펴보겠습니다.

<code>GET http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0 HTTP/1.1
Host: 114.80.165.113
Accept: */*
pragma-appid: 351091731
pragma-newtoken: c2032338f6abf96c8e2984db1655f2bac73b88f799e49aab4a426d414f994b5f
pragma-token: 73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff
pragma-dpid: 9214560561001942797
pragma-device: 566fe5aeb75a827967fbad8356608134ba98a4a6
Proxy-Connection: keep-alive
pragma-os: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0)
Accept-Language: zh-cn
network-type: wifi
User-Agent: MApi 1.1 (dpscope 7.5.0 appstore; iPhone 8.3 iPhone7,1; a0d0) Paros/3.2.13 </code>

http://114.80.165.113/mapi/ugcuserfeeds.bin?filtertype=5&userid=129059048&token=73114c7e9a4485319542039cdff854d989f61e5821d306b3abf0fc9904eb51ff&start=0에 직접 액세스하면 서버 측에서 직접 차단하고 450 오류를 반환합니다.

PHP의 서버는 일반적으로 Apache 또는 Nignx이며 클라이언트 개발자와의 계약에 따라 구성 항목에 일부 맞춤 요청을 사용할 수도 있습니다. 위의 parama-*와 같은 헤더 정보는 서버 구성 항목에서 이러한 사용자 정의 요청 헤더 정보를 얻은 다음 합의된 요청 정보인지 여부에 따라 450으로 다시 작성할 수 있습니다.

그러나 패킷을 캡처하여 모든 요청 헤더 정보를 얻은 다음 요청 헤더 정보를 완전히 시뮬레이션하여 데이터를 얻을 수 있습니다.

많은 앱이 최대 이 단계에서 API 인터페이스를 얻을 수 있습니다. , 처리하기 매우 쉬운 json 형식이며 Dianping APP는 압축된 것처럼 보이는 왜곡된 데이터 묶음을 직접 반환합니다.

이것은 PC 측과 다소 유사합니다. gzip, 서버 클라이언트는 gzip 압축 데이터를 반환하고, 브라우저는 gzip의 압축을 풀어 실제 데이터를 얻은 후 표시합니다.
리뷰에서 왜곡된 데이터도 이 원칙에 따른 것인지는 모르겠습니다. 그래서 압축 해제 알고리즘이 앱 자체에서 발생하기 때문에 정말 "굉장하다"고 말해야 합니다. 이는 데이터 보안을 보장할 뿐만 아니라 대역폭을 절약하고 데이터 전송 속도를 높입니다. 어떻게 수행되는지는 아직 알려지지 않았습니다.

양식 인터페이스

는 주로 서버에 데이터를 제출하는 HTML의 from 양식과 유사합니다. 일반적으로 포스트 http 요청입니다. 가장 큰 위험은 HTTP 요청을 강제하고 데이터베이스를 폭파시키는 것입니다. PC 측에서는 일반적으로 인증 코드를 통해 이 문제를 해결하지만, APP 측에서는 생각할 수 있는 유일한 것입니다. 인증 코드를 전달하는 방식은 단지 PC 측에서는 인증 코드를 세션에 저장하고, APP 측에서는 이를 캐시에 저장하는 것뿐이지만, 인증 코드가 추가되면 사용자 경험이 확실히 크게 저하될 것입니다. 이에 대한 더 나은 방법, 해결 방법은 아직 알려지지 않았습니다.

회원 인터페이스

소위 회원 인터페이스는 http://Example.com/index.php?module=users&action=info&user_id=333과 유사한 요청이며, 서버가 직접 user_id를 기반으로 해당 멤버십 작업을 수행하는 것은 매우 위험한 인터페이스 처리로, 상대방이 user_id를 변경하는 한 해당 구성원의 모든 인터페이스가 작동될 수 있으므로 현재 멤버십 시스템을 노출시키는 것과 같습니다.
일반적으로 PC에서는 회원 식별과 세션 유지를 위해 암호화된 쿠키를 사용합니다. 그러나 쿠키는 브라우저의 로컬 저장 기능에 속합니다. APP 측을 사용할 수 없으므로 토큰 매개변수를 통해 회원을 식별해야 하며 이 토큰을 어떻게 처리해야 합니까?

먼저 이 인터페이스를 암호화하기 전에 겪었던 네 가지 솔루션에 대해 이야기하겠습니다.

옵션 1
특정 md5 조합 알고리즘에 대해 APP 개발자와 합의한 다음 두 끝을 비교하여 동일하면 허용하고, 그렇지 않으면 거부합니다.
그러나 이 역시 APP 프로그램이 디컴파일되면 이러한 합의된 알고리즘이 노출됩니다. 특히 Android 앱에서는 더욱 그렇습니다. , 인터페이스 요청을 완전히 시뮬레이션하고 검증을 통과할 수 있습니다.

옵션 2
데이터베이스 회원 테이블의 비밀번호는 임의 암호화 및 이중 암호화된 md5 값이며, 사용자가 로그인하면 해당 회원의 uid와 비밀번호가 일반 텍스트로 반환됩니다. , 기타 알면서도 로그인할 수 없습니다. 그러면 결국 인터페이스를 요청할 때마다user_id=333&token=aa37e10c7137ac849eab8a2d5020568f 기본 키 uid를 통해 현재 uid에 해당하는 토큰을 빠르게 찾을 수 있으며, 그럼 비교해 보세요.
그런데 이 아이디어는 너무 양호합니다. 너무 간단합니다. 패킷을 캡처한 사람은 암호문 비밀번호를 통해 회원에 로그인할 수 없지만, 일단 토큰을 알면 사용자가 비밀번호를 변경하지 않는 한 로그인할 수 있습니다. 항상 토큰을 사용하여 회원의 관련 인터페이스를 작동합니다.

옵션 3
은 uid+网站公钥에서 시간에 민감한 암호화를 수행하고 특정 시간 제한 내에 사용할 수 있는 대칭 암호화 알고리즘을 사용합니다. 구성원이 성공적으로 로그인하면 서버는 ID를 암호화하여 클라이언트에 반환합니다. 클라이언트는 인터페이스를 요청할 때마다 이 매개변수를 가져오고 서버는 암호 해독을 통해 인증합니다.
그러나 이 역시 안전하지 않습니다. 왜냐하면, 외부로부터 우리 자신을 보호하기 위해 내부로부터 우리 자신을 보호할 수 없기 때문입니다. 이번 씨트립 중단은 사임한 내부 직원의 악의적인 작전에 의한 것이라고 들었습니다. 내부 악의적인 사람이 해당 알고리즘 규칙을 알고 있으면 데이터베이스 권한이 없어도 인터페이스를 통해 해당 회원을 조작할 수 있습니다.

옵션 4
회원이 로그인하면 로그인 인터페이스를 요청하고, 그러면 서버 측 A 토큰이 클라이언트에 반환됩니다. 토큰 생성 규칙은 网站公钥 + 当前uid + 当前时间戳 + 一段随机数 필요에 따라 토큰을 캐시에 넣을지 여부를 결정하고 자동으로 만료될 때까지 기다립니다. 또는 데이터베이스에 넣고(데이터베이스에 넣으려면 별도로 꺼내서 테이블을 사용하여 사용자의 로그인 및 로그아웃 시간을 기록), 사용자가 로그아웃할 때 변경하여 토큰만 사용할 수 있도록 합니다. 사용자의 수동 로그아웃과 로그인 사이에 사용됩니다.
보안을 보장하기 위해 사용자는 일정 시간 내에 자동으로 로그아웃할 수 있어야 합니다. 이 솔루션은 Linux 및 데이터베이스 권한 관리와 결합되어 외부 및 내부 보호를 모두 방지할 수 있습니다.

개발 시 주의 사항 다른 인터페이스

1. JSON은 크로스 플랫폼 속성이 더 우수하므로 JSON 형식 데이터를 사용하는 것이 가장 좋습니다. JSON을 생성할 때 json의 두 가지 형식, 즉 객체(사전)와 배열에 주의해야 합니다. 모바일 개발 언어의 PHP에는 유사한 foreach가 없으며 객체에 대한 작업은 순회할 수 있습니다. 일반적으로 키 이름을 통해 키 값을 얻습니다.
   
2. 성공인지 실패인지. 인터페이스는 명확한 데이터 상태 정보를 제공해야 하며 NULL을 반환할 수 없습니다. NULL이 반환되면 IOS 측에서 충돌이 발생합니다.

위에서 내용의 측면을 포함하여 PHP로 APP 인터페이스를 작성하는 데 따른 보안 문제에 대한 첫 번째 논의를 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.