WeiXinVote
1.0.0
최근 위챗의 유세 게시물을 보았는데, 할 일이 없을 때 이것저것 조사를 하다가 이 활동이 투표를 브러싱하는 데 사용될 수 있다는 사실을 발견하고, 브러싱 투표를 위한 스크립트를 작성하는 과정을 간략하게 기록하겠습니다. 사실 이런 종류의 크롤러 코드를 구현하는 것은 항상 작은 문제입니다. 중요한 것은 다른 사람의 페이지를 어떻게 분석하고 크롤링할지 알아야 한다는 것입니다.
WeChat 투표 페이지를 열고 화면을 아래로 내리면 화면 상단에 "이 웹페이지는 XXX에서 제공됩니다."가 표시됩니다. 여기서 "XXX"는 "mp.weixin.qq"가 아닙니다. com"이지만 이벤트 주최자 파티의 도메인 이름입니다. 즉, 이번 투표 활동을 위한 프로그램이 S몰 서버에서 실행되고 있는 것이다. 이는 WeChat 공개 플랫폼의 OpenID 개념과 관련이 있습니다. OpenID에 대한 공식적인 설명은 다음과 같습니다. WeChat ID를 암호화한 후 각 사용자는 각 공개 계정에 대해 고유한 OpenID를 갖게 됩니다. 즉, 사용자는 공용 계정에 대해 고유한 OpenId를 갖습니다.
투표의 논리는 사용자가 투표 요청 시 POST 매개변수에 사용자의 OpenID를 제공하는 것입니다. 투표 POST 요청을 받은 후 S mall 서버는 4시간 이내에 현재 OpenID가 투표했는지 쿼리하여 단일 사용자를 차단할 수 있습니다. . 투표 행위가 반복됩니다.
그러나 여기에는 큰 허점이 있습니다!
S몰에서는 오픈아이디 중복 여부만 판단할 수 있으나, 오픈아이디 확인을 위해 위챗 서버를 호출할 수 없기 때문에 오픈아이디의 유효성을 확인할 수 없습니다.
그런 다음 형식을 준수하는 OpenId를 생성하고 게시물 요청을 보내기만 하면 됩니다.
그런데 한 표가 실제로 두 단계로 이루어진다는 점에서도 이상합니다. 첫 번째는 get 요청입니다(그림에서 코딩된 부분은 개인정보 보호를 위해 설계되었습니다. 두 번의 요청을 통해 한 번의 투표가 완료된다는 점만 알면 됩니다.
첫 번째 요청의 이름을 보고 요청이 완료된 줄 알았으나 크롤러를 사용하여 이 인터페이스에 액세스했을 때 투표 수가 증가하지 않았습니다. 자세히 살펴보니 또 다른 요청이 있다는 것을 알게 되었습니다.
이 요청의 경로는 매우 이상하고, 잘못된 문자열이며 매번 다릅니다. 첫 번째 요청만 트리거한 후에는 다른 작업이 수행되지 않았으며, 첫 번째 요청을 통해 무작위로 생성된 일부 매개변수를 가져온 다음 두 번째 요청에서 이러한 매개변수를 가져오는 것이 투표임을 확신할 수 있습니다. 두 번째 요청이 완료되면 투표 프로세스가 완료됩니다. 따라서 두 번째 요청을 호출하는 첫 번째 요청 페이지 어딘가에 있어야 합니다. 이때 소스코드를 확인해 보니 페이지에 이와 같은 코드열이 있는 것을 발견했습니다.
페이지에서 잘못된 문자가 발견되는 경우는 코드가 암호화되었기 때문인 경우가 많습니다.
매개변수 중 두 개는 두 번째 요청의 경로입니다. 이 왜곡된 문자 문자열은 두 번째 요청과 관련이 있으며 이모티콘 문자열은 js 코드의 암호화임을 알 수 있습니다. 이 잘못된 문자 문자열이 무엇을 의미하는지 이해하지 못하더라도 세미콜론(;)을 눌러 잘못된 문자 문자열의 형식을 지정하고 이를 크롬 콘솔에서 직접 실행할 수 있습니다. 이 이모티콘 코드 문자열의 효과는 다음과 같습니다. 두 번째 요청을 실행합니다. (이 곳은 코드를 복구할 수 있는 곳이어야 합니다. 아시는 분은 설명을 해주시면 됩니다.)
이는 기본적으로 완료되고 나머지는 코드 구현입니다. 일반적으로 첫 번째 요청에 액세스하고 일반 규칙을 사용하여 페이지의 매개변수를 크롤링하고 매개변수를 두 번째 요청의 경로로 사용하여 두 번째 요청을 처리합니다. . 액세스를 요청했습니다. 물론, 임의의 액세스 시간 간격을 갖는 IP 프록시도 있습니다. 즉, 사용자 에이전트 수정에 따른 일반적인 문제는 설명하지 않습니다. , 이메일을 보낼 수 있습니다.
일반적으로 Python을 사용하여 코드를 구현하는 것은 어렵지 않습니다. 단계별로 분석하고, 웹 사이트의 논리를 익히고, 끊임없이 시도하는 것이 어렵습니다. 더 많이 해야만 효과가 있을 것이다
