XSS

우리는 언어가 아닌 프레임워크의 시대에 살고 있습니다. 이는 프로그래머가 보안을 포함한 개발의 여러 측면에 대해 덜 걱정할 수 있어야 한다는 것을 의미합니다. 현재 대부분의 백엔드 프레임워크는 보안 모듈을 구현하고 있으며, 외부 전문 기업 및 대기업에서 테스트하고 있습니다. 따라서 보안 인식 저하 특히 프리랜서인 경우 제품에 대한 책임감이 더 큰 젊은 프로그래머들 사이에서 두드러질 수 있습니다.

애플리케이션의 클라이언트 측에 대한 일반적인 공격 중 하나는 XSS(크로스 사이트 스크립팅)입니다. 실행 가능한 클라이언트 측 스크립트를 웹 애플리케이션에 삽입하여 수행되며[1], 구현된 HTML 렌더링 메서드 또는 자바스크립트 코드 평가자를 실행합니다. 세션 쿠키나 사용자 데이터 등 다양한 데이터를 수집할 수 있고 키로거와 같은 추적 애플리케이션을 설치할 수 있어 사용자와 비즈니스 소유자 모두에게 위험할 수 있는 XSS는 상대적으로 수익성이 높습니다. 때로는 다음과 같은 다른 형태의 공격이 수행되어 페이지에서 XSS를 허용하기도 합니다. SQL 주입.

예

페이지의 로그인 양식에서 로그인 이름 입력 시 로그인 이름 매개변수가 GET 요청 내에서 전송됩니다. 이 값은 애플리케이션의 서버나 클라이언트 측에서 처리되지 않습니다. 요청에 의해: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
코드가 실행되고 데이터가 노출됩니다.

다음은 XSS 공격 반영피해자에게 제출된 특수하게 준비된 URL 주소를 통해 스크립트가 주입되고 서버 응답에 반영되는 방식입니다. 다른 알려진 인기 있는 공격 형태는 다음과 같습니다:

• 저장된 XSS 일반적으로 애플리케이션에서 사용할 수 있는 양식에 의해 서버 측에 저장된 주입된 데이터로 수행됩니다. 클라이언트 애플리케이션은 예를 들어 데이터베이스에 저장된 코드를 렌더링합니다.
• DOM XSS 는 서버 측을 사용하지 않고 XSS 공격을 수행합니다. 이 글의 다음 부분에서는 이러한 형태의 공격에 대해 집중적으로 살펴보겠습니다.

React 및 Vue 라이브러리의 현재 취약점

현재 React/Vue 버전에서는 두 가지 주요 문제가 발견되었으나 아직 공식적으로 수정되지 않았습니다. 첫 번째 취약점은 모든 프레임워크에 동일한 특성을 가지며 템플릿 내에서 원시 HTML 렌더링을 허용하는 메서드와 관련이 있습니다: v-html 그리고 위험하게 설정된 내부 HTML, 에 대해 각각 Vue 및 React. 각 문서[2]에서는 현명하지 않은 사용으로 인해 사용자가 XSS 공격에 노출될 수 있음을 알려줍니다. 다른 옵션으로 문제를 해결할 수 없는 경우에는 데이터가 필터링됨 그리고 탈출. 이러한 방법은 위험하지만 고쳐질 것이라고 기대해서는 안 됩니다. 자신의 책임 하에 사용하세요.

2018년 1분기에 태그 요소의 속성을 설정하여 직접 코드를 실행할 수 있는 대형 버그가 React에서 발견되었습니다. 다음과 같이 속성 내에 예제 코드를 전달합니다. 자바스크립트:경고(1) 로 설정하고 렌더링된 링크를 실행하면 코드가 실행됩니다. 이 문제[4]는 아직 미해결 상태이며 수정 사항이 준비되어 병합되지 않았으므로 코드가 안전한지 확인하세요. 공식 토론에서 제안된 예시는 이 문제를 극복할 수 있는 몇 가지 방법을 제시합니다.

최신 버전으로 업데이트할 수 없는 경우에는 오래된 이슈가 코드에 노출되지 않도록 하여 문제를 일으키지 않도록 하세요:

• child 노드 주입 - React, 사용 React.createElement [5]
• 서버 측 렌더링 - React/Vue [6]
• CSS 삽입 [8]

여전히 자바스크립트에 관한 것입니다. 여전히 프런트엔드에 관한 것입니다.

프레임워크나 라이브러리 자체 외에도 언어로서의 자바스크립트에는 피하거나 주의해서 사용해야 하는 몇 가지 위험한 기능이 있다는 것을 잊지 마세요. 이러한 기능은 일반적으로 DOM 조작 또는 스크립트 실행과 관련이 있습니다. eval() 는 이러한 종류의 대표 함수를 나타내며, 주어진 문자열화된 코드를 직접 실행하기 때문에 매우 위험합니다[9]. 또한 이러한 함수를 찾을 때는 코드를 더 잘 살펴보세요:

• document.write
• document.writeln
• (element).innerHTML
• (요소).outerHTML
• (요소).insertAdjacentHTML

여기서 적절한 규칙이 설정된 린터를 사용하면 이러한 취약점을 찾는 데 도움이 될 수 있습니다. 또한 개발 코드의 보안 허점을 탐지하는 데 도움이 될 수 있는 공개 또는 상용 코드 분석기가 많이 있습니다.

어떤 라이브러리/프레임워크를 선택하든 프런트엔드 개발과 관련된 기본 원칙을 기억해야 합니다. 첫째, 삽입하는 외부 코드가 항상 신뢰할 수 있는 소스에서 제공되었는지 확인하세요. 감사 종속성을 잘 살펴보고 현명하게 선택하세요. 일부 종속성에는 심각한 취약점이 포함되어 있어 코드 자체에는 문제가 없더라도 코드가 노출될 수 있습니다. 종속성 보안에 대한 자세한 내용은 여기에서 확인할 수 있습니다:

https://thecodest.co/blog/security-in-javascript-packages/

그렇다면... 여전히 걱정해야 할까요?

예 - 그리고 보안 측면에서 외부 라이브러리나 사용자 자신을 절대 신뢰하지 말 것을 강력히 권장합니다. 소프트웨어가 아무리 안전하다고 생각하더라도 항상 일반적인 공격 형태[10]에 대해 가능한 한 많이 테스트하는 노력을 기울여야 합니다.

1. https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
2. https://vuejs.org/v2/guide/syntax.html#Raw-HTML
3. https://github.com/facebook/react/issues/12441
4. http://danlec.com/blog/xss-via-a-spoofed-react-element
5. https://medium.com/node-security/the-most-common-xss-vulnerability-in-react-js-applications-2bdffbcc1fa0
6. https://github.com/dotboris/vuejs-serverside-template-xss
7. https://frontarm.com/james-k-nelson/how-can-i-use-css-in-js-securely/
8. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#Do_not_ever_use_eval!

자세히 읽어보세요:

PHP에서 프로젝트를 유지 관리할 때 피해야 할 5가지 실수

PHP 개발. Symfony 콘솔 컴포넌트 - 팁과 요령

심포니 폴리필이 필요한 이유(... 그리고 필요하지 않은 이유)