프런트 엔드 개발의 일반적인 보안 문제 소개

자주 묻는 질문 소개:

(학습 영상 공유: 프로그래밍 영상)

1. 크로스 사이트 스크립팅 공격(XSS 공격)

XSS(Cross Site Scripting), 크로스 사이트 스크립팅 공격. XSS는 일반적인 웹 공격 기술 중 하나입니다. 소위 크로스 사이트 스크립팅 공격은 다음과 같습니다. 악의적인 공격자가 웹 페이지에 악성 스크립트 코드를 삽입하면 악성 코드가 실행됩니다. 쿠키 정보 탈취, 세션 하이재킹 등 다양한 공격을 합니다.

해결 방법:

(1) 입력 필터링. 사용자 입력을 절대 신뢰하지 말고 사용자가 입력한 데이터에 대해 특정 필터링을 수행하십시오. 예를 들어 입력된 데이터가 날짜 형식, 이메일 형식, 전화번호

코드 형식 등과 같은 예상 형식을 준수하는지 여부입니다. 이는 XSS 취약점에 대한 예비 방어를 제공할 수 있습니다. 위의 조치는 웹 측만 제한합니다. 공격자는 여전히 Fiddler와 같은 패킷 캡처 도구를 사용하여 프런트엔드 입력 제한을 우회하고 공격 스크립트를 삽입하도록 요청을 수정할 수 있습니다.

따라서 백엔드 서버는 사용자가 입력한 데이터를 받은 후 특수 위험 문자를 필터링하거나 이스케이프하여 데이터베이스에 저장해야 합니다. (2) 출력 인코딩. 서버에서 브라우저로 출력되는 데이터는 XSS 공격을 방지하기 위해 시스템의 보안 기능을 사용하여 인코딩되거나 이스케이프될 수 있습니다. PHP에는 보안 요구 사항을 충족할 수 있는 htmlentities() 및 htmlspecialchars()라는 두 가지 함수가 있습니다. 해당 JavaScript 인코딩 방법은 JavascriptEncode를 사용할 수 있습니다. (3) 보안 코딩. 개발에서는 웹 클라이언트 문서 재작성, 리디렉션 또는 기타 민감한 작업을 피하고 클라이언트 데이터 사용을 피해야 하며 이러한 작업은 가능한 한 동적 페이지를 사용하여 서버 측에서 구현되어야 합니다. (4) HttpOnly 쿠키. XSS 공격으로 인해 사용자 쿠키가 도용되는 것을 방지하는 가장 효과적인 방어 방법입니다. 웹 애플리케이션이 쿠키를 설정하면 해당 속성을 HttpOnly로 설정하면

클라이언트의 악성 JavaScript에 의해 웹 페이지의 쿠키가 도난당하는 것을 방지하고 사용자의 쿠키 정보를 보호할 수 있습니다. (5) WAF(웹 애플리케이션 방화벽), 웹 애플리케이션 방화벽의 주요 기능은 웹 트로이 목마,

XSS 및 CSRF와 같은 일반적인 웹 취약성 공격을 방지하는 것입니다. 타사에서 개발한 이 제품은 기업 환경에서 널리 사용됩니다.

2. 크로스 사이트 요청 위조(CSRF 공격)

CSRF(Cross Site Request Forgery), 즉 크로스 사이트 요청 위조는 일반적인 웹 공격이지만 많은 개발자가 이에 대해 익숙하지 않습니다. CSRF는 웹 보안에서 가장 쉽게 간과되는 웹사이트 공격 유형이기도 합니다

CSRF 공격의 원리: CSRF 공격 프로세스의 피해자 사용자는 웹사이트 A에 로그인하여 개인 정보를 입력하고 서버에서 생성된 쿠키를 로컬에 저장합니다. 그런 다음 공격자가 웹사이트 A에서 구축한 악성 링크를 클릭하여 웹사이트

B로 이동하고, 웹사이트 B는 사용자 쿠키 정보를 전달하여 웹사이트 B를 방문합니다. 웹사이트 A가 사용자가 직접 방문한 것처럼 착각을 일으키게 하고, 일련의 작업을 수행하는 가장 일반적인 작업은 전송입니다.

해결책:

(1) 인증 코드. 애플리케이션과 사용자 간의 상호 작용 중에, 특히 계정 거래와 같은 핵심 단계에서 사용자는 최종 요청을 완료하기 위해 인증 코드를 입력해야 합니다. 일반적인 상황에서는 인증 코드만으로도

CSRF 공격을 억제할 수 있습니다. 그러나 인증 코드를 추가하면 사용자 경험이 줄어들며 웹사이트에서 모든 작업에 인증 코드를 추가할 수는 없습니다. 따라서 인증코드는 주요 업무 지점에 인증코드를 설정하기 위한 보조 수단으로만 사용될 수 있습니다. (2) 추천인 확인.

HTTP 리퍼러는 헤더의 일부입니다. 브라우저가 웹 서버에 요청을 보낼 때 일반적으로 리퍼러 정보를 가져와 서버에 링크된 페이지를 알려줍니다. 서버는 이를 사용하여 처리할 정보를 얻을 수 있습니다.

. CSRF 공격은 요청 소스를 확인하여 방어할 수 있습니다. 일반 요청의 리퍼러에는 특정 규칙이 있습니다. 예를 들어 양식 제출의 리퍼러는 해당 페이지에서 시작된 요청이어야 합니다. 따라서 http 헤더 리퍼러

의 값이 이 페이지인지 확인하면 CSRF 공격인지 판단할 수 있습니다. 그러나 https에서 http로 이동하는 등의 경우에는 보안상의 이유로 브라우저가 리퍼러를 보내지 않으며 서버에서 확인할 수 없습니다. 이 웹사이트와 동일한 도메인에 있는 다른 웹사이트에 XSS 취약점이 있는 경우 공격자는 다른 웹사이트에 악성 스크립트를 주입할 수 있으며, 동일한 도메인에 해당 URL을 입력하는 피해자도 공격을 받게 됩니다. 위의 이유로 인해 Referer Check는 CSRF

를 방어하는 주요 수단으로 완전히 신뢰할 수 없습니다. 하지만 Referer Check를 통해 CSRF 공격 발생 여부를 모니터링할 수 있습니다. (3) 안티 CSRF 토큰. 현재 상대적으로 완전한 솔루션은 Anti-CSRF-Token을 추가하는 것입니다. 즉, 요청을 보낼 때 무작위로 생성된 토큰을 HTTP 요청의 매개변수로 추가하고 서버에 인터셉터를 설정하여 토큰을 확인하는 것입니다. 서버는 브라우저의 현재 도메인 쿠키에 있는 토큰 값을 읽고 요청의 토큰

과 쿠키의 토큰 값이 존재하고 동일한지 확인한 후 합법적인 요청으로 간주합니다. 그렇지 않으면 해당 요청은 불법으로 간주되어 서비스가 거부됩니다. 이 방법은 사용자가 로그인하여

세션이나 쿠키에 배치된 후 토큰을 생성할 수 있습니다. 그런 다음 서버는 각 요청마다 세션이나 쿠키에서 토큰을 가져와 이를 비교합니다. 요청.토큰 비교. 토큰의 존재로 인해 공격자는 더 이상 구성할 수 없습니다

CSRF 공격을 구현하기 위한 전체 URL을 만듭니다. 그러나 여러 페이지의 공존 문제를 처리할 때 특정 페이지에서 토큰을 소비하면 다른 페이지의 양식은 여전히 ​​소비된 토큰을 저장하고 다른 페이지의 양식을 제출할 때 토큰 오류가 발생합니다.

3. SQL 인젝션 공격

SQL 인젝션(SQL 인젝션)은 애플리케이션이 SQL(Structured Query Language, 구조적 쿼리 언어)을 백엔드 데이터베이스로 전송할 때 공격자가 웹 양식에 SQL 명령을 삽입하여 제출하거나 입력합니다. 도메인 이름 또는 페이지 요청의 쿼리 문자열을 사용하여 궁극적으로 서버를 속여 악성 SQL 명령을 실행하도록 합니다.

해결책:

(1) 민감한 시스템 정보의 유출을 방지합니다. php.ini 옵션인 display_errors=off를 설정하면 php 스크립트에서 오류가 발생한 후 민감한 정보 오류가 웹 페이지에 출력되는 것을 방지하여 공격자에게 기회를 제공할 수 있습니다. (2) 데이터 탈출. php.ini 옵션인 Magic_quotes_gpc=on을 설정하면 제출된 변수 앞에 '(작은 따옴표), "(큰 따옴표), (백슬래시), 공백 문자 등이 모두 자동으로 추가됩니다. 또는 mysql_real_escape( ) 함수를 사용하거나 (3) 블랙리스트 또는 화이트리스트 확인 추가 블랙리스트 확인은 일반적으로 사용자 입력이 예상 유형, 길이, 값 범위 또는 기타 형식 표준을 충족하는지 확인하는 것을 의미합니다. 입력에 명백한 악성 콘텐츠가 포함되어 있으면 사용자 요청이 거부됩니다. 화이트리스트 확인을 사용하면 일반적으로 블랙리스트 확인과 결합됩니다.

4. 파일 업로드 취약점

업로드 취약점은 해커가 가장 많이 악용한 시대입니다. 업로드 취약점은 WEBSHELL을 직접 획득하는 데 사용될 수 있습니다. 업로드 취약점은 현재 침입에서 흔히 나타나는 취약점이며, 공격자가 위험 콘텐츠나 악성 코드를 주입할 수 있습니다. 파일 업로드 취약점의 원리: 파일 업로드 기능 구현 코드는 사용자가 업로드하는 파일 접미사 및 파일 형식을 엄격하게 제한하지 않기 때문에 공격자가 임의의 콘텐츠를 통해 액세스할 수 있는 디렉터리에 업로드할 수 있습니다. Web.PHP 파일을 저장하고 이러한 파일을 PHP 인터프리터에 전달할 수 있으면 원격 서버에서 모든 PHP 스크립트를 실행할 수 있습니다.

해결책:

(1) 서버가 업로드된 파일 형식과 접미사를 결정하는지 확인하세요(2). ) 정의. 업로드 파일 유형 화이트리스트, 즉 화이트리스트에 있는 유형의 파일만 업로드가 허용됩니다. (3) 파일 업로드 디렉토리는 공격자가 2차 공격을 수행하는 것을 방지하기 위해 스크립트 분석을 금지합니다. CGI는 입력 매개변수를 그대로 페이지에 출력하는데, 공격자는 입력 매개변수를 수정하여 사용자를 속입니다.

자세한 소개:

웹사이트 보안

위 내용은 프런트 엔드 개발의 일반적인 보안 문제 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!