머리말
프론트 엔드 및 백엔드 분리의 개발 모델에서 개발 역할과 기능 측면에서 가장 명백한 변화는 다음과 같습니다. 과거에는 서버 엔드 레벨을 탐색하고 서버 엔드 코드를 작성하는 데 필요한 브라우저 환경에서만 개발을 담당 한 프론트 엔드 학생들입니다. 그리고 우리 앞에있는 기본적인 질문은 웹 보안을 보장하는 방법입니까?
이 기사는 프론트 엔드의 웹 개발에서 프론트 엔드 및 백엔드 분리 모드에서 발생하는 보안 문제에 대한 솔루션과 대응 및 예방 조치를 제안합니다.
크로스 사이트 스크립팅 공격 방어 (XSS)
문제와 솔루션
크로스 사이트 스크립팅 (XSS, 크로스 사이트 스크립팅)은 웹 사이트를 공격하는 가장 일반적이고 기본적인 방법입니다. 공격자는 웹 페이지에 불쾌한 코드가 포함 된 데이터를 게시 할 수 있습니다. 브라우저 가이 웹 페이지를 볼 때 특정 스크립트는 브라우저 사용자의 신원 및 권한으로 실행됩니다. XSS는보다 쉽게 수정하고 사용자 데이터 도용, 사용자 정보를 제공하고 CSRF 공격과 같은 다른 유형의 공격을 유발할 수 있습니다.
XSS 공격을 방지하는 기본 방법은 HTML 페이지에 대한 데이터 출력이 HTML (HTML Escape)에서 탈출되도록하는 것입니다. 예를 들어, 다음 템플릿 코드는 다음과 같습니다.
코드 사본은 다음과 같습니다.
<textArea name = "description"> $ description </textRea>
이 코드의 $ 설명은 템플릿의 변수입니다 (다른 템플릿에 정의 된 변수의 구문은 다릅니다. 여기에는 다이어그램이 있습니다). 사용자가 제출 한 데이터는 위의 템플릿 문의 결과를 다음과 같은 결과가되도록 "JavaScript"가 포함 된 코드를 입력 할 수 있습니다.
코드 사본은 다음과 같습니다.
<textarea name = "description">
</textarea> <cript> Alert ( 'hello') '</script>
</textarea>
브라우저에서 렌더링 된 위의 코드는 JavaScript 코드를 실행하고 화면에서 hello를 알립니다. 물론이 코드는 무해하지만 공격자는 사용자 정보를 수정하거나 쿠키 데이터를 훔치기 위해 JavaScript를 만들 수 있습니다.
솔루션은 매우 간단하며 HTML이 $ 설명의 값을 탈출하는 것입니다. 탈출 후 출력 코드는 다음과 같습니다
코드 사본은 다음과 같습니다.
<textarea name = "description">
</textarea> <cript> Alert (Hello!) </script>
</textarea>
위의 탈출 된 HTML 코드는 유해하지 않습니다.
미드웨이의 해결책
페이지에서 모든 사용자 출력 데이터를 피하십시오
데이터를 피하는 몇 가지 상황과 방법이 있습니다.
1. 템플릿 내부에 제공된 메커니즘을 사용하여 탈출하십시오
Midway는 Kissy xtemplate를 템플릿 언어로 사용합니다.
Xtemplate 구현에서 템플릿 데이터는 두 개의 괄호 ({{val}})를 사용하여 구문 분석 구문입니다. 기본적으로 데이터는 HTML 이스케이프이므로 개발자는 다음과 같은 템플릿을 작성할 수 있습니다.
코드 사본은 다음과 같습니다.
<textArea name = "description"> {{description}} </textArea>
XTEMPLATE에서 출력 데이터가 탈출되지 않으려면 3 개의 브래킷 ({{{val}})을 사용해야합니다.
2. 미드웨이에서 Escape 기능을 모호하게 호출하십시오
개발자는 Node.js 프로그램 또는 템플릿에서 Midway에서 제공하는 HTML 탈출 방법을 직접 호출하여 다음과 같이 표시된 데이터를 피할 수 있습니다.
방법 1 : node.js 프로그램의 HTML 탈출 데이터
코드 사본은 다음과 같습니다.
var Security = 요구 사항 ( '중간 보안');
// 서버의 데이터, 예를 들어 {html : '</textarea>', 기타 : ""}
data.html = security.escapehtml (data.html);
xtpl = xtpl.render (데이터);
방법 2 : 템플릿에서 HTML 탈출 HTML 데이터
코드 사본은 다음과 같습니다.
<textRea name = "description"> security.escapehtml ({{{{description}}}) </textRea>
참고 : Security.escapehtml은 템플릿 내부에서 데이터를 피할 때만 탈출하는 데 사용됩니다. 그렇지 않으면 내부 및 프로그램이 오버레이를 두 번 탈출하여 기대치를 충족시키지 못하는 출력이 발생합니다.
권장 : xtemplate을 사용하는 경우 템플릿의 내장 {{}}을 사용하여 직접 탈출하는 것이 좋습니다. 다른 템플릿을 사용하는 경우 보안을 사용하는 것이 좋습니다.
페이지의 사용자로부터 풍부한 텍스트 출력을 필터링합니다
"실제로, 나는 일부 메시지 보드 및 포럼과 같은 풍부한 텍스트를 출력하여 사용자에게 간단한 글꼴 크기, 색상, 배경 및 기타 기능을 제공하기 위해 XSS를 방지하기 위해 이러한 풍부한 텍스트를 어떻게 처리해야합니까?"
1. 미드웨이에서 보안이 제공하는 RichText 함수 사용
Midway는 풍부한 텍스트 방법을 제공하며, 이는 풍부한 텍스트를 필터링하고 XSS, 피싱 및 쿠키 도난과 같은 취약점을 방지하는 데 특별히 사용됩니다.
메시지 보드가 있으며 템플릿 코드는 다음과 같습니다.
코드 사본은 다음과 같습니다.
<div>
{{{메시지}}}
</div>
메시지는 사용자의 입력 데이터이므로 게시판의 내용에는 풍부한 텍스트 정보가 포함되어 있으며 여기에는 xtemplate에 3 개의 버팀대가 사용되며 HTML 이스케이프는 기본적으로 수행되지 않습니다. 그런 다음 사용자가 입력 한 데이터는 다음과 같습니다.
코드 사본은 다음과 같습니다.
<script src = "http://eval.com/eval.js"> </script> <span style = "color : red; font-size : 20px; 위치 : 고정;"> 나는 메시지를 남기고 있습니다 </span>
위의 리치 텍스트 데이터가 페이지에 직접 출력되면 필연적으로 Eval.com 사이트에서 현재 페이지로 JS를 주입하여 XSS 공격이 발생합니다. 이 취약점을 방지하기 위해 템플릿 또는 프로그램의 리치 텍스트 메소드를 호출하여 사용자의 리치 텍스트 입력을 처리합니다.
호출 방법은 EscapeHtml과 유사하며 두 가지 방법이 있습니다.
방법 1 : node.js 프로그램에서 직접 호출하십시오
코드 사본은 다음과 같습니다.
message = security.richtext (메시지);
var html = xtpl.render (메시지)
방법 2 : 템플릿에서 호출하십시오
코드 사본은 다음과 같습니다.
<div>
security.richtext ({{{usmess}}})
</div>
RichText 보안 메소드를 호출 한 후 최종 출력은 다음과 같습니다.
코드 사본은 다음과 같습니다.
<div>
<span style = "color : 빨간색; font-size : 20px;"> 나는 메시지를 남기고 있습니다 </span>
</div>
먼저 XSS 공격을 유발하는 스크립트 태그가 직접 걸러옵니다. 동시에 CSS 속성 위치 : 고정; 스타일 태그의 스타일도 필터링됩니다. 마지막으로, 무해한 HTML 리치 텍스트는 출력입니다
잠재적으로 XSS 공격으로 이어질 수있는 다른 방법에 대해 알아보십시오.
페이지 템플릿에서 가능한 XSS 공격 외에도 웹 애플리케이션에는 위험 할 수있는 몇 가지 다른 방법이 있습니다.
1. 오류 페이지의 취약성
페이지를 찾을 수없는 경우 시스템은 404를 찾을 수없는 오류를보고 할 수 있습니다 (예 : http : // localhost/page/not/find
404 NOTFOUND
Page/Page/Not/Found는 퇴장하지 않습니다
분명히 : 공격자는이 페이지를 사용하여 이와 같은 연결을 구성 할 수 있습니다. http : // localhost/%3cscript%3 ealert%28%27hello%27%29%3c%2fscript%3e를 클릭하도록 유혹합니다. 오류 페이지가 출력 변수를 벗어나지 않으면 <Script> Alert ( 'Hello') </script> 연결 중에 숨겨져 있습니다.
Express에서는 404 페이지를 보내는 방법은 다음과 같습니다.
res.send (404, '죄송합니다, 우리는 그것을 찾지 못합니다!')
여기서 개발자는 오류 페이지 (404 또는 기타 오류 상태)의 처리에주의를 기울여야합니다. 오류 메시지의 반환 내용에 PATH 정보가 포함 된 경우 (실제로 더 정확하기 위해 사용자 입력 정보) EscapeHTML을 수행해야합니다.
그 후, 오류 처리의 보안 메커니즘은 중간 프레임 워크 수준에서 완료됩니다.
미드웨이 솔루션에 대한 추가 메모
다른 템플릿 엔진
Midway는 기본적으로 Xtemplate 템플릿을 지원하지만 앞으로 Jade, Mustache, EJ 등과 같은 다른 템플릿을 지원할 수도 있습니다. 현재 주류 템플릿에서는 기본값이 탈출 및 에스케이프 출력 변수 쓰기 방법이 제공되며 개발자는 보안에 특별한주의를 기울여야합니다.
탈출에 대한 다른 지원
페이지의 일반적이고 풍부한 텍스트 데이터 출력 외에도 일부 시나리오에는 탈출이 필요한 다른 상황도 포함됩니다. Midway는 개발자가 사용할 수있는 다음으로 사용되는 이스케이프 방법을 제공합니다.
EscapeHtml은 XSS 취약점을 방지하기 위해 지정된 HTML의 문자를 필터링합니다.
jsencode 입력 문자열의 JavaScript 탈출. 중국의 유니 코드 탈출, 단일 따옴표 및 이중 인용문 탈출
EscapeJson은 JSON 구조의 탈출 기능을 파괴하지 않으며 JSON 구조에서 이름과 Vaule에서 EscapeHtml 처리 만 수행합니다.
EscapeJsonforjSvar는 당연히 jsencode+EscapeJson입니다
예는 다음과 같습니다
코드 사본은 다음과 같습니다.
var jsontext = "{/"<cript>/":/"<cript>/"}";
console.log (SecurityUtil.escapejson (jsontext)); // { "<cript>": "<cript>"}
var jsontext = "{/"hello/":/"<cript>/"}";
console.log (security.escapejsonforjsvar (jsontext)); // {/"/u4f60/u597d/":/"<cript>/"}
var str = "alert (/"hello/")";
console.log (securityUtil.jsencode (str)); // alert (/"/u4f60/u597d/")
CSRF (Cross-Site Reques) 예방 (CSRF)
문제와 솔루션
용어의 정의 : 양식 : 일반적으로 브라우저가 클라이언트에 대한 데이터를 제출하기 위해 사용하는 양식을 나타냅니다. 태그, Ajax 제출 데이터, 양식 제출 데이터 등을 포함하여 HTML과 같은 양식 태그가 아닌 양식 제출 데이터 등을 포함합니다.
크로스 사이트 요청 위조 (CSRF, 크로스 사이트 요청 위조)는 또 다른 일반적인 공격입니다. 공격자는 다양한 방법을 통해 요청을 위조하고 양식을 제출하는 사용자의 동작을 모방하여 사용자의 데이터를 수정하거나 특정 작업을 수행하는 목적을 달성했습니다.
사용자 인 척하기 위해 CSRF 공격은 종종 XSS 공격과 결합되지만 다른 수단은 사용될 수 있습니다. 예를 들어 사용자가 공격이 포함 된 링크를 클릭하도록 유도합니다.
CSRF 공격을 해결한다는 아이디어는 두 단계로 나뉩니다.
1. 공격의 어려움을 증가시킵니다. 요청을 쉽게 만들 수 있습니다. 사용자는 링크를 클릭하여 Get-Type 요청을 시작할 수 있습니다. 사후 요청은 비교적 어렵습니다. 공격자는 종종 JavaScript를 사용하여 구현해야합니다. 따라서 양식 또는 서버 인터페이스가 유형 포스트 유형 제출 요청 만 허용하는 경우 시스템의 보안을 증가시킬 수 있습니다.
2. 요청이 실제로 양식을 작성하거나 제 3자가 위조하지 않고 요청을 시작하고 사용자가 제출한지 확인하기위한 요청을 인증합니다.
정상적인 사용자 수정 웹 사이트 정보의 프로세스는 다음과 같습니다.
사용자 요청 정보 수정 (1) -> 웹 사이트는 사용자의 수정 된 정보 양식을 표시합니다 (2) -> 사용자는 정보를 수정하고 (3) -> 웹 사이트는 사용자의 수정 된 데이터를 수락하고 (4) 저장합니다.
CSRF 공격은이 경로를 취하지 않지만 2 단계에서 사용자 제출 정보를 직접 위조합니다.
2 (1) -> 수정할 정보를 위조하고 (2) -> 웹 사이트는 공격자가 매개 변수 데이터를 수정하고 (3) 저장하도록 허용합니다.
이 두 상황을 구별 할 수있는 한 CSRF 공격을 방지 할 수 있습니다. 그래서 그것을 구별하는 방법? 데이터가 1 단계의 양식에서 비롯된지 확인하기 위해 2 단계에 제출 된 정보를 확인하는 것입니다. 특정 검증 프로세스는 다음과 같습니다.
사용자 요청 정보 수정 (1) -> 웹 사이트에는 정보를 수정하는 데 사용되는 빈 양식이 표시됩니다. 이 양식에는 특수 토큰이 포함되어 있으며 세션 (2) -> 사용자는 정보를 수정하고 정보를 수정하고이를 제출하고 서버 (3) -> 웹 사이트를 비교하여 세션에서 웹 사이트를 비교합니다. 일관성이 있어야합니다. 그런 다음 사용자가 수정 한 데이터가 허용되고 저장됩니다.
이런 식으로, 공격자가 정보를 수정하고 제출하도록 위조 한 경우, 그는 세션에 직접 액세스 할 수 없으므로 실제 토큰 값을 얻지 못할 것입니다. 요청이 서버로 전송 된 경우 서버가 토큰 검증을 수행했을 때 일관성이없고 요청이 직접 거부되는 것으로 나타났습니다.
미드웨이 솔루션
제출 양식을 비활성화합니다
서버가 GET가 제출 한 양식 데이터를 수락하지 않으면 공격자에게 큰 어려움이 생길 것입니다. 요청을 구성하기 위해 페이지에 a-label href 속성 또는 IMG-Label SRC 속성을 구성하는 것이 매우 쉽기 때문에 제출하려면 스크립트를 사용하여 구현해야합니다.
CSRF 토큰으로 요청을 확인하십시오
Midway에는 Taobao의 분산 세션 및 토큰 검증의 논리가 포함되지 않기 때문에 Midway Framework에서는 서버와 클라이언트간에 토큰 만 전달되며 실제 검증 작업을 수행하지 않습니다. 프로세스는 다음과 같습니다.
그 후 : Midway에서 Node.js와 Taobao의 분산 세션이 연결된 후 중간 계층에서 자동으로 토큰 검증을 고려할 수 있습니다. 결국 보안 검증이 일찍 수행 될수록 비용이 낮습니다.
제안 : 미드웨이에서는 요청에 토큰 값이 있는지 확인할 수 있습니다. 수정 작업에 수정 작업에 토큰이없는 경우 중간 계층에서 직접 고려하여 안전하지 않다고 생각하고 요청을 버릴 수 있습니다.
다른 보안 문제
몇 가지 일반적인 웹 보안 문제가 있습니다. 다음은 몇 가지 소개 만 있으며 앞으로 미드웨이 프레임 워크에 계속 상속 될 것입니다.
HTTP 헤더 보안
CRLF 주입 공격자는 응답 헤더에 두 개의 CRLF 특수 문자를 주입하는 방법을 찾아 탁월한 응답 데이터 형식을 만들어 스크립트 등을 주입합니다.
쿠키가 기본적으로 가져오고 서버는 일반적으로 쿠키의 크기를 제한하기 때문에 모든 요청이 거부됩니다. 이는 사용자 클라이언트 쿠키가 특정 임계 값을 초과하도록 설정된 경우 더 이상 웹 사이트에 액세스 할 수 없습니다.
쿠키 예방 및 제어, 일반 쿠키 도난은 JavaScript (XSS 취약성)를 통해 얻을 수 있으므로 쿠키를 HTTP로만 설정하고 쿠키 만료 시간을 추가하십시오.
쿠키의 보안 문제와 관련하여 Webx는 이미 좋은 솔루션을 가지고있었습니다. 이번에는 Midway는 쿠키의 설정 및 검증에 대한 책임이 없으며 확인을 위해 WebX 레벨로 전달할 책임이 있습니다.
node.js 정보
XSS와 같은 주사적 취약점은 모든 취약점 중에서 가장 쉽게 무시되며 전체 인터넷 공격의 70% 이상을 차지합니다. Node.js 코드를 작성할 때 개발자는 항상 자신을 상기시키고 사용자의 입력을 신뢰하지 않아야합니다.
예를 들어 다음 예제입니다.
var mod = fs.readfilesync ( 'path'); 경로가 사용자 입력에서 나오면 사용자가 /etc /password를 입력한다고 가정하면 읽지 말아야 할 컨텐츠를 읽으므로 암호 누출 위험이 발생합니다.
var result = eval (jsonval); jsonval이 사용자 입력이 아닌 JSON인지 확인하십시오.
... 사용자 입력을 포함 할 수있는 다른 장소에서는 사용자의 입력이 우리가 기대하는 값인지 확인하십시오.
요약
프론트 엔드 및 백엔드의 분리 모드에서 전통적인 프론트 엔드 개발자는 백엔드 코드를 작성하기 시작할 수 있습니다. 아키텍처는 템플릿 레이어에만 책임이 있지만 많은 양의 백엔드 코드에도 노출됩니다. 따라서 보안은 프론트 엔드에게 큰 도전입니다.