JavaScript와 DOM은 악의적인 제작자가 웹을 통해 클라이언트 컴퓨터에서 실행되는 스크립트를 배포할 수 있는 가능성을 제공한다. 브라우저 제작자는 두 가지 제한을 통해 이러한 위험을 최소화한다. 첫째, 스크립트는 샌드박스 내에서 실행되며, 파일 생성과 같은 범용 프로그래밍 작업이 아닌 웹 관련 작업만 실행할 수 있다. 한 웹사이트의 스크립트는 다른 사이트로 전송된 사용자 이름, 비밀번호, 쿠키와 같은 정보에 접근할 수 없으며, 대부분의 자바스크립트 관련 보안 버그는 동일 출처 정책이나 샌드박스 위반이다.

일반적인 JavaScript의 하위 집합인 AdSafe, Secure ECMAScript(SES)는 특히 타사에서 만든 코드(광고 등)에 대해 더 높은 수준의 보안을 제공합니다 Closure Toolkit은, 타사 JavaScript와 HTML을 안전하게 임베딩하고 분리하기 위한 또 다른 프로젝트입니다.

콘텐츠 보안 정책(Content Security Policy)은 신뢰할 수 있는 코드만 웹 페이지에서 실행되도록 하는 주요 방법이다.

크로스 사이트 취약점

주요 기사 크로스 사이트 스크립팅, 크로스 사이트 요청 포제리 크로스 사이트 스크립팅 주요 기사 크로스 사이트 스크립팅 자바스크립트 관련 보안 문제 중 가장 흔한 것은 동일 소스 정책 위반인 크로스 사이트 스크립팅(XSS)이다. XSS 취약점은 공격자가 온라인 뱅킹 웹사이트와 같은 타깃 웹사이트에 악성 스크립트를 포함시킬 수 있는 경우 발생합니다. 이 예시의 스크립트는 피해자의 권한으로 뱅킹 애플리케이션에 접근할 수 있으며, 피해자의 승인 없이 기밀 정보를 공개하거나 송금할 수 있다. XSS 취약점에 대한 해결책은 신뢰할 수 없는 데이터를 표시할 때 항상 HTML 이스케이프를 사용하는 것이다. 사용하는 것입니다.

일부 브라우저는 공격자가 악성 스크립트가 포함된 URL을 제공하는 반사형 XSS 공격에 대한 부분적인 방어 기능을 제공한다. 그러나 이러한 브라우저를 사용하는 사용자도 악의적인 코드가 데이터베이스에 저장되는 것과 같은 다른 XSS 공격에는 취약하며, 서버 측에서 웹 애플리케이션을 올바르게 설계하는 것만이 XSS를 완전히 방지할 수 있다.

XSS 취약점은 브라우저 제작자의 구현 오류로 인해 발생하기도 한다.

크로스 사이트 요청 포제리

주요 기사 크로스 사이트 요청 포제리 또 다른 크로스 사이트 취약점은 CSRF(Cross-Site Request Forgery)다. CSRF는 공격자 사이트의 코드가 피해자의 브라우저를 속여 사용자가 의도하지 않은 행동(예: 은행 송금 등)을 하도록 유도하는 취약점이다. 공격 대상 사이트가 요청 인증을 위해 쿠키에만 의존하는 경우, 공격자 사이트의 코드에서 시작된 요청은 사용자가 시작한 것과 동일한 유효한 로그인 인증 정보를 전달할 수 있다. 일반적으로 CSRF에 대한 해결책은 쿠키뿐만 아니라 숨겨진 양식 필드에 인증 값을 요청하여 영구적인 영향을 미칠 수 있는 요청을 인증하는 것이며, HTTP Referrer 헤더를 확인하는 것도 도움이 될 수 있다.

'자바스크립트 하이재킹'은 CSRF 공격의 일종으로, 공격자 사이트의 <script> 태그가 JSON이나 자바스크립트와 같은 개인 정보를 반환하는 피해자 사이트의 페이지를 악용하는 공격이다. 가능한 해결책은 다음과 같습니다:

개인 정보를 반환하는 응답의 POST 또는 GET 파라미터에 인증 토큰을 요구한다.

클라이언트에 대한 잘못된 신뢰

클라이언트-서버 애플리케이션 개발자는 신뢰할 수 없는 클라이언트가 공격자의 통제 하에 있을 수 있다는 것을 인식해야 한다. 애플리케이션 작성자는 자바스크립트 코드가 의도한 대로(또는 전혀) 실행될 것이라고 가정할 수 없다. 몇 가지 의미가 있다:

원시 소스 코드가 클라이언트에 전송되어야 하기 때문에 웹 사이트 작성자는 JavaScript가 어떻게 작동하는지 완전히 숨길 수 없다. 코드를 난독화할 수는 있지만, 난독화는 리버스 엔지니어링이 가능하다. 자바스크립트 양식 유효성 검사는 사용자에게 편리함을 제공할 뿐, 보안이 아닙니다. 만약 사이트가 사용자가 이용약관에 동의했는지 여부를 확인하거나 숫자만 입력해야 하는 필드에서 유효하지 않은 문자를 제거하는 등의 작업을 수행하려면 클라이언트뿐만 아니라 서버에서도 수행해야 한다. 스크립트는 선택적으로 비활성화할 수 있기 때문에, 이미지 우클릭 후 저장과 같은 작업을 방지하기 위해 자바스크립트에 의존할 수 없다. 비밀번호와 같은 민감한 정보를 자바스크립트에 삽입하는 것은 공격자에게 유출될 수 있기 때문에 매우 나쁜 습관으로 간주된다. 개발자에 대한 잘못된 신뢰 npm이나 Bower와 같은 패키지 관리 시스템은 자바스크립트 개발자들에게 인기가 있다. 이러한 시스템을 통해 개발자는 다른 개발자의 프로그램 라이브러리에 대한 자신의 프로그램 의존성을 쉽게 관리할 수 있다. 개발자는 라이브러리 관리자가 라이브러리를 안전하고 최신 상태로 유지해 줄 것이라고 믿지만, 반드시 그렇지는 않다. 이러한 맹목적인 신뢰로 인해 취약점이 발생한다. 신뢰할 수 있는 라이브러리가 새로운 릴리스를 내놓으면 그 라이브러리에 의존하는 모든 프로그램에 버그나 취약점이 나타날 수 있다. 반대로, 알려진 취약점이 존재함에도 불구하고 라이브러리가 패치되지 않은 채 방치되는 경우도 있는데, 133,000개의 웹 사이트 샘플을 조사한 연구에 따르면 37%의 웹 사이트가 적어도 하나의 알려진 취약점이 있는 라이브러리를 포함하고 있는 것으로 나타났다. . 2016년 3월, 아제르 코술루(Azer Koçulu)가 npm에서 자신의 리포지토리를 삭제했을 때 발생했다. 이로 인해 그의 라이브러리에 의존하던 수만 개의 프로그램과 웹 사이트가 손상되었다.

브라우저 및 플러그인 코딩 오류

추가 정보 버퍼 오버플로 자바스크립트는 다양한 브라우저 기능에 대한 인터페이스를 제공하지만, 그 중 일부는 버퍼 오버플로와 같은 결함을 가지고 있다. 이러한 결함으로 인해 공격자는 사용자 시스템에서 원하는 코드를 실행하는 스크립트를 작성할 수 있다. 이 코드는 결코 다른 자바스크립트 애플리케이션에 국한되지 않는다. 예를 들어, 버퍼 오버런을 악용하면 공격자는 수퍼 유저 권한으로 운영체제의 API에 접근할 수 있다.

이러한 결함은 Firefox, Internet Explorer, Safari를 포함한 주요 브라우저에 영향을 미치고 있다.

비디오 플레이어, Adobe Flash, Microsoft Internet Explorer에서 기본적으로 활성화된 광범위한 ActiveX 컨트롤과 같은 플러그인에도 JavaScript를 통해 악용될 수 있는 결함이 있을 수 있다(이러한 결함은 과거에 악용된 적이 있다). 악용되고 있다).

윈도우 비스타에서 마이크로소프트는 인터넷 익스플로러의 프로세스를 제한된 권한으로 실행하여 버퍼 오버플로우와 같은 버그의 위험을 줄이려고 한다. 구글 크롬도 마찬가지로 페이지 렌더러를 자체 '샌드박스'에 가둬두고 있다.

샌드박스 구현 오류

웹 브라우저는 샌드박스 밖에서 자바스크립트를 실행할 수 있으며, 예를 들어 파일을 생성하거나 삭제하는 데 필요한 권한을 가지고 있다. 이러한 권한은 웹에서 온 코드에는 부여되지 않아야 한다.

윈도우 XP 서비스 팩 2에서 마이크로소프트는 인터넷 익스플로러의 JScript 권한을 낮췄다.

Microsoft Windows는 컴퓨터의 하드 드라이브에 있는 자바스크립트 소스 파일을 일반적이고 샌드박스화되지 않은 프로그램으로 실행할 수 있도록 허용하고 있다(참조: Windows Script Host). 따라서 자바스크립트는 (VBScript와 마찬가지로) 이론적으로 트로이 목마의 실행 가능한 벡터가 될 수 있지만, 자바스크립트 트로이 목마는 실제로는 드물다.

하드웨어 취약점

2015년, 자바스크립트 기반 로우해머 공격의 개념증명 구현이 보안 연구자들의 논문에 소개되었다.

2017년에는 ASLR을 우회할 수 있는 브라우저를 통한 자바스크립트 기반 공격이 시연됐다. 이를 'ASLR⊕Cache' 또는 AnC라고 부른다.

2018년, 인텔 및 기타 프로세서에서 투기적 실행에 대한 Spectre 공격을 발표한 논문에는 자바스크립트 구현이 포함되어 있다.