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:
먼저 로그인합니다. 은행사이트 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['toBankId'] && isset($_REQUEST['money']))
{
buy_stocks($_REQUEST['toBankId'], $_REQUEST['money']);
}
?>위험한 홈페이지 B는 여전히 해당 HTML 문장만 포함합니다. 코드:
和示例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['toBankId'] && isset($_POST['money']))
{
buy_stocks($_POST['toBankId'], $_POST['money']);
}
?>然而，危险网站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를 방지하는 보다 일반적인 방법 중 일부에 불과합니다. 웹 개발자는 애플리케이션 기능에 대한 이해를 바탕으로 보안 수준 요구 사항을 결정하고 다양한 보호 조치를 사용하는 것이 좋습니다. 동일한 애플리케이션 내에서 보호 방법을 조합하여 사용합니다.
참고: 고속도로에 요금소를 설치하는 것처럼 방어를 추가하는 것도 성능에 큰 영향을 미칩니다. 중요한 작업에만 방어를 추가하는 것이 좋습니다. 신중하게 고려하시기 바랍니다.
세션을 저장하기 위해 데이터베이스를 사용하면 어떤 장점이 있습니까?Apr 24, 2025 am 12:16 AM데이터베이스 스토리지 세션 사용의 주요 장점에는 지속성, 확장 성 및 보안이 포함됩니다. 1. 지속성 : 서버가 다시 시작 되더라도 세션 데이터는 변경되지 않아도됩니다. 2. 확장 성 : 분산 시스템에 적용하여 세션 데이터가 여러 서버간에 동기화되도록합니다. 3. 보안 : 데이터베이스는 민감한 정보를 보호하기 위해 암호화 된 스토리지를 제공합니다.
PHP에서 사용자 정의 세션 처리를 어떻게 구현합니까?Apr 24, 2025 am 12:16 AMSessionHandlerInterface 인터페이스를 구현하여 PHP에서 사용자 정의 세션 처리 구현을 수행 할 수 있습니다. 특정 단계에는 다음이 포함됩니다. 1) CustomsessionHandler와 같은 SessionHandlerInterface를 구현하는 클래스 만들기; 2) 인터페이스의 방법 (예 : Open, Close, Read, Write, Despare, GC)의 수명주기 및 세션 데이터의 저장 방법을 정의하기 위해 방법을 다시 작성합니다. 3) PHP 스크립트에 사용자 정의 세션 프로세서를 등록하고 세션을 시작하십시오. 이를 통해 MySQL 및 Redis와 같은 미디어에 데이터를 저장하여 성능, 보안 및 확장 성을 향상시킬 수 있습니다.
세션 ID 란 무엇입니까?Apr 24, 2025 am 12:13 AMSessionId는 웹 애플리케이션에 사용되는 메커니즘으로 사용자 세션 상태를 추적합니다. 1. 사용자와 서버 간의 여러 상호 작용 중에 사용자의 신원 정보를 유지하는 데 사용되는 무작위로 생성 된 문자열입니다. 2. 서버는 쿠키 또는 URL 매개 변수를 통해 클라이언트로 생성하여 보낸다. 3. 생성은 일반적으로 임의의 알고리즘을 사용하여 독창성과 예측 불가능 성을 보장합니다. 4. 실제 개발에서 Redis와 같은 메모리 내 데이터베이스를 사용하여 세션 데이터를 저장하여 성능 및 보안을 향상시킬 수 있습니다.
무국적 환경 (예 : API)에서 세션을 어떻게 처리합니까?Apr 24, 2025 am 12:12 AMJWT 또는 쿠키를 사용하여 API와 같은 무국적 환경에서 세션을 관리 할 수 있습니다. 1. JWT는 무국적자 및 확장 성에 적합하지만 빅 데이터와 관련하여 크기가 크다. 2. 쿠키는보다 전통적이고 구현하기 쉽지만 보안을 보장하기 위해주의해서 구성해야합니다.
세션과 관련된 크로스 사이트 스크립팅 (XSS) 공격으로부터 어떻게 보호 할 수 있습니까?Apr 23, 2025 am 12:16 AM세션 관련 XSS 공격으로부터 응용 프로그램을 보호하려면 다음 조치가 필요합니다. 1. 세션 쿠키를 보호하기 위해 Httponly 및 Secure 플래그를 설정하십시오. 2. 모든 사용자 입력에 대한 내보내기 코드. 3. 스크립트 소스를 제한하기 위해 컨텐츠 보안 정책 (CSP)을 구현하십시오. 이러한 정책을 통해 세션 관련 XSS 공격을 효과적으로 보호 할 수 있으며 사용자 데이터가 보장 될 수 있습니다.
PHP 세션 성능을 어떻게 최적화 할 수 있습니까?Apr 23, 2025 am 12:13 AMPHP 세션 성능을 최적화하는 방법 : 1. 지연 세션 시작, 2. 데이터베이스를 사용하여 세션을 저장, 3. 세션 데이터 압축, 4. 세션 수명주기 관리 및 5. 세션 공유 구현. 이러한 전략은 높은 동시성 환경에서 응용의 효율성을 크게 향상시킬 수 있습니다.
SESSION.GC_MAXLIFETIME 구성 설정은 무엇입니까?Apr 23, 2025 am 12:10 AMTHESESSION.GC_MAXLIFETIMESETTINGINSTTINGTINGSTINGTERMINESTERMINESTERSTINGSESSIONDATA, SETINSECONDS.1) IT'SCONFIGUDEDINPHP.INIORVIAINI_SET ()
PHP에서 세션 이름을 어떻게 구성합니까?Apr 23, 2025 am 12:08 AMPHP에서는 Session_Name () 함수를 사용하여 세션 이름을 구성 할 수 있습니다. 특정 단계는 다음과 같습니다. 1. Session_Name () 함수를 사용하여 Session_Name ( "my_session")과 같은 세션 이름을 설정하십시오. 2. 세션 이름을 설정 한 후 세션을 시작하여 세션을 시작하십시오. 세션 이름을 구성하면 여러 응용 프로그램 간의 세션 데이터 충돌을 피하고 보안을 향상시킬 수 있지만 세션 이름의 독창성, 보안, 길이 및 설정 타이밍에주의를 기울일 수 있습니다.
핫 AI 도구
Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱
AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.
Undress AI Tool
무료로 이미지를 벗다
Clothoff.io
AI 옷 제거제
Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!
인기 기사
뜨거운 도구
안전한 시험 브라우저
안전한 시험 브라우저는 온라인 시험을 안전하게 치르기 위한 보안 브라우저 환경입니다. 이 소프트웨어는 모든 컴퓨터를 안전한 워크스테이션으로 바꿔줍니다. 이는 모든 유틸리티에 대한 액세스를 제어하고 학생들이 승인되지 않은 리소스를 사용하는 것을 방지합니다.
Atom Editor Mac 버전 다운로드
가장 인기 있는 오픈 소스 편집기
Eclipse용 SAP NetWeaver 서버 어댑터
Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.
SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.
SecList
SecLists는 최고의 보안 테스터의 동반자입니다. 보안 평가 시 자주 사용되는 다양한 유형의 목록을 한 곳에 모아 놓은 것입니다. SecLists는 보안 테스터에게 필요할 수 있는 모든 목록을 편리하게 제공하여 보안 테스트를 더욱 효율적이고 생산적으로 만드는 데 도움이 됩니다. 목록 유형에는 사용자 이름, 비밀번호, URL, 퍼징 페이로드, 민감한 데이터 패턴, 웹 셸 등이 포함됩니다. 테스터는 이 저장소를 새로운 테스트 시스템으로 간단히 가져올 수 있으며 필요한 모든 유형의 목록에 액세스할 수 있습니다.
