KoreanHackerTeam
Moderator
1. 실수로 시금치 부지를 찾은 다음 테스트했습니다. 아이디어는 다음과 같습니다. 시금치 사이트이므로 사용자는 확실히 등록 할 것입니다. 그렇지 않으면 어떻게 돈을 청구 할 수 있습니까? 사용자와 강력하게 상호 작용하는 페이지를 등록 할 때 가능한 취약점은 다음과 같습니다.
SQL 주입 : 사용자가 입력 한 계정 정보가 필터링없이 데이터베이스를 쓰거나 쿼리하는 데 직접 사용되는 경우 SQL 주입 XSS가 있어야합니다. 입력 상자에 입력 된 개인 정보는 사용자 페이지에 표시됩니다. 동시에 관리자는 백그라운드에서 사용자의 개인 정보를 볼 수있는 권한이 있어야하며 여기에는 스토리지 XS가있을 수 있습니다. 반사적이거나 DOM XSS이더라도 그러한 사이트에는 고객 서비스가 있으므로 쿠키 또는 기타 목적을 훔치기위한 목적을 달성하기 위해 고객에게 링크를 클릭하도록하는 방법을 찾을 수 있습니다. 병렬 오른쪽 권리 : 사용자가 로그인하면 로그인 한 후 특정 페이지를 확인한 다음 패킷을 잡으면 유사한 ID 필드가있는 경우 ID 번호 CSRF를 변경하여 다른 사용자 및 관리자의 정보를 볼 수 있습니다. 비밀번호와 같은 계정 정보를 수정하십시오. 또는 이메일 주소를 수정 한 다음 이메일 주소를 통해 비밀번호를 수정하십시오. 결제 취약성 : 패킷을 잡고 매개 변수를 변경하여 0 위안이 지불하게합니다.이 아이디어를 따르십시오.
(1) 먼저 두 번째를 살펴 보겠습니다. 프롬프트 매개 변수를 탐지 도구의 페이로드로 변경 한 후 페이지는 다음과 같습니다. 페이로드가 실제로 페이지에 표시됩니다.没有任何过滤, 너무 행복합니다.
페이로드 자체가 JS 내부에 있기 때문에 스크립트 태그는 처음에 구성되지 않았지만 '19736%0A',}%0AALERT (666);%0A '와 같은 페이로드를 직접 사용했습니다. 페이로드의 목적은 백그라운드에서 원래 스크립트 태그에 직접 경고 (666)를 노출시키는 것이지만 많은 것들을 반복적으로 시도 할 수 없었습니다. 내 생각 만 조정하고 스크립트 태그를 재구성 할 수있었습니다. 이번에는 다음과 같이 성공했습니다. 그것은이 XSS에 잘못된 경보가 없음을 의미합니다.
다른 하나는 쿠키에 있습니다. SessionID가 변경되면 페이지의 HTML 소스 코드에 직접 나타날 수도 있습니다. 위의 첫 번째와 마찬가지로 자신의 JS 코드를 실행하기 위해 스크립트를 구성 할 수 있습니다. 그러나 백그라운드 소스 코드를 알지 못하므로 이것이 스토리지 유형 XSS인지 여부를 판단 할 수 없으며 URL 구성을 통해 다른 사람들이 클릭하도록 속일 수 없습니다. 나는 개인적으로 그것이 의미가 없다고 생각하기 때문에 더 이상 여기에서 확인하지 않을 것입니다.
백그라운드에 로그인 할 수 없으므로 다른 XSS가 스토리지 유형인지 여전히 확실하지 않습니다. 우리는이 단계에서 다른 XSS 취약점을 계속 확인하지 않을 것입니다.
(2) 로그인 인터페이스는 패킷을 캡처하고 사용자 이름과 암호는 실제로 일반 텍스트로 전송됩니다.
놓친 후 새 패키지를 잡고 리피터에 시도해 보았습니다. 내부에는字段captcha是验证码，删掉后服务器任然会执行，并且不会提示验证码错误이 있지만 사용자 이름이나 비밀번호가 잘못되어 많은 문제가 절약됩니다. 나는 먼저 올바른 계정을 사용하여 테스트하고 반환 된 상태가 Y이고 모든 것이 정상임을 발견했습니다.
그런 다음 단일 따옴표, 이중 따옴표, 브래킷, ') 또는 1=1-QWE 및 기타 SQL 주입으로 다양한 SQL 주입 된 페이로드를 시도하면 다음과 같습니다.
오른쪽의 기본 코드는 : "4-15 자,仅可输入英文字母以及数字的组合"을 입력하십시오. 그것은 의도적으로 필터링되었으며, 문자와 숫자 만 입력 할 수 있으며不能输入任何特殊符号으로, 여기에는 SQL 주입이 없을 가능성이 높습니다. (일부 웹 사이트 프론트 엔드 페이지도 설명이 있으며 실제로 백엔드 서버 측면에서 JS를 사용하여 프론트 엔드를 확인하지 않고 버프를 사용하여 패킷을 잡고 필드를 변경 한 후 필드를 수정할 수 없습니다).
(3) 병렬/수직 오버 리치 : 로그인 한 후 일부 사이트는 UID=123, GroupId=456, Telno=135000387465 등과 같은 쿠키에 다양한 ID를 가져옵니다. 필드의 의미를 쉽게 알 수 있으며 값을 변경 한 후 다른 사용자 및 관리자의 데이터를 볼 수 있습니다. 그러나 여기의 쿠키는 모든 세션이며 다양한 숫자를 가진 필드는 의미가 무엇인지 볼 수 없습니다. 버프를 사용하여 다른 값을 시도하고 Retuthing:n을 반환합니다.
(4) 0 위안 지불 : 지불 인터페이스에서 패킷을 잡고 요청 패킷의 내용을 해독 한 다음 내부에 다른 부호 필드가 있고 다른 필드가 확인됩니다. 금액이 변경되면 검증 알고리즘을 뒤집은 다음 부호 값을 다시 계산해야합니다. 여기서 당신은 일시적으로 포기합니다. 추신 : user_id는 마침내 여기에 노출되었습니다.
3. Xray 스캔을 통해 수지-뷰 파일 취약점이 발견되었습니다.
스캔 프롬프트에 따르면 파일=xxxx의 내용을 변경하면 아래 구성 파일과 같은 일부 파일을 찾을 수 있습니다.
이 취약점은 인트라넷 파일을 가로 질러 SSRF와 유사합니다. 그런 다음 GitHub에서 악용을위한 도구를 찾아 Burp를 사용하여 사전 철저한 디렉토리와 파일을 하나씩 실행했지만 다음 파일 만 발견되었으며,이 파일은 모두 일반 파일과 경로였으며 예상 구성 (예 : 계정) 파일이 발견되지 않았습니다.
C 드라이브를 가로 지르려면 보호되는 것 같습니다.
이 허점은 일시적으로 버려집니다.
4. 현재로서는 XSS 만 사용될 수 있으며 반사적입니다. 쿠키를 훔치는 스크립트 태그를 생성하고 XSS 취약점으로 URL에 포함시키는 스크립트 태그 만 생성하는 XSS 플랫폼 만 찾을 수 있습니다. 그런 다음 고객 서비스 MM을 찾아 클릭으로 트릭하십시오. 결과적으로 고객 서비스 MM은 바보에게 떨어질뿐만 아니라 새 사이트를 다시 시도 할 수있는 새로운 링크를 보냈습니다.
글쎄, 다시 시도해보십시오. 그래서 나는 새로운 사이트를 계속 구축하고 있습니다. 계정으로 새 사이트에 로그인 한 후 주로 사용자와 상호 작용하는 페이지를 찾습니다 (많은 매개 변수가 포함되어 있으며 변경의 여지가 많으며 취약성의 가능성은 정적 웹 페이지보다 훨씬 큽니다). 나는 많은 시간을 보냈고 수많은 링크를 확인했으며 다음과 같이 전환점이있는 것 같았습니다.
다음은 계정 이름, 전화 번호, 닉네임, 권한 등과 같은 다양한 민감한 데이터를 포함하는 JSON 문자열입니다. URL에는 클라이언트 키워드가 있습니다. 사용자 정보를 볼 수있는 인터페이스입니까? 버프를 즉시 사용하여 패킷을 잡고 URL (纯数字意味着索引，而且容易穷举)에서 순수한 숫자의 매개 변수를 변경하십시오. 예상대로, 일부 등록 된 사용자의 정보는 다음과 같습니다.
5. 또한 Xray를 통해 CORS 취약점 (CSRF 유형)도 발견되었으며 플랫폼의 고객, 관리자 또는 다른 사용자를 속일 수있는 방법을 찾아야합니다. 우리는 당분간 여기에 들어 가지 않을 것입니다.
이 시금치 부위의 요약 : 1. 사용자는 형태의 입력을 엄격히 제한했으며 SQL 주입과 XSS가 차단됩니다. 2. 수지 취약성은 고통스럽지 않으며 민감한 데이터를 얻을 수 없습니다. 3. 지불 : 부호 필드 검증이 있으며, 검증 알고리즘을 먼저 갈라져야합니다. 4. 결국 페이지는 매개 변수를 전달했지만 확인하지 않았습니다. 수치 매개 변수의 값을 변경하여 일부 사용자 정보가 폭발했습니다. 5. 사업적인 이유 때문일 수 있습니다. 프론트 엔드 페이지는 아직 파일을 업로드 할 장소를 찾지 못했지만 Xiaoma를 업로드하는 방법을 찾는 것은 여전히 불가능합니다.
참조 : 1. https://blkstone.github.io/2017/10/30/resin-attack-vectors/수지 서비스에 대한 공격 벡터 콜레이션
원래 링크 주소에서 재 인쇄 : https://www.cnblogs.com/theseventhson/p/13738535.html
SQL 주입 : 사용자가 입력 한 계정 정보가 필터링없이 데이터베이스를 쓰거나 쿼리하는 데 직접 사용되는 경우 SQL 주입 XSS가 있어야합니다. 입력 상자에 입력 된 개인 정보는 사용자 페이지에 표시됩니다. 동시에 관리자는 백그라운드에서 사용자의 개인 정보를 볼 수있는 권한이 있어야하며 여기에는 스토리지 XS가있을 수 있습니다. 반사적이거나 DOM XSS이더라도 그러한 사이트에는 고객 서비스가 있으므로 쿠키 또는 기타 목적을 훔치기위한 목적을 달성하기 위해 고객에게 링크를 클릭하도록하는 방법을 찾을 수 있습니다. 병렬 오른쪽 권리 : 사용자가 로그인하면 로그인 한 후 특정 페이지를 확인한 다음 패킷을 잡으면 유사한 ID 필드가있는 경우 ID 번호 CSRF를 변경하여 다른 사용자 및 관리자의 정보를 볼 수 있습니다. 비밀번호와 같은 계정 정보를 수정하십시오. 또는 이메일 주소를 수정 한 다음 이메일 주소를 통해 비밀번호를 수정하십시오. 결제 취약성 : 패킷을 잡고 매개 변수를 변경하여 0 위안이 지불하게합니다.이 아이디어를 따르십시오.
(1) 먼저 두 번째를 살펴 보겠습니다. 프롬프트 매개 변수를 탐지 도구의 페이로드로 변경 한 후 페이지는 다음과 같습니다. 페이로드가 실제로 페이지에 표시됩니다.没有任何过滤, 너무 행복합니다.
페이로드 자체가 JS 내부에 있기 때문에 스크립트 태그는 처음에 구성되지 않았지만 '19736%0A',}%0AALERT (666);%0A '와 같은 페이로드를 직접 사용했습니다. 페이로드의 목적은 백그라운드에서 원래 스크립트 태그에 직접 경고 (666)를 노출시키는 것이지만 많은 것들을 반복적으로 시도 할 수 없었습니다. 내 생각 만 조정하고 스크립트 태그를 재구성 할 수있었습니다. 이번에는 다음과 같이 성공했습니다. 그것은이 XSS에 잘못된 경보가 없음을 의미합니다.
다른 하나는 쿠키에 있습니다. SessionID가 변경되면 페이지의 HTML 소스 코드에 직접 나타날 수도 있습니다. 위의 첫 번째와 마찬가지로 자신의 JS 코드를 실행하기 위해 스크립트를 구성 할 수 있습니다. 그러나 백그라운드 소스 코드를 알지 못하므로 이것이 스토리지 유형 XSS인지 여부를 판단 할 수 없으며 URL 구성을 통해 다른 사람들이 클릭하도록 속일 수 없습니다. 나는 개인적으로 그것이 의미가 없다고 생각하기 때문에 더 이상 여기에서 확인하지 않을 것입니다.
백그라운드에 로그인 할 수 없으므로 다른 XSS가 스토리지 유형인지 여전히 확실하지 않습니다. 우리는이 단계에서 다른 XSS 취약점을 계속 확인하지 않을 것입니다.
(2) 로그인 인터페이스는 패킷을 캡처하고 사용자 이름과 암호는 실제로 일반 텍스트로 전송됩니다.
놓친 후 새 패키지를 잡고 리피터에 시도해 보았습니다. 내부에는字段captcha是验证码，删掉后服务器任然会执行，并且不会提示验证码错误이 있지만 사용자 이름이나 비밀번호가 잘못되어 많은 문제가 절약됩니다. 나는 먼저 올바른 계정을 사용하여 테스트하고 반환 된 상태가 Y이고 모든 것이 정상임을 발견했습니다.
그런 다음 단일 따옴표, 이중 따옴표, 브래킷, ') 또는 1=1-QWE 및 기타 SQL 주입으로 다양한 SQL 주입 된 페이로드를 시도하면 다음과 같습니다.
오른쪽의 기본 코드는 : "4-15 자,仅可输入英文字母以及数字的组合"을 입력하십시오. 그것은 의도적으로 필터링되었으며, 문자와 숫자 만 입력 할 수 있으며不能输入任何特殊符号으로, 여기에는 SQL 주입이 없을 가능성이 높습니다. (일부 웹 사이트 프론트 엔드 페이지도 설명이 있으며 실제로 백엔드 서버 측면에서 JS를 사용하여 프론트 엔드를 확인하지 않고 버프를 사용하여 패킷을 잡고 필드를 변경 한 후 필드를 수정할 수 없습니다).
(3) 병렬/수직 오버 리치 : 로그인 한 후 일부 사이트는 UID=123, GroupId=456, Telno=135000387465 등과 같은 쿠키에 다양한 ID를 가져옵니다. 필드의 의미를 쉽게 알 수 있으며 값을 변경 한 후 다른 사용자 및 관리자의 데이터를 볼 수 있습니다. 그러나 여기의 쿠키는 모든 세션이며 다양한 숫자를 가진 필드는 의미가 무엇인지 볼 수 없습니다. 버프를 사용하여 다른 값을 시도하고 Retuthing:n을 반환합니다.
(4) 0 위안 지불 : 지불 인터페이스에서 패킷을 잡고 요청 패킷의 내용을 해독 한 다음 내부에 다른 부호 필드가 있고 다른 필드가 확인됩니다. 금액이 변경되면 검증 알고리즘을 뒤집은 다음 부호 값을 다시 계산해야합니다. 여기서 당신은 일시적으로 포기합니다. 추신 : user_id는 마침내 여기에 노출되었습니다.
3. Xray 스캔을 통해 수지-뷰 파일 취약점이 발견되었습니다.
스캔 프롬프트에 따르면 파일=xxxx의 내용을 변경하면 아래 구성 파일과 같은 일부 파일을 찾을 수 있습니다.
이 취약점은 인트라넷 파일을 가로 질러 SSRF와 유사합니다. 그런 다음 GitHub에서 악용을위한 도구를 찾아 Burp를 사용하여 사전 철저한 디렉토리와 파일을 하나씩 실행했지만 다음 파일 만 발견되었으며,이 파일은 모두 일반 파일과 경로였으며 예상 구성 (예 : 계정) 파일이 발견되지 않았습니다.
C 드라이브를 가로 지르려면 보호되는 것 같습니다.
이 허점은 일시적으로 버려집니다.
4. 현재로서는 XSS 만 사용될 수 있으며 반사적입니다. 쿠키를 훔치는 스크립트 태그를 생성하고 XSS 취약점으로 URL에 포함시키는 스크립트 태그 만 생성하는 XSS 플랫폼 만 찾을 수 있습니다. 그런 다음 고객 서비스 MM을 찾아 클릭으로 트릭하십시오. 결과적으로 고객 서비스 MM은 바보에게 떨어질뿐만 아니라 새 사이트를 다시 시도 할 수있는 새로운 링크를 보냈습니다.
글쎄, 다시 시도해보십시오. 그래서 나는 새로운 사이트를 계속 구축하고 있습니다. 계정으로 새 사이트에 로그인 한 후 주로 사용자와 상호 작용하는 페이지를 찾습니다 (많은 매개 변수가 포함되어 있으며 변경의 여지가 많으며 취약성의 가능성은 정적 웹 페이지보다 훨씬 큽니다). 나는 많은 시간을 보냈고 수많은 링크를 확인했으며 다음과 같이 전환점이있는 것 같았습니다.
다음은 계정 이름, 전화 번호, 닉네임, 권한 등과 같은 다양한 민감한 데이터를 포함하는 JSON 문자열입니다. URL에는 클라이언트 키워드가 있습니다. 사용자 정보를 볼 수있는 인터페이스입니까? 버프를 즉시 사용하여 패킷을 잡고 URL (纯数字意味着索引，而且容易穷举)에서 순수한 숫자의 매개 변수를 변경하십시오. 예상대로, 일부 등록 된 사용자의 정보는 다음과 같습니다.
5. 또한 Xray를 통해 CORS 취약점 (CSRF 유형)도 발견되었으며 플랫폼의 고객, 관리자 또는 다른 사용자를 속일 수있는 방법을 찾아야합니다. 우리는 당분간 여기에 들어 가지 않을 것입니다.
이 시금치 부위의 요약 : 1. 사용자는 형태의 입력을 엄격히 제한했으며 SQL 주입과 XSS가 차단됩니다. 2. 수지 취약성은 고통스럽지 않으며 민감한 데이터를 얻을 수 없습니다. 3. 지불 : 부호 필드 검증이 있으며, 검증 알고리즘을 먼저 갈라져야합니다. 4. 결국 페이지는 매개 변수를 전달했지만 확인하지 않았습니다. 수치 매개 변수의 값을 변경하여 일부 사용자 정보가 폭발했습니다. 5. 사업적인 이유 때문일 수 있습니다. 프론트 엔드 페이지는 아직 파일을 업로드 할 장소를 찾지 못했지만 Xiaoma를 업로드하는 방법을 찾는 것은 여전히 불가능합니다.
참조 : 1. https://blkstone.github.io/2017/10/30/resin-attack-vectors/수지 서비스에 대한 공격 벡터 콜레이션
원래 링크 주소에서 재 인쇄 : https://www.cnblogs.com/theseventhson/p/13738535.html