PHP 보안 문제 요약

                                                       

1-XSSoCross-Site Scripting(크로스 사이트 스크립트 공격)은 XSS라고도 하며 코드 주입 공격입니다. 공격자는 사용자의 브라우저에서 실행될 수 있도록 대상 웹사이트에 악성 스크립트를 삽입합니다. 공격자는 이러한 악성 스크립트를 사용하여 쿠키, SessionID 등과 같은 사용자의 민감한 정보를 획득하여 데이터 보안을 위험에 빠뜨릴 수 있습니다.

출처

사용자의 UGC 정보

• 제3자의 링크

• URL 매개변수

• POST 매개변수

• Referer(신뢰할 수 없는 출처에서 올 수 있음)

• 쿠키(5월 다른 하위 도메인에서 주입 가능)

• Escape, 필터, 길이 제한

2-SQL 주입SQL 문을 통해 계정 없이 로그인할 수 있으며 데이터베이스를 조작할 수도 있습니다.

공격 예시

String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";

--当输入了上面的用户名和密码，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’

"""
--分析SQL语句：
--条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功；

--然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。
--这还是比较温柔的，如果是执行
SELECT * FROM user_table WHERE
username='' ;DROP DATABASE (DB Name) --' and password=''
--其后果可想而知…

SQL 주입 방어 방법

　1. 변수 데이터 유형 및 형식 확인

　2. 특수 기호 필터링

　3. 변수 바인딩 및 미리 컴파일된 명령문 사용

3-CSRFCSRF는 일반적으로 Cross-Site Request Forgery를 의미합니다. CSRF 공격의 정식 명칭은 Cross-Site Request Forgery(크로스 사이트 요청 위조)로, 웹사이트를 악의적으로 이용하는 행위입니다

CSRF는 신뢰할 수 있는 사용자의 위장 요청을 통해 신뢰할 수 있는 웹사이트를 이용합니다. 공격자는 귀하의 신원을 도용하고 귀하를 대신하여 제3자 웹사이트에 악의적인 요청을 보냅니다. CRSF가 할 수 있는 작업에는 귀하의 신원을 사용하여 이메일, 문자 메시지를 보내고, 거래 이체 등을 수행하고, 심지어 귀하의 계정을 도용하는 것도 포함됩니다.

예:

다음과 같이 Web A는 CSRF 취약점이 있는 웹사이트이고, Web B는 공격자가 구축한 악성 웹사이트이며, 사용자 C는 Web A 웹사이트의 합법적인 사용자입니다

3-1 CSRF 공격 원리 및 프로세스는 다음과 같습니다. 1. 사용자 C는 브라우저를 열고 신뢰할 수 있는 웹사이트 A를 방문하고 사용자 이름과 비밀번호를 입력하여 웹사이트 A에 로그인을 요청합니다.

2. 웹사이트 A는 쿠키 정보를 생성하여 브라우저에 반환합니다. 이때 사용자는 웹사이트 A에 성공적으로 로그인하고 웹사이트 A에 정상적으로 요청을 보낼 수 있습니다.

3 사용자는 웹사이트 A를 종료하기 전에 다음 위치에서 TAB 페이지를 엽니다. 동일한 브라우저에서 웹사이트 B를 방문합니다.

4. 웹사이트 B가 사용자를 수신합니다. 요청 후 일부 공격적인 코드가 반환되고 제3자 사이트 A에 액세스하라는 요청이 이루어집니다. 브라우저는 웹사이트 B의 요청에 따라 이용자가 모르는 사이에 쿠키를 운반하며, 웹사이트 A에 요청합니다. 웹사이트 A는 해당 요청이 실제로 B에 의해 시작되었다는 사실을 알지 못하므로 사용자 C의 쿠키 정보를 기반으로 C의 권한으로 요청을 처리하여 웹사이트 B의 악성 코드가 실행됩니다.

3-2 CSRF 공격 방어

현재 CSRF 공격을 방어하기 위한 세 가지 주요 전략이 있습니다. HTTP 참조자 필드를 확인하고 요청 주소에 토큰을 추가하고 이를 확인합니다. 그것을 확인하십시오.

1-HTTP Referer 필드 확인

HTTP 프로토콜에 따르면 HTTP 헤더에는 HTTP 요청의 소스 주소를 기록하는 Referer라는 필드가 있습니다. 일반적인 상황에서는 보안이 제한된 페이지에 대한 액세스 요청이 동일한 웹사이트에서 이루어집니다. 예를 들어 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory에 액세스하려면 사용자가 먼저 로그인해야 합니다. Bank.example로 이동한 후 페이지의 버튼을 클릭하면 이체 이벤트가 실행됩니다. 이때 이체 요청의 Referer 값은 이체 버튼이 위치한 페이지의 URL이 되며, 일반적으로bank.example 도메인 이름으로 시작하는 주소입니다. 해커가 은행 웹사이트에 CSRF 공격을 구현하려는 경우 자신의 웹사이트에서만 요청을 구성할 수 있습니다. 사용자가 해커의 웹사이트를 통해 은행에 요청을 보내면 요청의 리퍼러는 해커의 웹사이트를 가리킵니다. . 따라서 CSRF 공격을 방어하기 위해 은행 웹사이트는 각 전송 요청에 대한 추천자 값만 확인하면 됩니다. 도메인 이름이bank.example로 시작하는 경우 해당 요청이 은행 웹사이트 자체에서 온 것이며 합법적임을 의미합니다. 추천자가 다른 웹사이트인 경우 해커에 의한 CSRF 공격일 수 있으며 요청이 거부됩니다.

이 방법의 분명한 이점은 구현이 간단하고 쉽다는 것입니다. 일반 웹 사이트 개발자는 마지막에 보안에 민감한 모든 요청에 ​​인터셉터를 추가하기만 하면 됩니다. 참조자 값. 특히 현재 기존 시스템의 경우 기존 시스템의 코드나 로직을 변경할 필요가 없고 위험도 없으며 매우 편리합니다.

그러나 이 방법이 완벽한 방법은 아닙니다. Referer의 값은 브라우저에서 제공됩니다. HTTP 프로토콜에는 명확한 요구 사항이 있지만 각 브라우저는 서로 다른 Referer 구현을 가질 수 있으며 이는 브라우저 자체에 보안 취약점이 없음을 보장하지 않습니다. Referer 값을 확인하는 방법은 보안을 보장하기 위해 제3자(즉, 브라우저)에 의존합니다. 이론적으로 이는 안전하지 않습니다. 실제로 IE6이나 FF2와 같은 일부 브라우저에는 이미 Referer 값을 조작할 수 있는 몇 가지 방법이 있습니다. Bank.example 웹사이트가 IE6 브라우저를 지원하는 경우 해커는 사용자 브라우저의 Referer 값을bank.example 도메인 이름으로 시작하는 주소로 설정하여 검증을 통과하고 CSRF 공격을 수행할 수 있습니다.

최신 브라우저를 사용하더라도 해커가 Referer 값을 조작할 수는 없지만 이 방법에는 여전히 문제가 있습니다. Referer 값은 사용자의 접속 소스를 기록하기 때문에 일부 사용자는 이것이 자신의 개인 정보를 침해할 것이라고 생각합니다. 특히 일부 조직에서는 Referer 값이 조직의 인트라넷에서 외부 네트워크로 특정 정보를 유출할 것이라고 우려합니다. 따라서 사용자는 요청을 보낼 때 더 이상 리퍼러를 제공하지 않도록 브라우저를 직접 설정할 수 있습니다. 은행 웹사이트를 정상적으로 방문하면 요청에 Referer 값이 없기 때문에 해당 웹사이트는 이를 CSRF 공격으로 간주하고 합법적인 사용자에 대한 액세스를 거부합니다.

2-요청 주소에 토큰 추가 및 검증

CSRF 공격이 성공할 수 있는 이유는 해커가 사용자의 요청을 완전히 위조할 수 있기 때문입니다. 해커 이러한 인증정보를 알지 못해도 사용자 자신의 쿠키를 이용하여 직접 보안인증을 통과할 수 있습니다. CSRF에 저항하는 핵심은 해커가 위조할 수 없고 해당 정보가 쿠키에 존재하지 않는 정보를 요청에 넣는 것입니다. 무작위로 생성된 토큰을 HTTP 요청에 매개변수로 추가하고, 서버 측에 인터셉터를 구축하여 요청에 토큰이 없거나 토큰 내용이 잘못된 경우 발생할 수 있다고 간주됩니다. CSRF 공격이 발생하면 요청이 거부됩니다.

이 방법은 사용자가 로그인하여 세션에 배치된 후 추천자를 확인하는 것보다 더 안전합니다. 그런 다음 토큰은 요청 시 세션에서 제거되고 요청의 토큰과 비교됩니다. 이 방법의 어려움은 매개변수 형식으로 요청에 토큰을 추가하는 방법입니다. GET 요청의 경우 토큰이 요청 주소에 추가되어 URL이 http://url?csrftoken=tokenvalue가 됩니다. POST 요청의 경우 토큰이 요청에 매개변수로 추가되도록 양식 끝에 추가하세요. 하지만 웹사이트에서는 요청을 받아들일 수 있는 곳이 많습니다. 각 요청에 토큰을 추가하는 것은 매우 번거롭고 놓치기 쉽습니다. 일반적으로 사용되는 방법은 페이지를 방문할 때마다 자바스크립트를 사용하는 것입니다. 전체 dom 트리의 경우 dom의 모든 a 및 form 태그 뒤에 토큰이 추가됩니다. 이는 대부분의 요청을 해결할 수 있지만 페이지가 로드된 후 동적으로 생성되는 html 코드의 경우 이 방법은 효과가 없으며 프로그래머가 코딩할 때 수동으로 토큰을 추가해야 합니다.

이 방법의 또 다른 단점은 토큰 자체의 보안을 보장하기 어렵다는 것입니다. 특히 사용자가 자신의 콘텐츠를 게시하도록 지원하는 일부 포럼 및 기타 웹사이트에서는 해커가 자신의 개인 웹사이트 주소를 게시할 수 있습니다. 시스템은 이 주소 뒤에 토큰도 추가하므로 해커는 자신의 웹사이트에서 이 토큰을 가져와 즉시 CSRF 공격을 시작할 수 있습니다. 이를 방지하기 위해 토큰 추가 시 시스템 판단을 추가할 수 있으며, 링크가 자체 웹사이트인 경우 나중에 토큰을 추가하면 외부 네트워크로 연결되지 않습니다. 그러나 csrftoken이 요청에 매개변수로 첨부되지 않은 경우에도 해커의 웹사이트는 CSRF 공격을 시작하기 위해 Referer를 통해 토큰 값을 얻을 수 있습니다. 이는 일부 사용자가 브라우저 리퍼러 기능을 수동으로 끄는 이유이기도 합니다.

3-HTTP 헤더의 속성을 사용자 지정하고 확인합니다.

이 방법도 토큰을 사용하여 확인합니다. 이전 방법과 달리 토큰은 매개 변수 형식으로 HTTP 요청에 배치됩니다. HTTP 헤더의 사용자 정의 속성에 있습니다. XMLHttpRequest 클래스를 통해 이 유형의 모든 요청에 ​​csrftoken HTTP 헤더 속성을 한 번에 추가하고 여기에 토큰 값을 넣을 수 있습니다. 이는 기존 방식의 요청에 토큰을 추가해야 하는 불편함을 해결함과 동시에, XMLHttpRequest를 통해 요청한 주소는 브라우저의 주소 표시줄에 기록되지 않으며, 토큰이 다른 웹사이트로 유출될 염려가 없습니다. 추천자를 통해.

그러나 이 방법에는 큰 한계가 있습니다. XMLHttpRequest 요청은 일반적으로 Ajax 메서드에서 페이지의 부분 비동기 새로 고침에 사용됩니다. 모든 요청이 이 클래스로 시작하기에 적합한 것은 아니며 이 클래스 요청을 통해 얻은 페이지는 브라우저에서 기록할 수 없으므로 앞으로, 뒤로. , 새로고침 등이 수행될 수 있으며, 수집 및 기타 작업은 사용자에게 불편을 끼칩니다. 또한 CSRF 보호 기능이 없는 레거시 시스템의 경우 보호를 위해 이 방법을 사용하려면 모든 요청을 XMLHttpRequest 요청으로 변경해야 하며, 이로 인해 전체 웹사이트가 거의 다시 작성됩니다. 이 비용은 의심할 여지 없이 용납할 수 없습니다

4-CC 공격

4-1 CC 공격의 원리 :

CC 공격의 원리는 공격자가 일부 호스트를 제어하여 상대방 서버에 대량의 데이터 패킷을 지속적으로 전송하게 하여 서버 자원을 소모시키는 것이다. 지칠 때까지. CC는 주로 서버 리소스를 소비하는 데 사용됩니다. 많은 사람이 웹 페이지를 방문하면 CC는 무제한 액세스 없이 여러 사용자를 시뮬레이션합니다. 많은 데이터 작업(즉, CPU 시간이 많이 소요됨)이 필요한 페이지에는 CPU가 오랫동안 100% 상태로 유지되어 네트워크가 정체되어 정상화될 때까지 항상 연결이 끝나지 않습니다. 접근이 정지되었습니다.

4-2 CC 공격 유형:

CC 공격에는 세 가지 유형이 있습니다.

• 직접 공격
• Proxy 공격
• Botnet 공격

직접 공격은 주로 중요한 결함이 있는 WEB 애플리케이션을 대상으로 합니다. 프로그램 , 일반적으로 이러한 상황은 프로그램 작성에 문제가 있는 경우에만 발생하며 비교적 드뭅니다. 봇넷 공격은 DDOS 공격과 다소 유사합니다. 따라서 웹 애플리케이션 수준에서는 방어할 수 없으므로 프록시 공격은 일반적으로 100개의 프록시와 같은 일괄 프록시 서버를 운영하고 각 프록시는 10개의 요청을 발행합니다. 동시에 웹 서버는 1,000개의 동시 요청을 수신하고 요청을 보낸 후 즉시 프록시와의 연결을 끊습니다. 이는 프록시에서 반환된 데이터가 자체 대역폭을 차단하고 다른 요청을 시작할 수 없도록 방지하는 것입니다. 이때 WEB 서버는 이러한 요청에 응답하는 프로세스를 대기열에 추가하며 데이터베이스 서버도 마찬가지입니다. 이런 식으로 매점에 갈 때와 마찬가지로 정상적인 요청이 처리됩니다. 일반적으로 줄을 서 있는 사람은 10명 미만입니다. 오늘은 1,000명이 앞에 서 있다면, 이때는 페이지가 매우 느리게 열릴 것입니다. 흰색 화면이 나타납니다.

4-3 CC 공격과 DDOS의 차이점

DDoS는 IP에 대한 공격이고, CC는 서버 리소스를 공격합니다.

5-DOS 공격

DOS: 중국어 이름은 서비스 거부입니다. DOS 동작을 유발할 수 있는 모든 공격을 DOS 공격이라고 합니다. 이 공격의 결과는 컴퓨터나 네트워크가 정상적인 서비스를 제공할 수 없게 만드는 것입니다. 일반적인 DOS 공격에는 컴퓨터 네트워크 대역폭 및 연결에 대한 공격이 포함됩니다. DOS는 독립형 컴퓨터 간의 독립형 공격입니다.

DOS 공격의 원리: 먼저 공격자는 공격받은 서버에 대량의 가짜 IP 요청을 보냅니다. 공격자는 요청을 받은 후 확인 정보를 반환하고 공격자가 확인하기를 기다립니다. (여기에는 HTTP가 필요합니다. 프로토콜 작동 방법 및 TCP three-way handshake 기본 지식) 이 과정에는 공격자가 보낸 요청 정보가 거짓이므로 서버는 일정 시간 동안 반환된 확인 정보를 받을 수 없습니다. 대기 상태가 되며 이번에 요청한 리소스가 해제되지 않았습니다. 공격자가 일정 시간 동안 기다리면 타임아웃으로 인해 연결이 끊어지게 되는데 이때 공격자는 다시 새로운 허위 정보 요청을 보내게 되어 결국 서버 리소스가 마비될 때까지 소모하게 된다.

6-DDOS 공격

DDoS 공격은 분산 서비스 거부 공격 방식으로, 전통적인 DoS 공격을 기반으로 한 공격 방식입니다. 단일 DoS 공격은 일반적으로 일대일 방식으로 수행됩니다. 컴퓨터 및 네트워크 기술의 발전으로 DoS 공격의 난이도가 높아졌습니다. 그래서 DDoS 공격이 탄생했고 그 원리는 매우 간단합니다. 컴퓨터와 네트워크의 처리 능력이 10배 증가했고, 하나의 공격 기계를 사용하여 공격하는 것은 더 이상 효과적이지 않으므로 DDoS는 더 많은 인형 기계를 사용하여 공격을 시작하는 것입니다. 이전보다 더 큰 규모로 피해자를 공격한다. 일반적으로 사용되는 DDoS 소프트웨어에는 LOIC가 포함됩니다.
여기에 추가할 두 가지 사항: 첫째, DDOS 공격은 컴퓨터뿐만 아니라 라우터도 공격할 수 있습니다. 라우터는 특별한 유형의 컴퓨터이기 때문입니다. 둘째, 네트워크 속도에 따라 공격의 정도와 속도가 결정됩니다. 네트워크 속도가 제한된 환경에서는 공격 효과가 그다지 뚜렷하지 않지만 이에 비해 네트워크 속도가 빠른 것이 더 효과적입니다.

위 내용은 PHP 보안 문제 요약의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!