해커가 너의 프로그램을 공격하는 것은 네가 상상한 것보다 쉬울 것이다

TL;박사:
나는 커피숍에서 구독하는 매주 이메일에서 의심스러운 행동을 발견했다.그것은 내가 전용 링크를 통해 나의 선호도를 직접 편집할 수 있도록 제공한다.저는 쿠키와 신분 검증 영패(기교가 없음)를 돌아갈 수 있고 계좌 상세 정보 패널에 들어가 비밀번호/계좌 전자메일을 변경할 수 있습니다. 본질적으로 이 상점은 심각한 신분 검증과 권한 수여 문제에 직면하여 IDOR의PII(개인 식별 가능한 정보를 노출)합니다.그 밖에 CORS나 CSRF 완화 조치가 없어서 제가 원키 계정을 인수할 수 있는 악성 링크를 만들 수 있습니다.
면책 성명: 나는 누구도 명확한 동의 없이 어떤 테스트를 진행하는 것을 건의하지 않는다.내가 가장 좋아하는 상점의 즐거운 고객으로서, 나는 빈틈을 발견했고, 내 계좌가 어떻게 쉽게 조작되는지에 대해 흥미를 느꼈다.그 후로 호기심은 나로 하여금 이 벌레들을 한층 더 찾게 했다.나는 가능한 한 '무례성' 행동을 적게 취하고, 상점에 모든 것을 상세하게 보고하여, 그들이 위험을 낮출 수 있도록 도와주고, 나의 도움을 제공했다.

이 모든 게 어떻게 시작됐는지

나는 런던에서 가장 좋은 커피숍 중의 하나를 예약 구독했다.나는 매주 신선한 구운 콩 한 포대를 받을 뿐만 아니라, 커피 원두에 대한 선호도나 배달 시간표를 바꾸라는 이메일도 받는다.
나는 이미 이 링크를 여러 번 사용했다.배달을 한 번 건너뛰거나 앞으로 밀어붙이고 싶을 때, 나는 내 계좌를 신속하고 편리하게 방문할 수 있다.로그인 장애나 간섭 없음 - 원활하고 쉬운 고객 환경
어떤 이유로 지난주에 커피를 마신 후에 나는 조기 발송에 대한 선호도를 갱신했다. 나는 이상한 것들을 발견했다. 의외로 링크 영패의 한 글자를 삭제하는 것은 중요하지 않다는 것이다.나는 여전히 내가 좋아하는 내용을 보고 계정을 변경하고 업데이트할 수 있다.

# Original request leading to the panel
https://coffee.shop/api/recurring/customers/<user-hash>/?token=1111111

# Using a different token (any token or none at all for that matter)
https://coffee.shop/api/recurring/customers/<user-hash>/?token=qqqqqqq

한 가지 배경: 이 상점은 Ruby를 사용하는 매우 유명한 전자상거래 플랫폼을 기반으로 하는 웹 응용 프로그램이다. (이러한 잘못된 설정/빈틈이 많은 다른 상점에 존재한다고 가정하면 완전한 공개를 피하려고 한다.)이 사이트 자체는 내가 본 것 중에서 가장 화려한 것이 아니지만, 임무를 완수했다.기본적인 사용자 관리와 편리한 방식으로 나의 선호를 바꾸는 것은 매우 간단하고 맞춤형 방식이다.
이야기로 돌아가기: 내가 기호화폐를 제거할 때, 나는 내 계정의 납부 첫 번째 옵션을 방문할 수 있을 뿐만 아니라, 익명 브라우저를 통해 그것에 접근할 수 있다.본질적으로 쿠키 검증도 제대로 되지 않았다는 뜻이다.따라서 저는 GET 영패와 쿠키에서 분리를 요청하고 제가 원하는 곳에서 정보를 얻을 수 있습니다.이것은 첫 번째 빈틈이 될 것이다. 이 특정 단점의 신분 검증이 부족하다.
중요한 것은 어떤 고객도 이 결함을 볼 수 없다는 것이다.비정기 계정(자동 매주 정기 주문 없음)과 미구독 사용자의 변경은 모두 신분 검증 과정을 거쳐야 한다.이것이 바로 링크 중의 이 단점입니다. 정기적으로 주문하는 유료 구독 고객을 지원하여 변경 사항에 신속하게 접근할 수 있도록 하기 위해서입니다.끝점은 다음과 같이 나타납니다.

https://coffee.shop/api/recurring/customers/<unique-hash>/?token=<token>

이 점에서, 나는 나의 생각을 걱정하는 고객에서 공격자로부터 옮기려고 했다. 만약 내가 여기에 악의적인 의도가 있다면, 나는 어떻게 하겠는가?
나는'첫 번째 옵션'메뉴에서 edit 링크를 찾았다. 이것은 나로 하여금 표를 찾게 했다. 거기에서 나는 나의 상세한 정보를 변경할 수 있다. name, 메인 페이지address, phone_number, 물론 나의 email 주소도 있다(!).내가 전자 우편 주소를 강조하는 것은 이 필드가 통상적으로 계정을 인수할 수 있기 때문이다.개인 정보는 영원히 유출되어서는 안 된다. 그러나 항상 안전한 구멍으로 여겨지지 않고, 보호되지 않은 전자 우편 변경은 계정을 파괴할 수도 있다.전자 우편 주소는 사실상 웹 응용 프로그램 계정 식별자입니다.만약 당신이 계정의 전자 우편 주소를 제어한다면, 당신은 그것을 가지고 있을 것이다.제어 주소는 비밀번호를 재설정하고 기본적으로 계정을 제어할 수 있다.
전자 우편 주소 보호에 대한 중요한 알림입니다.더 정확히 말하면 이메일 주소 업데이트 보호.계정의 전자 메일 주소를 변경하려면 암호로 보호해야 합니다.예, 사용자가 인증을 통과하고 로그인한 경우에도 마찬가지입니다.바로 상술한 원인에서 나온 것이다.API는 끊임없이 변화하는데, 그것들 중 대다수는 이미 혹은 어느 때에 약간의 것을 드러낼 것이다.비밀번호와 전자메일 변경을 다른 층으로 보호하는 것은 흔하고 좋은 방법이다.일단 보호되면 사용자가 '진실' 임을 확보하기 위해 개인 메일박스의 변경 사항을 확인해 달라는 요청을 받을 것이다.암호 변경이든 전자 우편 변경이든 우리는 전자 우편 주소와 암호에 대한 제어가 사용자의 진실성에 좋은 표식이라고 가정한다.
계속해서 이메일 주소를 변경하고 사용자 이름+1을 추가하면 계정에 대한 통제를 잃지 않습니다(일반적으로 주소를 변경하거나 같은 메일박스의 여러 계정을 사용합니다).역시, 요청이 통과됐고 내 계좌도 업데이트됐어.이것은'커피 선호 업데이트'링크를 가진 모든 사람이 나의 계좌 상세한 정보를 인수하고 신용카드로 그들이 원하는 모든 것을 구매할 수 있다는 것을 의미한다.
그렇다면 나는 이 점을 어떻게 이용해야 하는가?나는 POC를 전시함으로써 가게 주인이 직면한 위험을 설명하려고 한다.공격을 이용하려면 어떤 HTML 폼을 만들어서 고객에게 보내서 그들의 쿠키를 요청에 추가해야 합니다.그러나, 표에 CSRF 영패가 없을 뿐만 아니라, 나는 그것이 전혀 검증을 거치지 않았다는 것을 기억한다.
CORS 헤드도 설치되지 않았습니다.이것은 어느 곳에서든지 +1 링크를 사용하여 상점의 API에 POST 요청을 보내고 해시 값에 따라 계좌를 변경할 수 있다는 것을 의미한다.일반적으로 위험recurring/customer/edit을 통해 CSRF 사용을 요청하기 때문에 이것은 매우 크다.GET 변경 요청을 이용하여 공격하려면 사용자가 보기/클릭할 수 있도록 어떤 종류의 stored XSS 링크 공격을 사용해야 한다.
Check out my post on CSRF attacks and mitigation
과자는 이곳에서 아무런 작용도 하지 않기 때문에, 이 모든 것은 중요하지 않다.그렇다면 쿠키 검증만으로는 방탄의 해결 방안이 아니라는 것을 보여주기 위해서다.그것은 꼭대기에서 이루어져야 할 서로 다른 안전층의 기선이다.

보도하다

나는 작문을 독학하고 있다better vulnerability reports. 그래서 나는 내가 할 수 있는 모든 것을 가게 주인에게 분명히 말했다.나는 기술의 세부 사항이 전달될 것이라고 가정하기 때문에 빈틈이 가져오는 영향과 위험을 강조하는 것이 매우 중요하다.이것은 나로 하여금'왜 중요한가'부분을 생각하게 했다.

왜 중요해!

인터넷은 규모가 크고 지수급으로 증가했다.그것 때문에 사용자와 응용 프로그램이 증가하고 있습니다. 네, 그리고 버그가 있습니다.개발자로서 흔히 볼 수 있는 위험과 이를 어떻게 테스트하는지 이해하면 우리가 지역 사회로서 더 좋은 응용 프로그램을 구축하여 더욱 즐겁고 안전한 고객을 지원하는 데 도움이 된다.이런 상황에서 아무도 피해를 주려고 하지 않지만 고객 체험을 보완하는 길에서 개발자와 제품 소유자는 위험과 그들의 이용이 가져온 영향을 명심해야 한다.
As a smart woman once said :

Hackers are the internet's immune system.

비록 나는 나를 하나라고 할 수 없지만 고품질의 버그 상금 플랫폼, 고기능의 연구원들이 많다.자원과 수단을 가진 팀들이 개인 프로젝트든 플랫폼 프로젝트든 개방을 고려하도록 격려하고 싶습니다.전문 기술을 이용하여 안전 결함을 발견하고 복구하다.
나는 정말 이 글이 다른 사람들의 머릿속에 빛을 발하여 그들의 고객을 보호할 수 있기를 바란다.나도 이것이 사용자들이 자신들이 신뢰할 만하다고 생각하는 서비스 제공자와의 소통에 대해 개방적인 시야를 유지할 수 있는 행동의 호소가 되기를 바란다.마지막으로, 나는 그들이 토끼굴에서 뚫고 내려갈 것을 알아차렸다고 생각하는 누구에게도 전화를 걸어 보고할 것이다.최악의 상황은 아무 일도 일어나지 않았다는 것이다.다른 한편, 당신은 정보 유출, 도용, 생명 연장을 구할 수 있을 것이다.

자신의 빈틈을 테스트하다

개발자들은 보안 파이프라인, QA 시스템, 그리고 자신들이 가져온 라이브러리를 지나치게 믿는다.모두 발표 과정의 기능층이지만 개발자는 자신에 대한 기본적인 테스트를 어떻게 생각하고 실행하는지 알아야 한다.
사유 과정은 대체로 다음과 같다.

악의적인 참여자가 특정한 요구를 제기하는 것을 방지하는 안전 메커니즘은 무엇입니까?

만약 내가 해커(또는 시간이 너무 많은 호기심 엔지니어)라면 내가 어떻게 그것을 돌아갈 수 있겠는가?

과자 안 써도 돼요?인증 헤더를 삭제해도 됩니까?과자를 제어할 수 있을까요?요청한 단점/헤드/주체/파라미터만 조종해서 캐릭터를 변경할 수 있습니까?

이 시스템을 예상치 못한 방식으로 사용할 수 있는 다른 창의적이지만 뚜렷한 방법이 있습니까?

이것은 개발자라면 누구나 물어야 할 부분인데, 특히 사용자 계정을 구축하고 보호할 때이다.새 인증 라이브러리가 추가되었습니까?테스트 해봐.쿠키 암호화 변경?응용 프로그램 관리 시스템에 캐릭터를 추가합니까?변화를 테스트하고 시스템을 조종해 보는 것은 재미있을 뿐만 아니라 건강하다.더 나아가 반나절의 시간을 들여 자기 안전의 스탬프를 한다.나는 이것이 내가 기술을 향상시키는 방식이라는 것을 안다. 심지어 한 번은 내가 우리의 시스템을 찾았는데, 내장된 것과 고객에게 서비스를 제공하는 것은 타협할 수 있는 방식이다.그러나 게시물마다 다른 이야기다.
읽어주셔서 감사합니다!