Secure Code insights

무제한 파일 업로드 문제는 공격 자체가 아니라 공격자가 애플리케이션 및 네트워크 리소스에 쉽게 액세스할 수 있는 일반적인 상황이나 상태입니다.추위에 젖은 옷을 입고 돌아다니는 것과 비슷하다고 생각할 수 있습니다.그렇게 하면 그 자체로 아프지는 않지만, 저항력이 낮아져 기회주의적 바이러스가 신체의 방어력을 쉽게 압도할 수 있습니다.

사이버 보안에서 공격자는 무제한 파일 업로드를 지원하도록 허용된 애플리케이션이나 프로그램을 빠르게 악용할 수 있습니다.그리고 그 결과는 치명적일 수 있습니다.영리한 공격자는 무제한 액세스를 사용하여 악성 파일을 업로드하거나, 스크립트를 설정하여 자격 증명을 도용하거나, 애플리케이션의 자체 권한을 사용하여 네트워크를 심층 공격할 수 있습니다.비교적 능숙하지 않은 공격자라도 이러한 종류의 무제한 액세스를 사용하여 서비스 거부 공격을 수행하거나 애플리케이션을 중단시킬 수 있습니다.

다행스럽게도 무제한 파일 업로드 문제를 해결할 수 있는 몇 가지 방법이 있습니다. 이 문제를 해결하면 잠재적 공격자를 차단할 수 있습니다.이를 위해 무제한 파일 업로드의 세 가지 주요 측면을 살펴보겠습니다.

• 작동 방식
• 왜 그렇게 위험한가요?
• 어떻게 하면 그들을 막을 수 있는 방어 시설을 마련할 수 있을까요?

공격은 무제한 파일 업로드를 어떻게 악용할까요?

사이트가 일반인의 파일 업로드를 허용하려는 데에는 여러 가지 이유가 있습니다.아마도 어떤 회사는 사람들을 채용하려고 하는데, 지원 절차의 일환으로 이들이 이력서를 업로드할 수 있도록 허용하려고 할 수도 있습니다.은행은 고객이 대출이나 새 계좌를 신청할 때와 같이 집에서 중요한 서류를 작성하도록 권장할 수 있습니다.관광 또는 소셜 미디어 사이트에서는 사용자가 사진을 업로드하여 다른 사람과 공유하도록 초대할 수 있습니다.

파일 업로드를 허용하는 데에는 여러 가지 타당한 이유가 있습니다.기본적으로 대부분의 새 애플리케이션은 제한 없이 모든 유형의 파일 업로드를 허용할 것입니다.문제는 잠재적 공격자가 해당 업로드에 제한이 없다는 것을 알아차릴 때 시작됩니다.

업로드에 대한 제한이 없으면 사이트는 세 가지 유형의 공격에 노출됩니다.악의적인 사용자는 가장 복잡하지 않은 방법부터 시작하여 수백 기가바이트의 정보가 포함된 압축 아카이브와 같은 대용량 파일을 간단히 업로드할 수 있습니다.이로 인해 대역폭이 고갈될 뿐만 아니라 애플리케이션에 할당된 스토리지 영역에 과부하가 걸릴 수 있습니다.

다음으로 악명 높은 사다리는 바이러스와 같은 악성 파일이나 랜섬웨어와 같은 더 불길한 파일을 업로드하는 사용자입니다.이것은 뱀파이어를 집에 초대해야 한다는 오래된 미신과 비슷합니다.누구나 자유롭게 들어올 수 있다는 표지판을 걸어두면 마치 무제한 파일 업로드가 가능한 것과 같습니다.더 이상 문을 통해 들어오는 내용을 통제할 수 없기 때문에 모든 방문자 또는 파일이 순조롭지는 않을 것이라고 예상할 수 있을 것입니다.일부는 괴물일 수도 있습니다.

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

무제한 파일 액세스가 왜 그렇게 위험한가요?

무제한 파일 액세스가 가능한 애플리케이션을 배포하는 것이 당장 위험한 것은 아니지만, 기본적으로 사이버 보안 방어에 허점을 뚫고 조직을 공격하도록 누군가를 초대하는 것과 같습니다.조만간 누군가 반응할 것입니다.

가장 기본적인 수준에서는 공격자가 큰 피해를 입히기 위해 많은 기술이 필요하지도 않습니다.매우 큰 파일을 압축하여 업로드하는 것만으로도 유효한 사용자에 대한 서비스를 거부할 수 있습니다.시간이 지나면 앱이 프로그래밍되고 네트워크로 연결되는 방식에 따라 애플리케이션 또는 전체 사이트가 중단될 수도 있습니다.

무제한 파일 액세스를 사용하면 네트워크 방화벽과 기타 보호 기능에 허점이 생길 수도 있습니다.공격자가 코어 네트워크에 직접 멀웨어를 업로드할 수 있는 경로를 만들었다면 수신 이메일이나 직원의 웹 브라우징 활동을 감시하는 스캐너가 있어도 상관 없습니다.맬웨어는 응용 프로그램이나 응용 프로그램이 실행 중인 서버를 손상시킬 수 있지만 가능한 최선의 결과일 수 있습니다.최악의 시나리오에서는 랜섬웨어와 같은 진정한 악성 프로그램이 손상된 서버를 이용하여 전체 네트워크로 확산될 수 있습니다.

무제한의 파일 액세스가 가능한 애플리케이션을 악용할 때 더 숙련된 공격자는 그다지 눈에 띄지 않을 것입니다.대신 공격자는 취약점을 이용해 애플리케이션을 손상시키고 이를 이용해 네트워크 깊숙이 침투하여 느리게 움직이면서 탐지를 피하려 할 수 있습니다.웹 셸이나 다른.exe 유형 파일을 업로드한 다음 파일이 도착하면 해당 파일에 직접 명령을 전송하여 이 작업을 수행할 수 있습니다.사용자가 셸을 통해 실행하는 모든 작업은 일반적으로 서버를 호스팅하는 응용 프로그램에 설정된 권한 수준에 관계없이 서버에서 실행됩니다.서버에서는 이러한 명령이 응용 프로그램에서 나오므로 더 이상 확인하거나 검사할 필요가 없습니다.

이 모든 것이 무제한 파일 액세스 취약점을 네트워크에서 가장 위험한 취약점으로 만듭니다.문제는 문제가 발생하는지 여부가 아니라 언제 발생하느냐의 문제일 수 있습니다.

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

그렇다면 무제한 파일 액세스 문제를 해결하려면 어떻게 해야 할까요?가장 쉬운 방법은 업로드할 수 있는 파일 유형에 하나 또는 여러 개의 제한을 추가하는 것입니다.원하는 경우 사용자에게 이러한 내용을 알릴 수 있습니다. 예를 들어 해당 사이트에서 Word 또는 텍스트 파일만 허용하거나 사진 공유 사이트의 경우.jpgs 또는.gifs만 허용한다고 알릴 수 있습니다.백엔드에서는 허용 가능한 파일 확장자의 화이트리스트를 만든 다음 나머지는 모두 거부해야 합니다.또한 파일 이름의 최대 길이에도 제한을 두어야 합니다.파일 이름에 특수 문자가 있는 경우 (실행 가능한 명령을 트리거하려는 시도를 의미할 수 있음) 역시 거부해야 합니다.

파일 유형 및 이름 지정 규칙 외에도 각 파일의 최대 크기를 제한해야 합니다.최대 크기는 애플리케이션에서 수집할 것으로 예상되는 파일 유형에 적합하고 적절한 크기여야 합니다.즉, Word 파일의 경우 최대 10메가바이트 정도이고 그래픽 파일의 경우 이보다 더 큰 크기 (약 50메가바이트) 일 수 있습니다.최소 파일 크기 규칙을 설정할 수도 있습니다. 단, 예상 파일의 크기 범위를 잘 알고 있는 경우 (예: 사용자가 특정 양식을 작성하여 업로드하는 경우) 에 한합니다.

공격자는 여전히 파일 형식 및 크기 제한을 초과하여 셸이나 기타 잠재적 악성 프로그램을 몰래 훔칠 수 있는 영리한 방법을 찾을 수 있습니다.이를 보완하기 위해 수집된 파일은 항상 실행 권한 없이 개인 디렉터리에 저장해야 합니다.보안을 강화하기 위해 시스템에서 파일 이름을 일련의 임의 문자로 바꿀 수 있습니다.이렇게 하면 네트워크 외부의 인증되지 않은 사용자가 업로드한 파일의 위치를 검색하는 것을 방지할 수 있으며, 이로 인해 네트워크에 다시 접속할 수 있습니다.하지만 이렇게 하려면 임의의 파일 이름을 원래 이름과 연결하는 테이블을 설정하고 유지 관리해야 할 수도 있습니다.

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

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

백엔드에 여러 계층의 보안이 적용되면 무제한 파일 업로드 문제는 더 이상 문제가 되지 않습니다.기본적으로 파일 업로드에 제한을 두어 문제를 해결하는 것이므로 더 이상 제한이 없는 문제가 아닙니다.좋은 파일만 내부로 들어갈 수 있고 뱀파이어와 멀웨어는 모두 추위에 노출되지 않습니다.

자세한 내용은 OWASP 무제한 파일 업로드를 참조하십시오. 예방 치트 시트에는 네트워크에서 이러한 상황이 허용될 때 발생하는 가장 일반적인 몇 가지 문제가 요약되어 있습니다.또한 다음을 통해 새로 습득한 방어 지식을 테스트할 수 있습니다. 무료 쇼케이스 사이버 보안 팀이 궁극의 사이버 전사가 될 수 있도록 교육하는 Secure Code Warrior 플랫폼을 활용했습니다.이 취약점을 해결하는 방법과 기타 위협의 도적 갤러리를 자세히 알아보려면 다음 사이트를 방문하십시오. 시큐어 코드 워리어 블로그.

지금 바로 이 취약점을 해결할 준비가 되셨나요?전장으로 가서 실력을 시험해 보세요.

잘못된 보안 구성이라는 용어는 잘못된 코드 대신 애플리케이션의 구성 설정으로 인해 발생하는 일반적인 취약점을 포함하는 포괄적인 용어입니다.가장 흔한 오류에는 일반적으로 단순한 실수가 포함되며, 이러한 잘못된 구성으로 앱을 배포하는 조직에 큰 영향을 미칠 수 있습니다.

가장 일반적인 보안 구성 오류에는 애플리케이션을 프로덕션 환경에 배포하기 전에 애플리케이션의 디버깅 프로세스를 비활성화하지 않는 것, 애플리케이션이 최신 패치로 자동으로 업데이트되지 않도록 하는 것, 기본 기능을 비활성화하는 것을 잊어버리는 것 등 앞으로 큰 문제를 일으킬 수 있는 여러 가지 사소한 것들이 포함됩니다.

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

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

• 해커가 일반적인 보안 구성 오류를 찾아 악용하는 방법
• 잘못된 보안 구성이 위험할 수 있는 이유
• 보안 구성 오류를 찾아 수정하는 데 사용할 수 있는 정책 및 기법

공격자는 일반적인 보안 구성 오류를 어떻게 악용합니까?

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

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

일부 잘못된 컨피그레이션은 잘 알려져 있고 악용하기 쉽습니다.예를 들어 기본 암호를 사용하도록 설정한 경우 공격자는 기본 사용자 이름과 함께 해당 암호를 입력하기만 하면 시스템에 대한 높은 수준의 액세스 권한을 얻을 수 있습니다.

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

보안 구성이 왜 그렇게 위험한가요?

악용되는 정확한 보안 구성 오류에 따라 정보 노출부터 전체 애플리케이션 또는 서버 손상에 이르기까지 다양한 피해가 발생할 수 있습니다.잘못된 보안 구성은 숙련된 공격자가 활용할 수 있는 방어 수단에 허점을 제공합니다.기본 암호 활성화와 같은 일부 취약성의 경우 경험이 없는 해커도 이를 악용할 수 있습니다.결국, 기본 암호를 찾아 입력하는 일은 천재일 필요가 없습니다!

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

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

이를 정의한 후에는 모든 앱이 배포되기 전에 거치는 프로세스를 마련해야 합니다.이상적으로는 누군가가 이 프로세스를 책임지고, 이를 시행할 수 있는 충분한 권한을 부여받고, 일반적인 보안 구성 오류가 발생할 경우에 대한 책임도 지는 것이 좋습니다.

보안 구성 오류에 대한 추가 정보

자세한 내용은 OWASP 목록을 참조하십시오. 가장 일반적인 보안 구성 오류.새로 습득한 방어 지식을 테스트해 볼 수도 있습니다. 무료 데모 사이버 보안 팀이 궁극의 사이버 전사가 될 수 있도록 교육하는 Secure Code Warrior 플랫폼을 활용했습니다.이 취약점을 해결하는 방법과 기타 위협의 도적 갤러리를 자세히 알아보려면 다음 사이트를 방문하십시오. 시큐어 코드 워리어 블로그.

보안 구성 오류를 막을 준비가 되셨나요?저희 플랫폼으로 가서 도전해 보세요 [여기서 시작]

XML 인젝션 공격은 해커가 XML 데이터베이스를 호스팅하는 시스템을 손상시키기 위해 고안한 아주 작은 익스플로잇입니다.여기에는 의약품부터 영화에 이르기까지 모든 것에 대한 정보를 자세하게 저장하는 기존 데이터베이스를 생각할 때 떠오르는 것들이 포함됩니다.일부 XML 데이터스토어는 인증된 사용자를 확인하는 용도로도 사용되므로 새 XML 코드를 해당 데이터스토어에 삽입하면 해당 시점부터 호스트 시스템에서 받아들일 새 사용자가 생성될 수 있습니다.

공격자가 XML 주입을 구현하려면 XML 데이터베이스에 의존하거나 적어도 XML 데이터베이스에 액세스하는 애플리케이션이 있어야 합니다.이러한 상황이 발생하고 사용자 입력이 제대로 확인되지 않을 때마다 데이터스토어에 새 XML 코드를 추가할 수 있습니다.공격자의 기술에 따라 새 XML 코드를 추가하면 상당한 피해를 입히거나 전체 데이터베이스에 액세스할 수 있게 될 수도 있습니다.

계속 읽다 보면 XML 인젝션이 앞에서 다룬 SQL 인젝션 공격과 밀접하게 관련되어 있다는 것을 알게 될 것입니다.이는 서로 다른 유형의 데이터베이스를 대상으로 하지만 매우 유사하기 때문입니다.다행스럽게도 수정 사항도 비슷합니다.한 가지 유형의 공격을 물리치는 방법을 배우면 다른 유형의 공격을 막기 위해 노력할 때 게임에서 앞서 나갈 수 있습니다.

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

• XML 인젝션 작동 방식
• 왜 그렇게 위험한가요?
• 어떻게 하면 그들을 완전히 막을 수 있는 방어 시설을 마련할 수 있을까요?

공격자는 어떻게 XML 인젝션을 트리거하나요?

권한 없는 사용자가 XML 코드를 작성하여 기존 XML 데이터베이스에 삽입할 수 있을 때마다 XML 삽입이 성공합니다.이를 위해 필요한 작업은 두 가지뿐입니다. 하나는 XML 데이터베이스를 사용하거나 XML 데이터베이스에 연결하는 응용 프로그램이고, 다른 하나는 공격자가 공격을 시작할 때 사용할 보안되지 않은 데이터 경로입니다.

XML 인젝션은 처리를 위해 서버로 전송되기 전에 사용자 입력이 삭제되거나 다른 방식으로 제한되지 않는 경우 거의 항상 성공합니다.이를 통해 공격자는 코드를 직접 작성하거나 일반 쿼리 문자열 끝에 삽입할 수 있습니다.성공하면 서버가 XML 코드를 실행하도록 속여 레코드를 추가 또는 삭제하거나 전체 데이터베이스를 드러낼 수 있습니다.

해커는 일반 쿼리에 XML 코드를 추가하여 XML 인젝션 공격을 구현합니다.이는 검색 필드부터 로그인 페이지까지 무엇이든 될 수 있습니다.쿠키나 헤더와 같은 항목도 포함될 수 있습니다.

예를 들어, 등록 양식에서 사용자는 사용자 이름 또는 암호 필드 뒤에 다음 코드를 추가할 수 있습니다.

<user></user>
<role>관리자</role>
<username>존_스미스</username> <password>점프783!탱고 @12</password>

이 예에서는 관리자 액세스 권한을 가진 John_Smith라는 새 사용자를 생성합니다.적어도 새 사용자는 적절한 암호 밀도 규칙을 사용하고 있습니다.안타깝게도 이들이 실제로 공격자인 것은 사실입니다.

해커가 XML 인젝션에 성공하기 위해 항상 그런 홈런을 칠 필요는 없습니다.쿼리를 조작하고 서버가 반환하는 다양한 오류 메시지를 기록하면 XML 데이터베이스의 구조를 파악할 수 있습니다.그리고 이 정보는 다른 유형의 공격을 강화하는 데 사용될 수 있습니다.

XML 인젝션이 왜 그렇게 위험한가요?

XML 삽입 공격과 관련된 위험 수준은 대상 XML 데이터베이스에 저장되는 정보 또는 해당 정보가 사용되는 방식에 따라 다릅니다.예를 들어 사용자 인증에 XML 데이터베이스를 사용하는 경우 XML 주입을 통해 공격자는 시스템에 액세스할 수 있습니다.이를 통해 공격자가 대상 네트워크의 관리자가 될 수도 있는데, 이는 매우 위험한 상황입니다.

기존 데이터베이스에 대해 XML 인젝션을 부과하는 경우, 정보가 도난당하거나, 저장소에 잘못된 데이터가 추가되거나, 양호한 데이터를 덮어쓸 위험이 있습니다.XML 코드는 배우기가 그리 어렵지 않으며 일부 명령은 매우 강력하여 전체 정보 필드를 덮어쓰거나 데이터스토어의 콘텐츠를 표시할 수도 있습니다.

일반적으로 데이터베이스에 저장된 정보가 가치를 가지지 않는 한 아무도 데이터베이스를 구축하지 않습니다.해커들은 이 사실을 알고 있기 때문에 종종 해커들을 표적으로 삼습니다.해당 데이터에 직원이나 고객의 개인 정보 등이 포함되어 있는 경우 데이터가 손상되면 평판을 잃거나 재정적 손실, 무거운 벌금 또는 소송으로 이어질 수 있습니다.

XML 인젝션 공격 중지

XML 인젝션은 인젝션의 난이도가 낮고 XML 데이터베이스가 널리 보급되어 있기 때문에 상당히 흔합니다.하지만 이러한 공격은 이미 오래전부터 존재해 왔습니다.따라서 이러한 공격이 실행되지 않도록 하는 몇 가지 강력한 수정 사항이 있습니다.

공격을 차단하는 가장 좋은 방법 중 하나는 사전 컴파일된 XML 쿼리만 사용하도록 애플리케이션을 설계하는 것입니다.이렇게 하면 쿼리 기능이 승인된 활동 하위 집합으로 제한됩니다.사전 컴파일된 쿼리 함수와 일치하지 않는 추가 인수나 명령과 함께 들어오는 모든 항목은 실행되지 않습니다.너무 제한적으로 사용하고 싶지 않다면 파라미터화를 사용할 수도 있습니다.이렇게 하면 사용자 입력이 특정 유형의 쿼리와 데이터로 제한됩니다 (예: 정수만 사용).이러한 매개 변수를 벗어나는 모든 항목은 유효하지 않은 것으로 간주되어 쿼리가 실패하게 됩니다.

사전 컴파일되거나 매개변수화된 쿼리를 사용자 지정 오류 메시지와 함께 사용하는 것도 좋습니다.애플리케이션은 실패한 쿼리에서 설명이 포함된 기본 오류 메시지를 다시 보내는 대신 해당 응답을 가로채서 보다 일반적인 메시지로 대체해야 합니다.이상적으로는 사용자에게 쿼리가 실패한 이유를 알려주고 데이터베이스 자체에 대한 정보는 제공하지 않는 것이 좋습니다.이러한 사용자 지정 메시지를 몇 가지 선택으로 제한하면 해커는 실패한 쿼리를 바탕으로 유용한 정찰 정보를 컴파일할 수 없게 됩니다.

XML 인젝션은 처음 개발되었을 때 큰 성공을 거두었습니다.하지만 이 기술이 얼마나 오래 전이었는지 생각해보면 오늘날에는 더 이상 뚫을 수 없는 방어 수단을 쉽게 구축할 수 있습니다.

XML 인젝션에 대한 추가 정보

자세한 내용은 OWASP를 참조하십시오. 에 글을 쓰다 XML 인젝션.또한 다음을 사용하여 새로 발견한 방어 지식을 테스트할 수 있습니다. 무료 데모 사이버 보안 팀이 궁극의 사이버 전사가 될 수 있도록 교육하는 Secure Code Warrior 플랫폼을 활용했습니다.이 취약점을 해결하는 방법과 기타 위협의 도적 갤러리를 자세히 알아보려면 다음 사이트를 방문하십시오. 시큐어 코드 워리어 블로그.

개발자, QA, 엔지니어링 책임자, AppSec 전문가 등 어떤 식으로든 소프트웨어를 다루면 보안이 업무의 일부일 가능성이 높습니다.소프트웨어 취약점을 지적하는 것은 보안팀의 일이고, 처음부터 결함 없는 코드를 작성하기 위해 최선을 다하는 것도 개발자의 임무입니다.하지만 이러한 작업을 최대한 효율적이고 효과적으로 수행하려면 애플리케이션이 실행되는 코드부터 시작하여 모든 당사자가 보안 위협에 맞서 협력하는 것이 중요합니다.

그러나 보안 코딩에 대해 효과적으로 배우고 그 지식을 유지하는 것은 본질적으로 어려운 일처럼 보일 수 있습니다.올바른 도구가 있으면 그럴 필요가 없습니다.하지만 이해관계자와 상사가 올바른 유형의 교육에 투자하도록 설득하는 것이 항상 쉬운 것은 아닙니다.교육은 규정 준수 기준을 충족하기 위한 목적으로만 선택되는 경우가 많으며, 대부분의 경우 개발자의 일상 업무와는 무관한 경우가 많습니다.하지만 개발자들이 매일 사용하는 언어:프레임워크를 통해 실시간으로 보안에 대해 배우고 재미있게 할 수 있다면 어떨까요?그리고 무엇보다 중요한 것은 무엇일까요?조직은 동시에 업계 표준을 준수합니다.

저희가 도와드리겠습니다.다음은 조직 내 동료, 리드 및 최종 의사 결정권자로부터 충성을 얻어 개발자 중심의 보안 코딩 교육 프로그램에 참여할 수 있는 몇 가지 전략입니다.

처음부터 소프트웨어 취약점을 방지하면 엄청난 시간과 비용을 절약할 수 있습니다.

반복되는 보안 문제를 찾거나, 보고하거나, 해결하는 데 너무 많은 시간을 허비하고 계신가요?여러분은 혼자가 아닙니다.

다음 시나리오를 상상해 보십시오. AppSec이 취약점을 발견하고 이를 개발 팀에 보고하는 즉시 개발자는 관련 교육 수업에 참여하여 해당 결함을 수정하는 방법뿐만 아니라 향후 동일한 실수를 방지하는 방법을 배웁니다.결과는 어떻게 될 것이라고 생각하시나요?개발자는 관련성 때문에 그 교훈을 기억하고 있을 가능성이 높으며 같은 오류를 다시 범할 가능성이 적습니다.즉, 보안 팀에서 일하면 한 명의 개발자가 자신도 모르게 해당 취약점을 다시 만들 가능성이 줄어들고, 같은 개발자가 돌아가서 다시 수정해야 할 가능성도 줄어듭니다.

저희 고객인 Contrast Security가 제작한 이 동영상을 통해 실시간 교육이 개발팀에 얼마나 큰 도움이 되는지 확인해 보세요.

모든 개발자가 정기적인 보안 코드 교육에 참여하고 보안 문제에 대해 실시간으로 학습할 수 있는 도구를 손쉽게 사용할 수 있다면 놀라운 소프트웨어를 만들고 보안 프로그램을 개발하는 데 걸리는 시간은 헤아릴 수 없을 정도입니다.조직에서 이와 같은 도구에 투자하는 것은 꽤 괜찮은 주장처럼 들리죠?

보안 기술을 익히기 위해 사용하고 싶은 훌륭한 도구를 찾았다면 (기침) 과 같은 것 시큐어 코드 워리어, 이는 조직 내 CISO 또는 CTO에게 이를 홍보할 때 유용하게 활용할 수 있습니다.

역량을 갖춘 개발자는 더 나은 결과를 제공하고 만족도를 높입니다.

시간과 돈은 물론 경영진에게 매우 중요하지만 업무 만족도도 중요합니다.만족한 직원은 더 나은 결과를 제공하고, 더 오래 근무하며, 긍정적인 근무 환경에 기여합니다.그렇기 때문에 경력 개발 및 교육은 비용이 아니라 투자입니다.그리고 그 훈련이 정말 재미있고 의미 있는 것을 가르친다면 어떨까요?바로 성공으로 가는 황금 티켓이죠.

좋은 소식은 개발자들이 보안이 업무에 얼마나 중요한지 알기 때문에 일반적으로 보안을 배우려는 의욕이 높다는 것입니다.Evans Data Corporation과 함께 실시한 연구에서 전 세계 개발자를 대상으로 설문조사를 실시한 결과, 개발자들이 보안을 배우고자 하는 이유는 다음과 같습니다.

1. 생산성과 효율성을 높입니다.
2. 그들은 호기심이 많고 개인적으로 그것에 대해 배우는 데 관심이 있습니다.
3. 안전하지 않은 코드와 관련된 문제를 피하고자 합니다.
4. 그들은 그것이 경력 발전의 잠재력을 제공한다는 것을 이해합니다.
5. 인적 자원을 보다 효율적으로 사용할 수 있습니다.
   

(전체 백서 다운로드 여기.)

유일한 문제는 대부분의 보안 코딩 교육이 그들을 실망시키고 있다는 것입니다.이는 그들의 일상 업무와 관련이 없으며, 솔직히 말해서 완전히 지루합니다.이러한 기능들은 일반적으로 정보를 보존하고 실제로 학습하는 측면에서 좋은 결과를 가져오지 못합니다.그러나 학습 플랫폼이 개발자 중심적이고 재미있고 참여도가 높으며 업무와 관련성이 높으면 실제 결과를 제공하고 역량을 갖춘 개인을 만들 수 있습니다. 원하는 보안 코드를 작성할 수 있습니다.그리고 개발 책임자든 CISO나 CTO이든 상사가 개발자가 안전하게 코딩에 관심을 갖고 그렇게 할 수 있는 기술을 갖추는 것을 원하지 않는 이유는 무엇일까요?

보안에 대한 이해는 전반적으로 더 나은 엔지니어를 만듭니다.

엔지니어는 소프트웨어가 어떻게 공격에 취약할 수 있는지 이해하면 이를 염두에 두고 작업을 수행합니다.무엇이 잘못될 수 있는지 더 많이 이해할수록 예방적 접근 방식을 더 많이 활용하게 됩니다.

뿐만 아니라 품질이 낮은 코드는 소프트웨어 취약점을 포함할 가능성이 높으며 개발자가 자신도 모르게 해당 코드에 취약점을 도입하기 쉽습니다.이유는 무엇일까요?그들이 하는 일 중 많은 부분이 코드를 읽고 변경하는 것이기 때문이죠.코드가 제대로 구성되지 않고 잘못된 로직을 사용하면 이러한 작업을 수행하는 데 시간이 더 오래 걸리고 무언가를 변경하여 실수로 심각한 보안 버그가 발생하기 쉬워집니다.

보안에 대한 이해와 문제 방지 방법을 이해하면 해당 코드의 전반적인 품질과 실수로 버그가 쉽게 발생하지 않도록 작성하는 방법에 대해서도 더 깊이 생각하게 됩니다.보안 교육은 윈-윈 (win-win) 방식입니다.개발자는 보안 코딩에 대해 배우지만 그 과정에서 더 나은 엔지니어가 되기도 합니다.

숫자에는 힘이 있습니다

안전한 코딩 학습 플랫폼을 도입하기 위해 리더의 동의를 얻는 또 다른 좋은 전략은 동료를 참여시키는 것입니다.보안 지식 향상에 관심이 있는 개발자가 많을수록 경영진이나 최고 경영진이 보안 지식에 투자하도록 설득하기가 더 쉬워집니다.

그럼 어떻게 할 수 있을까요?대부분의 개발자가 보안을 더 잘해야 할 필요성을 이해하고 배우고 싶어한다는 사실을 감안하면 그리 어렵지 않을 것입니다.이 내용을 살펴보도록 할 수도 있습니다. 시큐어 코드 워리어 개발자 쇼케이스 우리 제품을 살짝 살펴보고 보안 코딩 기술을 테스트해 보세요.안전하지 않은 코드의 영향을 보고 보안에 대해 배우는 것이 재미있을 수 있다는 것을 알게 되면 더 많은 것을 배울 수 있는 힘을 얻게 될 것입니다.

올바른 도구를 채택한 후 개발자의 참여를 유도하는 가장 좋은 방법은 건전한 경쟁을 벌이는 것입니다.토너먼트로 교육 프로그램을 시작해 보세요.

Nelnet이 어떻게 토너먼트를 통해 창의력을 발휘하여 회사 내에 보안 문화를 구축했는지 확인해 보세요.

지속적인 보안 교육을 통해 바람직한 기업 문화를 조성합니다.

훈련은 지루할 필요도 없고, 지루해서도 안 됩니다.강의는 비용이 많이 들고 조직하기가 어렵다는 것을 알고 있습니다. 특히 팀이 분산되어 있는 경우에는 강의에서 많은 것을 빼앗을 가능성이 낮습니다.하지만 조직에서는 개발자들에게 보안 코딩 교육을 지속적으로 제공하고 있습니다. 보안 코딩 교육은 매년 규정 준수 여부를 확인하는 데 그치지 않습니다.단순히 현상 유지만으로는 더 이상 충분하지 않습니다.이제 개발 관리자와 AppSec은 한 걸음 더 나아가 지속적이고 참여도 높은 학습을 촉진하는 교육 도구를 함께 구현해야 할 때입니다.의사 결정권자를 설득하는 것부터 시작해야 합니다.

여러 가지 이유로 지속적인 실습 교육이 필요합니다.사이버 보안 위협은 끊임없이 진화하고 있으므로 이러한 위협에 대응하기 위한 교육도 지속적으로 실시되는 것은 당연합니다.뿐만 아니라 이미 언급했듯이 실시간으로 학습하면 학습한 내용을 유지할 가능성이 훨씬 높아집니다.보안을 염두에 두고 코딩하는 것은 구현하기 어렵습니다. 개발자가 거의 1년 전에 문맥을 벗어난 슬라이드쇼에서 배운 내용을 되새길 기대하는 것은 비현실적이기 때문입니다.하지만 특정 소프트웨어 취약점이 신고되는 순간 이를 방지하는 방법을 알게 되고 동시에 게임을 플레이하는 것처럼 느껴진다면 이는 완전히 새로운 일입니다.

실습형 관련 교육이 시행되는 즉시 보안은 기업 문화의 일부가 되며 더 이상 사후 고려 사항으로 취급되지 않습니다.소프트웨어 개발 라이프사이클의 시작부터 개발 프로세스에 반영됩니다.

그래서 뭘 기다리고 있는 거지?조직 내 보안을 개선하고 중요한 회사 및 고객 데이터를 보호하기 위한 여정을 시작하세요.개발자와 상사를 참여시켜 조직의 보안 코딩 수준을 한 단계 끌어올리세요.처음부터 보안에 대해 생각해 봄으로써 같은 취약점을 반복해서 경험하지 마세요.

더 많은 리소스가 필요하신가요?‍

“CISO/CTO 설득하기 키트” 전문 다운로드

이 기사의 한 버전이 에 게재되었습니다. 데브옵스닷컴; 새로운 정보를 포함하도록 제목이 변경되고 업데이트되었습니다.

CISO와 CIO는 특히 당혹스러운 회사 데이터 침해 사고가 발생한 경우 소프트웨어 보안에 대한 책임을 지는 것은 당연한 일이지만, 관련성을 높일 수 있는 특별한 기회도 얻게 됩니다. 바로 자신들이 새로운 혁신가이며 올바른 접근 방식으로 큰 영향력을 행사할 수 있다는 것입니다.공공 및 상업 조직을 막론하고 지구상의 모든 조직은 빠르게 디지털화되는 세상에서 시장 공간을 유지 (및 확보) 하기 위해 싸우고 있습니다.고객은 과거와 미래의 제품 모두에서 원활한 온라인 경험을 기대하며, 이에 따라 “디지털 우선” 비즈니스 접근 방식이 필수가 되고 있습니다.결국 이러한 기대치를 충족하지 못한다면 기회를 노릴 준비가 되어 있는 경쟁업체가 있을 것이 거의 확실합니다.

그렇다면 이것이 현대의 CISO, 즉 CIO에게 의미하는 바는 무엇일까요?당연하게도 이들은 개발자 팀을 고용하여 디지털 제품 또는 서비스를 구성하는 코드를 한 줄씩 만들고 있다는 뜻입니다.사이버 보안은 수년 동안 주요 고려 사항이었지만, 점점 더 많은 비즈니스 운영이 온라인 및 공격자의 눈에 띄면서 위험 요소가 증가하고 있습니다.침해로 인한 영향은 엄청나지만 디지털화를 거부하는 것은 선택 사항이 아닙니다.

창의적인 CISO와 CIO는 AppSec 및 개발 팀과 함께 디지털 미래의 길을 계속 개척할 수 있는 유리한 위치에 있습니다.이들은 의심할 여지 없이 온라인 비즈니스, 정부 및 공공 서비스의 장기적 혁신을 주도할 것이지만, 빠른 시장 출시 목표와 높은 소프트웨어 품질의 균형을 맞춰야 하는 막중한 책임을 지고 있습니다. 과 보안 위험 완화

이 균형은 지금까지 달성하기가 대단히 어려웠습니다.이로 인해 개발 팀은 일반적으로 특징과 기능을 제공하는 데 주로 초점을 맞추고 급속히 빠져나가는 코드에서 발생할 수 있는 취약점을 고려하지 않고 단편화되는 경우가 많았습니다.AppSec 전문가는 동일한 실수를 지속적으로 수정하며, 비교적 단순한 백도어를 열어 두면 보안 침해 위협이 커질 수 있습니다.

데이터를 안전하게 보호하려면 CISO와 CIO는 팀의 협업 방식을 창의적으로 활용하고 긍정적인 보안과 위에서 아래로 책임을 공유하는 문화를 조성해야 합니다.가 직면한 치명적인 결과를 한 번 보세요. 메리어트 2018년 보안 위반으로 인해 미화 1억 2,300만 달러 이상의 GDPR 벌금이 부과되고, 5억 개 이상의 레코드가 도난당했으며, 보안 평판이 엉망이 되었습니다.이 재해는 대부분 안전하지 않은 코딩 관행의 직접적인 결과로 발생했습니다. 2014년 초에 스타우드 서버에서 발견된 SQL 인젝션 취약점메리어트가 2016년에 인수한 회사입니다.애플리케이션 보안 관점에서 볼 때 이들의 후속 소프트웨어 사용은 분명히 검증되지 않았습니다.이로 인해 악의적인 공격자는 수년 동안 데이터에 액세스하고 데이터를 수집할 수 있게 되었으며, 취약한 암호와 같은 다른 취약점은 시간이 지남에 따라 악용할 수 있는 구멍이 더 많아졌습니다.

CIO와 CISO는 자체 소프트웨어 보안 환경을 매우 신중하게 고려해야 합니다.평균적인 개발자들은 보안에 대해 얼마나 알고 있을까요?AppSec과 개발 팀은 얼마나 잘 협력하고 있나요?“마법의 지팡이” 같은 해결책은 없지만 문화, 교육 및 지원을 개선하고 개선할 수 있습니다.개발 팀 양철통 조직의 첫 번째 데이터 침해 위험에서 벗어나 운영 단계로 넘어가기 전에 악성 코드를 차단하는 보안 슈퍼히어로로 전환하세요.

시큐어 코딩 상태 점검: 생명 유지 서비스를 받고 계신가요?

여러분의 개발팀은 어디에 적합할까요?이 보안 코딩 체크리스트는 CIO와 CISO가 개발팀이 더 빠르고, 더 우수하고, 안전한 코드로 혁신하는 데 도움을 줄 수 있는 진정한 보안 코딩 챔피언이 될 준비가 되어 있는지 (또는 실제로 보안 프로그램 점검이 필요한지 여부) 확인할 수 있도록 돕기 위해 만들었습니다.

1.나머지 최고 경영진은 얼마나 지지하고 있나요?기존 네트워크 보안으로는 더 이상 충분하지 않다는 사실을 이해하고 있습니까?

소프트웨어의 미래에는 구식 보안 조치를 사용하여 네트워크 계층을 보호하는 것만으로는 충분하지 않습니다 (솔직히 말해서 거의 성공하지 못합니다). 심지어 준 전문가 해커에게도 마찬가지입니다.일관성 있는 여러 보고서 중에서도 버라이존의 “2017 데이터 침해 조사 보고서“오늘날 데이터 침해의 무려 35% 가 웹 애플리케이션 취약점으로 인해 발생한다고 합니다.

웹 애플리케이션 보안은 네트워크 보안만큼이나 중요합니다. 이를 무시하고 AppSec 조치의 기본적이고 기본적인 보호 계층에 대한 예산을 책정하지 않으면 보안 침해 위험에 노출될 수 있습니다.

2.왼쪽으로 충분히 많이 움직이고 있고, 충분히 일찍 움직이고 있나요?

애플리케이션 보안에 대한 현재의 접근 방식은 소프트웨어 개발 수명 주기 (SDLC) 에서 오른쪽에서 왼쪽으로 이동하는 데 초점을 맞추어 상당히 많은 도구를 사용합니다.이는 정의 및 설계상 프로세스에 결함이 있음을 인지하고 탐지 및 대응 결과를 뒷받침합니다.보안팀은 이미 작성된 코드에서 취약점을 찾아 탐지하고, 커밋된 코드가 작성될 때 버그가 없는지 확인하는 대신 수정하기 위해 대응하고 있습니다.국립 표준 기술 연구소에 따르면 (NIST), 그것은 커밋된 코드의 취약점을 탐지하고 수정하는 데 30배 더 많은 비용 소요 IDE에 작성된 것처럼 이를 방지하기 위한 것입니다.여기에는 제작 지연, 이중 처리, 잘 알려진 동일한 보안 문제를 반복해서 해결하는 데 소요되는 시간도 고려되지 않았습니다.

진정으로 강력한 보안 문화는 다음과 같이 주장합니다. 시작 왼쪽: 개발자 집단 내 보안 챔피언에게 영감을 주는 동시에 개발 팀에게 보안 코딩 사고방식으로 성장하고 행동할 수 있는 올바른 도구와 교육을 제공했습니다.지속적인 자기 계발과 문제 해결 능력을 발휘하여 조직의 첫 번째 방어선이 되어 일반적인 취약점이 발생하지 않도록 방지하는 데 중점을 두고 있습니다.

3.실용적인 보안 기술을 쌓기 위해 노력하고 있습니까, 아니면 일방적인 지식을 제공하고 있습니까?

대부분의 보안 교육 솔루션 (온라인 및 CBT) 은 직무와 직접 관련된 실용적인 기술 대신 지식을 구축하는 데 중점을 둡니다.개발자가 번창하고 보안 코드 작성에 참여하려면 실제 환경에서 기술을 계속 학습하고 개발하도록 적극적으로 장려하는 상황에 맞는 실습 학습을 정기적으로 이용할 수 있어야 합니다.개발자들은 실제 코드 예제를 통해 최근에 발견된 취약점에 대해 학습하고 선호하는 언어와 프레임워크로 작업할 수 있어야 합니다.이러한 학습 경험은 학생들이 작업 과정에서 활발히 작업하고 있는 코드의 알려진 취약점을 찾아 식별하고 해결하는 방법을 이해하는 데 효과적입니다.

세상에는 지식이 풍부한 교사가 많고 보안 취약점 해결에 관한 정보는 넘쳐나지만 교과서를 훑어보거나 몇 시간 분량의 비디오를 시청하는 것으로는 창의적이고 문제를 해결하는 개발자의 마음을 사로잡지 못합니다. 데이터 침해가 지속적으로 발생한다는 징후를 보이더라도 취약점이 코드에 들어가는 것을 방지하는 데는 거의 효과가 없습니다.

4.실시간 메트릭으로 보안 코딩 기술을 측정하고 계신가요?

개발 팀 내에서 보안 우선 사고방식을 구축하는 데 있어 중요한 단계는 증거를 수집하고 검토하는 것입니다.이는 추측이나 추측에 의존해서는 안 됩니다. 개발자는 보안을 중시하거나 그렇지 않습니다.

메트릭스는 개발자와 조직에 그들의 노력이 결실을 맺고 있고 개개인의 보안 코딩 기술이 향상되고 있음을 증명하려고 합니다.측정할 수 없는 것은 개선할 수 없습니다.관련 평가가 있어야 하며, 이를 통해 개발 팀의 진행 상황을 실시간으로 파악할 수 있을 뿐만 아니라 지속적인 개선을 위해 보안 코딩의 강점과 약점을 벤치마킹하는 데도 도움이 됩니다.

보안 교육이 효과적인지, 참여도가 높은지, 심지어 유지되었는지에 대한 강조도 없이 조직에서 보안 교육이 “꼭 필요한” 교육으로 전락하는 경우가 너무 많습니다.

5.아웃소싱 공급업체가 강력한 보안 코딩 기술을 사용하고 있습니까?

많은 조직에서 개발 작업을 타사 기관에 위탁하기로 결정합니다.기업이 해외에 있든 해외에 있든 그들의 일반적인 보안 코딩 능력과 관행은 고객에게 상대적으로 수수께끼입니다.최상의 경우, 조직이 보안과 관련하여 받을 수 있는 유일한 형태의 보증은 결과물의 “보안”을 요구하는 계약서의 명세서뿐입니다.이러한 개발 업체의 기술을 사전에 검증하기 위한 조치를 취하는 회사는 거의 없습니다. 따라서 간략한 내용대로 작동하지만 건전한 보안 코딩 관행을 따르지 않고 구축된 소프트웨어를 제공받을 위험이 있습니다.설상가상으로, 구매 회사가 애플리케이션의 본질적인 보안 결함을 인지하지 못하면 취약한 소프트웨어를 외부로 내보낼 위험이 있습니다.

가장 일반적인 시나리오는 전담 보안 전문가 (찾기가 어렵고 비용이 많이 드는 개인) 가 취약점을 찾아내는 경우로, 출시 날짜가 지연되고, 누가 이러한 보안 취약점을 수정하기 위해 비용을 지불해야 하는지에 대한 계약상의 논의가 발생할 수 있습니다.하지만 똑똑하고 다음 애플리케이션을 구축할 개발자의 애플리케이션 보안 기술을 평가하면 잠재적인 지연, 좌절 및 현금을 크게 줄일 수 있습니다.

6.개발자들이 가장 흔하게 악용되는 보안 취약점을 알고 있습니까?

악용되는 웹 애플리케이션 취약점의 85% 이상은 단지 10개의 알려진 취약점에 기인합니다.” OWASP 탑 10.애플리케이션 보안 교육에서는 최소한 이러한 취약성 유형과 더불어 더 많은 취약성 유형도 다루어야 합니다.개발자가 직면하는 교육 과제는 정기적으로 수정 및 업데이트되어야 하며, 새로운 코딩 프레임워크나 새로운 취약성 유형에 대한 새로운 과제도 함께 수정해야 합니다.

실제 보안 코딩 시나리오를 사용한 정밀 교육이 표준이어야 합니다. 모호한 일반 지식은 효과가 없습니다.(이러한 보안 코딩 시나리오가 어떤 모습일지 궁금하신가요?저희 사이트를 확인해 보세요 코더들이 보안을 정복하다 블로그 시리즈; 각 게시물에는 플레이 가능한 챌린지가 있습니다).

7.사내 보안 전문가가 있나요?

개발자 중심의 모든 조직은 보안 챔피언, 즉 개발팀 내에서 높은 보안 표준을 유지할 책임을 지는 사람에게 투자해야 합니다.이들의 목적은 보안과 관련하여 궁금한 점이 있는 모든 사람을 위한 지원 담당자가 될 뿐만 아니라 보안 모범 사례를 따르는 것을 주요 지지자가 되는 것입니다.

이는 보안 문화 퍼즐의 중요한 부분입니다. 훌륭한 보안 챔피언은 집중적인 교육을 통해 추진력을 유지하고, 팀의 모든 구성원이 필요한 것을 갖추도록 하며, 계속해서 지원을 요청할 수 있습니다.

8.개발자들이 보안 코딩을 더 쉽게 할 수 있는 도구에 투자하셨나요?

조직이 애자일 개발을 실천하는 조직이거나 실제로 회사에서 구축한 애플리케이션을 자주 업데이트해야 하는 경우, 보안의 일부를 자동화하는 것만이 정신없는 속도와 업무량을 따라잡을 수 있는 유일한 방법 중 하나입니다.

SDLC의 각 단계에는 어드바이저, 품질 게이트키퍼 또는 탐지 도구 역할을 하는 도구가 있습니다.또한 일부 도구는 코드에 대한 자동 테스트를 실행하여 소프트웨어가 생산되면 해킹 시도를 시뮬레이션합니다.모든 도구에는 고유한 장점과 문제점이 있으며, 누구도 포괄할 수 없습니다. 애플리케이션 내에 보안 위협이 존재하지 않는다는 것을 100% 보증합니다.취할 수 있는 가장 중요한 예방 조치는 취약점을 조기에 발견할수록 비즈니스에 미치는 영향을 최소화하면서 더 빠르고 저렴하게 해결할 수 있다는 것입니다.

미래 지향적인 CISO를 위한 다음 단계

그렇다면 귀사는 위의 체크리스트와 비교했을 때 어떤 성과를 거두었을까요?

CISO와 CIO는 기본적으로 엔터프라이즈 DevOps 및 DecSecOps 기능을 적극적으로 구축해야 하지만, 그렇다고 해서 팀 전체에 적합한 도구와 교육을 고려하고 구현할 시간이 없다는 의미는 아닙니다.보안 코딩 기술은 혁신을 가로막는 것이 아니라 무기가 될 것이며, 이를 포기하면 회사의 평판과 데이터가 완전히 파괴될 수 있습니다.이러한 기술은 중요한 기능이며 취약점을 줄이고 위험을 완화하는 훨씬 저렴한 장기적 솔루션이기도 합니다.

훌륭하고 혁신적인 CISO는 건강한 보안 문화를 위에서 아래로 조율할 수 있습니다. 직원들이 보안 모범 사례를 효과적으로 실행하는 데 필요한 것을 갖추도록 하세요.

피터 다니유는 보안 전문가이자 의 공동 설립자입니다. 시큐어 코드 워리어.

검증되지 않은 리디렉션 및 전달을 할 수 있는 기능을 갖춘 웹 사이트 또는 시스템을 구성하는 것은 사용자와 조직 모두에게 매우 위험할 수 있습니다.이러한 일반적인 실싱 피수는 사르저지/평소에 제한되는 페이지 및 최악의적인 정보에 대한 권한을 얻으려는 해커용용용하는 경우가 있습니다.

웹 사용자를 위한 새 페이지로 전달하도록 설계될 때마다 이러한 요청이 조작되고 하이킹될 위험이 있습니다. 전달 매개변수가 아닌 다른 사람을 가리키는 목적지는 것을 중시합니다.

다행인 것은 검증되지 않은 리미션 및 전달은 사용자 환경에서 제거하기가 더 쉬운 취약성 중 하나라는 것입니다.직접 몇 가지 간단한 조치를 취하여 이러한 문제가 발생할 수 있습니다.

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

• 해자가 검증되지 않은 리미션 및 전달 취약점을 악용하는 방법
• 검증되지 않은 리미션 및 전달을 하는 것이 위험할 수 있는 이유
• 이 찾아 문제를 해결하는 데 사용할 수 있는 정책과 기법.

공격자는 검증되지 않은 리맵션 및 전달을 어떻게 악용합니까?

공격자는 먼저 특정 사용자를 위한 특정 페이지 또는 여러 페이지로 전달하도록 설정된 웹 애플리케이션을 사용합니다.코드 대상 정의점이 없습니다.예 자바 자리 하이퍼링크에서는 같은 작업을 수행할 수 없습니다.

Response.SendRedirect (” http://www.knownsafesite.com “);

이 취약점은 사이트 리디렉션에 대한 사용자 입력을 대신 받아들이도록 프로그래밍된 경우 또는 다른 소스에서 정보를 가져오기 위해 매개변수가 열려 있는 경우 발생합니다.예를 들어 “url'get” 매개변수를 사용할 수 있습니다.

응답.전송 리디렉션 (요청.get매개 변수 (“url”));

# #이렇게 유연성이 향상되지만 검증되지 않은 리디렉션 및 전달 취약성 발생.해시는 슬래브는 나중에 #피싱 이메일처럼 일부처럼 자신이 선택한 곳으로 리디렉션할 수 있습니다. ############################ #0 ######### #0 ######## ######## ################################# #0

검증되지 않은 리미션과 전달이 왜 그렇게 위험한가요?

전달을 통한 사전 동의 및 전달을 통한 심각한 위험이 발생할 수 있습니다.사용자에게 가장 큰 위험은 피싱 공격의 피해자가 될 수 있는 것입니다.최상위 URL을 볼 수 있습니다.최상위 URL을 볼 수 있기 때문에 #피싱 #최상위 URL이나 기타 통신하고 링크를 클릭할 수 있습니다.할 수도 있습니다.

검증되지 않은 리디렉션 및 전달로 인한 위협 제거

검증되지 않은 리미션과 포워드는 시스템이 개발되는 동안 작동하기 시작합니다.이러한 문제는 사후에 제거될 수 있지만, 이를 수행하는 가장 쉬운 방법은 애초 리젝션수의 전달을 위한 것입니다.

리디렉션 또는 전달 시스템의 프레임___J_R_J_의 대상이 아닌 경우 순조로운 대상 집합 중 하나로 이동하는지 확인하는 절차를 마련해야 합니다.

검증되지 않은 리미션 및 전달에 대한 추가 정보

자세한 내용은 OWASP을 참조하십시오. 참조 페이지 검증되지 않은 리미션 및 전달에 대해서.또한 이를 통해 새로 발견한 방어 지식을 테스트할 수 있습니다. 무료 데모 사이버 보안 팀이 궁극의 사이버 전사가 될 수 있도록 교육하는 보안 코드 워리어 플랫폼을 활용했습니다.이 취약점을 해결하는 방법과 기타 위협의 도적 갤러리를 자세히 알아보려면 다음 사이트를 방문하세요. 시큐어 코드 워리어 블로그.

검증되지 않은 리디렉션 및 포워드를 한 번 처리하세요.게임화된 교육 플랫폼에서 새로운 지식을 적용하고 기술을 테스트해 보세요. [여기서 시작]

크로스 사이트 스크립팅 (XSS) 은 2000년대 초반부터 보안 전문가들에게 큰 버그로 작용해 왔으며, 안타깝게도 수십 년이 지난 지금도 여전히 가장 일반적인 코드 레벨 위협 중 하나로 인식되고 있습니다.이런 종류의 소프트웨어 취약점은 너무나 오랫동안 우리를 괴롭혀 왔으며, 최근 경고는 CISA 시큐어 바이 디자인 (Secure-by-Design) 운동의 일환으로 이 운동을 단번에 저지하기 위해 노력하고 있습니다.이들은 대규모로 취약성 클래스를 제거하는 것을 세계적인 사명으로 삼고 있습니다. 개발자 주도 보안에 대한 이러한 집중 조명은 변화를 가져오고 변화를 가져올 수 있습니다. 하지만 이를 위해서는 보안 성공을 위해 개발자를 준비시킨 스마트 엔터프라이즈의 노력이 필요합니다.

그렇다면 XSS란 정확히 무엇일까요?

웹 브라우저는 온라인에서 멋진 콘텐츠를 볼 수 있는 관문일 수 있지만 안타깝게도 좋은 소식만 있는 것은 아닙니다.웹 브라우저의 고유한 동작은 보안 취약점의 촉매제가 될 수 있습니다.브라우저는 특징적으로 해당 마크업을 신뢰하고 아무 문제 없이 실행하는 것으로 시작했습니다.이 기능이 악의적인 목적으로 악용되기 전까지는 괜찮고 멋지지만... 공격자들은 결국 이러한 경향을 악용하여 자신들의 사악한 목적을 달성할 방법을 찾았습니다.

크로스 사이트 스크립팅은 브라우저의 신뢰와 사용자의 무지를 이용하여 데이터를 도용하고 계정을 탈취하며 웹 사이트를 훼손합니다. 이는 매우 심각하고 빠르게 악화될 수 있는 취약점입니다.

XSS의 작동 방식, 발생할 수 있는 손상 및 예방 방법을 살펴보겠습니다.

XSS는 어떻게 작동하나요?

XSS는 신뢰할 수 없는 입력 (주로 데이터) 이 페이지의 출력으로 렌더링되지만 실행 코드로 잘못 해석될 때 발생합니다.공격자는 입력 매개 변수 내에 악성 실행 코드 (HTML 태그, JavaScript 등) 를 넣을 수 있습니다. 이 매개 변수는 브라우저로 다시 반환될 때 데이터로 표시되는 대신 실행됩니다.

위에서 언급한 것처럼 이 취약점은 데이터를 실행 코드와 구별하기 어려운 브라우저의 핵심 기능 동작으로 인해 나타났습니다.웹의 운영 모델은 다음과 같습니다.

1. 사용자가 웹 페이지를 방문함
2. 이 페이지는 로드할 파일과 실행할 파일을 브라우저에 알려줍니다.
3. 브라우저는 질문 없이 페이지에 있는 내용을 실행합니다.

이 기능 덕분에 웹에서 즐기는 가장 멋진 인터랙티브 경험이 가능해졌습니다.반면, 이로 인해 비용이 많이 드는 익스플로잇과 취약점이 발생하기도 합니다.

공격자가 취약한 사이트에 악성 스크립트를 추가하면 의심할 여지 없이 실행됩니다.심층적인 조사나 탐지 조치가 마련되어 있지 않습니다.

XSS에는 세 가지 유형이 있습니다.

• 저장된 XSS
• 반사형 XSS
• 돔 XSS

저장된 XSS 공격자가 애플리케이션의 데이터 필드 (예: 사용자의 휴대폰 번호를 저장하는 필드) 에 악성 스크립트를 영구적으로 저장할 수 있을 때 발생합니다.그러면 애플리케이션에 해당 데이터 필드가 표시될 때마다 이 개략적인 스크립트가 사용자의 브라우저로 전송됩니다.

이러한 유형의 공격은 포럼 사이트 또는 댓글 엔진에서 자주 볼 수 있습니다.공격자가 댓글에 악성 스크립트를 입력하면 bam - 해당 댓글을 보는 모든 사용자가 자신도 모르게 스크립트를 실행합니다.

반사형 XSS 사용자 입력이 사용자의 브라우저에 그대로 반영될 때 발생합니다.검색 결과를 가져오는 동안 사용자에게 “검색한 대상...” 이라는 검색 상자를 예로 들 수 있습니다.

이제 URL에 검색어를 쿼리 매개변수로 배치하여 검색이 작동한다고 가정해 보겠습니다.악의적인 공격자는 피해자에게 동일한 매개변수에 악성 스크립트가 포함된 링크를 보낼 수 있습니다. 사실 대부분의 웹 사용자는 거의 알아차리지 못할 것입니다.

피해자가 링크를 클릭하면 피싱 사이트로 리디렉션되어 자신도 모르게 해당 사이트의 비밀번호를 입력합니다.공격자가 방금 자신의 계정 키를 훔쳤다는 사실은 거의 알지 못합니다.

돔 XSS 이 취약점은 비교적 새로운 변종입니다.Angular 및 React와 같은 많은 UI 프레임워크에서 사용되는 복잡한 템플릿 구조를 활용합니다.

이러한 템플릿을 사용하면 동적 콘텐츠와 풍부한 UI 애플리케이션을 사용할 수 있습니다.잘못 사용하면 XSS 공격을 실행하는 데 사용될 수 있습니다.

자, 이제 됐어요.간단히 말해서 XSS의 범위를 알 수 있습니다.어떻게 파괴적으로 사용될 수 있는지 더 자세히 알아보도록 하겠습니다.

XSS가 왜 그렇게 위험한가요?

XSS는 사용자를 악성 사이트로 리디렉션하고 쿠키를 도용하고 세션 데이터를 찾는 데 사용할 수 있습니다.기본적으로 JavaScript가 무엇을 할 수 있든 XSS 공격도 가능합니다.

XSS 공격의 세 가지 예는 다음과 같습니다.

1. 야후 이메일 사용자 세션 쿠키를 도난당했음 2015년에는 XSS를 사용하고 있습니다.
2. 더 새미 웜 마이스페이스의 XSS 취약점을 통해 배포되었습니다.이 악성코드는 여전히 역사상 가장 빠르게 확산되고 있는 악성코드로, 단 20시간 만에 백만 명의 사용자에게 영향을 미쳤습니다.
3. eBay는 제품 설명에 악성 스크립트를 포함하도록 허용했습니다.이로 인해 XSS 공격 이베이 사용자를 상대로.

XSS 공격은 믿을 수 없을 정도로 단순하고 매우 심각합니다.이로 인해 세션, 사용자 자격 증명 또는 민감한 데이터가 도난될 수 있습니다.평판 손상과 수익 감소는 이러한 공격의 주요 함정입니다.웹 사이트를 훼손하는 것만으로도 비즈니스에 바람직하지 않은 결과를 초래할 수 있습니다.

하지만 XSS는 당신과 같은 똑똑한 보안 전사가 물리칠 수 있습니다.해결책은 복잡하지 않으며 XSS가 널리 사용되는 익스플로잇이 된 이후 업계는 오랫동안 발전해 왔습니다.

XSS를 물리칠 수 있습니다.

XSS를 물리치는 열쇠는 상황을 이해하는 것입니다.구체적으로 말하자면, 사용자 입력이 클라이언트로 다시 렌더링되는 컨텍스트와 다시 렌더링되는 컨텍스트입니다.HTML 코드 내부 또는 자바스크립트 스니펫 내부.

사용자 입력을 브라우저로 다시 보낼 필요가 없다면 훨씬 더 좋습니다.하지만 그럴 경우 HTML로 인코딩해야 하는 경우가 많습니다.출력을 HTML로 인코딩하면 브라우저에 콘텐츠를 있는 그대로 렌더링하고 실행하지 말라고 지시합니다.

입력 유효성 검사도 중요합니다.하지만 유효성 검사 및 화이트리스팅은 아니다 완벽한 솔루션.인코딩은 몇 단계 더 나아가 브라우저에서 악성 스크립트를 실행하지 못하도록 합니다.유효성 검사 및 화이트리스팅 전략으로 포착되지 않은 부분이 무엇이든 인코딩 문제가 해결됩니다.

현재 많은 프레임워크에서 HTML 출력을 자동으로 인코딩하고 있습니다.
앵귤러, ASP.NET MVC, 및 React.js 기본 HTML 인코딩이 사용되는 프레임워크입니다.이러한 프레임워크에 특수 메서드를 호출하여 인코딩하지 않도록 구체적으로 지시해야 합니다.

대부분의 다른 프레임워크, (예: 장고 과 스프링) 에는 코드에 쉽게 통합할 수 있는 XSS 방지를 위한 표준 라이브러리가 있습니다.

가장 큰 과제는 사용자 입력이 시스템에 들어오는 모든 방법을 스스로 분석하여 계속 주시할 수 있도록 하는 것입니다.쿼리 파라미터는 공격을 수반할 수 있으며 포스트 파라미터도 공격을 일으킬 수 있습니다.애플리케이션 전체의 데이터 흐름을 추적하고 외부에서 들어오는 데이터를 신뢰하지 마십시오.

국경 순찰대처럼 생각하세요.모든 데이터를 중지하고 검사하고 악의적으로 보이면 데이터를 허용하지 마세요.그런 다음 렌더링할 때 인코딩하여 누락된 잘못된 부분이 여전히 문제를 일으키지 않도록 하세요.

이러한 전략을 실행하면 XSS를 통한 공격으로부터 사용자를 안전하게 보호할 수 있습니다.한 번 살펴보세요 OWASP 치트 시트 데이터를 효과적으로 관리할 수 있는 더 많은 팁을 확인하세요.

XSS를 막고 보안 기술을 업그레이드하세요.

XSS는 OWASP 2017년 상위 10개 웹 보안 위험 목록에서 7위를 차지했습니다.이미 나온 지 오래되었지만 주의하지 않으면 여전히 나타날 수 있고 응용 프로그램에 문제가 발생할 수 있습니다.

개발자가 코드를 작성할 때 보안을 최우선으로 생각하는 사고방식을 구축하는 데 있어 교육은 매우 중요합니다.또한 이러한 교육은 개발자가 활발히 사용하는 언어로 실제 애플리케이션을 시뮬레이션할 때 항상 가장 효과적입니다.이를 염두에 두고 저희 사이트를 확인해 보는 것은 어떨까요? 학습 리소스 XSS에 대해 더 알고 싶으신가요?그 후에는 숙달로 이어지는 훈련과 연습을 시작할 수 있습니다.

지금 바로 XSS 취약점을 찾아 수정할 준비가 되셨나요? 자신에게 도전하세요 시큐어 코드 워리어 플랫폼에서

민감한 데이터 노출은 지난 몇 년간 가장 널리 알려지고 영향력이 큰 데이터 침해 사고의 원인이 되었습니다. 여기에는 다음과 같은 치명적인 메리어트 보안 침해 사건이 포함됩니다. 3억 건 이상의 고객 기록이 도난당했습니다, 및 에퀴팩스가 공격을 받았을 때 1억 5천만 명이 더.중간 수준의 정교함이 필요하고 때로는 공격자 측에 특수 장비가 필요하지만 대부분의 경우 해커가 해킹하기가 그리 어렵지 않으며 일부 공격 기능을 자동화하는 도구도 있습니다.

민감한 데이터 노출은 승인된 열람만을 위한 정보가 암호화되지 않았거나 보호되지 않거나 보호가 취약한 상태에서 승인되지 않은 사람에게 노출될 때마다 발생합니다.여기에는 대부분 해커가 훔치려는 신용카드 번호, 사용자 ID, 기업 비밀, 법률 및 업계 규정의 보호를 받을 수 있는 개인 정보 등의 데이터가 포함됩니다.

해커는 암호화하지 않고 저장하거나 암호화 체계를 간접적으로 공격하여 민감한 정보를 훔칠 수 있습니다.이들은 강력한 암호화를 직접 해독하는 대신 암호화 키를 훔치거나, 데이터가 암호화되지 않은 상태로 이동될 때 (예: 전송 준비 완료) 데이터를 공격합니다.

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

• 공격자가 민감한 데이터 노출을 유발하는 방법
• 민감한 데이터 노출이 위험한 이유
• 이 취약점을 해결할 수 있는 기술

공격자는 민감한 데이터 노출을 어떻게 악용합니까?

민감한 데이터 노출은 일반적으로 사이트가 강력한 엔드-투-엔드 암호화를 사용하여 데이터를 보호하지 않거나 보호 체계에 악용 가능한 결함이 있을 때 발생합니다.사용된 암호화가 특히 약하거나 시대에 뒤떨어진 경우에도 발생할 수 있습니다.

해커는 암호화가 모든 곳에 확장되지 않은 경우 이를 우회할 방법을 찾는 경우가 많습니다.예를 들어 사용자 ID 데이터베이스가 정보를 암호화된 상태로 저장했다가 검색 시 자동으로 암호를 해독하는 경우 해커는 이전에 이 블로그에서 다룬 다음과 같은 공격 중 하나를 사용할 수 있습니다. SQL 또는 XML 인젝션, 데이터베이스에 암호 해독 프로세스를 수행하도록 명령합니다.그러면 해커가 추가 작업 없이 데이터를 해독할 수 있습니다.열쇠를 소매치기만 하면 되는데 왜 철제 문을 무너뜨리려 할까요?

취약한 암호화도 문제입니다.예를 들어 오래된 암호화 체계를 사용하여 신용 카드를 저장한 경우 해커가 다음과 같은 것을 사용할 수 있다면 문제가 될 수 있습니다. 로컬 파일 포함 전체 데이터베이스를 자신의 컴퓨터로 가져오는 데 취약합니다.캡처한 데이터를 AES-256 비트 암호화와 같은 강력한 방법으로 보호했다면 해커의 소유로 넘어가더라도 데이터를 손상시키기가 훨씬 더 어려웠을 것입니다.하지만 이전 DES 표준과 같이 약하거나 시대에 뒤떨어진 암호화를 사용하는 경우 GPU (그래픽 처리 장치) 랙과 같은 특수 장비를 갖춘 해커는 비교적 짧은 시간 내에 암호화를 해제하도록 지시할 수 있습니다.

민감한 데이터 노출은 왜 위험한가요?

민감한 데이터가 노출되면 권한이 없는 사용자가 보호된 정보를 볼 수 있기 때문에 위험합니다.데이터가 중요하지 않으면 보호될 수 없기 때문에 해당 보호를 위반할 경우 문제가 발생할 수 있습니다.조직이 직면하고 싶어하는 상황은 절대 아닙니다.

민감한 데이터 노출로 인해 발생할 수 있는 문제의 정도는 노출되는 데이터의 종류에 따라 다릅니다.사용자 또는 암호 데이터가 도난당하면 시스템에 대한 추가 공격을 시작하는 데 사용될 수 있습니다.개인 정보가 노출되면 사용자는 신원 도용이나 피싱과 같은 2차 공격에 노출될 수 있습니다.노출된 데이터가 미국의 HIPAA (건강 보험 이전 및 책임법) 또는 유럽의 일반 데이터 보호 규정 (GDPR) 과 같은 법률에 의해 법적으로 보호되는 경우 조직은 무거운 벌금과 정부 조치에 취약할 수도 있습니다.

민감한 데이터 노출 제거

민감한 데이터 노출을 막는 것은 기업 전체에서 민감한 데이터를 최신의 강력한 엔드-투-엔드 암호화하는 것에서 시작됩니다.여기에는 저장된 데이터와 전송 중인 데이터가 모두 포함됩니다.민감한 데이터가 스토리지에 있는 동안 암호화하는 것만으로는 충분하지 않습니다.사용 전이나 전송 전에 암호화되지 않은 경우 서버를 속여 암호화를 해제하도록 하는 2차 공격을 통해 데이터가 노출될 수 있습니다.

전송 중인 데이터는 항상 전송 계층 보안 (TLS) 을 사용하여 보호해야 합니다. 이렇게 하면 맨 인 미들 (man in middle) 을 이용한 공격이나 이동 데이터에 대한 기타 공격을 방지할 수 있습니다.또한 민감한 데이터는 네트워크의 어느 곳에서도 캐시해서는 안 됩니다.민감한 데이터는 강력한 암호화 상태로 저장하거나 TLS 보호를 사용하여 전송하여 공격자가 악용할 취약점이 없도록 해야 합니다.

마지막으로, 조직에서 보호하고 있는 민감한 데이터의 종류를 목록화하세요.조직에서 이러한 데이터를 저장할 이유가 없다면 폐기하십시오.아무런 이득도 없이 잠재적 문제에 자신을 노출시키는 이유는 무엇일까요?원본에서 유지 관리하지 않는 데이터는 도용될 수 없습니다.

민감한 데이터 노출에 대한 추가 정보

자세한 내용을 보려면 OWASP가 말하는 내용을 살펴보십시오. 민감한 데이터 노출.또한 다음과 같이 새로 발견한 방어 지식을 테스트할 수 있습니다. 무료 데모 사이버 보안 팀이 궁극의 사이버 전사가 될 수 있도록 교육하는 Secure Code Warrior 플랫폼을 활용했습니다.이 취약점을 해결하는 방법과 기타 위협의 도적 갤러리를 자세히 알아보려면 다음 사이트를 방문하십시오. 시큐어 코드 워리어 블로그.

웹 사이트로 이동하여 로그인합니다.평소처럼 구매하려는 제품으로 장바구니를 채웁니다.그러면 으악 - 손이 미끄러져 브라우저 탭이 닫힙니다.잠시 당황한 후 사이트의 URL을 브라우저에 다시 입력하고 “Enter” 키를 누릅니다.사이트로 돌아와 로그인해도 모든 품목이 카트에 그대로 있습니다.휴.

재인증을 하지 않고도 사이트에서 사용자의 신원을 어떻게 알 수 있었나요?세션을 사용하고 있었기 때문에 사용자를 식별했습니다.세션은 웹을 사용할 때 좋은 사용자 경험을 위한 핵심입니다.하지만 세션을 잘못 관리하면 공격자가 악용할 수 있는 보안 허점이 생길 수 있습니다.

이제 세션 관리가 무엇을 의미하는지, 세션 관리가 취약하면 어떤 문제가 발생할 수 있는지, 세션을 제대로 관리하기 위해 무엇을 할 수 있는지 살펴보겠습니다.

세션 관리 약점에 대한 이해

세션이란 서버에 저장된 값을 말하며 응용 프로그램의 단일 사용자에게만 해당됩니다.이는 두 가지 이유로 필요합니다. 첫째, HTTP가 상태 비저장 프로토콜이라는 것입니다.각 요청은 별개이며 요청 이전 또는 이후에 들어온 요청을 알 수 없습니다.서버는 세션을 통해 요청을 보낸 사람을 추적할 수 있습니다.그렇지 않으면 버튼이나 링크를 클릭할 때마다 로그인해야 합니다.

세션의 두 번째 이유는 사용자 권한 부여입니다.세션 식별자는 시스템 내에서 특정 권한을 가진 특정 사용자를 식별하는 데 사용할 수 있습니다.애플리케이션은 사용자가 누구이며 무엇을 할 수 있는지 알 수 있습니다.

세션에는 두 가지 구성 요소가 있습니다.서버측 데이터 저장소는 세션 식별자를 저장하고 이를 사용자 ID 또는 카트 정보와 같은 사용자 정보에 매핑합니다.동일한 세션 식별자가 쿠키로 브라우저에 전송됩니다.쿠키는 브라우저에 의해 사용자 시스템에 저장됩니다.클라이언트는 각 요청과 함께 쿠키를 전달하여 이 요청이 동일한 사용자로부터 온 것임을 서버에 알립니다.대부분의 애플리케이션은 세션을 사용하여 사전 인증 및 사후 인증 모두에서 사용자를 추적합니다.

적절한 세션 관리는 애플리케이션 보안에 필수적입니다.유효한 세션 ID는 사용자 이름/암호 또는 2차 인증 토큰과 동일한 신뢰 수준을 갖습니다.

잘못된 세션 관리가 위험한 이유

세션 관리가 제대로 이루어지지 않으면 계정 탈취가 완료될 수 있습니다.즉, 고객 데이터가 도난당하거나 제품을 사기로 구매할 수 있습니다.공격자가 유효한 세션 ID를 얻을 수 있는 방법은 여러 가지가 있습니다.

A 세션 고정 공격 사용자가 시스템에 로그인하거나 URL을 사용하여 세션 식별자를 설정할 수 있는 경우와 같이 중요한 시간에 세션이 변경되지 않는 경우에 발생합니다.이러한 방식으로 세션 식별자를 설정하면 동일한 인증 소스를 사용하는 여러 애플리케이션에서 사용자가 계속 로그인할 수 있도록 할 수 있습니다.이 경우 공격자는 웹 사이트를 탐색하여 세션 ID를 얻을 수 있습니다.그런 다음 공격자는 URL에 세션 ID가 포함된 URL을 이메일을 통해 의심하지 않는 피해자에게 보냅니다.피해자는 이메일에 있는 URL을 클릭하고 웹 사이트에 로그인합니다.로그인 시 세션 ID가 교체되지 않는 경우 공격자는 이제 유효하고 인증된 세션 ID를 갖게 됩니다.이를 통해 완전한 계정 탈취가 가능합니다.

부실한 세션 관리에 대한 또 다른 공격은 무차별 추측 공격입니다.개발자가 자체 세션 관리 시스템을 만들려고 할 때 추측하기 쉬운 세션 ID를 사용하는 경우가 많습니다.이러한 패턴은 시퀀스 (1, 2, 3) 일 수도 있고 예측 가능한 패턴일 수도 있습니다.공격자는 유효한 세션 ID가 발견될 때까지 계속해서 세션 ID를 추측할 뿐입니다.이로 인해 계정 탈취가 발생할 수도 있습니다.

일정 시간이 지나도 자동으로 무효화되지 않는 세션은 사용자를 공격하는 데 악용될 수 있습니다.성공 사이트 간 요청 위조 공격은 사용자가 사이트를 떠난 후에도 여전히 유효한 세션에 따라 달라집니다.공격자가 사용자가 방문한 사이트에 iframe 또는 이미지를 배치한다고 가정해 보겠습니다.“src” (source) 속성은 취약한 사이트의 URL로 설정되고 사용자를 대신하여 작업을 수행합니다.예를 들어 취약한 은행 애플리케이션이 사용자의 허가 없이 공격자의 계좌로 돈을 이체하도록 만들 수 있습니다.

세션 관리는 까다로울 수 있고 약점은 치명적일 수 있습니다.하지만 이는 잘 알려진 문제이므로 해결할 수 있습니다.

안전하지 않은 세션 관리 극복

세션 관리는 모든 웹 애플리케이션의 핵심 요소입니다.따라서 많은 웹 개발 프레임워크에는 세션 관리 기능이 내장되어 있습니다.전문가들이 이러한 시스템을 면밀히 검토하여 문제를 찾아내고 해결했습니다.사용하세요.

몇 가지 일반적인 특성 훌륭한 세션 관리 다음을 포함하세요:

공격자가 추측할 수 없는 무작위 세션 ID 생성

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

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

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

무차별 대입 공격을 방지하기 위한 최소 128비트 길이의 세션 ID

Spring과 같은 웹 프레임워크, ASP.NET 코어, 레일, 및 장고 이러한 속성이 있으므로 이 경우 더 높은 보안 표준에 사용해야 합니다.

요점: 세션 관리 시스템을 처음부터 새로 만들지 마십시오.

세션 ID가 생성되면 보호해야 합니다.다음을 설정합니다. 보안 및 HTTP 전용 플래그 세션 쿠키를 'true'로 설정합니다.이렇게 하면 JavaScript로 해당 값을 검색할 수 없으며 브라우저가 HTTPS를 통해서만 쿠키를 전송하므로 공격자가 전송 중인 다른 사람의 세션을 훔치는 것을 방지할 수 있습니다.

세션 보안

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