웹을 안전하게 유지하는 방법

1. 소개

인터넷이 발달한 초기에는 아직 IE 브라우저의 시대였습니다. 당시 인터넷을 서핑하는 모든 사람들의 목적은 인터넷을 통해 정보를 공유하고 뉴스를 얻는 것이었습니다. 브라우저. 인터넷의 급속한 발전으로 인해 웹 페이지는 점점 더 많은 일을 할 수 있게 되었습니다. 뉴스를 읽고 게임을 할 수 있을 뿐만 아니라 쇼핑과 채팅도 가능해졌습니다.

웹페이지의 기능이 점차 높아지면서 일부 검은 모자가 나타나기 시작했고, 그들은 어떤 기술적 수단을 통해 이익을 얻으려고 합니다. 예를 들어, 트로이 목마 바이러스는 키보드를 모니터링하고 키보드에 입력하는 내용을 해커의 컴퓨터로 보낼 수 있으며, 내용을 분석하여 해커는 쉽게 게임 계정과 비밀번호를 알아낼 수 있습니다. 그 후, 인터넷의 다양한 바이러스를 해결하는 데 전념하는 일부 바이러스 백신 소프트웨어가 탄생했습니다. 지속적인 개발을 통해 바이러스 백신 소프트웨어는 컴퓨터에 없어서는 안될 소프트웨어가 되었습니다.

왜 이런 보안 문제가 발생하나요?

보안은 결국 신뢰의 문제입니다. 모든 사람이 정상적인 절차에 따라 온라인에 접속하고 개인적인 이익을 추구하지 않는다면 이야기할 보안 문제는 없을 것입니다.

보안의 기본은 신뢰에 있지만, 모두가 서로를 신뢰하게 만드는 것은 쉽지 않습니다. 현 단계에서 우리가 할 수 있는 일은 보안 보호를 지속적으로 개선하고, 허점을 줄이고, 불법 공격을 점점 더 어렵게 만드는 것입니다. 이를 통해 점차적으로 블랙햇의 수를 줄이고 바이러스 생성자를 줄일 수 있습니다.

1. 보안을 잘하는 방법

보안을 잘하려면 먼저 보안 문제의 속성을 이해해야 합니다. 선배들은 수많은 실습을 통해 마침내 보안의 속성을 보안의 세 가지 요소로 요약했습니다.

1) 기밀성

데이터 내용이 유출되지 않도록 보호하세요. 일반적으로 암호화 방법이 사용됩니다.

2) 무결성

데이터 내용이 완전하고 변조되지 않았음을 보호합니다. 일반적으로 디지털 서명 방식을 사용합니다.

3) 가용성.

데이터는 언제든지 사용할 수 있습니다. 일반적으로 DOS를 방어합니다.

2. 보안 평가

보안의 3가지 요소를 갖춘 후에는 보안 문제를 평가할 수 있습니다.

1) 자산 분류

가장 중요한 데이터를 알아보세요. 데이터베이스와 같이 가장 중요한 데이터의 호스팅 공간을 알아낸 다음 데이터베이스는 방어에 집중해야 합니다. 데이터베이스의 호스팅 공간을 알아보세요. 예를 들어 서버에서 이 서버는 2차 방어를 수행해야 합니다. 다음과 같이 서버의 호스트 공간을 알아보세요. OSI 네트워크 수준에서는 네트워크 수준에서 일반 방어를 수행해야 합니다.

2) 위협 분석

위협(해를 끼칠 수 있는 소스)을 알아보세요. 위험을 알아보세요(가능한 손실을 위험이라고 합니다).

3) 위험 분석

은 위험 = 위협 수준 * 위협 타당성이라는 다기준 의사결정 분석을 채택합니다. 모든 위협을 계산하고, 최종 위험 순위를 매기고, 위험도가 높은 문제의 우선순위를 지정합니다.

4) 해결 방법 확인

안전하지 않은 구현을 찾아 해결 방법을 결정합니다. 솔루션은 비즈니스 요구 사항의 원래 의도를 변경해서는 안 됩니다. 솔루션은 사용자에게 투명해야 하며 사용자의 습관을 바꾸지 않아야 합니다.

보안 평가를 완료한 후 보안 솔루션을 갖게 됩니다. 후속 보안 작업은 이 계획만 따르면 문제가 없습니다.

3. 안전 원칙

안전 솔루션을 갖춘 후에는 몇 가지 안전 원칙을 공식화하고 이를 실천함으로써 절반의 노력으로 두 배의 결과를 얻을 수 있습니다.

1) 블랙리스트 및 화이트리스트 원칙

화이트리스트 솔루션은 안전한 리소스를 승인하는 것을 의미합니다. 블랙리스트 구성표는 안전하지 않은 리소스를 비활성화하는 것을 의미합니다. 블랙리스트는 일반적으로 안전하지 않은 모든 리소스를 계산할 수 없기 때문에 화이트리스트 솔루션 사용에 우선순위를 두어야 합니다. 예를 들어 XSS를 공격하는 방법은 스크립트, CSS, 이미지 태그 등 여러 가지가 있습니다. 이러한 태그를 블랙리스트에 추가하더라도 다른 태그에 XSS 공격 위험이 없다는 보장은 없습니다.

2) 최소 권한의 원칙

필요한 권한만 부여하고, 과도한 권한을 부여하지 않으며, 오류 발생 가능성을 줄입니다. 예를 들어 일반 권한을 가진 Linux 사용자는 ~ 폴더 아래의 디렉터리만 조작할 수 있습니다. 누군가 라이브러리를 삭제하고 도망치려는 경우 rm -rf /를 실행하면 권한이 없다는 메시지가 표시됩니다.

3) 심층 방어 원칙

이 원칙은 배럴 이론과 유사하며, 안전 수준은 가장 짧은 보드에 따라 달라지는 경우가 많습니다. 즉, 어떤 결점도 남기지 마십시오. 검은 모자는 더 큰 허점을 파기 위한 돌파구로 결점을 사용할 수 있습니다.

4) 데이터와 코드 분리 원칙

사용자 데이터가 코드로 실행되면 데이터와 코드의 경계가 혼란스러워져 보안 문제가 발생합니다. 예: XSS는 이를 공격에 사용합니다.

5) 예측 불가능 원칙

이 원칙은 공격 임계값을 높이고 변조 및 위조에 따른 공격을 효과적으로 방지하기 위한 것입니다. 예를 들어, 데이터베이스에서 숫자형 자동 증가 기본 키 대신 uuid를 사용하면 공격자가 해당 ID를 추측하는 것을 방지할 수 있어 일괄 작업을 수행할 수 있습니다. 토큰은 또한 예측 불가능성을 이용합니다. 공격자는 토큰을 구성할 수 없고 공격할 수도 없습니다.

이러한 보안 원칙을 염두에 두고 몇 가지 일반적인 공격 및 방어 사례를 소개하겠습니다.

2. 보안 공격 및 방어 사례

많은 보안 공격 및 방어 사례가 있습니다. 여기서는 상대적으로 노출률이 높은 몇 가지 보안 문제를 주로 소개합니다.

(1) 클라이언트 공격

주로 XSS 공격, CSRF 공격, 클릭 하이재킹이 포함됩니다.

1. XSS 공격

XSS 공격의 본질은 사용자 데이터를 HTML 코드의 일부로 실행하여 원래 의미를 혼동하고 새로운 의미를 생성하는 것입니다.

사진과 같이 <script>alert(document.cookie)</script>라는 사용자 이름을 등록했습니다. 이 사용자 이름을 볼 수 있는 모든 페이지에는 해당 쿠키가 팝업됩니다. 현재 브라우저에서 코드의 논리가 공격자의 웹사이트에 쿠키를 보내는 것이라면 공격자는 이전 사용자인 것처럼 가장하여 로그인할 수 있습니다.

XSS를 공격하는 방법은 다양합니다. XSS 공격은 사용자와 상호작용하는 모든 곳에 존재할 수 있습니다. 예:

• 모든 입력 상자.

• window.location.

• window.name.

• document.referrer.

• document.cookie.

• 로컬 저장소.

• ...

사용자가 페이지와 상호 작용하는 곳이 너무 많기 때문에 아직 발견되지 않은 일부 XSS 공격 방법이 있을 것이며 검은 모자에 의해 일단 발견되면 심각한 영향을 미칠 수 있습니다 , 그러니 우리는 반드시 주의를 기울여야 합니다.

1) XSS 공격의 영향

XSS 공격에 성공한 후 공격자는 다음과 같은 대량의 사용자 정보를 얻을 수 있습니다.

사용자 UA를 식별합니다. 사용자 브라우저 확장을 식별합니다. 사용자가 방문한 웹사이트를 식별합니다. (CSS Visited 속성을 통해) 사용자의 실제 IP를 가져옵니다. (WebRTC 등을 통해) 쿠키 탈취(사용자 로그인 위조, 사용자 정보 탈취) XSS 피싱. (페이지에 로그인 팝업창을 삽입하여 사용자가 웹사이트 내의 로그인 팝업창인 것처럼 착각하게 만듭니다(실제로는 피싱 웹사이트에서 발생). 사용자가 로그인하면 계정과 비밀번호가 피싱 사이트에 유출됩니다.

2) XSS 공격 방어

현재 XSS는 인터넷 업계의 주목을 받고 있으며 많은 개발 프레임워크에는 보안 HTML 렌더링 방법이 내장되어 있습니다.

일부 보안 구성을 사용자 정의할 수도 있습니다.

프런트엔드 JS가 쿠키를 작동할 수 없도록 HTTP에 http-only 헤더를 구성하세요. 사용자가 데이터를 제출할 때 안전하지 않은 데이터를 필터링하기 위해 XssFilter를 사용하여 입력 확인. 출력 검사, 페이지가 렌더링될 때 위험한 데이터를 필터링합니다.

간단히 말하면: js의 쿠키 작동 금지, 제출 시 html 확인, 출력 시 html 확인(트랜스코딩 가능)

2. CSRF 공격

CSRF(교차 사이트 요청 위조) 교차 사이트 요청 위조는 A 종류입니다. 사용자가 의도하지 않은 일부 작업을 수행하기 위해 사용자 ID를 사용하는 행위.

예:

사용자는 먼저 서버 B에 로그인한 다음 서버 C에 액세스했습니다. 서버 C는 악성 스크립트를 사용하여 A인 것처럼 가장하여 서버 B의 특정 기능을 호출합니다. 서버 B의 경우 이것이 A가 시작한 요청이라고 생각하고 정상적인 요청으로 처리합니다.

상상해 보세요. C가 A인 척하며 이체를 한다면 분명 경제적 손실이 많이 발생할 것입니다.

1) CSRF 방어 방법

CSRF를 방어하는 방법은 주로 다음과 같습니다.

a, 인증 코드 추천인 확인

모든 요청에는 요청이 확실하고 신뢰할 수 있는지 확인하기 위해 사용자 인증이 필요합니다. 즉, 악성 스크립트가 복잡한 확인 코드를 인식할 수 없다는 사실을 활용하여 모든 요청이 합법적인지 확인합니다.

b, 리퍼러 확인

요청을 시작한 서버가 대상 서버인지 확인하세요. 즉, HTTP 요청의 Referer 헤더가 현재 요청의 도메인 이름을 전달합니다. 이 도메인 이름이 불법 서버의 도메인 이름인 경우 액세스를 금지해야 합니다.

c, Token

예측 불가능의 원칙을 사용하여 각 요청에는 무작위 코드가 있어야 합니다. 이 무작위 코드는 일반 사용자가 저장한 것으로, Black hats는 무작위 코드를 모르고 요청을 하는 사용자인 척할 수 없습니다.

(동영상 공유 학습: php 동영상 튜토리얼)

3. 클릭 하이재킹

클릭 하이재킹은 시각적인 속임수 공격 방법입니다. 공격자는 iframe 중첩을 통해 공격해야 할 웹사이트를 자신의 웹페이지에 삽입하고, iframe을 투명하게 설정한 후 페이지에 버튼을 노출시켜 사용자의 클릭을 유도한다.

투명한 종이를 겹겹이 얹은 사진같습니다. 보이는 것은 공격자의 페이지이지만 사실 이 페이지는 맨 아래에만 있고 실제로 클릭하는 것은 투명하게 만든 또 다른 웹페이지입니다. 공격자.

1) 클릭 하이재킹 방어

클릭 하이재킹은 주로 iframe을 통해 전달되기 때문에 방어 시에는 주로 iframe을 기반으로 합니다.

옵션 1: 프레임 파괴

if (self !== top) {  // 跳回原页面
  top.location = self.location;
}

일반 웹사이트는 JS 스크립트를 사용하여 악성 웹사이트에 의해 삽입되었는지 여부를 확인합니다. 예를 들어, 블로그 웹사이트가 iframe으로 열린 것을 감지하면 자동으로 일반 페이지로 이동합니다.

옵션 2: HTTP에서 x-frame-options 헤더를 사용하여 iframe 로드를 제어합니다. 여기에는 3가지 선택 값이 있습니다:

DENY는 페이지가 iframe을 통해 표시될 수 없음을 의미합니다. SAMEORIGIN은 동일한 도메인 이름으로 iframe을 통해 페이지를 표시할 수 있음을 의미합니다. ALLOW-FROM은 페이지가 지정된 소스의 iframe에 표시될 수 있음을 의미합니다.

配置 iframe 的 sandbox 属性：sandbox = "allow-same-origin" ，则只能加载与主站同域的资源。

（二）服务端攻击

服务器端的攻击的方式也非常多，这里列举几个常见的。

SQL 注入攻击文件上传漏洞登录认证攻击应用层拒绝服务攻击webServer 配置安全

1、SQL 注入攻击

SQL 注入和 XSS 一样，都是违背了数据和代码分离原则导致的攻击方式。

如图所示，我们利用 SQL 注入，就能在不需要密码的情况下，直接登录管理员的账号。

攻击的前提是：后端只用了简单的拼接 SQL 的方式去查询数据。

// 拼接出来的 sql 如下：select * from user where username = 'admin' or 1=1 and password = 'xxx'
// 无论密码输入什么，这条 sql 语句都能查询到管理员的信息

除此之外，SQL 注入还有以下几种方式：

a、使用 SQL 探测，猜数据库表名，列名。

通过 MySQL 内置的 benchmark 探测数据库字段。如：一段伪代码 select database as current if current[0]==='a',benchmark（10000,'猜对了'） 如果表明猜对了，就延迟 10 s 并返回成功。

b、使用存储过程执行系统命令

通过内置的方法或存储过程执行 shell 脚本。如：xp_cmdshell、sys_eval、sys_exec 等。

c、字符串截断

如：MySQL 在处理超长的字符串时，会显示警告，但会执行成功。注册一个 admin + 50 个空格的用户，会触发截断，最终新增一个 admin 用户，这样就能拥有管理员权限了。

1）SQL 注入防御

防止 SQL 注入的最好的办法就是，不要手动拼接 SQL 语句。

最佳方案，使用预编译语句绑定变量：通常是指框架提供的拼接 SQL 变量的方法。这样的语义不会发生改变，变量始终被当成变量。严格限制数据类型，如果注入了其他类型的数据，直接报错，不允许执行。使用安全的存储过程和系统函数。

2、CRLF 注入

在注入攻击中，换行符注入也是非常常见的一种攻击方式。

如果在 HTTP 请求头中注入 2 个换行符，会导致换行符后面的所有内容都被解析成请求实体部分。攻击者通常在 Set-Cookie 时，注入换行符，控制请求传递的内容。

3、文件上传漏洞

上传文件是网页开发中的一个常见功能，如果不加处理，很容易就会造成攻击。

如图所示，攻击者上传了一个木马文件，并且通过返回的 URL 进行访问，就能控制服务器。

通常我们会控制上传文件的后缀名，但也不能完全解决问题，攻击者还可以通过以下方式进行攻击：

• 伪造正常文件

• 将木马文件伪装成正常的后缀名进行上传。

• 如果要避免这个问题，我们可以继续判断上传文件的文件头前 10 个字节。

• Apache 解析方式是从后往前解析，直到找到一个认识的后缀名为止

• 如：上传一个 abc.php.rar.rar.rar 能绕过后缀名检查，但在执行时，被当成一个 php 文件进行执行。

• IIS 会截断分号进行解析

• 如：abc.asp;xx.png 能绕过后缀名检查，但在执行时，被当成一个 asp 文件进行执行。

• HTTP PUT 方法允许将文件上传到指定位置

• 通过 HTTP MOVE 方法，还能修改上传的文件名。

• 通过二者配合，就能先上传一个正常的后缀名，然后改为一个恶意的后缀名。

• PHP CGI 路径问题

• 执行 http://abc.com/test.png/xxx.php 时，会把 test.png 当做 php 文件去解析。

• 如果用户正好是把一段恶意的 php 脚本当做一张图片进行上传，就会触发这个攻击。

1）文件上传漏洞防御

防御文件上传漏洞，可以从以下几点考虑：

将文件上传的目录设置为不可执行。判断文件类型检查 MIME Type，配置白名单。检查后缀名，配置白名单。使用随机数改写文件名和文件路径上传文件后，随机修改文件名，让攻击者无法执行攻击。单独设置文件服务器的域名单独做一个文件服务器，并使用单独的域名，利用同源策略，规避客户端攻击。通常做法是将静态资源存放在 CDN 上。

4、登录认证攻击

登录认证攻击可以理解为一种破解登录的方法。攻击者通常采用以下几种方式进行破解：

• 彩虹表

• 공격자는 MD5 암호문을 해독하여 원본 텍스트를 찾기 위해 일반 텍스트와 MD5 간의 대응을 대량으로 수집합니다.

• 레인보우 테이블의 MD5 비밀번호는 소금을 추가하고 2차 암호화를 수행하여 크랙을 방지할 수 있습니다.

• 세션 고정 공격

• 서버에서 응용 프로그램 시스템의 SessionID 고정 메커니즘을 사용하여 동일한 SessionID를 사용하는 다른 사람의 도움을 받아 인증 및 승인을 얻습니다.

• 공격자가 로그인에 실패한 후 백엔드는 SessionID를 반환합니다. 공격자는 로그인할 수 있도록 SessionID를 일반 사용자에게 제공합니다. 로그인에 성공한 후 공격자는 이 SessionID를 사용하여 일반 사용자인 것처럼 가장할 수 있습니다. 로그인합니다.

• 로그인할 때마다 브라우저가 SessionID를 새로 고치면 이 문제를 피할 수 있습니다.

• 세션이 계속 공격합니다

• 때때로 사용자 경험을 위해 백엔드는 사용자가 살아있는 한 사용자의 세션이 만료되는 것을 허용하지 않습니다.

• 공격자는 지속적으로 요청을 보내 이 세션을 활성 상태로 유지할 수 있습니다.

1) 로그인 인증 방어 방법

다단계 인증 비밀번호가 1차 방어선으로 사용되지만 비밀번호 확인에 성공한 후에도 계속해서 확인할 수 있습니다: 동적 비밀번호, 디지털 인증서, SMS 확인 코드 등 사용자 보안을 보장합니다. SMS와 웹페이지는 완전히 독립된 시스템이기 때문에 공격자가 SMS 인증코드를 획득하기 어려워 공격을 수행할 수 없습니다.

5. 애플리케이션 계층 서비스 거부 공격

DDOS 공격이라고도 알려진 애플리케이션 계층 서비스 거부 공격은 대량의 요청을 사용하여 리소스 과부하를 유발하고 서버를 사용할 수 없게 만드는 것을 말합니다.

일반적으로 다음과 같은 DDOS 공격 방법이 있습니다.

• SYN Flood 공격

• HTTP 3방향 핸드셰이크 메커니즘을 사용하여 서버 연결 리소스를 소비합니다.

• 예: 공격자는 다수의 HTTP 요청을 시작했지만 3번의 핸드셰이크를 완료하지 않고 2번의 핸드셰이크만 완료했습니다. 이때 서버는 시간이 초과될 때까지 계속 기다립니다. 이때 서버는 수많은 쓰레기 요청을 처리하느라 바빠 정상적인 요청을 고려할 시간이 없습니다.

• Slowloris 공격

• 은 매우 느린 속도로 HTTP 요청 헤더를 보내 서버 연결 리소스를 소모합니다.

• 예: 공격자는 많은 수의 HTTP 요청을 전송하지만 각 요청 헤더는 매우 느리게 전송되어 10초마다 한 문자를 전송하므로 서버는 항상 연결을 유지해서는 안 됩니다. 이렇게 하면 서버 연결 수가 매우 빠릅니다.

• HTTP POST DOS

• HTTP를 보낼 때 Content-Length를 매우 크게 지정한 다음 긴 간격으로 보내면 서버 연결 리소스가 소모됩니다.

• CC 공격

• 은 리소스를 많이 소모하는 일부 페이지를 대상으로 하며 지속적으로 요청을 시작합니다.

• 예: 페이지의 일부 페이지에는 백엔드 작업이 많이 필요하거나 시간이 많이 걸리는 데이터베이스 쿼리가 필요합니다. 요청 수가 많은 경우 서버의 CPU, 메모리 및 기타 리소스가 점유될 수 있습니다.

• 서버 제한 DOS

• XSS를 통해 지나치게 긴 쿠키를 삽입하면 요청 헤더 길이가 웹 서버의 용량을 초과하게 되고 서버는 서비스를 거부하게 됩니다.

• ReDOS

• 일부 결함이 있는 정규 표현식을 목표로 수많은 요청이 시작되고 시스템 리소스가 소모됩니다.

1) 애플리케이션 계층 서비스 거부 공격 방어

현재 애플리케이션 계층 서비스 거부 공격에 대한 완벽한 솔루션은 없지만 여전히 일부 최적화를 수행할 수 있습니다.

애플리케이션 코드의 성능을 최적화하고 Redis, Memcache 등의 캐싱 솔루션을 합리적으로 사용하여 CPU 리소스 사용량을 줄입니다. 네트워크 아키텍처를 최적화하고 백엔드에서 로드 밸런싱을 구축합니다. 정적 리소스는 CDN을 사용하여 관리됩니다. 요청 빈도 제한 서버는 모든 IP 주소의 요청 빈도를 계산하고 비정상적인 IP를 필터링하여 비활성화합니다. LRU 알고리즘을 사용하여 처음 1,000개 요청의 IP 주소를 캐시할 수 있습니다. IP 요청 빈도가 너무 높으면 비활성화하세요.

사실 DDOS 처리의 핵심 아이디어는 신뢰할 수 없는 사용자를 비활성화하고 일반 사용자가 리소스를 사용하도록 하는 것입니다.

3. 웹 서버 구성 보안

우리는 웹 애플리케이션을 배포할 때 Nginx, Apache, IIS, Tomcat, Jboss 및 기타 웹 서버를 자주 사용합니다. 이러한 서버도 제대로 구성되지 않으면 몇 가지 보안 위험이 있습니다. 공격에 쉽게 노출됩니다.

웹 서버를 구성할 때 다음 사항을 참고할 수 있습니다.

1. 사용자 권한으로 웹 서버를 실행합니다.

최소 권한의 원칙에 따라 웹 서버를 최소한의 권한으로 실행하고 이후에는 권한을 제한합니다. 침략당하고 있습니다.

2. 시각적 백엔드 삭제

Tomcat, Jboss 등의 웹 서버를 실행할 때 시각적 작업 백엔드는 기본적으로 활성화되어 포트 8080에서 실행되며 첫 번째 액세스는 인증되지 않습니다.

공격자는 시각적 배경을 사용하여 원격으로 war 패키지를 로드하거나 제어를 위한 트로이 목마 파일을 업로드할 수 있으므로 시각적 플랫폼을 삭제해야 합니다.

3. 제때에 버전을 업데이트하세요

주요 웹 서버는 가끔씩 일부 취약점을 수정하므로 제때에 버전을 업데이트하세요.

관련 권장 사항: 웹 서버 보안

위 내용은 웹을 안전하게 유지하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!