크로스 사이트 요청 위조 CSRF 공격 및 방어-PHP 튜토리얼-php.cn

1. CSRF란 무엇인가요?

CSRF(Cross-site request forgery), 중국어 이름: cross-site request forgery, 원클릭 공격/세션 라이딩이라고도 함, 줄여서 CSRF/XSRF.

2. CSRF는 무엇을 할 수 있나요?

CSRF 공격을 이렇게 이해할 수 있습니다. 공격자는 귀하의 신원을 도용하고 귀하의 이름으로 악의적인 요청을 보냅니다. CSRF가 할 수 있는 일은 귀하의 이름으로 이메일과 메시지를 보내고, 귀하의 계정을 도용하고, 심지어 상품 구매, 가상 화폐 이체까지 포함합니다. 발생하는 문제는 다음과 같습니다: 개인 정보 유출 및 재산 보안.

3. CSRF 취약점 현황

이러한 CSRF 공격 방식은 2000년 외국 보안요원에 의해 제안되었으나 중국에서는 2006년이 되어서야 주목을 받기 시작했다. , 국내외 CSRF 취약점은 NYTimes.com(New York Times), Metafilter(대형 BLOG 웹사이트), YouTube 및 Baidu HI와 같은 많은 대규모 커뮤니티 및 대화형 웹사이트에서 보고되었습니다. 그리고 현재 많은 웹사이트에서 인터넷 사이트는 아직 준비가 되어 있지 않아 보안 업계에서는 CSRF를 "잠자는 거인"이라고 부릅니다.

4. CSRF 원칙

CSRF 공격을 완료하려면 피해자는 두 단계를 차례로 완료해야 합니다.

1. 신뢰할 수 있는 웹사이트 A에 로그인하고 로컬에서 생성합니다. 쿠키.

2. A에서 로그아웃하지 않고 위험한 웹사이트 B에 접속합니다.

이것을 보면 "위 두 가지 조건 중 하나라도 충족하지 않으면 CSRF의 공격을 받지 않을 것이다"라고 말할 수 있을 것입니다. 예, 사실입니다. 그러나 다음 상황이 발생하지 않는다고 보장할 수는 없습니다.

1. 웹사이트에 로그인한 후 더 이상 탭 페이지를 열고 다른 웹사이트를 방문하지 않을 것이라고 보장할 수 없습니다.

2. 브라우저를 닫은 후 로컬 쿠키가 즉시 만료되고 마지막 세션이 종료된다는 보장은 없습니다. (사실 브라우저를 닫는다고 세션이 종료되는 것은 아니지만 대부분의 사람들은 브라우저를 닫는 것이 세션을 로그아웃/종료하는 것과 같다고 착각하고 있습니다...)

　3. 위 그림에서 말하는 것은 공격 웹 사이트는 다른 취약점이 있는 신뢰할 수 있고 자주 방문하는 웹 사이트일 수 있습니다.

위 내용은 CSRF 공격에 대한 아이디어를 간략하게 설명한 것입니다. 아래에서는 몇 가지 예를 사용하여 구체적인 CSRF 공격을 자세히 설명하겠습니다. 여기서는 은행 송금 작업을 예로 들어보겠습니다. 은행 웹사이트는 그렇게 멍청하지 않습니다.>)

예 1:

GET 요청을 사용하여 은행 이체 작업을 완료하는 은행 웹사이트 A(예: http://www.mybank.com) /Transfer .php?toBankId=11&money=1000

다음과 같은 HTML 코드가 포함된 위험한 웹사이트 B:

크로스 사이트 요청 위조 CSRF 공격 및 방어

먼저 로그인합니다. 은행사이트 A로 갔다가 위험한 사이트 B로 접속했는데, 아, 그러면 은행계좌에 1,000위안이 빠져있는 걸 발견하게 되는데...

이건 왜일까요? 그 이유는 은행 웹사이트 A가 HTTP 사양을 위반하고 GET 요청을 사용하여 리소스를 업데이트하기 때문입니다. 위험한 웹사이트 B에 접근하기 전에 이미 은행 웹사이트 A에 로그인되어 있었고 B는 GET을 사용하여 제3자 리소스를 요청합니다(여기서 제3자는 은행 웹사이트를 의미합니다. 원래는 합법적인 요청이었지만 여기서는 범죄자가 이를 활용) 브라우저는 은행 웹사이트 A의 쿠키를 가져와 "http://www.mybank.com/Transfer.php?toBankId=11&money=1000" 리소스를 얻기 위한 Get 요청을 발행합니다. 그 결과, 은행 웹사이트 서버는 요청을 받은 후 이것이 자원 업데이트 작업(이체 작업)이라고 판단하여 즉시 이체 작업을 수행했습니다...

　예 2:

위 문제를 방지하기 위해 은행에서는 POST 요청을 사용하여 이체 작업을 완료하기로 결정했습니다.

은행 홈페이지 A의 WEB 형태는 다음과 같습니다.

    <form action="Transfer.php" method="POST">
　　　　<p>ToBankId: <input type="text" name="toBankId" /></p>
　　　　<p>Money: <input type="text" name="money" /></p>
　　　　<p><input type="submit" value="Transfer" /></p>
　　</form>

로그인 후 복사

백그라운드 처리 페이지 Transfer.php는 다음과 같습니다.

    <?php
　　　　session_start();
　　　　if (isset($_REQUEST[&#39;toBankId&#39;] &&　isset($_REQUEST[&#39;money&#39;]))
　　　　{
　　　　    buy_stocks($_REQUEST[&#39;toBankId&#39;],　$_REQUEST[&#39;money&#39;]);
　　　　}
　　?>

로그인 후 복사

위험한 홈페이지 B는 여전히 해당 HTML 문장만 포함합니다. 코드:

　 크로스 사이트 요청 위조 CSRF 공격 및 방어

　　和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

　　示例3：

　　经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

   <?php
　　　　session_start();
　　　　if (isset($_POST[&#39;toBankId&#39;] &&　isset($_POST[&#39;money&#39;]))
　　　　{
　　　　    buy_stocks($_POST[&#39;toBankId&#39;],　$_POST[&#39;money&#39;]);
　　　　}
　　?>

로그인 후 복사

　　然而，危险网站B与时俱进，它改了一下代码：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>
　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

로그인 후 복사

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

　　总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。

　　理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

五.CSRF的防御

CSRF 的防范机制有很多种，防范的方法也根据 CSRF 攻击方式的不断升级而不断演化。常用的有检查 Refer 头部信息，使用一次性令牌，使用验证图片等手段。出于性能的考虑，如果每个请求都加入令牌验证将极大的增加服务器的负担，具体采用那种方法更合理，需要谨慎审视每种保护的优缺点。

1. 检查 HTTP 头部 Refer 信息，这是防止 CSRF 的最简单容易实现的一种手段。根据 RFC 对于 HTTP 协议里面 Refer 的定义，Refer 信息跟随出现在每个 Http 请求头部。Server 端在收到请求之后，可以去检查这个头信息，只接受来自本域的请求而忽略外部域的请求，这样就可以避免了很多风险。当然这种检查方式由于过于简单也有它自身的弱点：

a) 首先是检查 Refer 信息并不能防范来自本域的攻击。在企业业务网站上，经常会有同域的论坛，邮件等形式的 Web 应用程序存在，来自这些地方的 CSRF 攻击所携带的就是本域的 Refer 域信息，因此不能被这种防御手段所阻止。

b) 同样，某些直接发送 HTTP 请求的方式（指非浏览器，比如用后台代码等方法）可以伪造一些 Refer 信息，虽然直接进行头信息伪造的方式属于直接发送请求，很难跟随发送 cookie，但由于目前客户端手段层出不穷，flash，javascript 等大规模使用，从客户端进行 refer 的伪造，尤其是在客户端浏览器安装了越来越多的插件的情况下已经成为可能了。

2. 使用一次性令牌，这是当前 Web 应用程序的设计人员广泛使用的一种方式，方法是对于 Get 请求，在 URL 里面加入一个令牌，对于 Post 请求，在隐藏域中加入一个令牌。这个令牌由 server 端生成，由编程人员控制在客户端发送请求的时候使请求携带本令牌然后在 Server 端进行验证。但在令牌的设计上目前存在着几个错误的方案：

a) 使用和 Session 独立的令牌生成方式。这种令牌的值和 Session 无关，因此容易被其他用户伪造。这里的其他用户指的是当前 Web 应用程序的其他用户和活跃在网络传输阶段各个设置上的监听者，这种恶意用户可能使用自己的令牌来进行替换以便达到伪造的目的。

b) 完全使用 Session 认证信息作为令牌的生成方式。这种保护方式对于保护 CSRF 是起了作用的，但是可能会造成其他危害，具体来说，如果某些 URL 或者网页被拷贝下来与其他人共享，那么这些 URL 或者拷贝下来的网页中可能会含有用户的会话信息，这种信息一旦被恶意用户获得，就能造成极大的危害。

因此，一个正确的令牌设计应该是使用 Session 信息做 Hash，用得出的哈希值来做 CSRF 的令牌。

3. 검증 이미지를 사용하는 방법의 목적은 로봇의 무차별 공격을 방지하는 것입니다. 그러나 CSRF 방지 측면에서 이중 보호를 위해 인증 사진과 일회성 토큰을 결합하는 보안 요구 사항이 상대적으로 높은 일부 애플리케이션도 있습니다. 이러한 이미지 검증 정보는 악성 프로그램이 클라이언트에서 식별하기 어렵기 때문에 더욱 강력한 보호 기능을 제공할 수 있습니다. 클라이언트의 브라우저가 이미 안전하지 않은 환경에 있을 수 있는 경우(예: 클라이언트의 보안 수준이 낮은 수준으로 설정되어 있거나 클라이언트의 브라우저에 안전하지 않은 플러그인이 설치되어 있는 경우 등)

위는 CSRF를 방지하는 보다 일반적인 방법 중 일부에 불과합니다. 웹 개발자는 애플리케이션 기능에 대한 이해를 바탕으로 보안 수준 요구 사항을 결정하고 다양한 보호 조치를 사용하는 것이 좋습니다. 동일한 애플리케이션 내에서 보호 방법을 조합하여 사용합니다.

참고: 고속도로에 요금소를 설치하는 것처럼 방어를 추가하는 것도 성능에 큰 영향을 미칩니다. 중요한 작업에만 방어를 추가하는 것이 좋습니다. 신중하게 고려하시기 바랍니다.