🥇웹사이트 보안의 치명적인 죄: 올해의 취약점 스캐너 통계에서 배운 것

약 XNUMX년 전에 DataLine이 출시되었습니다. 서비스 IT 애플리케이션의 취약점을 검색하고 분석합니다. 이 서비스는 운영에 관한 Qualys 클라우드 솔루션을 기반으로 합니다. 우리는 이미 말했다. 솔루션을 사용하는 291년 동안 우리는 다양한 사이트에 대해 XNUMX건의 스캔을 수행하고 웹 애플리케이션의 일반적인 취약점에 대한 통계를 축적했습니다.

아래 기사에서는 다양한 수준의 중요도 뒤에 숨어 있는 웹사이트 보안의 허점을 정확히 보여 드리겠습니다. 스캐너가 특히 자주 발견한 취약점은 무엇인지, 왜 발생할 수 있는지, 자신을 보호하는 방법은 무엇인지 알아보겠습니다.

Qualys는 모든 웹 애플리케이션 취약성을 낮음, 중간, 높음의 세 가지 중요도 수준으로 나눕니다. '심각도'별 분포를 보면 모든 것이 나쁘지 않은 것 같습니다. 심각도가 높은 취약점은 거의 없으며 대부분 심각하지 않습니다.

그러나 비판적이지 않다고 해서 무해하다는 뜻은 아닙니다. 또한 심각한 손상을 초래할 수도 있습니다.

주요 "중요하지 않은" 취약점

혼합 콘텐츠 취약점.
웹사이트 보안의 표준은 암호화를 지원하고 정보가 가로채지 않도록 보호하는 HTTPS 프로토콜을 통해 클라이언트와 서버 간 데이터를 전송하는 것입니다.

일부 사이트에서 사용 혼합 콘텐츠: 일부 데이터는 안전하지 않은 HTTP 프로토콜을 통해 전송됩니다. 가장 자주 전달되는 방법은 다음과 같습니다. 수동적 콘텐츠 – 사이트 표시에만 영향을 미치는 정보: 사진, CSS 스타일. 하지만 가끔 이런 식으로 전달되는 경우도 있습니다. 활성 콘텐츠: 사이트의 동작을 제어하는 스크립트입니다. 이 경우 특수 소프트웨어를 사용하면 서버에서 들어오는 활성 콘텐츠가 포함된 정보를 분석하고 응답을 즉시 수정하며 제작자가 의도하지 않은 방식으로 기계가 작동하도록 할 수 있습니다.

최신 버전의 브라우저에서는 혼합 콘텐츠가 포함된 사이트가 안전하지 않다는 것을 사용자에게 경고하고 해당 콘텐츠를 차단합니다. 웹사이트 개발자는 콘솔에서도 브라우저 경고를 받습니다. 예를 들어, 다음과 같이 표시됩니다. 파이어 폭스:

왜 위험합니까?: 공격자는 안전하지 않은 프로토콜을 사용하여 사용자 정보를 가로채고 스크립트를 교체하며 사용자를 대신하여 사이트에 요청을 보냅니다. 사이트 방문자가 데이터를 입력하지 않았더라도 다음으로부터 보호되지는 않습니다. 피싱 – 사기적인 방법을 사용하여 기밀 정보를 얻는 경우. 예를 들어, 스크립트를 사용하면 사용자에게 친숙한 사이트로 가장하는 안전하지 않은 사이트로 사용자를 리디렉션할 수 있습니다. 어떤 경우에는 악성 사이트가 원본보다 훨씬 좋아 보이고 사용자가 직접 양식을 작성하고 기밀 데이터를 제출할 수도 있습니다.

웹 개발자가 기억해야 할 것: 사이트 관리자가 SSL/TLS 인증서를 설치 및 구성한 경우라도 인적 오류로 인해 취약점이 발생할 수 있습니다. 예를 들어 페이지 중 하나에 상대 링크가 아닌 http의 절대 링크를 추가하고 http에서 https로의 리디렉션을 설정하지 않은 경우입니다.

브라우저를 사용하여 사이트의 혼합 콘텐츠를 감지할 수 있습니다. 페이지의 소스 코드를 검색하고 개발자 콘솔에서 알림을 읽어보세요. 그러나 개발자는 오랫동안 지루하게 코드를 수정해야 합니다. 다음과 같은 자동화된 분석 도구를 사용하면 프로세스 속도를 높일 수 있습니다. SSL 확인, 무료 Lighthouse 소프트웨어 또는 유료 소프트웨어 Screaming Frog SEO Spider.

또한, 상속된 코드인 레거시 코드의 문제로 인해 취약점이 발생할 수도 있습니다. 예를 들어 일부 페이지가 https로의 사이트 전환을 고려하지 않는 이전 템플릿을 사용하여 생성된 경우입니다.
"HTTPOnly" 및 "보안" 플래그가 없는 쿠키입니다.
"HTTPOnly" 속성은 공격자가 사용자 데이터를 훔치기 위해 사용하는 스크립트에 의해 쿠키가 처리되지 않도록 보호합니다. "secure" 플래그는 쿠키가 일반 텍스트로 전송되는 것을 허용하지 않습니다. 보안 HTTPS 프로토콜을 사용하여 쿠키를 보내는 경우에만 통신이 허용됩니다.

두 속성 모두 쿠키 속성에 지정됩니다.
```
Set-Cookie: Secure; HttpOnly
```
왜 위험합니까?: 사이트 개발자가 이러한 속성을 지정하지 않으면 공격자가 쿠키에서 사용자 정보를 가로채서 악용할 수 있습니다. 인증 및 권한 부여에 쿠키가 사용되는 경우 사용자는 사용자 세션을 가로채고 사용자를 대신하여 사이트에서 작업을 수행할 수 있습니다.

웹 개발자가 기억해야 할 것: 일반적으로 널리 사용되는 프레임워크에서는 이러한 속성이 자동으로 설정됩니다. 그러나 여전히 웹 서버 구성을 확인하고 플래그를 설정하십시오: Set-Cookie HttpOnly; 안전한.

이 경우 "HTTPOnly" 속성은 쿠키를 귀하의 JavaScript에 보이지 않게 만듭니다.
경로 기반 취약점.
스캐너는 잠재적으로 기밀 정보가 포함된 공개적으로 액세스 가능한 파일이나 웹 사이트 디렉터리를 발견하는 경우 이러한 취약점을 보고합니다. 예를 들어 개별 시스템 구성 파일이나 전체 파일 시스템에 대한 액세스를 탐지합니다. 이러한 상황은 사이트에 대한 접근 권한이 잘못 설정되어 있는 경우 발생할 수 있습니다.

왜 위험합니까?: 파일 시스템이 "돌출"되면 공격자는 운영 체제 인터페이스에 빠져 비밀번호가 일반 텍스트로 저장된 폴더를 찾으려고 시도할 수 있습니다(그러지 마세요!). 또는 비밀번호 해시를 훔치고 비밀번호를 무차별 대입하여 시스템에서 권한을 높이고 인프라로 더 깊이 들어가려고 시도할 수도 있습니다.

웹 개발자가 기억해야 할 것: 접근권한을 잊지 말고 플랫폼, 웹 서버, 웹 애플리케이션을 구성하여 웹 디렉터리를 "탈출"하는 것이 불가능하도록 설정하세요.
자동 채우기가 활성화된 민감한 데이터를 입력하기 위한 양식입니다.
사용자가 웹사이트에서 양식을 자주 작성하는 경우 브라우저는 자동 완성 기능을 사용하여 이 정보를 저장합니다.

웹사이트의 양식에는 비밀번호나 신용카드 번호와 같은 민감한 정보가 포함된 필드가 포함될 수 있습니다. 이러한 필드의 경우 사이트 자체에서 양식 자동 완성 기능을 비활성화하는 것이 좋습니다.

왜 위험합니까?: 사용자의 브라우저에 민감한 정보가 저장되어 있는 경우 나중에 공격자가 피싱 등을 통해 해당 정보를 가로챌 수 있습니다. 본질적으로 이러한 미묘한 차이를 잊어버린 웹 개발자는 사용자를 설정하고 있습니다.

웹 개발자가 기억해야 할 것: 이 경우에는 편의성과 보안이라는 고전적인 갈등이 발생합니다. 웹 개발자가 사용자 경험을 고려한다면 의식적으로 자동 완성을 선택할 수 있습니다. 예를 들어, 따라야 할 사항이 있는 경우 웹 컨텐츠 접근성 지침 – 장애가 있는 사용자를 위한 콘텐츠 접근성에 대한 권장 사항.

대부분의 브라우저에서는 autocompete="off" 속성을 사용하여 자동 완성을 비활성화할 수 있습니다. 예를 들면 다음과 같습니다.
```
 <body>
    <form action="/ko/form/submit" method="get" autocomplete="off">
      <div>
        <input type="text" placeholder="First Name">
      </div>
      <div>
        <input type="text" id="lname" placeholder="Last Name" autocomplete="on">
      </div>
      <div>
        <input type="number" placeholder="Credit card number">
      </div>
      <input type="submit">
    </form>
  </body>
```
하지만 Chrome에서는 작동하지 않습니다. 이는 JavaScript를 사용하여 우회되며 레시피의 변형을 찾을 수 있습니다. 여기에.
X-Frame-Options 헤더는 사이트 코드에 설정되어 있지 않습니다.
이 헤더는 프레임, iframe, 삽입 또는 개체 태그에 영향을 미칩니다. 도움을 받으면 사이트를 프레임 안에 삽입하는 것을 완전히 금지할 수 있습니다. 이렇게 하려면 X-Frame-Options: 거부 값을 지정해야 합니다. 또는 X-Frame-Options: sameorigin을 지정할 수 있습니다. 그러면 iframe에 삽입하는 것은 해당 도메인에서만 가능합니다.

왜 위험합니까?: 이러한 헤더가 없으면 악성 사이트에서 다음과 같은 행위를 할 수 있습니다. 클릭재킹. 이 공격을 위해 공격자는 버튼 위에 투명한 프레임을 만들어 사용자를 속입니다. 예를 들어, 사기꾼은 웹사이트의 소셜 네트워킹 페이지를 구성합니다. 사용자는 자신이 이 사이트의 버튼을 클릭하고 있다고 생각합니다. 대신 클릭이 차단되고 사용자의 요청이 활성 세션이 있는 소셜 네트워크로 전송됩니다. 이는 공격자가 사용자를 대신하여 스팸을 보내거나 구독자와 좋아요를 얻는 방법입니다.

이 기능을 비활성화하지 않으면 공격자가 애플리케이션 버튼을 악성 사이트에 배치할 수 있습니다. 그는 귀하의 추천 프로그램이나 사용자에게 관심이 있을 수 있습니다.

웹 개발자가 기억해야 할 것: 웹 서버나 로드 밸런서에 충돌하는 값을 가진 X-Frame-Options를 설정할 경우 취약점이 발생할 수 있습니다. 이 경우 서버와 밸런서는 백엔드 코드에 비해 우선순위가 높기 때문에 헤더를 다시 작성합니다.

X-Frame-Options 헤더의 거부 및 동일 출처 값은 Yandex 웹 뷰어의 작동을 방해합니다. 웹뷰어에서 iframe 사용을 허용하려면 설정에서 별도의 규칙을 작성해야 합니다. 예를 들어 nginx의 경우 다음과 같이 구성할 수 있습니다.
```
http{
...
 map $http_referer $frame_options {
 "~webvisor.com" "ALLOW-FROM http://webvisor.com";
 default "SAMEORIGIN";
 }
 add_header X-Frame-Options $frame_options;
...
}
```
PRSSI(경로 기준 스타일시트 가져오기) 취약점.
이는 사이트 스타일의 취약점입니다. 스타일 파일에 액세스하기 위해 href="/ko/somefolder/styles.css/"와 같은 상대 링크를 사용하는 경우 발생합니다. 공격자가 사용자를 악성 페이지로 리디렉션하는 방법을 찾으면 이를 이용하게 됩니다. 페이지는 해당 URL에 상대 링크를 삽입하고 스타일 호출을 시뮬레이션합니다. 스타일을 가장하여 악의적인 작업을 수행할 수 있는 badsite.ru/…/somefolder/styles.css/와 같은 요청을 받게 됩니다.

왜 위험합니까?: 사기꾼이 또 다른 보안 허점을 발견하면 이 취약점을 악용할 수 있습니다. 결과적으로 쿠키나 토큰에서 사용자 데이터를 훔칠 수 있습니다.

웹 개발자가 기억해야 할 것: X-Content-Type-Options 헤더를 nosniff로 설정합니다. 이 경우 브라우저는 스타일에 대한 콘텐츠 유형을 확인합니다. 유형이 text/css가 아닌 경우 브라우저는 요청을 차단합니다.

심각한 취약점

비밀번호 필드가 있는 페이지가 안전하지 않은 채널을 통해 서버에서 전송됩니다(비밀번호 필드가 포함된 HTML 양식은 HTTP를 통해 제공됨).
암호화되지 않은 채널을 통한 서버의 응답은 "중간자" 공격에 취약합니다. 페이지가 서버에서 클라이언트로 이동하는 동안 공격자는 트래픽을 가로채서 클라이언트와 서버 사이에 끼어들 수 있습니다.

왜 위험합니까?: 사기꾼은 페이지를 교체하고 사용자에게 기밀 데이터 양식을 보낼 수 있으며, 이 양식은 공격자의 서버로 이동됩니다.

웹 개발자가 기억해야 할 것: 일부 사이트에서는 비밀번호 대신 이메일/전화로 일회용 코드를 사용자에게 보냅니다. 이 경우 취약점은 그다지 심각하지 않지만 메커니즘은 사용자의 삶을 복잡하게 만듭니다.
안전하지 않은 채널을 통해 로그인 및 비밀번호가 포함된 양식 보내기(로그인 양식은 HTTPS를 통해 제출되지 않음)
이 경우 로그인 및 비밀번호가 포함된 양식이 암호화되지 않은 채널을 통해 사용자로부터 서버로 전송됩니다.

왜 위험합니까?: 이전 사례와 달리 이미 심각한 취약점이 존재합니다. 민감한 데이터를 가로채기 위해 코드를 작성할 필요도 없기 때문에 가로채기가 더 쉽습니다.
알려진 취약점이 있는 JavaScript 라이브러리 사용.
스캔 중에 가장 많이 사용된 라이브러리는 다양한 버전이 포함된 jQuery였습니다. 각 버전에는 적어도 하나 이상의 알려진 취약점이 있습니다. 취약점의 성격에 따라 영향은 매우 다를 수 있습니다.

왜 위험합니까?: 알려진 취약점에 대한 익스플로잇이 있습니다. 예:

웹 개발자가 기억해야 할 것: 정기적으로 주기(알려진 취약점 검색 - 수정 - 확인)로 돌아갑니다. 예를 들어 오래된 브라우저를 지원하거나 비용을 절약하기 위해 의도적으로 레거시 라이브러리를 사용하는 경우 알려진 취약점을 수정할 수 있는 기회를 찾으십시오.
XSS(교차 사이트 스크립팅).
XSS(교차 사이트 스크립팅) 또는 교차 사이트 스크립팅은 웹 애플리케이션에 대한 공격으로, 이로 인해 데이터베이스에 악성 코드가 유입됩니다. Qualys가 이러한 취약점을 발견하면 잠재적인 공격자가 악의적인 작업을 수행하기 위해 자신의 js 스크립트를 사이트 코드에 도입할 수 있거나 이미 도입했음을 의미합니다.

저장된 XSS 스크립트가 서버에 내장되어 공격받은 페이지가 브라우저에서 열릴 때마다 실행되기 때문에 더 위험합니다.

반사된 XSS HTTP 요청에 악성 스크립트가 삽입될 수 있으므로 수행하기가 더 쉽습니다. 애플리케이션은 HTTP 요청을 수신하지만 데이터의 유효성을 검사하지 않고 패키징한 후 즉시 보냅니다. 공격자가 트래픽을 가로채서 다음과 같은 스크립트를 삽입하면
```
<script>/*+что+то+плохое+*/</script> 
```
그러면 클라이언트를 대신하여 악의적인 요청이 전송됩니다.

XSS의 놀라운 예: CVC 입력 페이지, 카드 만료 날짜 등을 시뮬레이션하는 js 스니퍼입니다.

웹 개발자가 기억해야 할 것: Content-Security-Policy 헤더에서 script-src 속성을 사용하여 클라이언트 브라우저가 신뢰할 수 있는 소스에서만 코드를 다운로드하고 실행하도록 합니다. 예를 들어 script-src 'self'는 당사 사이트의 모든 스크립트만 허용 목록에 추가합니다.
가장 좋은 방법은 인라인 코드입니다. unsafe-inline 값을 사용하는 인라인 자바스크립트만 허용합니다. 이 값은 인라인 js/css 사용을 허용하지만 js 파일 포함을 금지하지는 않습니다. script-src 'self'와 함께 외부 스크립트가 실행되지 않도록 비활성화합니다.

Report-uri를 사용하여 모든 것을 기록하고 이를 사이트에 구현하려는 시도를 살펴보십시오.
SQL 주입.
이 취약점은 웹 사이트의 데이터베이스에 직접 액세스하는 웹 사이트에 SQL 코드를 주입할 가능성을 나타냅니다. 사용자의 데이터가 검사되지 않으면 SQL 주입이 가능합니다. 정확성을 확인하지 않고 즉시 쿼리에 사용됩니다. 예를 들어 웹 사이트의 양식에서 입력이 데이터 유형과 일치하는지 확인하지 않는 경우 이런 일이 발생합니다.

왜 위험합니까?: 공격자가 이 양식에 SQL 쿼리를 입력하면 데이터베이스가 충돌하거나 기밀 정보가 노출될 수 있습니다.

웹 개발자가 기억해야 할 것: 브라우저에서 나오는 내용을 믿지 마십시오. 클라이언트 측과 서버 측 모두에서 자신을 보호해야 합니다.

클라이언트 측에서는 JavaScript를 사용하여 필드 유효성 검사를 작성합니다.

널리 사용되는 프레임워크에 내장된 기능은 서버에서 의심스러운 문자를 피하는 데도 도움이 됩니다. 또한 서버에서 매개변수화된 데이터베이스 쿼리를 사용하는 것이 좋습니다.

웹 애플리케이션에서 데이터베이스와의 상호 작용이 정확히 발생하는 위치를 결정합니다.

상호 작용은 ID 요청(ID 변경), 새 사용자 생성, 새 댓글 또는 데이터베이스의 새 항목과 같은 정보를 받을 때 발생합니다. SQL 주입이 발생할 수 있는 곳입니다. 데이터베이스에서 레코드를 삭제하더라도 SQL 주입이 가능합니다.

일반 권고

바퀴를 재발명하지 말고 검증된 프레임워크를 사용하세요.. 일반적으로 널리 사용되는 프레임워크가 더 안전합니다. .NET - ASP.NET MVC 및 ASP.NET Core, Python - Django 또는 Flask, Ruby - Ruby on Rails, PHP - Symfony, Laravel, Yii, JavaScript - Node.JS-Express.js, Java - 스프링 MVC.

공급업체 업데이트를 따르고 정기적으로 업데이트하세요.. 그들은 취약점을 발견하고 익스플로잇을 작성하여 공개적으로 사용할 수 있도록 하면 모든 일이 다시 일어날 것입니다. 소프트웨어 공급업체의 안정적인 버전 업데이트를 구독하세요.

접근권한 확인. 서버 측에서는 항상 귀하의 코드를 처음부터 마지막 문자까지 사이트를 파괴하고 데이터 무결성을 침해하려는 가장 미워하는 적이 작성한 것처럼 취급하십시오. 더욱이 때로는 이것이 사실입니다.

클론, 테스트 사이트를 사용한 후 프로덕션에 사용. 이는 첫째, 생산적인 환경에서 실수와 실수를 피하는 데 도움이 될 것입니다. 생산적인 환경은 돈을 가져오고 단순한 생산 환경은 중요합니다. 문제를 추가, 수정 또는 종료할 때는 테스트 환경에서 작업한 다음 발견된 기능과 취약점을 확인한 다음 프로덕션 환경에서 작업할 계획을 세우는 것이 좋습니다.

다음으로 웹 애플리케이션을 보호하세요. 웹 응용 프로그램 방화벽 취약점 스캐너의 보고서를 통합합니다.. 예를 들어 DataLine은 Qualys와 FortiWeb을 서비스 번들로 사용합니다.

출처 : habr.com

웹사이트 보안의 치명적인 죄: 올해 취약점 스캐너 통계를 통해 배운 것

주요 "중요하지 않은" 취약점

심각한 취약점

일반 권고

코멘트를 추가 답장을 취소