관련 학습 권장 사항: javascript
귀하의 웹 시스템은 정말 안전한가요?
웹 시스템에서는 작은 취약점이 종종 매우 심각한 결과를 초래할 수 있습니다. 따라서 웹 보안은 모든 시스템이 설계, 개발, 운영, 유지 관리 과정에서 반드시 고려해야 할 문제입니다.
요즘 많은 웹 시스템에서 취하는 방어 조치는 기본적이고 단순한 쪽으로 편향되어 있으며 종종
등과 같은 일반적인 보안 취약점만을 대상으로 합니다. 이러한 기본 방어 조치는 필요하고 구현하는 데 비용이 많이 들지 않지만 시스템 보안 방어의 기본 부분일 뿐입니다. 많은 개발자들은 이러한 작업을 수행하는 것만으로도 대부분의 상황에 대처할 수 있다고 생각합니다. 이 아이디어는 매우 위험합니다. 실제로 이러한 기본적이고 표준화된 취약점 외에도 각 비즈니스 시스템의 비즈니스 로직 자체도 해커의 공격 대상이 될 가능성이 높습니다. 아래에는 이전에 시스템을 개발할 때 직면했던 몇 가지 일반적인 비즈니스 논리 허점을 나열하겠습니다. 이것이 모든 사람에게 영감을 줄 수 있기를 바랍니다.
우리 모두는 HTTP 자체가 상태 비저장이라는 것을 알고 있습니다. 브라우저와 서버가 서로의 신원을 알고 서로 신뢰할 수 있도록 하기 위해 대부분의 웹 시스템은 "토큰"과 같은 합의된 자격 증명을 사용하여 구현됩니다. 토큰은 사용자가 로그인한 후에 생성되며 사용자가 적극적으로 로그아웃하거나 일정 시간이 지나면 만료됩니다. 즉, 요청이 해당 토큰을 가져오면 서버는 토큰을 가져와 해당 확인을 수행할 수 있으며, 확인이 통과되면 요청을 신뢰하고 가져오지 않으면 관련 비즈니스 로직을 실행합니다. 불법이거나 만료된 것을 가져오면 불법으로 간주됩니다. 이는 문제가 없어 보이지만 실제 구현에는 숨은 허점이 있을 수 있다.
두 가지 예를 살펴보겠습니다.
1. 프론트엔드 개발자 Xiao Ming은 사용자가 종료 버튼을 클릭하는 로직을 작성할 때 단순히 쿠키 또는 로컬 저장소에서 토큰 값을 지웠습니다(토큰은 일반적으로 이 두 저장소에 저장됩니다). 장소), 비즈니스에서 토큰이 만료되도록 백엔드에 대한 요청을 시작하지 않았습니다. 그러면 이 토큰의 유효성은 본질적으로 사용자의 의도에 어긋나며 이때 위험이 매우 높습니다. 사용자가 자발적으로 종료하더라도 토큰은 여전히 유효합니다. 어떤 방식으로든 토큰을 획득하고 기록하면 사용자 정보 변경, 주문 등 사용자가 수행한 작업을 완벽하게 재생할 수 있습니다.
2. 위의 예에서는 토큰이 만료되도록 설정해야 한다고 언급했습니다. 합리적인 만료 시간은 위험을 효과적으로 줄일 수 있습니다. 하지만 백엔드 개발 담당자가 토큰 만료 구성을 설정할 때 현기증이 나고 손이 떨릴 수도 있고, 추가 숫자를 입력할 수도 있고, 단위를 잘못 이해해서 S급 단위에 MS급 값을 사용할 수도 있으니, 그러면 만료 시간이 설정됩니다. 적극적으로 로그아웃하는 것을 싫어하거나 로그인 후 오랫동안 페이지에 머무르는 사용자에게는 매우 위험합니다. 토큰은 사용자가 오랫동안 사용하지 않더라도 여전히 유효합니다. 다른 사람이 토큰을 얻으면 많은 나쁜 일을 할 수 있습니다.
파일 업로드는 아바타 업로드, 네트워크 디스크에 파일 업로드 등 웹 애플리케이션에서 일반적으로 사용되는 기능이어야 합니다. 악의적인 사용자가 업로드할 때 트로이 목마, 바이러스, 악성 스크립트 및 기타 파일을 업로드할 수 있습니다. 이러한 파일이 서버에서 실행되면 심각한 결과를 초래할 수 있습니다. 이 공격 방법은 상대적으로 비용이 저렴하고 공격자가 악용하기가 상대적으로 쉽습니다. 업로드가 허용되는 파일 형식이 많을수록 공격 가능성이 커집니다. 악성 프로그램이 성공적으로 업로드되면 사용자가 다운로드하여 사용자 컴퓨터에서 실행된 후 감염될 수 있습니다. 또한, 서버에 악성 프로그램이 실행되어 서버를 제어할 수 있게 되어 서버 마비 및 데이터 손실이 발생할 수도 있습니다.
일반적인 상황에서 프로그램은 파일 형식을 판단하고 합법적이라고 생각되는 파일만 서버에 업로드하도록 허용합니다. 그러나 일부 웹 프로그램에서는 이러한 판단이 프론트엔드에서만 이루어지고 백엔드에서는 이루어지지 않습니다. 이는 불법 파일 업로드 요청을 쉽게 수정할 수 있는 공격자에게 기회를 제공합니다.
올바른 접근 방식은 이를 방어하기 위해 파일 확장자 판단, MIME 감지 및 백엔드 업로드 파일 크기 제한을 수행하는 것입니다. 또한, 업무와 분리된 서버에 파일을 저장하여 악성 파일이 업무 서버를 공격하여 서비스 이용이 불가능해지는 것을 방지할 수 있습니다.
시스템에 로그인할 때 대부분의 시스템은 사용자가 로그인할 때 사용자가 존재하는지 여부를 확인한 후 "등록되지 않은 휴대폰 번호입니다"라는 메시지를 표시합니다. 이 논리가 별도의 인터페이스를 사용하여 수행되면 무차별 열거의 위험이 있습니다. 공격자는 이 인터페이스를 사용하여 휴대폰 번호 라이브러리를 사용하여 요청 열거를 수행하고 시스템에 등록된 휴대폰 번호를 식별할 수 있으며, 이는 다음 단계에서 무차별 비밀번호 크래킹 기회를 제공합니다.
이 문제의 경우 로그인 확인 인터페이스에 이 판단을 적용하고 명확한 프롬프트를 반환하지 않는 것이 좋습니다. 잘 만들어진 웹사이트에서는 대개 "휴대폰번호가 등록되지 않았거나 비밀번호가 틀렸습니다."라는 메시지가 뜹니다. 이로 인해 사용자 경험이 손상되기는 하지만 더 안전합니다.
포럼 게시물을 예로 들어, 패킷 캡처 도구를 사용하여 포럼 게시물의 요청 프로세스를 캡처하고 도구 재생 프로세스를 통해 게시물 목록에 두 개의 동일한 게시물이 나타나는 것을 확인할 수 있습니다. 이것은 재생에 의한 공격입니다. 재생 빈도가 빨라지면 시스템에 많은 양의 정크 데이터가 생성될 뿐만 아니라 빈번한 쓰기로 인해 비즈니스 데이터베이스에 큰 부담이 가해집니다.
재생 위험이 있는 요청의 경우 요청 빈도 제한을 추가하는 것이 좋습니다. 예를 들어 두 요청의 타임스탬프를 확인하고 특정 시간 값보다 큰 경우 유효하도록 설정할 수 있습니다.
권한 확인은 회사 조직 구조 관리 시스템 등 웹 시스템의 기본 기능으로 부서명, 부서장 수정 기능을 제공한다. 권한 확인을 추가하면 사용자가 이러한 기능을 통해 사용할 권한이 없는 정보를 수정하는 것을 효과적으로 방지할 수 있습니다. 이러한 시스템에서는 권한 확인이 반드시 구현되지만 실제로는 올바르게 구현됩니까?
시스템의 사용자가 부서 이름을 수정하려면 최고 관리 권한이 있어야 하고 부서 A에 속해야 한다는 두 가지 조건을 충족해야 한다고 규정한다고 가정해 보겠습니다. 실제 코드 구현에서 개발자는 사용자가 최고 관리자인지 여부만 확인하고 사용자가 해당 부서에 속하는지는 확인하지 않는 경우가 많습니다. 이 경우 부서 B의 슈퍼 관리 계정을 사용하여 부서 A의 이름을 수정할 수 있습니다. 이는 우리의 권한을 넘어서 이름을 수정하는 것과 같습니다. 이는 분명히 우리가 예상한 결과가 아닙니다. 부서 B의 최고 관리자 사용자가 인터페이스에서 부서 A의 부서 이름을 수정하는 입구를 찾을 수 없는 경우에도 요청을 잡아 매개변수를 수정할 수 있습니다.
무단 수정은 물론, 승인된 권한을 넘어서 볼 수도 있습니다. A부서의 슈퍼매니저가 B부서의 부서 정보를 볼 수 있을 거라 기대하진 않겠죠?
시스템에서 역할에 대한 사용자 액세스 권한을 엄격하게 확인하고 제한하는 것이 좋습니다.
보안은 작은 문제가 아닙니다. 처음에 언급했듯이 어떤 취약점이라도 큰 타격을 줄 수 있으므로 모두가 주의하시기 바랍니다. 우리는 비즈니스 디자인에 주의를 기울여야 할 뿐만 아니라 구현으로 인해 발생하는 낮은 수준의 취약점을 피하기 위해 코드 검토에도 주의를 기울여야 합니다.
위 내용은 다양한 보안 취약점 중 일부에 불과합니다. 더 심각한 웹 애플리케이션 보안 위험에 대해서는 OWASP Top 10 2017에서 발표된 상위 10가지 보안 문제를 참조하세요. www.owasp.org.cn/owasp-proje…
위 내용은 JS 감지를 사용하면 웹 시스템이 정말 안전합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!