코더는 보안을 정복 : 공유 및 학습 - 교차 사이트 스크립팅

게시일: 2018.12.06.
by Jaap Karan Singh
사례 연구

코더는 보안을 정복 : 공유 및 학습 - 교차 사이트 스크립팅

게시일: 2018.12.06.
by Jaap Karan Singh
리소스 보기
리소스 보기

웹 브라우저는 온라인에서 모든 훌륭한 것들에 대한 우리의 관문일 수 있지만 슬프게도 모든 좋은 소식은 아닙니다. 웹 브라우저의 고유한 동작은 보안 취약점의 촉매제가 될 수 있습니다. 브라우저는 특성적으로 본 마크업을 신뢰하고 의심의 여지없이 실행하여 시작되었습니다. 그 기능이 불미스러운 목적을 위해 악용 될 때까지 모든 벌금과 dandy입니다 ... 그리고 당연히, 공격자는 결국 자신의 악한 끝을 더하기 위해이 경향을 악용 할 수있는 방법을 발견했다.

사이트 간 스크립팅(XSS)은 브라우저의 신뢰와 사용자의 무지를 사용하여 데이터를 도용하고, 계정을 인수하고, 웹 사이트를 훼손합니다. 그것은 매우 추한 얻을 수있는 취약점, 매우 빠르게.

XSS의 작동 방식, 어떤 피해를 줄 수 있는지, 이를 방지하는 방법을 살펴보겠습니다.

XSS는 어떻게 작동합니까?

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

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

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

이 기능은 우리가 웹에서 즐길 수있는 가장 멋진, 대화 형 경험의 일부를 주도하고있다. 동전의 다른 측면은 또한 비용이 많이 드는 악용과 취약점을 주도했다는 것입니다.

공격자가 악의적인 스크립트를 취약한 사이트에 추가하면 의심할 여지 없이 실행됩니다. 더 깊은 조사나 탐지 조치가 없습니다.

사용자 정의 자바 스크립트 코드는 사용자의 브라우저에서 실행될 수 있습니다.

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

  • 저장된 XSS
  • 반사된 XSS
  • DOM XSS

저장된 XSS는 공격자가 응용 프로그램의 데이터 필드(예: 사용자의 휴대폰 번호를 저장하는 필드)에 악성 스크립트를 지속적으로 저장할 수 있는 경우에 발생합니다. 그런 다음 이 스케치 스크립트는 데이터 필드가 응용 프로그램에 표시될 때마다 사용자의 브라우저로 전송됩니다.

이러한 유형의 공격은 포럼 사이트 또는 댓글 엔진에서 자주 볼 수 있습니다. 공격자는 댓글에 악의적인 스크립트를 입력하고, 밤 - 무의식적으로 스크립트를 실행하는 댓글을 보는 모든 사용자.

반사된 XSS는 사용자 입력이 사용자의 브라우저에 있는 것처럼 다시 반영될 때 발생합니다. 예를 들어 "검색한..." 검색 상자가 표시됩니다. 검색 결과를 가져오는 동안 사용자에게.

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

피해자는 링크를 클릭하고 피싱 사이트로 리디렉션되어 무의식적으로 사이트에 대한 암호를 입력합니다. 그들은 거의 그들이 실현, 공격자는 단지 자신의 계정에 키를 도난했다.

DOM XSS는 이 취약점의 비교적 새로운 다양성입니다. 각도 및 반응과 같은 많은 UI 프레임워크에서 발견되는 복잡한 템플릿 구조를 활용합니다.

이러한 템플릿을 사용하면 동적 콘텐츠와 풍부한 UI 응용 프로그램을 사용할 수 있습니다. 잘못 사용하면 XSS 공격을 실행하는 데 사용할 수 있습니다.

그래서, 거기 당신은 그것을 가지고있다. 당신은 간단히 XSS의 범위를 가지고있다. 그것은 파괴적으로 사용할 수있는 방법에 더 깊이 다이빙하자.

XSS가 왜 그렇게 위험합니까?

XSS는 사용자를 악의적인 사이트로 리디렉션하고 쿠키를 훔치고 세션 데이터를 추적하는 데 사용할 수 있습니다. 기본적으로 JavaScript가 할 수 있는 모든 작업을 수행할 수 있는 XSS 공격도 가능합니다.

다음은 XSS 공격의 세 가지 예입니다.

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

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

그러나 XSS는 당신처럼 정통한 보안 전사에 의해 패배 할 수 있습니다. 수정은 복잡하지 않으며 XSS가 일반적으로 사용되는 악용이된 이후 업계는 길고 먼 길을 왔습니다.

XSS를 물리칠 수 있습니다.

XSS를 물리 치기 위한 핵심은 맥락을 이해하는 것입니다. 특히 사용자 입력이 클라이언트로 다시 렌더링되고 클라이언트가 다시 렌더링되는 컨텍스트입니다. HTML 코드 내부 또는 JavaScript 스니펫 내부입니다.

사용자 입력을 브라우저로 다시 보낼 필요가 없는 경우 훨씬 더 좋습니다. 그러나 이 경우 HTML 인코딩되는 경우가 많습니다. 출력을 인코딩하는 HTML은 브라우저에 콘텐츠를 있는 것으로 렌더링하고 실행하지 말라고 지시합니다.

입력 유효성 검사도 중요합니다. 그러나 유효성 검사 및 화이트리스트는 완벽한 솔루션이 아닙니다. 인코딩은 몇 단계 더 나아가 브라우저가 악의적인 스크립트를 실행하지 못하도록 합니다. 유효성 검사 및 화이트리스트 전략에 걸리지 않는 것이 무엇이든 인코딩이 선택됩니다.

이제 많은 프레임워크가 HTML 출력을 자동으로 인코딩하고 있습니다.
각도, ASP.NET MVCReact.js 기본 HTML 인코딩이 사용되는 프레임워크입니다. 이러한 프레임워크는 특수 메서드를 호출하여 인코딩하지 않도록 특별히 말해야 합니다.

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

가장 큰 과제는 사용자 입력이 시스템에 들어갈 수 있는 모든 방법을 분석하여 눈을 떼어낼 수 있도록 하는 것입니다. 쿼리 매개 변수는 매개 변수를 게시할 수 있는 것처럼 공격을 수행할 수 있습니다. 응용 프로그램 전체의 데이터 흐름을 따르고 외부에서 온 데이터를 신뢰하지 않습니다.

국경 순찰처럼 생각. 모든 데이터를 중지하고 검사하며 악의적인 것으로 보이는 경우 허용하지 않습니다. 그런 다음 렌더링 할 때 인코딩하여 놓친 나쁜 물건이 여전히 문제가 발생하지 않도록합니다.

이러한 전략을 실행하고 사용자는 XSS를 통한 공격으로부터 안전합니다. OWASP 치트 시트를 살펴보고 데이터를 제어할 수 있는 더 많은 팁을 확인하십시오.

XSS를 저지하고 보안 기술을 레벨업하십시오.

XSS는 OWASP 상위 10 2017 웹 보안 위험 목록에서 7위에 있습니다. 그것은 잠시 동안 주변 되었습니다., 하지만 그것은 여전히 표시 하 고 조심 하지 않은 경우 응용 프로그램에 문제를 일으킬 수 있습니다.

교육은 개발자가 코드를 만들 때 보안 우선 사고 방식을 구축하는 데 매우 중요합니다. 또한 개발자가 적극적으로 사용하는 언어에서 실제 응용 프로그램을 시뮬레이션할 때 해당 교육이 항상 가장 효과적입니다. 이를 염두에 두고 학습 리소스를 확인하여 XSS에 대해 자세히 알아보세요. 그 후, 당신은 당신의 숙달로 이어지는 훈련과 연습을 시작할 수 있습니다.

지금 XSS 취약점을 찾고 수정할 준비가 되었다고 생각하십니까? 자신에게 도전하기 에 Secure Code Warrior 플랫폼.

리소스 보기
리소스 보기

저자

야프 카란 싱

더 알고 싶으신가요?

블로그에서 최신 보안 코딩 인사이트에 대해 자세히 알아보세요.

Atlassian의 광범위한 리소스 라이브러리는 안전한 코딩 숙련도를 확보하기 위한 인적 접근 방식을 강화하는 것을 목표로 합니다.

블로그 보기
더 알고 싶으신가요?

개발자 중심 보안에 대한 최신 연구 보기

광범위한 리소스 라이브러리에는 개발자 중심의 보안 코딩을 시작하는 데 도움이 되는 백서부터 웨비나까지 유용한 리소스가 가득합니다. 지금 살펴보세요.

리소스 허브

코더는 보안을 정복 : 공유 및 학습 - 교차 사이트 스크립팅

게시일: 2018.12.06.
Jaap Karan Singh

웹 브라우저는 온라인에서 모든 훌륭한 것들에 대한 우리의 관문일 수 있지만 슬프게도 모든 좋은 소식은 아닙니다. 웹 브라우저의 고유한 동작은 보안 취약점의 촉매제가 될 수 있습니다. 브라우저는 특성적으로 본 마크업을 신뢰하고 의심의 여지없이 실행하여 시작되었습니다. 그 기능이 불미스러운 목적을 위해 악용 될 때까지 모든 벌금과 dandy입니다 ... 그리고 당연히, 공격자는 결국 자신의 악한 끝을 더하기 위해이 경향을 악용 할 수있는 방법을 발견했다.

사이트 간 스크립팅(XSS)은 브라우저의 신뢰와 사용자의 무지를 사용하여 데이터를 도용하고, 계정을 인수하고, 웹 사이트를 훼손합니다. 그것은 매우 추한 얻을 수있는 취약점, 매우 빠르게.

XSS의 작동 방식, 어떤 피해를 줄 수 있는지, 이를 방지하는 방법을 살펴보겠습니다.

XSS는 어떻게 작동합니까?

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

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

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

이 기능은 우리가 웹에서 즐길 수있는 가장 멋진, 대화 형 경험의 일부를 주도하고있다. 동전의 다른 측면은 또한 비용이 많이 드는 악용과 취약점을 주도했다는 것입니다.

공격자가 악의적인 스크립트를 취약한 사이트에 추가하면 의심할 여지 없이 실행됩니다. 더 깊은 조사나 탐지 조치가 없습니다.

사용자 정의 자바 스크립트 코드는 사용자의 브라우저에서 실행될 수 있습니다.

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

  • 저장된 XSS
  • 반사된 XSS
  • DOM XSS

저장된 XSS는 공격자가 응용 프로그램의 데이터 필드(예: 사용자의 휴대폰 번호를 저장하는 필드)에 악성 스크립트를 지속적으로 저장할 수 있는 경우에 발생합니다. 그런 다음 이 스케치 스크립트는 데이터 필드가 응용 프로그램에 표시될 때마다 사용자의 브라우저로 전송됩니다.

이러한 유형의 공격은 포럼 사이트 또는 댓글 엔진에서 자주 볼 수 있습니다. 공격자는 댓글에 악의적인 스크립트를 입력하고, 밤 - 무의식적으로 스크립트를 실행하는 댓글을 보는 모든 사용자.

반사된 XSS는 사용자 입력이 사용자의 브라우저에 있는 것처럼 다시 반영될 때 발생합니다. 예를 들어 "검색한..." 검색 상자가 표시됩니다. 검색 결과를 가져오는 동안 사용자에게.

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

피해자는 링크를 클릭하고 피싱 사이트로 리디렉션되어 무의식적으로 사이트에 대한 암호를 입력합니다. 그들은 거의 그들이 실현, 공격자는 단지 자신의 계정에 키를 도난했다.

DOM XSS는 이 취약점의 비교적 새로운 다양성입니다. 각도 및 반응과 같은 많은 UI 프레임워크에서 발견되는 복잡한 템플릿 구조를 활용합니다.

이러한 템플릿을 사용하면 동적 콘텐츠와 풍부한 UI 응용 프로그램을 사용할 수 있습니다. 잘못 사용하면 XSS 공격을 실행하는 데 사용할 수 있습니다.

그래서, 거기 당신은 그것을 가지고있다. 당신은 간단히 XSS의 범위를 가지고있다. 그것은 파괴적으로 사용할 수있는 방법에 더 깊이 다이빙하자.

XSS가 왜 그렇게 위험합니까?

XSS는 사용자를 악의적인 사이트로 리디렉션하고 쿠키를 훔치고 세션 데이터를 추적하는 데 사용할 수 있습니다. 기본적으로 JavaScript가 할 수 있는 모든 작업을 수행할 수 있는 XSS 공격도 가능합니다.

다음은 XSS 공격의 세 가지 예입니다.

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

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

그러나 XSS는 당신처럼 정통한 보안 전사에 의해 패배 할 수 있습니다. 수정은 복잡하지 않으며 XSS가 일반적으로 사용되는 악용이된 이후 업계는 길고 먼 길을 왔습니다.

XSS를 물리칠 수 있습니다.

XSS를 물리 치기 위한 핵심은 맥락을 이해하는 것입니다. 특히 사용자 입력이 클라이언트로 다시 렌더링되고 클라이언트가 다시 렌더링되는 컨텍스트입니다. HTML 코드 내부 또는 JavaScript 스니펫 내부입니다.

사용자 입력을 브라우저로 다시 보낼 필요가 없는 경우 훨씬 더 좋습니다. 그러나 이 경우 HTML 인코딩되는 경우가 많습니다. 출력을 인코딩하는 HTML은 브라우저에 콘텐츠를 있는 것으로 렌더링하고 실행하지 말라고 지시합니다.

입력 유효성 검사도 중요합니다. 그러나 유효성 검사 및 화이트리스트는 완벽한 솔루션이 아닙니다. 인코딩은 몇 단계 더 나아가 브라우저가 악의적인 스크립트를 실행하지 못하도록 합니다. 유효성 검사 및 화이트리스트 전략에 걸리지 않는 것이 무엇이든 인코딩이 선택됩니다.

이제 많은 프레임워크가 HTML 출력을 자동으로 인코딩하고 있습니다.
각도, ASP.NET MVCReact.js 기본 HTML 인코딩이 사용되는 프레임워크입니다. 이러한 프레임워크는 특수 메서드를 호출하여 인코딩하지 않도록 특별히 말해야 합니다.

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

가장 큰 과제는 사용자 입력이 시스템에 들어갈 수 있는 모든 방법을 분석하여 눈을 떼어낼 수 있도록 하는 것입니다. 쿼리 매개 변수는 매개 변수를 게시할 수 있는 것처럼 공격을 수행할 수 있습니다. 응용 프로그램 전체의 데이터 흐름을 따르고 외부에서 온 데이터를 신뢰하지 않습니다.

국경 순찰처럼 생각. 모든 데이터를 중지하고 검사하며 악의적인 것으로 보이는 경우 허용하지 않습니다. 그런 다음 렌더링 할 때 인코딩하여 놓친 나쁜 물건이 여전히 문제가 발생하지 않도록합니다.

이러한 전략을 실행하고 사용자는 XSS를 통한 공격으로부터 안전합니다. OWASP 치트 시트를 살펴보고 데이터를 제어할 수 있는 더 많은 팁을 확인하십시오.

XSS를 저지하고 보안 기술을 레벨업하십시오.

XSS는 OWASP 상위 10 2017 웹 보안 위험 목록에서 7위에 있습니다. 그것은 잠시 동안 주변 되었습니다., 하지만 그것은 여전히 표시 하 고 조심 하지 않은 경우 응용 프로그램에 문제를 일으킬 수 있습니다.

교육은 개발자가 코드를 만들 때 보안 우선 사고 방식을 구축하는 데 매우 중요합니다. 또한 개발자가 적극적으로 사용하는 언어에서 실제 응용 프로그램을 시뮬레이션할 때 해당 교육이 항상 가장 효과적입니다. 이를 염두에 두고 학습 리소스를 확인하여 XSS에 대해 자세히 알아보세요. 그 후, 당신은 당신의 숙달로 이어지는 훈련과 연습을 시작할 수 있습니다.

지금 XSS 취약점을 찾고 수정할 준비가 되었다고 생각하십니까? 자신에게 도전하기 에 Secure Code Warrior 플랫폼.

우리는 당신에게 우리의 제품 및 / 또는 관련 보안 코딩 주제에 대한 정보를 보낼 수있는 귀하의 허가를 바랍니다. 우리는 항상 최대한의주의를 기울여 귀하의 개인 정보를 취급 할 것이며 마케팅 목적으로 다른 회사에 판매하지 않을 것입니다.

양식을 제출하려면 '분석' 쿠키를 활성화하세요. 완료되면 언제든지 다시 비활성화할 수 있습니다.