데이터는 기업의 생명선입니다. 생존, 돈을 벌고 고객에게 서비스를 제공하는 데 필요한 기본 정보입니다. 점점 더 디지털 중심이 되는 사회에서 개발자들은 이 귀중한 정보의 관리인으로서 막대한 책임을 지고 있습니다. 개발자가 기밀 데이터를 보호하지 않으면 비즈니스는 안전하지 않은 암호화 스토리지에 속합니다.

데이터를 안전하게 저장하는 방법과 데이터를 저장하지 않을 때 발생할 수 있는 방법을 살펴보겠습니다.

안전하지 않은 암호화 스토리지 이해

공격자가 시스템에 액세스할 때 일반적으로 값 데이터를 찾기 위해 합니다. 알고 있는 데이터 유형은 다른 사람의 계정을 인수하는 데 사용하거나 다른 공격을 실행하는 데 사용할 수 있습니다. 때때로, 데이터의이 종류는 단순히 빠른 현금에 대한 암시장에서 판매된다.

안전하지 않은 암호화 스토리지는 SQL 주입 이나 XSS와 같은 단일 취약점이 아닙니다. 보호해야 하는 데이터를 보호해야 하는 방식으로 보호하지 않는 결과입니다.

중요한 정보는 보호되어야 합니다. 당신은 일반 텍스트에 암호 와 신용 카드 정보를 저장할 때, 당신은 당신의 사업과 러시아어 룰렛을 재생됩니다.

해커가 데이터베이스에 침입하여 SQL 주입, XML 주입 또는 기타 공격을 사용하여 데이터를 훔치는 경우 모든 것을 갖습니다. 그러나 데이터를 암호화하면 실제 데이터를 사용하는 데 훨씬 더 힘든 시간이 주어질 수 있습니다.

위반이 항상 악의적인 외부인의 결과는 아니라는 점에 유의해야 합니다. 악성 내부자는 암호화되지 않은 경우 쉽게 데이터를 훔칠 수 있습니다. 회사의 직원은 데이터베이스의 모든 것을 볼 필요가 없으며 부적절한 액세스 제어 또는 노출된 중요한 데이터가 완전히 도난당할 수 있습니다.

모든 암호화가 동일하지 않다는 것을 기억하십시오. 잘못된 암호화 알고리즘을 사용하는 것은 사용하지 않는 것만큼 위험합니다. 알려진 약한 알고리즘은 정통한 공격자에 대한 저항을 거의 제공하지 않습니다.

안전하지 않은 암호화 스토리지가 위험한 이유

많은 회사가 다른 취약점(예: SQL 주입)에 의해 손상되어 도난당한 데이터를 숨길 수 없게 됩니다. 이것은 끔찍한 상황을 더욱 악화시다.

• 성인 친구 파인더는 4억 1,200만 개의 계정을 유출하여 위반되었습니다. 계정의 암호는 약한 SHA-1 해싱 알고리즘으로 보호되었습니다. 그들은 한 달 이내에 공격자에 의해 쉽게 금이 되었습니다.
• Uber는 5,700만 건의 사용자 기록과 600,000건의 운전자 기록을 유출하여 위반되었습니다. 개인 정보가 손실되었습니다. Uber의 GitHub 계정에 Uber의 AWS 계정 사용자 이름과 비밀번호가 포함된 리포지토리가 오픈에 사용되어 있었기 때문에 발생했습니다... 좋은 생각이 아닙니다. Uber의 밸류에이션은 200억 달러 감소했으며, 이는 이 위반으로 인해 크게 감소했습니다.
• 소니의 플레이 스테이션 네트워크는 7,700 만 개의 계정을 유출, 위반되었다. 1,200만 개의 계정에암호화되지 않은 신용 카드 정보가 포함되어 있습니다. 소니는 나중에 위반에 대한 1$500 만 달러의 집단 소송을 해결했습니다.

중요한 데이터를 제대로 저장하지 않는 데는 분명히 심각한 결과가 있습니다.

소니는 상당한 처벌인 소송을 제기했습니다. 그러나 소송을 당하지 않더라도 평판및 규제 적 피해는 비즈니스에 치명적일 수 있습니다.

안전하지 않은 암호화 스토리지 를 패배

개발자는 위의 데이터 유출이 발생하지 않도록 어떻게 막을 수 있습니까?

첫 번째 단계는 암호화가 필요한 데이터를 식별하는 것입니다. 결국 모든 데이터가 동일하지는 않습니다. 데이터를 분류한다음 적절한 경우 암호화를 사용합니다.

일반적으로 주민등록번호, 비밀번호, 신용카드 정보와 같은 개인정보를 보호해야 합니다. 비즈니스의 특성에 따라 개인으로 간주되는 건강 기록 또는 기타 정보를 보호해야 할 수 있습니다.

어떤 데이터를 보호해야 하는지 알게 되면 다음 단계는 올바른 도구를 사용하여 보안을 보장하는 것입니다. 일반적으로, 그것은 시간의 시험을 서 하 고 강한 것으로 간주 되는 암호화 알고리즘에 충실 하는 것이 좋다.

아무리, 자신의 암호화 기능을 작성하지 않습니다. 공격자가 암호화를 끊는 데 사용할 수 있는 결함이 포함될 수 있습니다.

사회 보장 번호 또는 신용 카드 데이터와 같은 데이터를 암호화하려면 AES를사용합니다. AES에 대한 다른 작업 모드가 있으며, 쓰기 시 매우 권장되는 모드는 갈로이/카운터 모드(GCM)입니다. 또 다른 팁은 패딩 유형을 선택하도록 요청하는 라이브러리에 패딩을 사용하지 않도록 하는 것입니다.

암호의 경우 해시를 되돌릴 수 없으므로 해시 알고리즘을 사용하여 암호를 해시합니다. 해시된 값을 감안할 때 공격자는 값을 만든 원본 텍스트를 검색할 수 없습니다. Argon2및 Bcrypt는암호를 해시하는 데 적합한 선택으로 간주됩니다. 해시하기 전에 임의의 값을 가진 암호를 항상 "소금"해야 하므로 동일한 암호에 대해 두 해시가 비슷하지 않습니다.

이러한 함수에는 모든 주요 프로그래밍 언어/프레임워크에 대한 구현이 있습니다. 특정 언어 또는 프레임워크에 대한 설명서를 확인하여 효과적으로 사용하는 방법에 대한 정보를 확인하십시오.

주요 생성, 스토리지 및 관리는 암호화의 중요한 구성 요소입니다. 제대로 관리되지 않는 키를 노출하여 데이터를 해독하는 데 사용할 수 있습니다. 일부 프레임워크는 ASP와 같은 주요 관리에 도움이 됩니다. NET의 데이터 보호 API. 주요 관리를 위한 일반적인 모범 사례는 OWASP의 치트 시트를확인하십시오.

데이터를 안전하게 저장하는 것은 비용이 많이 들고 당황스러운 데이터 유출을 방지하는 방법입니다. 최악의 경우 공격자가 데이터를 도용할 수 있는 경우 악의적인 목적으로 데이터를 보거나 사용하는 데 훨씬 더 어려운 시간을 할애할 수 있습니다.

눈에 보이지 않는 곳에 데이터 숨기기

데이터를 보호하는 방법을 신속하게 살펴보겠습니다.

• 보호가 필요한 것을 알 수 있도록 데이터를 분류합니다.
• 중요한 데이터를 암호화하기 위해 업계에서 검증한 강력한 알고리즘을 사용
• 강력한 단방향 해시를 사용하여 암호 저장

주제를 자세히 연구하려면 학습 리소스를확인하십시오. 당신이 파고 연습 할 준비가되면, 당신의 원하는 언어로 우리의 플랫폼을 시도. 우리는 많이 커버!

이러한 도구를 사용하면 데이터가 도난당하지 않도록 하고 회사가 돈을 잃고 명성을 손상시키는 것을 방지할 수 있습니다.

지금 안전하지 않은 암호화 스토리지를 찾고 수정할 준비가 되셨습니까? 경기장으로 가서 기술을 테스트하십시오[여기에서 시작]

XQuery 주입 공격은 때때로 더 널리 퍼진 SQL 주입 공격에동생처럼 생각된다. 비슷한 근본 원인을 가지고 있으며 공격자가 이 두 가지 를 트리거하기 위해 악용하는 명령도 매우 가깝습니다. XQuery 주입 공격은 XML 데이터에 대한 XPath 쿼리 중에만 발생할 수 있습니다. 이 때문에 XPath 주입 또는 XPath 공격이라고도 합니다.

대부분의 웹 사이트는 XML 데이터베이스를 사용하여 사용자 로그인 자격 증명, 고객 정보, 개인 ID 정보 및 기밀 또는 민감한 데이터를 보유하는 것과 같은 중요한 기능을 수행하므로 XQuery 공격은 다소 큰 공격 공간을 제공합니다.

이 에피소드에서는 다음을 배우게 됩니다.

• 공격자가 XQuery 주사를 사용하는 방법
• XQuery 주사가 위험한 이유
• 이 취약점을 해결할 수 있는 기술입니다.

공격자는 XQuery 주입을 트리거하는 방법은 무엇입니까?

대부분의 컴퓨터 언어와 마찬가지로 XPath용 코드는 단순하게 설계되었습니다. 실제로 XPath는 표준 언어이며 모든 표기법 및 구문 문은 응용 프로그램을 사용하는 응용 프로그램에 관계없이 변경되지 않습니다. 즉, XPath 쿼리를 조작하는 데 사용되는 명령은 잘 알려져 있으며 자동화될 수도 있습니다.

핵심XPath 쿼리는 XML 데이터베이스에 조회할 정보를 알려주는 간단한 문입니다. 가장 간단한 예제 중 하나에서 사용자 레코드가 있는지 확인한 다음 로그인 자격 증명을 검색하는 데 사용됩니다. 문제는 XPath 쿼리에 사용자 입력이 포함되어 있으므로 해커가 쿼리를 조작하여 보호해야 하는 정보를 반환할 수 있다는 것입니다.

예를 들어 로그인 보안을 우회하려고 할 때 공격자는 전체 프로세스를 우회하는 XPath 쿼리 끝에 변수를 추가할 수 있습니다. 예제는 다음과 같이 보일 수 있습니다.

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

여기서 사용자 이름 필드는 1=1 또는 a=문 으로 인해 모든 사용자와 일치하도록 합니다. 쿼리의 첫 번째 부분만 사실이어야 하기 때문에 암호 필드는 중요하지 않습니다.

XQuery 주입이 위험한 이유는 무엇입니까?

XQuery 주입 공격이 매우 위험한 주된 이유는 공격자가 로그인 및 계정 보안을 우회할 수 있기 때문입니다. 또한 응용 프로그램에 따라 달라지지 않는 표준 언어를 사용하여 자동화된 방식으로 수행할 수 있습니다. 공격자는 이 취약점에 대해 웹 사이트 및 응용 프로그램을 자동으로 스캔하고 발견되는 즉시 조치를 할 수 있습니다. 앱이 취약한 경우 공격자가 앱이 손상됩니다. 계정 보안을 손상시키는 것 외에도 XQuery 공격을 데이터 유출에 사용할 수도 있습니다. 예를 들어 공격자는 XML 데이터베이스에서 모든 레코드를 전송할 수 있습니다.

XQuery 주입 공격 제거

유사한 취약점과 마찬가지로 한 가지 핵심 방어는 단순히 사용자 입력을 신뢰하지 않는 것입니다. 사용자가 데이터베이스 쿼리를 만들든 그렇지 않든 정보를 입력할 수 있는 경우 프로세스를 면밀히 조사해야 합니다. 그것은 물리적 건물의 창문과 문을 확보하는 것과 다르지 않다, 그 사람들이 액세스 할 수있는 주요 방법이기 때문에.

XQuery 사출 보호의 경우 필터링을 통해 사용자 입력을 소독하거나 사용자 입력의 화이트리스트 입력 유효성 검사를 사용하여 수행됩니다. SQL 쿼리에 대해 준비된 문과 유사한 매개 변수XPath 인터페이스를 사용할 수도 있습니다.

마지막으로 모든 응용 프로그램에 최소 권한을 적용해야 합니다. 즉, 모든 응용 프로그램 쿼리를 수행할 수 있는 읽기 전용 권한이 있는 사용자를 만드는 것을 의미할 수 있습니다.

이러한 기술을 사용하면 웹 사이트 또는 응용 프로그램에 대해 모든 XQuery 주입 시도를 중지할 수 있습니다.

XQuery 주사에 대한 자세한 정보

추가 읽기에 대 한, OWASP XQuery 주입에 대 한 무슨 말을 봐 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리 치고 다른 위협의 도적 갤러리에 대해 자세히 알아보려면 보안 코드 전사 블로그를 방문하십시오.

보안 오용이라는 용어는 잘못된 코드가 아닌 응용 프로그램의 구성 설정으로 인해 도입된 일반적인 취약점을 포함하는 약간의 캐치올입니다. 가장 일반적인 실수에는 일반적으로 이러한 잘못된 구성으로 앱을 배포하는 조직에 큰 영향을 미칠 수 있는 간단한 실수가 포함됩니다.

가장 일반적인 보안 오구성 중 일부는 프로덕션 환경에 배포하기 전에 앱에서 디버깅 프로세스를 비활성화하지 않고, 응용 프로그램이 최신 패치로 자동으로 업데이트하지 않고, 기본 기능을 비활성화하는 것을 잊어 버리고, 도로에 큰 문제를 일으킬 수 있는 다른 작은 것들의 호스트를 포함합니다.

보안 잘못된 구성 취약점에 대처하는 가장 좋은 방법은 프로덕션 환경에 배포되기 전에 네트워크에서 보안 문제를 제거하는 것입니다.

이 에피소드에서는 다음을 배우게 됩니다.

• 해커가 일반적인 보안 오인을 찾고 악용하는 방법
• 보안 오구성이 위험할 수 있는 이유
• 보안 오구성을 찾고 수정하는 데 사용할 수 있는 정책 및 기술입니다.

공격자는 일반적인 보안 오디큐어를 악용하는 방법은 무엇입니까?

일반적인 보안 오수에는 많은 것들이 있습니다. 가장 인기있는 것들은 해커 커뮤니티에서 잘 알려져 있으며 취약점을 검색 할 때 거의 항상 검색됩니다. 가장 일반적인 잘못된 구성 중 일부는 다음과 같지만 이에 국한되지는 않습니다.

• 잘 알려진 암호로 기본 계정을 사용하지 않도록 설정하지 않습니다.
• 사용자에게 스택 추적 또는 기타 오류 메시지가 표시되는 프로덕션 환경에서 디버깅 기능이 켜져 있습니다.
• 불필요한 포트, 서비스, 페이지, 계정 또는 권한과 같이 불필요한 또는 기본 기능이 활성화되어 있습니다.
• 보안 헤더를 사용하지 않거나 안전하지 않은 값을 사용하지 않습니다.

일부 잘못된 구성은 악용하기에 잘 알려져 있고 사소한 것입니다. 예를 들어 기본 암호를 사용하도록 설정한 경우 공격자는 시스템에 대한 높은 수준의 액세스를 얻으려면 기본 사용자 이름과 함께 암호를 입력하기만 하면 됩니다.

다른 잘못된 구성에는 앱을 배포한 후 디버깅 기능이 활성화된 경우와 같이 좀 더 많은 작업이 필요합니다. 이 경우 공격자는 오류를 트리거하려고 시도하고 반환된 정보를 기록합니다. 해당 데이터로 무장한 그들은 시스템 또는 훔치려는 데이터의 위치에 대한 정보를 노출할 수 있는 고도로 표적화된 공격을 시작할 수 있습니다.

보안 오인구성이 왜 그렇게 위험합니까?

악용되는 정확한 보안 오용에 따라 정보 노출에서 완전한 응용 프로그램 또는 서버 손상에 이르기까지 손상이 포함될 수 있습니다. 모든 보안 오구성은 숙련된 공격자가 활용할 수 있는 방어에 구멍을 제공합니다. 기본 암호를 사용하도록 설정하는 것과 같은 일부 취약점의 경우 경험이 부족한 해커도 이를 악용할 수 있습니다. 결국, 그것은 기본 암호를 조회하고 입력 하는 천재를 하지 않습니다!

보안 잘못 구성으로 인한 위협 제거

보안 오조직을 방지하는 가장 좋은 방법은 조직 전체에 배포되는 모든 앱 및 프로그램에 대한 보안 설정을 정의하는 것입니다. 여기에는 불필요한 포트 를 비활성화하고, 앱에서 사용하지 않는 기본 프로그램 및 기능을 제거하고, 모든 기본 사용자와 암호를 비활성화하거나 변경하는 등의 항목이 포함되어야 합니다. 또한 프로덕션 환경에 닿기 전에 소프트웨어에서 디버깅 모드를 항상 비활성화하는 것과 같은 일반적인 잘못된 구성을 확인하고 처리하는 것도 포함됩니다.

이러한 프로세스가 정의되면 모든 앱이 배포되기 전에 처리하는 프로세스를 배치해야 합니다. 이상적으로, 누군가가 이 프로세스를 담당해야 하며, 이를 시행할 수 있는 충분한 권한을 부여해야 하며, 일반적인 보안 오구성이 미끄러져야 할 책임이 있습니다.

보안 오수에 대한 자세한 정보

추가 읽기를 위해 가장 일반적인 보안 잘못된 구성의 OWASP 목록을 살펴 볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 보안 오구성을 저지할 준비가 되셨습니까? 우리의 플랫폼에 머리와 자신을 도전 [여기에서 시작]

수지는 이틀 만에 예정된 불쾌한 보고서에서 벗어나기 위해 이메일을 엽니다. 그녀는 무료 아이 패드에 대한 링크가 받은 편지함에 나타납니다 볼 수 있습니다. 그것을 클릭 한 후, 그녀는 큰 배너 페이지읽기와 웹 사이트에 간다, "당신의 무료 아이 패드를 위해 여기를 클릭하십시오!". 그녀는 버튼을 클릭하지만 정말 아무것도 일어나지 않을 것 같다. 문제는 어떤 일이 일어났다는 것입니다.

받은 편지함으로 다시 이동한 후, 그녀는 모든 이메일이 삭제되었음을 깨닫습니다. 그녀는 심지어 그들 중 어느 것도 "delete'에 충돌하지 않았다. 무슨 일이죠?

이메일 사이트가 클릭잭이 지정되었습니다. Clickjacking은 사용자가 수행하려고 하지 않은 작업을 수행하도록 속여 심각한 문제를 초래할 수 있습니다.

이제 clickjacking이 어떻게 작동하는지, 왜 위험한지, 그리고 이를 방지하기 위해 좋아하는 개발자가 할 수 있는 일을 살펴보겠습니다.

클릭재킹 이해

"UI 리드레싱 공격"이라고도 하는 clickjacking은공격자가 웹 페이지에서 여러 개의 투명한 레이어를 사용하여 사용자를 속여 단추를 클릭하거나 사용자가 클릭하지 않으려는 링크를 클릭할 때 발생합니다.

혹시 당신의 차에 붙어 버그가 있었다? 그들은 격렬하게 밖으로 날아가려고 창에 날아다다. 버그의 의도는 나무와 야외처럼 보이는 것을 비행하는 것입니다, 그 경로를 차단 유리의 망각.

Clickjacking은 사용자가 버그이고 웹 사이트가 길을 차단하는 유리를 제외하고는 디자인면에서 유사합니다. 사용자는 무료 아이폰과 같은 원하는 것을 봅니다. 공격자는 무료 iPhone 광고 위에 투명 프레임 안에 사이트를 배치합니다. 사용자가 버튼을 클릭하여 'free'prize'를 잡으면 실제로 사이트의 버튼을 클릭하여 의도하지 않은 작업을 수행합니다.

클릭재킹이 위험한 이유

공격자가 클릭재킹으로 무엇을 할 수 있습니까? 그것은 주로 문제의 웹 사이트의 기능에 따라 달라집니다.

공격자는 사용자가 소셜 미디어에서 공격자의 사이트를 좋아하거나 공유하도록 할 수 있습니다. 많은 사람들이 편의를 위해 자신의 소셜 미디어 계정에 로그인 하기 때문에 이 쉽게 해제 될 수 있습니다.

사이트를 프레임에 배치할 수 있는 경우 단추를 클릭하여 중요한 작업을 완료할 수 있으며 이는 공격 벡터역할을 할 수 있습니다. 예를 들어 사용자가 무료 iPad를 얻기 위해 클릭하지만 대신 사이트의 계정 설정을 변경하여 계정 의 보안을 덜 합니다. 이 유형의 공격은 어도비 플래시 플러그인 설정 페이지에대해 발생했습니다. 설정은 투명 프레임에 배치되어 사용자를 속여 마이크와 카메라에 플래시 애니메이션에 액세스할 수 있도록 할 수 있습니다. 공격자는 피해자를 기록할 수 있습니다. 개인 정보 보호의 주요 침공.

이메일 클라이언트가 사이트로 프레임될 수 있어 사용자가 사서함의 모든 이메일을 삭제하거나 공격자가 관리하는 이메일 주소로 이메일을 전달할 수 있습니다.

결론은 사용자가 클릭하는 내용을 볼 수 없으므로 모든 것을 클릭하도록 확신할 수 있습니다. 그것은 사회적 공유 또는 악성 코드를 다운로드 여부, 가능성은 광대 하다.

클릭재킹을 물리치는 방법

클릭재킹을 방지할 수 있습니다. 클릭재킹을 방지하는 것이 좋습니다. "프레임 조상" HTTP 응답 헤더를 사용하여 사이트를 프레임으로 만드는 방법을 제어할 수 있습니다.

• "프레임 조상 없음'- 다른 사이트는 당신의 프레임을 할 수 없습니다. 권장 설정입니다.
• '프레임-조상 셀프'- 사이트의 페이지는 사이트 내의 다른 페이지로만 프레임할 수 있습니다.
• "frame-ancestors self <uri list=""> - Your site can be framed by the sites in the URI lists and no others.</uri>

CSP 프레임-조상은 현재 모든 주요 브라우저에서 지원되지 않습니다. "X-프레임 옵션" HTTP 헤더를 이러한 브라우저의 대체 옵션으로 사용합니다.

• DENY - 아무도 귀하의 사이트를 프레임 할 수 없습니다. 권장되는 설정입니다.
• SAMEORIGIN - CSP에 대한 "자체"와 동일합니다. 당신은 당신의 자신의 콘텐츠를 프레임 수 있지만, 다른 사람은 할 수 없습니다.
• ALLOW-FROM <uri> - Allow the specified URI to frame your content.</uri>

클릭잭을 받지 마세요.

Clickjacking은 공격자가 제품을 조작할 수 있는 경우 평판 손상및 수익 손실로 이어질 수 있는 영리하고 오해의 소지가 있는 공격입니다. 무료 학습 리소스를 확인하여 클릭재킹에 대해 자세히 알아보십시오.

콘텐츠 보안 정책 및 "X-프레임 옵션" 헤더를 사용하여 다른 사용자가 악의적인 방법으로 사이트를 사용하지 못하도록 합니다. 공격자가 사용자를 조작하는 것을 허용하지 마십시오. 클릭잭을 받지 마십시오.

OS 명령 주입 공격은 응용 프로그램에서 사용자가 셸에 입력할 수 있지만 입력 문자열이 유효한지 확인하는 작업을 수행하지 않을 때마다 발생할 수 있습니다. 이렇게 하면 공격자가 응용 프로그램을 호스팅하는 운영 체제에 직접 명령을 삭제하고 손상된 응용 프로그램에 대해 설정된 권한 수준이 있습니다.  

OS 명령 주입 공격은 엔트리 레벨과 숙련도가 적은 해커에 의해 수행 될 수 있습니다, 이는 보안 팀이 경험하는 가장 일반적인 약점 중 하나를 만든다. 고맙게도, 성공을 방지 하는 매우 효과적인 방법이 꽤 있다. 이 에피소드에서는 다음을 배우게 됩니다.

       작동 방식

       왜 그렇게 위험합니까?

       방어를 막기 위해 어떻게 방어할 수 있을까요?

공격자는 OS 명령 주입을 어떻게 사용합니까?

공격자가 OS 명령 주입 공격을 시작하기 위해 가장 먼저 해야 할 일은 응용 프로그램 내에서 사용자 입력을 찾는 것입니다. 사용자가 작성하는 양식은 잠재적으로 포인트에서 뛰어 내리는 것이 좋습니다. 가장 영리한 공격자는 쿠키 나 HTTP 헤더와 같은 것을 발사 점으로 사용할 수 있습니다.

두 번째로 해야 할 일은 운영 체제가 응용 프로그램을 호스팅하는 지 파악하는 것입니다. 선택의 소수만 있다는 것을 감안할 때, 시행 착오는 이 단계에 대해 잘 작동할 수 있습니다. 대부분의 응용 프로그램 서버는 Windows 기반 (Windows의 맛이 일반적으로 중요하지 않음), 일부 유형의 Linux 상자 또는 가능성 유닉스가 될 것입니다.

이 시점에서 해커는 입력을 수정하여 운영 체제 명령을 무해한 입력으로 삽입합니다. 이렇게 하면 호스팅 OS가 응용 프로그램이 있는 권한 수준에서 의도하지 않은 명령을 실행해야 합니다.

예를 들어 응용 프로그램 내의 유효한 사용자가 파일 내용을 보려면 다음 명령을 사용할 수 있습니다.이 경우 월별 이사회 회의의 메모가 표시됩니다.

임원("고양이" + 파일 이름)

예제에서는 다음 명령을 실행하고 모임 메모를 사용자에게 다시 반환합니다.

$ ./고양이 회의노트.txt

7월 회의에는 집행위원회 위원 3명이 참석했다. 새로운 예산 프로젝트가 논의되었지만 아무런 조치나 투표가 취해지지 않았습니다.

이는 공격자가 리눅스에서 디렉터리 내용을 나열하는 데 사용되는 명령과 같이 입력 끝에 추가 명령을 추가할 때 발생하는 일입니다. 이 경우 모임 노트를 표시하는 원래 명령이 여전히 수행됩니다. 그러나 악의적인 사용자는 디렉터리에 있는 다른 모든 명령과 후속 OS 명령 주입 공격에 사용할 수 있는 다른 명령도 표시됩니다. 그들은 입력 :

$ ./고양이 회의 노트.txt & ls

그리고 대신이것을 얻을 :

7월 회의에는 집행위원회 위원 3명이 참석했다. 새로운 예산 프로젝트가 논의되었지만 아무런 조치나 투표가 취해지지 않았습니다.

미팅노트.txt
6월회의노트.txt
메이미팅노트.txt
형식.c
미스널.c
메모 오류.c
트렌던스.c
글을 쓰는곳.c

당신이 볼 수 있듯이, 이 경우, 뿐만 아니라 해커는 디렉토리의 내용을 표시 했다, 하지만 또한 그들은 사용할 수 있는 다른 명령의 메뉴를 주어진 " 그들은 지금 그들은 호스트 운영 체제에서 실행할 수 있습니다 알고 명령.

OS 명령 주입 공격이 왜 그렇게 위험합니까?

사용자가 대상 응용 프로그램의 목적을 우회하고 운영 체제 명령을 실행하는 데 사용할 수 있도록 하는 것은 매우 위험합니다. 공격자는 기밀 데이터를 도용하거나 서버 드라이브 전체서를 서식하는 등 파괴적인 작업을 쉽게 수행할 수 있습니다. 공격자가 사용할 수 있는 옵션은 운영 체제 내에서 허용되는 명령과 사용 창의력으로만 제한됩니다.

OS 명령은 응용 프로그램과 동일한 권한 수준에서 실행됩니다. 관리 권한이 있는 앱은 이를 손상시키는 해커가 모든 OS 명령을 실행할 수 있음을 의미합니다.

OS 명령 주입에 대한 공격 패턴은 잘 알려져 있고 문서화되어 있습니다. 취약한 응용 프로그램은 전문 해커만큼 스크립트 키디에 취약합니다. 기술이 거의 없는 공격자는 OS 명령을 잘라내고 응용 프로그램에 붙여 넣을 수 있습니다.

OS 명령 주입에 대한 보안 확인 받기

OS 명령 주입을 중지 할 수있는 몇 가지 좋은 기술이 있습니다. 첫 번째 단계는 기능을 수행하는 데 필요한 최소 한량의 권한으로 응용 프로그램을 실행하는 것입니다. 이는 공격을 방지하지 는 않지만 위반이 발생하면 피해가 최소화됩니다.

대부분의 프로그래밍 언어와 프레임워크는 디렉터리 콘텐츠 목록, 하드 디스크에서 파일 작성 또는 읽기와 같은 일반적인 OS 메서드에 대한 API 호출을 제공합니다. 사용자 환경에서 OS 명령 주입을 제거하는 한 가지 완벽한 방법은 모든 응용 프로그램에서 OS 명령 대신 이러한 API 호출을 직접 사용하도록 하는 것입니다.

이 작업을 사용할 수 없는 경우 OS 명령에서 사용자 입력을 사용하기 전에 사용자 입력의 유효성을 검사합니다. 화이트리스트를 사용하여 작은 신뢰할 수 있는 값 집합만 사용할 수 있습니다. 블랙리스트를 사용하여 이 작업을 기술적으로 수행할 수 있지만 허용되는 명령은 훨씬 적을 수 있으므로 화이트리스팅이 거의 항상 쉽습니다. 유효한 POST 및 GET 매개 변수를 화이트리스트에 포함시키는 것을 잊지 말고 쿠키와 같은 사용자 입력 벡터를 간과하는 경우가 많습니다.

마지막으로 사용 가능한 프로그래밍 API가 없고 화이트리스트를 사용할 수 없는 경우 소독 라이브러리를 사용하여 OS 명령에서 사용할 수 있는 사용자 입력의 특수 문자를 이스케이프합니다.

OS 명령 주입 공격에 대한 자세한 정보

추가 읽기를 위해 OS 명령 주입 공격에 대한 OWASP 작성을 살펴 볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

웹 사이트로 이동하여 로그인합니다. 평소처럼, 당신은 당신이 사고 싶은 제품으로 장바구니를 채웁니다. 그런 다음, 후프 - 당신의 손은 미끄러 브라우저 탭을 닫습니다. 사소한 공황 후 사이트의 URL을 다시 브라우저로 입력하고 "Enter" 키를 누르게 됩니다. 사이트로 다시 로그인되고 모든 항목이 여전히 장바구니에 있습니다. 휴.

이 사이트는 다시 인증하지 않고 누를 수 있는 사람이 누구인지 어떻게 알 수 있었습니까? 그것은 세션을 사용 했기 때문에 당신을 식별. 세션은 웹을 사용할 때 좋은 사용자 환경의 핵심입니다. 그러나 세션을 잘못 관리하면 공격자가 악용할 수 있는 보안 허점이 발생할 수 있습니다.

이제 세션 관리가 의미하는 바, 세션 관리가 얼마나 약한지, 세션을 제대로 관리하기 위해 수행할 수 있는 작업을 살펴보겠습니다.

세션 관리 약점 이해

세션은 응용 프로그램의 단일 사용자와 관련된 서버에 저장된 값을 나타냅니다. 이것은 두 가지 이유로 필요합니다: 첫째, HTTP는 상태없는 프로토콜입니다. 각 요청은 별개이며 요청 전후에 발생한 요청에 대한 지식이 없습니다. 세션을 사용하면 요청을 보낸 서버 트랙을 추적하는 데 도움이 됩니다. 그렇지 않으면 버튼이나 링크를 클릭할 때마다 로그인해야 합니다.

세션의 두 번째 이유는 사용자의 권한 부여입니다. 세션 식별자를 사용하여 시스템 내에서 특정 권한이 있는 특정 사용자를 인식할 수 있습니다. 응용 프로그램은 사람이 누구이며 무엇을 할 수 있는지 알 수 있습니다.

세션에는 두 가지 구성 요소가 있습니다. 서버 측의 데이터 저장소는 세션 식별자를 저장하고 사용자 ID 또는 카트 정보와 같은 사용자에 대한 정보로 매핑합니다. 동일한 세션 식별자가 쿠키의 브라우저로 전송됩니다. 쿠키는 사용자 시스템의 브라우저에 저장됩니다. 클라이언트는 각 요청으로 쿠키를 전달하여 서버가 이 요청이 동일한 사용자로부터 수신되고 있음을 알 수 있습니다. 대부분의 응용 프로그램은 세션을 사용하여 사전 인증 및 사후 인증 사용자를 추적합니다.

적절한 세션 관리는 응용 프로그램의 보안에 필수적입니다. 유효한 세션 ID는 사용자 이름/암호 또는 2단계 인증 토큰과 동일한 신뢰 수준을 가지고 있습니다.

가난한 세션 관리가 위험한 이유

세션 관리가 좋지 면 계정 인계가 완료될 수 있습니다. 즉, 고객 데이터를 도난당하거나 제품을 부정하게 구입할 수 있습니다. 공격자가 유효한 세션 ID를 얻는 방법에는 여러 가지가 있습니다.

세션 고정 공격은 사용자가 시스템에 로그인하는 경우와 URL을 사용하여 세션 식별자를 설정할 수 있는 경우와 같이 주요 시간에 세션이 변경되지 않을 때 발생합니다. 이러한 방식으로 세션 식별자를 설정하면 동일한 인증 원본을 사용하는 다른 응용 프로그램에서 사용자가 로그인하도록 할 수 있습니다. 이 경우 공격자는 웹 사이트를 탐색하고 세션 ID를 얻을 수 있습니다. 그런 다음 공격자는 URL에서 세션 ID가 있는 이메일을 통해 의심하지 않는 피해자에게 URL을 보냅니다. 피해자는 이메일의 URL을 클릭하고 웹 사이트에 로그인합니다. 로그인 시 세션 ID가 회전되지 않으면 공격자에게 유효하고 인증된 세션 ID가 있습니다. 이렇게 하면 계정 을 완전히 인수할 수 있습니다.

세션 관리 불량에 대한 또 다른 공격은 무차별 적인 추측 공격입니다. 개발자가 자체 세션 관리 시스템을 만들려고 할 때 추측하기 매우 간단한 세션 ID를 사용하는 경우가 많습니다. 이들은 시퀀스 (1, 2, 3) 또는 어떤 종류의 예측 가능한 패턴일 수 있습니다. 공격자는 유효한 ID가 발견될 때까지 세션 ID를 추측하기만 하면 됩니다. 이것은 또한 계정 인수로 이어집니다.

일정 시간이 경과한 후 자동으로 무효화되지 않은 세션을 악용하여 사용자를 공격할 수 있습니다. 성공적인 사이트 간 요청 위조 공격은 사용자가 사이트를 떠난 후에도 여전히 유효한 세션에 따라 달라집니다. 공격자가 사용자가 방문한 사이트에 iframe 또는 이미지를 배치한다고 가정해 보겠습니다. "src"(소스) 특성은 취약한 사이트의 URL로 설정되어 사용자를 대신하여 작업을 수행합니다. 예를 들어 사용자의 허가 없이 공격자의 계정으로 송금하기 위해 취약한 은행 응용 프로그램을 만들 수 있습니다.

세션 관리는 까다로울 수 있으며 약점은 치명적일 수 있습니다. 그러나, 그것은 잘 알려진 문제이며 해결할 수 있습니다.

안전하지 않은 세션 관리 패배

세션 관리는 모든 웹 응용 프로그램의 핵심 부분입니다. 따라서 많은 웹 개발 프레임워크에는 세션 관리 기능이 기본 제공됩니다. 이러한 시스템은 전문가를 면밀히 조사하여 문제를 발견하고 해결했습니다. 그들을 사용합니다.

좋은 세션 관리의 몇 가지 일반적인 속성은 다음과 같습니다.

     공격자가 추측할 수 없는 임의 세션 ID가 생성되었습니다.

     사용자가 로그아웃할 때 세션이 무효화됩니다.

     일정 시간이 경과한 후 세션이 자동으로 무효화됩니다.

     사용자가 로그인한 후 세션 I가 변경됩니다.

     무차별 암호 힘 공격을 방지하기 위해 최소 128비트 길이의 세션 ID

스프링, ASP.NET 코어, 레일및 장고와 같은 웹 프레임워크는 이러한 속성을 가지고 있으며 이 경우 더 높은 보안 표준에 사용해야 합니다.

결론: 처음부터 자체 세션 관리 시스템을 만들지 마십시오.

세션 ID가 만들어지면 보호해야 합니다. 보안 및 httpOnly 플래그를 'true'on 세션 쿠키로 설정합니다. 이렇게 하면 JavaScript로 값을 검색할 수 없으며 브라우저는 HTTPS를 통해서만 쿠키를 전송하여 공격자가 전송 중에 다른 사람의 세션을 훔치지 못하게 합니다.

세션 보안

무료 학습 리소스를 확인하여 안전한 세션 관리에 대해 자세히 알아보십시오. 세션을 보호하는 방법을 배우면 보안 위반으로 인해 사용자 계정 인수, 평판 손상 및 수익 손실을 방지하는 데 도움이 됩니다. 세션을 보호하고 사용자를 안전하게 보호합니다.

패딩 오라클은 대체 록 밴드에 대한 정말 나쁜 이름처럼 들리지만, 실제로 공격자가 암호화 키를 모르고 정보를 해독하는 데 사용할 수있는 취약점입니다.

공격자의 전반적인 난이도측면에서 이 문제는 저울의 맨 위에 있습니다. 우리는 마법의 암호 해독 버튼에 대해 이야기하는 것이 아니라 해커가 셀 패딩과 관련하여 그들에게 보낸 오류 메시지를 검토하고 암호화 된 데이터가 끝나고 패딩이 시작되는 위치를 결정하는 데 사용할 수있는 힘든 프로세스입니다. 그런 다음 암호화 내에서 다양한 비트를 알아낼 수 있으며 검사할 시간과 입력이 충분한 시간을 부여하여 균열을 낼 수 있습니다.

고맙게도 암호화된 데이터를 해독하기 위해 패딩 오라클을 사용하는 공격자의 기능을 제거할 수 있는 비교적 쉬운 몇 가지 단계가 있습니다. 이 에피소드에서는 다음을 배우게 됩니다.

• 작동 방식
• 이 취약점이 그렇게 위험한 이유
• 방어를 방지하기 위해 방어를 제자리에 놓을 수있는 방법.

패딩 오라클은 어떻게 작동합니까?

암호 블록 체인(CBC)은 데이터베이스 내에 저장된 셀과 같은 전체 정보 시퀀스가 전체 정보 체인에 적용되는 암호화 키를 사용하여 암호화되는 블록 암호로 만드는 방법입니다. CBC를 사용하는 경우 단일 암호 블록의 암호화는 모든 진행 블록에 따라 달라집니다. 이론적으로, 이것은 암호화를 매우 강하게 만듭니다.

CBC 암호(및 해당 문제에 대한 모든 블록 암호)의 문제는 정확한 크기의 블록을 사용하여 암호화할 수 있다는 것입니다. 일반적으로 이 작업은 8바이트 또는 16바이트 크기로 수행됩니다. 그렇다면 CBC가 2바이트의 데이터를 16바이트 암호 텍스트 장치에 장착해야 하는 경우 어떻게 됩니까? 그것은 패딩을 사용합니다, 기본적으로 그냥 말도 안되는 문자, 간격을 채우고 단위를 적절한 크기로 만들 수 있습니다.

대부분의 패딩 방식은 PKCS#7이 가장 인기 있는 것 중 하나이기 때문에 공격자는 어떤 종류의 패딩이 사용되고 있는지 알 수 있습니다. 예를 들어 CBC가 블록에 5개의 문자를 패드해야 하는 경우 PKCS#7은 일반 텍스트 후 5회 반복되는 0x05 바이트 값을 사용합니다.

공격자는 CBC 및 패딩 방식에 대한 지식을 사용하여 오라클이라고도 하는 호스트 서버에 쿼리를 보냅니다. 올바른 도구에 액세스할 수 있는 경우 서버에서 쿼리의 패딩이 잘못된지 알려주도록 강제할 수 있습니다. 이를 위해 서버가 패딩이 정확하다는 것을 알려줄 때까지 암호의 모든 바이트에 대해 0에서 255로 순환할 수 있습니다. 그런 다음 다음 장치로 이동하여 프로세스를 반복하여 모든 경우에 패딩이 시작되는 위치를 기록합니다.

이렇게 하면 메시지 나 셀의 암호를 해독할 수는 없지만 일반 텍스트가 끝나고 패딩이 시작되는 위치 측면에서 체인의 모든 링크를 매핑할 수 있습니다. 또한 XOR 계산을 사용하여 원래 일반 텍스트의 마지막 바이트 값을 파악할 수도 있습니다.

패딩 오라클이 왜 그렇게 위험합니까?

해커가 암호화를 깨는 데 많은 노력을 기울이는 이유는 잠재적 인 지불금 때문입니다. 귀중하지 않은 것을 암호화하는 사람은 거의 없습니다. 호스트 조직에 대한 위험은 손상된 데이터에 따라 다릅니다. 여기에는 암호, 사용자 계정, 재무 정보, 신용 카드 번호, 환자 기록, 민감한 통신 또는 매우 수요가 많고 귀중한 정보의 수와 같은 것들이 포함될 수 있습니다.

패딩 오라클을 사용하면 후속 공격의 관문이 될 수도 있습니다. 예를 들어 공격자가 패딩 오라클을 사용하여 암호를 도용할 수 있는 경우 권한을 높이고 네트워크 깊숙이 침투하는 것은 쉬운 보조 작업입니다.

모든 사람은 암호화를 스누핑이나 타협에 대한 궁극적 인 방어로 생각합니다. 그러나 암호화 과학과 그것을 깨뜨릴 사람들 사이의 앞뒤로 수세기 동안 계속되어 왔습니다. 패딩 오라클은 공격자에게 우위를 제공하는 하나의 방법일 뿐입니다.

패딩 오라클 공격 하드 랜딩 제공

고맙게도 패딩 오라클을 방지하는 방법에는 꽤 있습니다. 가장 좋은 것 중 하나는 갈로이/카운터 모드(GCM) 또는 오프셋 코드북 모드(OCB)와 같은 더 강력한 암호화 작업 모드를 사용하는 것입니다. 그것은 128 비트의 암호 블록 크기를 사용 한다는 점에서 CBC와 다릅니다. 또한 각 데이터 블록에 대한 카운터를 사용한 다음 해당 번호를 사용하여 암호 텍스트를 만듭니다. 즉, 오라클 공격을 패딩하는 것은 영향을 받지 않습니다.

좋은 오류 처리 제어를 구현하면 공격자가 성공할 가능성이 크게 저하될 수 있습니다. 패딩 오라클 공격은 정보 유출에 의존하므로 암호화/암호 해독 오류에 대한 특정 패딩 오류 대신 일반 오류 메시지를 반환합니다.

MAC(메시지 인증 코드)를 구현할 수도 있습니다. MAC 값은 검증자가 비밀 키를 사용하여 메시지 콘텐츠의 변경 내용을 감지할 수 있도록 하여 데이터 무결성과 진위 여부를 보호합니다.

마지막으로 모든 패딩 오라클 공격에는 반복쿼리가 필요합니다. 단일 셀에서 패딩 스키마를 파악하기 위해 200건 이상의 요청이 있을 수 있으며, 체인에서 보호되는 정보 단위수를 곱합니다. 동일한 소스에서 들어오는 요청 수를 제한하면 공격자가 실제로 시도를 시작하기 전에 공격자 액세스를 거부하여 패딩 오라클 공격을 종료할 수 있습니다.

패딩 오라클에 대한 추가 연구

공격자가 중요한 정보를 해독할 수 있는 모든 방법은 실제 악몽이 될 수 있습니다. 그러나, 우리는 당신이 처음에 일어나는 것을 방지하기위한 꽤 좋은 방법을 배웠으면 좋겠다.

추가 읽기를 위해 패딩 오라클에서 OWASP 정의 및 체크리스트를 살펴볼 수 있습니다. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 패딩 오라클 공격을 저지하는 과제에 대해 생각하십니까? Secure Code Warrior 플랫폼:

대부분의 컴퓨터 시스템은 LDAP(경량 디렉터리 액세스 프로토콜)를 사용합니다. IP(인터넷 프로토콜) 네트워크를 통해 분산 디렉터리 정보 서비스를 유지하는 데 사용됩니다. 그래서 기본적으로, 그것은 사용자를 추적 하는 방법으로 작동.

LDAP는 사용자가 다양한 작업을 수행할 수 있는 권한이 있는지, 특히 조직 내에서 정의된 역할과 관련된지 확인하기 위해 앱의 인증 원본으로 자주 사용됩니다. 예를 들어 회계에 있는 사람만 회사 회계 소프트웨어를 사용할 수 있습니다. 사용자가 설정된 권한 내에서 행동하도록 LDAP 테이블을 확인하도록 응용 프로그램이 프로그래밍되는 경우가 많습니다.

악의적인 사용자가 LDAP 쿼리를 조작할 수 있는 경우에 문제가 발생할 수 있습니다. 이렇게 하면 수신 서버가 일반적으로 허용되지 않는 잘못된 쿼리를 실행하거나 암호 없이 무효 또는 보안이 낮은 사용자에게 높은 수준 또는 관리자 액세스를 부여하도록 속일 수 있습니다.  

LDAP 주사는 까다로울 수 있지만,이 에피소드에서, 우리는 배울 것이다 :

• 작동 방식
• 왜 그렇게 위험합니까?
• 방어를 막기 위해 어떻게 방어할 수 있을까요?

공격자는 LDAP 주입을 어떻게 사용합니까?

LDAP 기반 공격이 수년 동안 인기를 끌고 있는 이유 중 하나는 거의 모든 컴퓨터 시스템이 이를 사용하기 때문에 있습니다. LDAP는 오픈 소스이며 매우 잘 작동하므로 많은 대안이 만들어지지 않았습니다.

LDAP의 핵심은 IP 기반 컴퓨터 시스템 또는 네트워크 내에서 유효한 사용자를 추적하는 데이터베이스입니다. 사용자가 시스템, 네트워크, 서버, 응용 프로그램 및 동일한 네트워크의 다른 사용자에 대한 정보를 공유할 수 있습니다.

정보는 DN으로 축약되는 고유 이름이라고 하는 데이터베이스 라인 또는 레코드와 동등한 LDAP에 의해 저장됩니다. 각 DN은 고유합니다. 예를 들어, 이것은 대기업의 시카고 회계 사무소에서 일하는 사용자에게 DN이 어떻게 보일 수 있는지입니다.

cn=제임스 스미스, ou=기업 계정, dc=시카고, do=Parkview  

각 DN이 고유하도록 하려면 "+", "/", "=" 및 몇 가지 다른 코드와 같은 다양한 코드를 레코드에 추가할 수 있습니다. 시카고 파크뷰 오피스의 기업 계좌에서 일하는 제임스 스미스가 두 명 있더라도 레코드 이전이나 이후에 공백을 삽입하여 각각 개별 DN을 가질 수 있습니다.

응용 프로그램은 일반적으로 LDAP를 사용하여 사용자가 급여 부서에서 올바른 연락처를 찾아 검사에서 실수에 대해 이야기할 때와 같은 특정 DN에 대한 쿼리를 보낼 수 있도록 합니다. LDAP 주사는 검색 쿼리에서 사용자가 제공한 매개 변수에 대한 유효성 검사가 없을 때 발생할 수 있습니다. 이 경우 해커는 양성 검색을 조작하여 인증 메커니즘을 우회하거나 추가 임의 쿼리를 실행할 수 있습니다. 이렇게 하면 서버가 사용자 암호와 같이 허용되지 않아야 하는 결과를 표시하도록 속이거나 유효한 암호 가 있거나 없는 네트워크 내의 보안이 높은 영역에 대한 액세스 권한을 응용 프로그램을 부여할 수도 있습니다.

LDAP 주사가 왜 그렇게 위험한가요?

LDAP 주사의 가장 큰 위험은 전 세계 IP 컴퓨터 네트워크의 대부분에 걸쳐 프로토콜의 확산 가능성이 높습니다. 그것은 정보를 훔치려는 해커를위한 쉬운 디딤돌, 또는 네트워크에서 자신의 권한을 높이기 위해 합니다. LDAP 주사가 가능한지 확인하지 않으므로 보안 팀은 해당 구멍이 항상 닫혀 있는지 확인해야 합니다.

특히 유효한 사용자가 조직 내의 사용자 및 그룹 또는 DN에 포함된 기타 정보에 대한 제한된 정보를 찾을 수 있도록 많은 응용 프로그램이 프로그래밍됩니다. 예를 들어, 앱을 통해 누군가가 LDAP를 사용하여 시카고에서 일하는 기업 회계사의 연락처 정보를 검색할 수 있으며, 이는 위의 예에서 친구 제임스 스미스를 반환합니다. 사용 권한에 따라 LDAP 쿼리를 완벽하게 사용할 수 있습니다.

악의적인 사용자가 쿼리를 필터링하지 않은 매개 변수를 추가하여 검색의 특성을 변경하고 서버를 속여 일반적으로 제공해서는 안 되는 정보를 제공할 수 있습니다. 예를 들어 사용자=* 문자열을 추가하면 공격자는 전체 조직의 모든 단일 사용자에 대한 정보를 얻을 수 있으며, 이는 허용되지 않을 수 있습니다.

인증에 LDAP를 사용하는 응용 프로그램의 경우 문제가 더욱 악화될 수 있습니다. 예를 들어 공격자는 LDAP 쿼리 끝에 있는 (&) 문자열을 사용하여 서버를 속여 인수가 사실이라고 생각할 수 있습니다. 앱이 LDAP를 사용하여 암호의 유효성을 검사하는 경우 LDAP 주입을 통해 True 인수를 강제로 사용하면 권한이 없는 사용자가 암호 없이도 관리자로 네트워크에 로그인할 수 있습니다.

LDAP 주입을 네트워크에 L-DON't 만들기

LDAP 주사를 방지 하는 가장 좋은 방법 중 하나는 LINQtoAD 또는 그것을 저항 하기 위해 특별히 설계 된 다른 프레임 워크 같은 것을 구현 하는. 네트워크에 LDAP 쿼리를 활용하는 응용 프로그램이 이미 있는 경우 이 작업을 불가능할 수 있습니다. 그러나, 이 경우에도, 그것은 여전히 앞으로 주입 저항 하는 프레임 워크를 사용 하는 모든 새로운 응용 프로그램에 대 한 좋은 생각.

LDAP를 사용하는 기존 응용 프로그램은 화이트리스트 유효성 검사 및 입력 소독을 사용하여 주사에 대해 강화할 수도 있습니다. 가능한 경우 사용자 입력을 제한된 신뢰할 수 있는 값 집합으로 제한합니다. 그렇지 않으면 LDAP 쿼리의 일부인 사용자 입력은 먼저 소독되어야 하며 GET 및 POST 매개 변수, 쿠키 및 HTTP 헤더를 공격 벡터로 사용할 수 있으므로 포함시키는 것을 잊지 마세요. 입력 소독을 수행하기 위해 자신의 함수를 작성하지 마십시오. 신뢰할 수 있는 타사 보안 포커스 라이브러리 또는 기본 제공 프레임워크 API를 대신 사용합니다.

대상 수정 프로그램 외에도 LDAP 쿼리 응용 프로그램에 할당하는 것과 같은 좋은 컴퓨팅 관행도 네트워크에서 필요한 최소한의 권한을 도움이 될 수 있습니다. 그런 식으로, 최악의 일이 발생하고 LDAP 주입을 통해 얻을 경우, 피해는 완화 될 것이다.

LDAP 주사에 대한 자세한 정보

추가 읽기에 대 한, LDAP 주사에 OWASP 쓰기를 살펴 볼 수 있습니다., 또는 주사 방지 치트 시트. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

무제한 파일 업로드 문제는 공격 자체가 아니라 공격자가 응용 프로그램 및 네트워크 리소스에 쉽게 액세스할 수 있는 일반적인 상황 또는 상태입니다. 당신은 추위에 젖은 옷을 걷고 같은 종류의 생각할 수 있습니다. 그 일을 하는 동안 반드시 그 자체로 아프게 하지 않습니다.

사이버 보안에서 공격자는 무제한 파일 업로드를 지원할 수 있는 모든 응용 프로그램 또는 프로그램을 빠르게 악용할 수 있습니다. 그리고 결과는 파괴적 일 수 있습니다. 영리한 공격자는 무제한 액세스를 사용하여 악의적인 파일을 업로드하거나, 스크립트를 설정하여 자격 증명을 훔치거나, 응용 프로그램의 자체 권한을 사용하여 네트워크에 더 깊은 공격을 시작할 수 있습니다. 비교적 정교하지 않은 공격자조차도 이러한 종류의 자유로운 액세스를 사용하여 서비스 거부 공격을 수행하거나 응용 프로그램을 충돌시킬 수 있습니다.

고맙게도, 자신의 트랙에서 공격자가 될 것입니다 중지됩니다 무제한 파일 업로드 문제를 정복하는 몇 가지 방법이 있습니다. 이를 위해 무제한 파일 업로드의 세 가지 주요 측면에 대해 설명합니다.

• 작동 방식
• 왜 그렇게 위험합니까?
• 방어를 막기 위해 어떻게 방어할 수 있을까요?

공격은 무제한 파일 업로드를 악용하는 방법은 무엇입니까?

사이트가 대중이 파일을 업로드하도록 허용하는 데는 여러 가지 이유가 있습니다. 아마도 회사는 사람들을 고용하고자하며 응용 프로그램 프로세스의 일환으로 이력서를 업로드 할 수 있도록하고 싶을 것입니다. 은행은 고객이 대출 이나 새 계좌를 신청할 때와 같은 중요한 서류를 집에서 작성하도록 권장할 수 있습니다. 관광 또는 소셜 미디어 사이트는 사용자가 다른 사람들과 공유하기 위해 사진을 업로드하도록 초대할 수 있습니다.

파일 업로드를 허용하는 데는 여러 가지 타당한 이유가 있습니다. 기본적으로 대부분의 새 응용 프로그램은 제한 없이 모든 유형의 파일 업로드를 허용할 것입니다. 문제가 발생할 수 있는 공격자가 해당 업로드에 제한이 없음을 알면 문제가 발생합니다.

세 가지 유형의 공격에 대한 주제 사이트를 업로드하는 데 제한이 없습니다. 가장 정교한 것부터 시작하여 악의적인 사용자는 수백 기가바이트의 정보가 포함된 지퍼 아카이브와 같은 거대한 파일을 업로드하기만 하면 됩니다. 대역폭을 질식하는 것 외에도 응용 프로그램에 할당된 저장소 영역을 과부하시킬 수 있습니다.

다음으로 악명 높은 사다리에 바이러스 또는 랜섬웨어 같은 더 사악한 뭔가 같은 악성 파일을 업로드 하는 사용자. 이것은 특히 당신의 가정에 뱀파이어를 초대해야하는 그 오래된 미신처럼. 누군가가 자유롭게 들어올 수 있다는 표지판을 어울린다면 무제한 파일 업로드가 있는 것과 같습니다. 당신은 더 이상 문을 통해 오는 것을 제어하지 않습니다, 당신은 아마 모든 방문자, 또는 파일이 양성 될 것이라고 예상해야한다. 그들 중 일부는 괴물일 지도 모릅니다.

마지막으로 숙련된 공격자는 무제한 업로드를 사용하여 네트워크에 대한 발판을 마련하여 더 깊은 공격을 할 수 있습니다. 누군가가 업로드할 수 있는 것에 대한 제한이 없으므로 공격자는 해당 프로세스를 통해 자체 웹 셸을 보낼 수 있습니다. 그 후 셸에 명령을 보낼 수 있으며 이러한 명령은 응용 프로그램과 동일한 권한 수준으로 서버에서 실행됩니다.

무제한 파일 액세스가 그렇게 위험한 이유는 무엇입니까?

무제한 파일 액세스로 응용 프로그램을 배포하는 것은 즉시 위험하지않지만 기본적으로 사이버 보안 방어에 구멍을 열고 조직을 공격하도록 사람을 초대하는 것과 같습니다. 조만간 누군가가 응답할 것입니다.

가장 기본적인 수준에서 공격자는 혼란을 일으키기 위해 많은 기술이 필요하지 않습니다. 단순히 매우 큰 파일을 압축하고 업로드하는 것만으로도 유효한 사용자에게 서비스를 거부하기에 충분할 수 있습니다. 시간이 지남에 따라 앱이 프로그래밍되고 네트워크로 연결되는 방식에 따라 응용 프로그램 또는 전체 사이트가 충돌할 수도 있습니다.

무제한 파일 액세스가 있으면 네트워크 방화벽 및 기타 보호를 통해 구멍이 열릴 수도 있습니다. 공격자가 핵심 네트워크에 맬웨어를 직접 업로드할 수 있는 경로를 만든 경우 들어오는 전자 메일이나 직원 웹 브라우징 활동을 보고 있는 스캐너가 있는 경우에는 문제가 되지 않습니다. 악성 코드는 응용 프로그램 또는 실행 중인 서버를 충돌할 수 있습니다., 비록 그것은 아마 최고의 결과. 최악의 경우 랜섬웨어와 같은 악의적인 프로그램은 손상된 서버를 사용하여 전체 네트워크로 확산될 수 있습니다.

무제한 파일 액세스가 있는 응용 프로그램을 악용할 때 더 숙련된 공격자가 그렇게 명확하지 않을 것입니다. 대신 취약점을 사용하여 응용 프로그램을 손상시키고 이를 사용하여 네트워크에 더 깊이 침투하여 천천히 이동하고 탐지를 방지할 수 있습니다. 웹 셸 또는 다른 .exe 유형 파일을 업로드한 다음 명령이 도착하면 직접 명령을 전송하여 수행할 수 있습니다. 사용자가 셸을 통해 실행하는 모든 항목은 일반적으로 서버에서 실행되며 응용 프로그램을 호스팅하는 응용 프로그램에 대해 설정된 권한 수준을 사용합니다. 서버로 이러한 명령은 응용 프로그램에서 오고 있으며 추가 검사 또는 검사될 가능성이 없습니다.

이 모든 것들은 무제한 파일 액세스 취약점을 네트워크에 가지고 있는 가장 위험한 취약점 중 하나입니다. 그것은 아마 문제가 발생할 것입니다 경우의 문제가 아니다, 하지만 때.

무제한 파일 액세스 취약점을 제거하려면 어떻게 해야 합니까?

그렇다면 무제한 파일 액세스 문제를 어떻게 해결할 수 있습니까? 가장 쉬운 방법은 업로드할 수 있는 파일 유형에 하나 또는 여러 가지 제한을 추가하는 것입니다. 예를 들어 사이트가 Word 또는 text 파일만 수락하거나 그림 공유 사이트의 경우 .jpgs 또는 .gif만 수락한다고 말하는 경우 사용자에게 전달될 수 있습니다. 백 엔드에서 허용 가능한 파일 확장의 화이트리스트를 만든 다음 다른 모든 것을 거부해야 합니다. 파일 이름의 최대 길이에도 제한을 두어야 합니다. 파일에 실행 명령을 트리거하려는 시도를 나타낼 수 있는 특수 문자가 있는 경우 마찬가지로 거부해야 합니다.

파일 형식 및 명명 규칙 외에도 각 파일의 최대 크기를 제한하려는 것입니다. 최대 크기는 응용 프로그램이 수집해야 하는 파일 유형에 합당하고 적절한 것이어야 합니다. 즉, 워드 파일에 대한 10 메가 바이트 정도의 캡과 그래픽 파일에 대한 아마도 약 50 메가 바이트, 조금 더 큰 무언가를 의미 할 수있다. 최소 파일 크기 규칙을 설정할 수도 있지만 예상 파일의 크기 범위가 잘 알려진 경우에만 사용자가 특정 양식을 작성하고 업로드하는 경우일 수 있습니다.

공격자는 여전히 파일 유형 및 크기 제한을 지나 쉘 또는 잠재적으로 악의적 인 프로그램을 몰래 하는 영리한 방법을 찾을 수 있습니다. 보정하려면 수집된 파일을 실행 권한이 없는 개인 디렉터리에 항상 저장해야 합니다. 보안을 추가하려면 시스템에서 파일을 일련의 임의 문자로 바꿀 수 있습니다. 이렇게 하면 권한이 없는 사용자가 네트워크 외부에서 업로드된 파일의 위치를 검색하지 못하게 되어 네트워크에 약간의 회인이 발생할 수 있습니다. 그러나 이렇게 하려면 임의의 파일 이름을 원래 지정에 연결하는 테이블을 설정하고 유지 관리해야 할 것입니다.

마지막으로, 업로드를 통해 네트워크에 도착하는 모든 항목은 조직에서 해당 작업에 사용하는 방어 프로그램에 의해 맬웨어 및 바이러스에 대해 검색해야 합니다. 이 모든 것을 잡을 수 없습니다., 하지만 파일 업로드를 통해 입력 하려고 가장 일반적인 악성 파일의 최대 90% 이상 을 감지 하는 데 사용할 수 있는 보안의 중요 한 계층.

무제한 파일 업로드 문제 제한

백엔드에 여러 계층의 보안 계층이 배치되면 무제한 파일 업로드 문제가 문제가 되지 않습니다. 기본적으로 파일 업로드에 제한을 두어 문제를 제거하고 있으므로 더 이상 제한되지 않습니다. 모든 뱀파이어와 악성 코드는 추위에 남아있는 동안 만 좋은 파일은 내부에 허용됩니다.

추가 읽기를 위해, OWASP 무제한 파일 업로드 방지 치트 시트를살펴 볼 수 있습니다., 이러한 종류의 상황이 네트워크에서 허용 될 때 가장 일반적인 문제 중 일부를 설명 하는. 또한 새로운 방어 지식을 테스트에 넣을 수 있습니다. Secure Code Warrior 사이버 보안 팀이 궁극적인 사이버 전사가 될 수 있도록 하는 플랫폼. 이 취약점을 물리치는 것에 대해 자세히 알아보려면 Secure Code Warrior 블로그.

지금 이 취약점을 해결할 준비가 되었다고 생각하십니까? 전장으로 가서 기술을 테스트하십시오.