이번 주에 우리는 Zip 라이브러리의 기본 동작에 대해 이야기 할 것입니다. 응용 프로그램 개발자인 경우 이전에 이 것을 사용한 가능성이 매우 높습니다. 인터넷을 통해 다운로드되는 대부분의 리소스는 zip 형식으로 되어 있습니다. 압축 된 데이터는 작기 때문에 더 빨리 다운로드되고 대역폭을 적게 소비합니다.

좀 더 구체적인 예를 원한다면: 게임 텍스처, 키보드에서 자동 완성을 위한 언어 팩, ... 많은 리소스가 응용 프로그램과 함께 자동으로 번들로 제공되는 것이 아니라 나중에 다운로드됩니다.

그러나 이 기능을 사용할 때는 zip 아카이브의 파일 이름에 경로 통과 정보가 포함될 수 있습니다. 추출하면 의도한 디렉터리 외부에서 파일이 생성됩니다. 이것은 종종 기존 파일을 덮어 쓰려는 의도로 수행됩니다.

다음 두 파일이 포함된 zip 아카이브가 있다고 가정해 보겠습니다.

파일1
.. /file2

이 아카이브를 추출하면 zip 디렉토리에서 file1이 예상되는 곳에서 추출됩니다. 그러나 file2는 지퍼 라이브러리에 아카이브를 추출하도록 요청한 곳보다 높은 하나의 디렉터리로 작성되었습니다.

따라서 zip 라이브러리가 이 경우를 제대로 처리하지 않으면 공격자가 시스템에 임의파일을 작성할 수 있습니다. 라이브러리가 안전한지 항상 확인하면 이 엄지 손가락 규칙은 라이브러리에 유효하지만 특히 이러한 유형의 파일에 대해 zip 라이브러리의 기본 동작을 확인하는 것을 알고 있습니다.

이 사례가 Android에서 제대로 처리되지 않을 때 결과를 입증할 수 있습니다. Android에서는 Java Zip 라이브러리(java.util.zip)가 사용되며, 라이브러리는 기본적으로 위에서 설명한 대로 경로를 통과할 수 있도록 합니다.

Androids Dalvik 실행 형식(.dex)은 단일 파일이 가질 수 있는 클래스의 양에 제한이 있습니다. 더 많은 클래스가 필요한 앱은 API 레벨 21(Android 5.0 롤리팝)부터 추가된 MultiDex 지원 라이브러리를 사용할 수 있습니다. 이 라이브러리는 응용 프로그램의 데이터 디렉터리에서 보조 .dex 파일을 저장하고, 이 디렉토리는 앱 사용자가 writable이며.dex 파일이 필요할 때이 코드를 로드하고 실행합니다.

즉, 공격자가 악의적인 zip 아카이브를 사용하여 오버라이팅하여 .dex 파일을 수정할 수 있으며, 더 나쁜 경우 이 파일이 로드되고 실행되어 원격 코드 실행 취약점이 발생합니다. 이것은 단지 이론적 예가 아니라 앱 스토어에서 1억 다운로드를 기록한 앱 마이 토킹 톰(My Talking Tom)에서 입증되었습니다. 다음은 블랙 햇에서 선보인 악용 동영상입니다.

항상 zip 라이브러리의 동작을 확인하여 불안감을 인식하십시오. zip 라이브러리에서 경로 통과를 비활성화할 수 없는 경우 각 항목을 추출하기 전에 각 항목의 이름을 유효성검사해야 합니다. 이름은 정식화되어야 하며 결과 경로는 아카이브를 추출하려는 디렉터리에 있어야 합니다. 우리는 그것에 있는 동안, 당신은 또한 zip 폭탄을 방지 하기 위해 추출 된 아카이브의 총 크기를 확인 해야, 하지만이 또 다른 주에 대 한 게시물 될 것입니다.

경로 통과에 대한 몇 가지 문제를 해결하거나 보안 코딩 기술을 테스트하려면 플랫폼을 확인하십시오.

다음에 당신을 보고, 기억, 보안 코드 또는 아니 코드!

- 임의의 수의 "로 이름이 미리 고정된 지퍼에 파일을 삽입할 수 있습니다. / "
- 지퍼 라이브러리가이 경우를 제대로 처리하지 않으면 의도 된 추출 디렉토리 외부에서 작성 할 수 있습니다.
- zip 파일이 신뢰할 수 없는 경우 공격자에게 임의쓰기 취약점이 제공됩니다.

https://www.blackhat.com/docs/ldn-15/materials/london-15-Welton-Abusing-Android-Apps-And-Gaining-Remote-Code-Execution.pdf

XML(확장 가능한 Markup 언어)은 기계와 사람이 읽을 수 있는 형식으로 문서를 인코딩하는 데 사용되는 태그 언어입니다. 그러나 일반적으로 사용되는 이 형식에는 여러 보안 결함이 포함됩니다. 이 첫 번째 XML 관련 블로그 게시물에서 스키마를 사용하여 XML 문서를 안전하게 처리하는 기본 사항에 대해 설명합니다.

OWASP는 XML 및 XML 스키마와 관련된 다양한 취약점을 두 범주로 나눕니다.

잘못된 XML 문서

잘못된 XML 문서는 W3C XML 사양을 따르지 않는 문서입니다. 잘못된 문서로 인해 다른 요소의 순서를 변경하거나 금지된 문자의 사용이 끝나는 태그를 제거하는 몇 가지 예가 있습니다. 이러한 모든 오류는 치명적인 오류가 발생해야 하며 문서는 추가 처리를 거치지 않아야 합니다.

잘못된 문서로 인한 취약점을 방지하기 위해 W3C 사양을 따르고 잘못된 문서를 처리하는 데 훨씬 더 오래 걸리지 않는 잘 테스트된 XML 파서를 사용해야 합니다.

잘못된 XML 문서

잘못된 XML 문서는 잘 형성되지만 예기치 않은 값이 포함되어 있습니다. 여기서 공격자는 XML 스키마를 제대로 정의하지 않는 응용 프로그램을 활용하여 문서가 유효한지 여부를 식별할 수 있습니다. 아래에서 올바르게 유효성을 검사하지 않으면 의도하지 않은 결과가 발생할 수 있는 문서의 간단한 예제를 찾을 수 있습니다.

XML 데이터에 트랜잭션을 저장하는 웹 스토어:

   <purchase></purchase>
     <id>123</id>
     <price>200</price>
   

And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>

   <purchase></purchase>
     <id>123</id>
     <price>0</price>
     <id></id>
     <price>200</price>
   

If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>

스키마가 충분히 제한적이지 않거나 다른 입력 유효성 검사가 충분하지 않으므로 음수, 특수 소수점(예: NaN 또는 Infinity) 또는 예상되지 않은 곳에 매우 큰 값을 입력하여 유사한 의도하지 않은 동작으로 이어질 수 있습니다.

잘못된 XML 문서와 관련된 취약점을 방지하려면 부적절한 데이터 유효성 검사 문제를 방지하기 위해 정확하고 제한적인 XML 스키마를 정의하여 수행해야 합니다.

다음 블로그 게시물 우리는 점보 페이로드와 두려워 OWASP 상위 10 번호 4, XXE와 같은 XML 문서에 대한 몇 가지 고급 공격에 갈 것입니다.

그 동안 포털에서 XML 입력 유효성 검사에 대한 기술을 연마하거나 이의를 제기할 수 있습니다.

XML 및 XML 스키마에 대한 사양에는 여러 보안 결함이 포함됩니다. 동시에 이러한 사양은 XML 응용 프로그램을 보호하는 데 필요한 도구를 제공합니다. XML 스키마를 사용하여 XML 문서의 보안을 정의하더라도 파일 검색, 서버 측 요청 위조, 포트 스캐닝 또는 무차별 강제 등 다양한 공격을 수행하는 데 사용할 수 있습니다.

https://www.owasp.org/index.php/XML_Security_Cheat_Sheet

실패한 모든 인증 시도, 액세스 거부 및 입력 유효성 검사 오류로 인해 실패한 사이버 보안 계획의 결과로 로깅 및 모니터링 결함이 부족합니다. 프로덕션 환경의 다른 지점에서 발생할 수 있지만 잘못된 로그인 시도를 중지하지 못한 것과 가장 관련이 있습니다.

사이버 보안 팀이 공격에 대해 알지 못하기 때문에 공격에 대응하지 않는다는 것을 의미하기 때문에 위험한 취약점입니다. 이를 통해 공격자는 시스템을 더 관통하거나 자격 증명을 업그레이드하는 동안 눈에 띄지 않게 유지될 수 있습니다. 사실 적절한 로깅 및 모니터링이 없으면 공격을 감지하고 중지하는 것이 매우 어렵거나 불가능해집니다.

지금 도전으로 기술을 테스트 할 준비가 되셨습니까? 이것 좀 확인해 주세요:

공격자는 부족한 로깅 및 모니터링을 어떻게 악용합니까?

모든 API는 로깅 수준이 올바르게 설정되지 않은 경우, 너무 낮게 설정된 경우, 오류 메시지에 충분한 세부 정보를 포함하지 않거나 로깅 기능이 전혀 없는 경우 부족한 로깅 및 모니터링에 취약합니다.

흥미로운 예는 해커가 웹 사이트 또는 서비스에 대한 손상된 사용자 이름의 큰 목록을 얻은 경우입니다. 실험을 통해 시스템을 잠그기 전에 세 번의 로그인 시도가 필요하고 사이버 보안 담당자에게 통보되기 전에 세 번의 로그인 시도가 필요하다는 것을 알 수 있습니다.

이 정보로 무장한 그들은 대신 단일 계정을 무력화하는 대신 "123456" 또는 "암호"와 같은 일반적인 암호를 사용하여 손상된 목록의 모든 이름으로 로그인하기 위해 스크립트를 작성할 수 있습니다. 트릭은 잠금 및 경고에 대한 임계값 이하로 유지, 한 번, 또는 두 번 각 사용자 이름을 시도한다는 것입니다. 운이 좋다면 박쥐에서 적어도 몇 개의 암호를 손상시킬 수 있습니다. 그 후, 그들은 단순히 재설정 하 고 "qwerty" 또는 "신"과 같은 다른 암호를 사용 하 여 프로세스를 다시 실행 하는 로그인 카운터에 대 한 하루를 기다립니다. 관리자가 자신이 하는 일을 감지하지 못하면 공격자는 목록을 여러 번 살펴보고 결국 대부분의 계정을 약한 암호로 손상시킬 수 있습니다.

OWASP제공 예에서 비디오 공유 플랫폼이 부족한 로깅 및 모니터링 취약점을 악용하는 자격 증명 스터핑 공격을 사용하여 공격을 받은 예에서 발생했습니다. 회사가 사용자 불만을 제기하기 시작하기 전까지는 공격이 일어나고 있다는 것을 전혀 알지 못했습니다. 결국, 그들은 API 로그에서 증거를 발견하고 모든 사용자에게 강제 암호 변경 알림을 발행하고 규제 당국에 공격을보고해야했습니다.  

부족한 로깅 및 모니터링 취약점 제거

자동화 및 지속적인 모니터링은 이 취약점을 종식시키는 데 도움이 될 수 있습니다. 시작하려면 실패한 모든 인증 시도를 기록해야 합니다. 또한 이 로그는 STIX 및 TAXII와 같이 기계가 읽을 수 있는 형식으로 넣어 사용 임계값에 관계없이 공격을 검색하도록 훈련된 SIEM(보안 정보 및 이벤트 관리) 시스템으로 수집할 수 있어야 합니다.

또한 로그 파일을 보호해야 합니다. 중요한 정보로 취급하고 공격자의 삭제 또는 수정으로부터 보호합니다. 좋은 정책은 로그 파일을 백업하고 암호화하는 것입니다.

마지막으로 의심스러운 활동을 가능한 한 빨리 감지하고 응답할 수 있도록 사용자 지정 대시보드 및 경고를 만듭니다. 시스템에서 공격자의 시간을 제거하면 낮고 느린 공격 기술을 사용하여 탐지되지 않은 상태로 유지하는 기능을 제거합니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

2015년부터 전 세계 개발자들에게 보안에 대한 적극적이고 긍정적인 접근 방식을 통해 코드를 보호하고, 재작업 과 수정을 줄이며, 보안 팀을 재미있는 경찰이 아닌 다른 것으로 볼 수 있도록 돕고 있습니다.

우리는 여전히 은하계 전역에서 코드를 확보함에 따라 개발자와 나란히 서기 위해 최선을 다하고 있지만, 전투를 강화하고 보안 인식 개발자를 다음 단계로 끌어 올릴 때입니다.

새로운 기능 출시를 발표하게 되어 기쁩니다. Secure Code Warrior 플랫폼: Missions . 이 새로운 챌린지 범주는 개발자가 정한 보안 교육의 다음 단계로, 사용자를 보안 지식 의 리콜에서 실제 시뮬레이션 환경에 적용하는 것으로 이동합니다. 이 비계, 마이크로 러닝 접근 방식은 작업 과 관련된 강력한 안전한 코딩 기술을 구축, 훨씬 더 재미있는보다 (수직적으로) 근무의 배경에 끝없는 교육 비디오를보고.

우리의 첫 번째 플레이, 공공 임무는 GitHub 유니코드 위반의 시뮬레이션입니다. 그것은 현혹 간단 보일 수 있습니다., 하지만 그것은 해부 하는 재미 정말 영리한 취약점. 보안 연구원 0xsha는 이 동일한 버그가 사례 변환을 통해 장고를 악용하는 데 어떻게 사용될 수 있는지에 대한 포괄적인 사례 연구를 하는 동시에 프로그래밍 언어 간에 취약점 동작이 어떻게 변할 수 있는지를 밝혔습니다. 이 보안 문제에 대해 더 많은 것을 발견할 수 있으며, 우리의 임무는 시작하기에 좋은 장소입니다.

GitHub의 정면(사례 매핑) 충돌

2019년 11월 28일 블로그 게시물에서 보안 연구 그룹 지혜는 GitHub에서 발견한 보안 버그에 대해 보고했습니다. 그들은 유니코드에서 사례 매핑 충돌을 사용하여 잘못된 이메일 주소로 암호 재설정 전자 메일 전송을 트리거할 수 있는 방법을 설명했습니다(또는 공격자처럼 생각하고 있는 경우 위협 행위자가 선택한 이메일 주소).

보안 취약점은 결코 좋은 소식이 아니지만, 화이트햇을 흔들보안 연구원들은 코드베이스에서 잠재적으로 악용가능한 오류를 발견하면 재해를 피할 수 있는 기회는 말할 것도 없고 자비를 제공합니다. 그들의 블로그와 보고서는 종종 훌륭한 독서를 위해 만들고, 새로운 취약점과 그것이 어떻게 작동하는지에 대해 배우는 것은 멋지다.

보안 코딩 기량의 다음 단계로 이동하기 위해, 그것은 단지 일반적인 취약점을 찾을 수 없습니다 (특히 멋진 새로운 것 - 우리 모두는 악의적 인 위협 배우가 이러한 새로운 기술로 일부 데이터를 발굴하는 비옥한 땅을 찾고있을 것입니다 알고) 뿐만 아니라 그들을 악용하는 방법을 이해하는 안전, 실습 환경을 가지고.

그래서, 그냥 그렇게 할 수 있습니다. 유니코드의 케이스 매핑 충돌이 어떻게 악용되는지, 실시간으로 어떻게 보이는지, 보안 연구원의 사고 방식을 어떻게 활용할 수 있는지 알아보려면 계속 읽으십시오.

지금 케이스 매핑 충돌에 걸릴 준비가 되셨습니까? 바로 단계:

유니코드: 복잡하고 끝없이 사용자 정의 할 수 있으며 이모티콘 그 이상

"유니코드"는 보통 사람의 어휘에 있지 않을 수 있지만 대부분의 사람들이 매일 어떤 형태로 든 사용할 가능성이 높습니다. 웹 브라우저, Microsoft 소프트웨어 또는 이모티콘을 사용한 경우 유니코드와 친밀하고 친분적입니다. 전 세계 대부분의 작사 시스템에서 텍스트를 일관되게 인코딩하고 처리하는 표준으로, 모두가 단일 문자 세트를 사용하여 (디지털 방식으로) 자신을 표현할 수 있도록 합니다. 143,000자 이상이 기재되어 있기 때문에 아이슬란드인이든 터키점도 사용하지 않든, 그 사이에 는 무엇이든 다루고 있습니다.

유니코드가 세트에 있는 문자의 양이 많기 때문에 캐릭터를 다른 "동등한" 캐릭터로 변환하는 방법이 많은 경우에 필요합니다. 예를 들어, 점없는 유니코드 문자열을 ASCII로 변환하면 단순히 "i"로 바뀌어야한다는 것이 합리적일 것으로 보입니다.

문자 인코딩의 큰 볼륨으로 재해에 대한 큰 잠재력을 온다

유니코드의 사례 매핑 충돌은 비즈니스 논리 결함이며 핵심은 2FA로 보호되지 않는 계정의 계정 인수로 이어질 수 있습니다. 문제의 취약점을 설명하기 위해 실제 코드 스니펫에서 이 버그의 예를 살펴보겠습니다.

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

논리는 다음과 같이 진행됩니다.

1. 사용자가 제공한 전자 메일 주소를 수락하고 일관성을 위해 대문자로 사용됩니다.
2. 전자 메일 주소가 데이터베이스에 이미 있는지 확인합니다.
3. 이 경우 새 임시 암호를 설정합니다 (이것은 모범 사례가 아닙니다. 대신 암호 재설정을 가능하게 하는 토큰링크가 있는 링크를 사용하십시오.
4. 그런 다음 임시 암호를 포함하는 1 단계에서 가져온 주소로 이메일을 보냅니다 (이것은 매우 가난한 관행입니다. 이케스.)

사용자가 이메일 John@G î tHub.com(터키 점리스 i)에 대한 암호 재설정을 요청하는 원래 블로그 게시물에제공된 예제에서 어떤 일이 발생하는지 살펴보겠습니다.

1. 논리는 John@G JOHN@GITHUB.COM thub.com 변환
2. 데이터베이스에서 위로 보이는 사용자가 JOHN@GITHUB.COM
3. 새 암호를 생성하고 John@G thub.com

이 프로세스는 매우 민감한 이메일을 잘못된 전자 메일 주소로 전송하게 됩니다. 이런!

이 유니 코드 악마를 캐스팅하는 방법

이 특정 취약점의 흥미로운 측면은 취약하게 만드는 여러 가지 요인이 있다는 것입니다.

1. 실제 유니코드 캐스팅 동작
2. 사용할 전자 메일 주소(예: 데이터베이스)에 이미 존재하는 이메일 주소 대신 사용할 전자 메일 주소를 결정하는 논리입니다.

이론적으로 지혜의 블로그 게시물에 식별된 두 가지 방법으로 이 특정 문제를 해결할 수 있습니다.

1. Punycode 변환을 통해 이메일을 ASCII로 변환
2. 사용자가 제공한 이메일 주소가 아닌 데이터베이스의 전자 메일 주소를 사용합니다.

소프트웨어를 강화하는 데 있어 가능한 한 많은 방어 층을 사용하여 우연히 아무것도 남기지 않는 것이 좋습니다. 우리가 아는 모든, 이 인코딩을 악용하는 다른 방법이있을 수 있습니다 - 우리는 아직 그들을 인식하지 못하고 있습니다. 위험을 줄이고 공격자에게 열려 있을 수 있는 창을 닫기 위해 할 수 있는 모든 일은 유용합니다.

직접 이것을 시도 할 준비가 되셨습니까?

대부분의 개발자는 손상된 데이터가 비즈니스에 좋지 않은 다는 것을 알고 있습니다. 그러나 보안 인식 엔지니어는 증가하는 취약점, 침해 및 사이버 보안 불황에 대한 강력한 해독제입니다.

보안 코딩 및 인식 기술을 다음 단계로 끌어올릴 시간입니다. 프런트 엔드 및 백엔드 컨텍스트 모두에서 잘못된 코드가 미치는 영향을 볼 수 있는 몰입형 안전한 시뮬레이션에서 이 GitHub 취약점을 경험하십시오. 공격자는 장점이 있으므로 경기장도 만들고 화이트햇 카운터 펀치로 실제 기술을 적용합시다.

이 목록의 대부분의 취약점은 API와 매우 관련이 있지만 비활성화된 보안 기능/디버그 기능 사용/부적절한 권한 문제는 어디서나 공격할 수 있는 문제입니다. API에서 좀 더 널리 퍼질 가능성이 있지만 공격자는 종종 패치되지 않은 결함과 보호되지 않은 파일 또는 네트워크 의 어느 곳에서나 디렉토리를 찾으려고 시도합니다. 디버깅을 사용하도록 설정하거나 보안 기능을 사용하지 않도록 설정한 API를 통해 오면 악의적인 작업이 좀 더 쉬워집니다. 더 나쁜 것은 자동화된 도구가 보안 오구성을 감지하고 악용할 수 있으므로 환경에 있는 경우 악용될 가능성이 있으므로 이 취약점으로 인해 위험한 API 결함의 OWASP 목록이 발생하게 됩니다.

우리가 재미에 들어가기 전에,이 디버그 문제를 해결할 수 있는지 확인 :

비활성화된 보안 기능/디버그 기능을 활성화/부적절한 사용 권한 결함은 API에 어떻게 몰래 넣을 수 있습니까?

이 다차원 API 결함이 네트워크에 어떻게 추가되는지 확인하려면 해당 다차원 API 결함이 해당 구성 요소 부분으로 분해해야 합니다. 활성화된 디버그 기능 문제부터 시작해 보겠습니다. 디버깅은 개발자가 응용 프로그램이 제대로 수행되지 않거나 오류를 만들지 않는 이유를 파악하는 데 도움이 되는 유용한 도구입니다. 디버깅을 사용하도록 설정하면 오류 와 예외가 자세한 오류 페이지를 생성하므로 개발자가 무엇이 잘못되었는지 확인하고 문제를 해결할 수 있습니다. 응용 프로그램이 아직 개발 중인 동안 이 활성을 갖는 것은 완벽합니다.

그러나 대부분의 프레임워크에 디버깅이 활성화된 코드에서 프로덕션 환경에서 디버그 모드를 실행하는 것에 대한 경고가 있는 이유가 있습니다. 예를 들어:

# 보안 경고 : 디버그가 생산에서 켜져 실행되지 마십시오!
디버그 = True

이 예제에서는 디버깅이 활성화되었습니다. 예외가 발생하면 장고 응용 프로그램은 자세한 오류 페이지를 생성합니다. 프로덕션 환경에서 이 작업을 수행하는 경우 적대범은 환경에 대한 메타데이터 정보를 포함하는 이러한 오류 페이지에 액세스할 수 있습니다. 대부분의 프레임워크는 기본적으로 디버깅을 해제했지만 긴 개발 프로세스 중에 활성화되면 다시 전환하는 것을 잊어버리기 쉽습니다. 그런 다음 응용 프로그램이 프로덕션 환경으로 이동하면 공격자에게 응용 프로그램 또는 전체 서버 또는 네트워크를 손상시키는 방법에 대한 많은 정보를 제공합니다.

디버그 모드를 사용하도록 설정하는 것은 대부분 독립 실행형 문제이지만 부적절한 사용 권한과 비활성화된 보안 기능은 취약점이 함께 작동하는 경우가 많습니다. 예를 들어 OWASP에서 제공하는 실제 시나리오에서 공격자는 검색 엔진을 사용하여 실수로 인터넷에 연결된 데이터베이스를 찾습니다. 인기 있는 데이터베이스 관리 시스템이 기본 구성을 사용하고 있었기 때문에 인증이 비활성화되었습니다. 따라서 부적절한 권한과 비활성화된 보안 기능을 결합하여 취약점을 제공함으로써 공격자는 PII, 개인 기본 설정 및 인증 데이터와 수백만 개의 레코드에 액세스할 수 있게 되었습니다.

비활성화된 보안 기능/디버그 기능 사용/부적절한 권한 취약점 제거

이 취약점을 제거하는 두 갈래의 접근 방식을 만들어야 할 것입니다. 문제의 사용 가능한 디버그 부분을 제거하려면 개발 프로세스에 검사를 추가하여 API 또는 응용 프로그램을 프로덕션 환경으로 이동하기 전에 디버깅을 사용하지 않도록 하기만 하면 됩니다. 우리의 예에서, 그렇게 할 수있는 적절한 명령은 다음과 같습니다 .

# 보안 경고 : 디버그가 생산에서 켜져 실행되지 마십시오!
디버그 = 거짓

이제 장고 응용 프로그램의 디버그 피쳐는 FALSE로 구성된 DEBUG 플래그로 비활성화됩니다. 오류에 대한 응답으로 오류 페이지가 생성되지 않습니다. 적대국이 여전히 오류 페이지에 액세스할 수 있는 경우 유용한 메타데이터가 포함되지 않으며 응용 프로그램에 위험을 초래하지 않습니다.

다양한 특정 취약점을 포괄할 수 있으므로 비활성화된 보안 기능 및 부적절한 권한 취약점제거가 훨씬 더 어렵습니다. 이를 막는 가장 좋은 방법은 표준적이고 반복 가능한 프로세스를 개발하여 잠긴 자산을 프로덕션 환경에 빠르고 쉽게 배포할 수 있도록 하는 것입니다.

그럼에도 불구하고 오케스트레이션 파일, API 구성 요소 및 Amazon S3 버킷 사용 권한과 같은 클라우드 서비스가 지속적으로 검토되고 업데이트되는 프로세스를 만들어야 합니다. 또한 이 검토는 조직이 항상 API 보안을 개선하고 있는지 확인하기 위해 시간이 지남에 따라 전체 환경의 보안 설정의 전반적인 효율성을 평가해야 합니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

많은 최신 프레임워크는 개발자가 클라이언트의 입력을 코드 변수 및 내부 개체로 자동으로 바인딩하는 함수를 사용하도록 유도하기 때문에 대량 할당 취약점이 생깁니다. 이는 코드를 단순화하고 작업 속도를 높이기 위해 수행됩니다.

공격자는 이 방법론을 사용하여 클라이언트에서 업데이트해서는 안 되는 개체 속성에 변경 내용을 강제로 사용할 수 있습니다. 일반적으로 이로 인해 사용자가 웹 사이트를 가져오거나 회사 기밀을 훔치는 대신 관리자 권한을 자신에게 추가하는 것과 같은 비즈니스 별 문제가 발생합니다. 공격자는 또한 개체 간의 관계와 악용 중인 응용 프로그램의 비즈니스 논리에 대해서도 고려해야 합니다.

그러나, 그 중 어느 것도 대량 할당 취약점 영리하고 악의적 인 사용자의 손에 덜 위험하게만들지 않습니다.

전체 가이드를 시작하기 전에 게임화된 챌린지를 플레이하고 요금을 어떻게 알려주는지 확인하세요.

공격자는 대량 할당 취약점을 어떻게 악용할 수 있습니까?

OWASP에 의해 제시된 시나리오(그리고 당사가 약간 수정)는 질량 할당을 사용하여 코드의 개체에 바인딩된 다른 속성을 포함하는 차량 공유 응용 프로그램을 가정합니다. 여기에는 사용자가 변경할 수 있는 권한 관련 속성과 응용 프로그램에서만 내부적으로만 설정해야 하는 프로세스 종속 속성이 포함됩니다. 둘 다 질량 할당을 사용하여 속성을 개체에 바인딩합니다.

이 시나리오에서는 차량 공유 응용 프로그램을 통해 많은 사용자가 많은 사용자를 향한 응용 프로그램에서 흔히 볼 수 있듯이 프로필을 업데이트할 수 있습니다. 이 작업은 PUT로 전송된 API 호출을 사용하여 수행되며 다음 JSON 개체를 반환합니다.

{"user_name":"SneakySnake", "age":17, "is_admin":false}

이 경우 공격자인 SneakySnake씨가 속성과 개체 간의 관계를 파악했기 때문에 다음 문자열로 프로필을 업데이트하라는 원래 요청을 다시 보낼 수 있습니다.

{"user_name":"SneakySnake","age":24,, "is_admin":true}

끝점이 질량 할당에 취약하므로 새 입력을 유효한 것으로 받아들입니다. 뿐만 아니라 우리의 해커는 자신의 프로필에 몇 년을 추가 않았다, 그러나 그는 또한 자신에게 관리 권한을 할당.

대량 할당 취약점 제거

일부 프레임워크에서 대량 할당 함수를 사용하는 것이 편리할 수 있으므로 API를 안전하게 유지하려는 경우 이를 사용하지 않아야 합니다. 대신 요청 값을 개체에 직접 바인딩하는 대신 구문 분석합니다. 또한 감소된 데이터 전송 개체를 사용하여 관련 위험 없이만 개체 자체에 직접 바인딩하는 것과 거의 동일한 편의성을 제공할 수 있습니다.

추가 예방 조치로 위의 예제의 관리자 권한과 같은 중요한 속성은 거부되어 API 호출의 서버에서 허용되지 않을 수 있습니다. 더 나은 아이디어는 기본적으로 모든 속성을 거부 한 다음 사용자가 업데이트하거나 변경할 수 있도록 특정, 비 민감하지 않은 것들을 허용하는 것입니다. 이러한 작업을 수행하면 API를 잠그고 사용자 환경에서 대량 할당 취약점을 제거하는 데 도움이 될 수 있습니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

새로운 GitHub 액션을 사용하여 GitHub 코드 검색 워크플로우에서 직접 업계 표준 SARIF 파일에 개발자 중심 교육을 추가합니다.

9월 30일, GitHub는 GitHub 코드 스캔의일반적인 가용성을 공식적으로 발표했습니다. GitHub 코드 스캔은 프로덕션 환경에 도달하기 전에 보안 취약점을 쉽게 찾는 개발자 우선 GitHub 네이티브 접근 방식입니다.

코드 스캐닝은 GitHub 작업" 또는 기존 CI/CD 환경과 통합되어 개발 팀의 유연성을 극대화합니다. 코드가 생성될 때 코드를 스캔하고, 끌어오기 요청 내에서 실행 가능한 보안 검토를 표면화하고, GitHub 워크플로의 일부로 보안을 자동화합니다.

개발자를 위한 보안에 대한 원활한 접근 방식입니다.

개방형 SARIF(정적 분석 결과 교환 형식) 표준을 기반으로 구축된 코드 스캔은 끊임없이 증가하는 조직의 요구에 부응하도록 설계되어 동일한 GitHub 네이티브 환경 내에 오픈 소스 및 상용 정적 애플리케이션 보안 테스트(SAST) 솔루션과 같은 것을 포함할 수 있습니다.

타사 코드 검색 도구는 끌어오기 요청과 같은 GitHub 자체의 이벤트를 기반으로 GitHub 작업 또는 GitHub 앱을 사용하여 시작할 수 있습니다. 결과는 SARIF로 형식화되고 GitHub 보안 경고 탭에 업로드됩니다. 그런 다음 도구별로 경고가 집계되고 GitHub는 중복 경고를 추적하고 억제할 수 있습니다. 이를 통해 개발자는 네이티브 GitHub 환경 내에서 GitHub의 모든 프로젝트에 대해 선택한 도구를 사용할 수 있습니다. 간단히 말해서 보안에 대한 전통적인 접근 방식의 혼란을 줄이고 개발자 워크 플로우를 존중합니다.

어제 Secure Code Warrior GitHub는 블로그 게시물에서 유일한 개발자 중심 교육 제공업체인 Third-Party 코드 스캐닝 도구: 정적 분석 및 개발자 보안 교육,Synk, Checkmarx, 주문형 요새, 시놉시스 및 Veracode와 함께 선보였습니다.

많은 SCA/SAST 솔루션이 발견된 각 취약점에 대해 많은 세부 정보와 게시된 권고 및 관련 CWEs에 대한 참조를 제공하지만 모든 개발자가 보안 전문가도 아니며 이를 기대할 수 없습니다. 실용적이고 사용 가능한 조언과 도구는 실행 가능한 인식의 핵심입니다.

컨텍스트 마이크로 러닝.

개발자가 취약점에 대해 더 많이 사용할수록 위험을 더 많이 이해하고 가장 시급한 문제를 해결하는 데 우선 순위를 정하고 궁극적으로 취약점을 방지할 수 있습니다. 그게 바로 그곳이다 Secure Code Warrior 들어옵니다. 우리의 임무는 개발자가 처음부터 재미, 참여 및 프레임 워크 별 교육을 통해 보안 코드를 작성할 수 있도록 하여 보안 준수, 일관성, 품질 및 개발 속도를 신속하게 개선할 수 있도록 보안 사고 방식을 생각하고 코딩하는 것입니다.

GitHub 코드 스캔 통합

Secure Code Warrior GitHub 코드 검색에 컨텍스트 학습을 제공하는 GitHub 작업을 구축했습니다. 즉, 개발자는 Snyk 컨테이너 작업과 같은 타사 작업을 사용하여 취약점을 찾은 다음 CWE별 하이퍼 관련 학습으로 출력을 보강할 수 있습니다.

이 Secure Code Warrior GitHub Action은 업계 표준 SARIF 파일을 처리하고 SARIF 규칙 개체의 CWE 참조를 기반으로 컨텍스트 학습을 추가합니다. 이를 통해 개발 및 보안 팀은 취약성을 찾을 수 있을 뿐만 아니라 취약성이 다시 발생하지 않도록 방지 하는 실행 가능한 지식으로 지원되는 SAST 도구 보고서를 풍부하게 관리할 수 있습니다.

직접 해볼 준비가 되셨습니까?

여기에서 GitHub 마켓플레이스에서 직접 무료로 작업을 수행할 수 있습니다.
에 대해 자세히 알아보기 Secure Code Warrior GitHub 액션은 여기에 있습니다.

이 블로그 시리즈는 응용 프로그램 프로그래밍 인터페이스(API)와 관련된 최악의 취약점 중 일부에 초점을 맞출 것입니다. 이러한 상태는 너무 나빠서 개방형 웹 응용 프로그램 보안프로젝트(OWASP)상위 API 취약점 목록을 만들었습니다. 최신 컴퓨팅 인프라에 API가 얼마나 중요한지를 감안할 때, 이러한 문제는 응용 프로그램 및 프로그램을 모든 비용으로 유지해야 하는 중요한 문제입니다.

누락된 함수 수준 액세스 제어 취약점을 통해 사용자는 제한해야 하는 기능을 수행하거나 보호해야 하는 리소스에 액세스할 수 있습니다. 일반적으로 함수와 리소스는 코드 또는 구성 설정에 의해 직접 보호되지만 올바르게 수행하는 것이 항상 쉬운 것은 아닙니다. 최신 응용 프로그램에는 여러 유형의 역할과 그룹과 복잡한 사용자 계층 구조가 포함되기 때문에 적절한 검사를 구현하는 것이 어려울 수 있습니다.

하지만 먼저, 이 까다로운 종류의 버그를 탐색할 때 어디에서 있는지 확인하기 위해 게임화된 도전을 플레이해 보는 것은 어떨까요?

좀 더 심층적인 모습을 살펴보겠습니다.

API는 구조가 높기 때문에 특히 이 결함에 취약합니다. 코드를 이해하는 공격자는 코드를 제한해야 하는 명령을 구현하는 방법에 대해 교육된 추측을 할 수 있습니다. 이것이 기능/리소스 수준 액세스 제어 취약점으로 인해 OWASP 상위 10위권이 된 주된 이유 중 하나입니다.

공격자는 함수 수준 액세스 제어 취약점을 어떻게 악용할 수 있습니까?

함수 나 리소스가 제대로 보호되지 않는다고 의심되는 공격자는 먼저 공격하려는 시스템에 액세스해야 합니다. 이 취약점을 악용하려면 합법적인 API 호출을 끝점으로 보낼 수 있는 권한이 있어야 합니다. 아마도 낮은 수준의 게스트 액세스 기능 또는 응용 프로그램의 기능의 일부로 익명으로 가입 하는 몇 가지 방법이 있다. 해당 액세스 권한이 설정되면 합법적인 API 호출에서 명령을 변경할 수 있습니다. 예를 들어 PUT로 GET을 교환하거나 URL의 사용자 문자열을 관리자로 변경할 수 있습니다. API가 구조화되어 있기 때문에 허용되는 명령과 문자열에 배치할 위치를 쉽게 추측할 수 있습니다.

OWASP는 신규 사용자가 웹 사이트에 가입할 수 있도록 설정된 등록 프로세스의 이러한 취약점을 예로 들 수 있습니다. 다음과 같이 API GET 호출을 사용할 수 있습니다.

/api/초대/{invite_guid}

악의적인 사용자는 사용자의 역할과 이메일을 포함하여 초대에 대한 세부 정보가 포함된 JSON을 다시 가져옵니다. 그런 다음 GET을 POST로 변경하고 다음 API 호출을 사용하여 사용자에서 관리자로 초대를 올릴 수도 있습니다.

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

관리자만 POST 명령을 보낼 수 있어야 하지만 제대로 보호되지 않으면 API는 이를 합법적인 것으로 받아들이고 공격자가 원하는 대로 실행합니다. 이 경우 악의적인 사용자가 새 관리자로 시스템에 참여하도록 초대됩니다. 그 후, 그들은 합법적 인 관리자가 할 수있는 것을보고 할 수 있었고, 이는 좋지 않을 것입니다.

기능 수준 액세스 제어 취약점 제거

공격자가 구조화 된 API 내에서 보호되지 않은 함수를 찾는 것은 어렵지 않기 때문에 이 API 취약점을 방지하는 것이 특히 중요합니다. API에 대한 어느 수준의 액세스 권한을 얻을 수 있는 한 코드 구조를 매핑하고 결국 팔로우할 호출을 만들 수 있습니다.

따라서 역할 기반 권한 부여 방법을 사용하여 모든 비즈니스 수준 기능을 보호해야 합니다. 대부분의 프레임워크는 이를 실현하기 위해 중앙 집중식 루틴을 제공합니다. 선택한 프레임워크가 구현하기 어려운 경우 쉽게 사용할 수 있도록 특별히 빌드된 외부 모듈이 많이 있습니다. 궁극적으로 어떤 방법을 선택하든 서버에서 권한을 구현해야 합니다. 클라이언트 측에서 함수를 보호하려고 하지 마십시오.

함수 및 리소스 수준 권한을 만들기 위해 작업할 때는 사용자에게 필요한 작업과 더 이상 수행할 수 있는 권한만 부여해야 합니다. API 또는 기타 것을 코딩할 때항상 그렇듯이 권한 방법론을 가장 적게 연습하십시오. 그것은 당신의 환경을 보호하고 도로 아래로 사이버 보안 관련 문제를 많이 머리를 것입니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

사이버 보안 전문가를 위한 연례 행사에서 국가 사이버 보안 인식의 달은 많은 기업들이 조직 전체의 일반적인 보안 인식 심장 박동에 대해 숙고하고 평가하는 데 활용하는 시간입니다. 그리고 2018년에만 62%의 기업이 피싱 또는 사회 공학 공격을 경험하고 있기 때문에, 보안 역할이든 그렇지 않든 비즈니스의 모든 개인을 보장하는 것의 중요성은 적절한 사이버 보안 인식 교육을 과장할 수 없습니다.

점점 더 글로벌 한 이벤트가 됨에 따라 이 달은 모범 사례를 논의하기 위한 캐치 올(catch-all)을 나타내며, 이니셔티브는 의도적으로 표면 화도를 보이고 있습니다. 그러나 강력한 보안 프로그램과 사내 전문가가 있는 조직조차도 이번에는 더 많은 기술 팀이 자신의 역할의 맥락에서 더 많은 보안 인식이 필요한 것을 평가할 수 있습니다.

AppSec 전문가, 개발 팀이 이끌고 엔지니어링 코호트의 보안에 정통한 구성원에게는 계란을 빨아 먹는 방법을 배우는 것처럼 느껴질 수 있지만, 회사 전체의 새로운 차원으로 보안과 안전을 밀어낼 수 있는 것은 비즈니스 내에서 이러한 챔피언입니다.

사이버 보안 인식의 달을 높이는 방법

이것은 보안 팀이 올리브 브랜치의 무언가를 개발 팀에 확장할 수 있는 절호의 기회입니다.

일부 킥오프 아이디어는 다음과 같습니다.

1. 개발자가 보안 코딩에 대해 배우는 데 필요한 지원을 받을 수 있도록 도와줍니다. 작업에 적합한 도구를 갖추지 못하는 것은 너무 단단한 바구니에 작업을 슬램 덩크에 정당화 느낄 수있는 좋은 방법입니다. 개발자가 코딩 프로세스에서 보안을 우선 순위로 볼 수 있는 올바른 교육 과 도구가 없다면 많은 팀이 공통의 취약점을 코드에서 제외할 수 있는 장비가 제대로 갖추어져 있는 것은 당연합니다.
   
   이번 달에 사용하여 개발 기술 스택에서 누락된 내용, 관리자가 함께 협력하여 통신을 개선하고 보안 가시성을 높일 수 있으며, 누가 보안을 옹호하고 옹호할 수 있는지 를 파악할 수 있습니다.
   
2. '점심 식사 및 학습' 이벤트를 개최합니다. 사이버 보안 및 개발 커뮤니티는 일반적으로 자신의 전문 지식을 공유하기에 너무 행복한 믿을 수 없을만큼 관대 한 사람들로 가득합니다. 컨퍼런스 연사, 다른 회사의 기술 동료 또는 현지 OWASP 챕터에 연락하여 누가 팀에 와서 채팅을 할 수 있는지 확인하거나 조직의 누군가와 웨비나 레코드를 기록할 수 있습니다. 비교적 빠른 승리이며, 유망한 개발자가 앞에서 다른 보안 경력 경로를 볼 수 있는 큰 이점이 될 수 있습니다.
   
3. 몇 가지 친절한 경쟁을 위해 수집합니다. 보안에 대해 배우는 것은 조금 다르고 특별한 무언가를 할 때 훨씬 더 재미있습니다. 보안 코딩 tournaments 개발자가 안전한 코딩 기술을 테스트하고 게임화된 환경에서 동료와 경쟁하도록 하는 좋은 방법입니다. 멋진 드레스 테마가 일어나고, 팀과 창의력을 발휘하십시오 (개발자 대 관리자는 어떻습니까?). 피자, 음료를 주문하고, 활기찬 음악 펌핑을 받으며, 조직 전체를 기억하는 이벤트가 될 수 있습니다.

커뮤니티에 환전하기: 무료 다운로드 Secure Code Bootcamp 앱

저는 개발자로서, 우리가 무료로 공유하고 사용할 수 있는 것을 검색하는 경우가 항상 있었습니다. 그것은 다른 사람을 도울 수 있는 몇 가지 프리웨어를 만들기 위해 자부심의 포인트, 그리고 이번 달은 우리의 뿌리를 반영 하 고 우리가 지역 사회에 제공할 수 있는 보고 좋은 시간.

이를 위해 새로운 무료 앱인 Secure Code Bootcamp 을 발표하게 되어 기쁘게 생각합니다. 이 앱은 언제 어디서나 보안 인식을 점진적으로 향상시키며 도전하고자 하는 코더를 위한 포켓용 보안 코딩 동반자입니다.

지금 iOS와 안드로이드에 대한 응용 프로그램을 다운로드하고, 찾아 노드에서 OWASP 취약점을 식별하는 방법을 배울 .JS, 파이썬 : 장고, 자바 : 봄, C # .NET : MVC :