답변:
Magento의 장바구니에 추가 GET 작업에서 CSRF 토큰이 "필요"한 이유에 대한이 질문에 대한 명확한 답변을 얻는 것이 어려울 것입니다. 그 목적을 해석하려고 노력할 것입니다. 나는 결코 보안 전문가가 아니며 이것은이 특정 상황에서 CSRF에 대한 나의 해석입니다.
에서 owasp.org
CSRF (Cross-Site Request Forgery)는 최종 사용자가 현재 인증 된 웹 응용 프로그램에서 원치 않는 동작을 실행하도록하는 공격입니다. CSRF 공격은 공격자가 위조 된 요청에 대한 응답을 볼 수있는 방법이 없기 때문에 데이터 도난이 아닌 상태 변경 요청을 대상으로합니다.
이 공격의 한 가지 예는 이메일이나 대체 웹 페이지에 숨겨진 이미지를 포함시키는 것입니다.
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">웹 서버는 요청이 발생한 위치를 구별하지 않고 해당 사용자의 장바구니에 항목을 충실하게 추가합니다.
CSRF 공격을 방지하는 목적은 상태 변경 요청 을 방지 하는 것 입니다. 장바구니에 품목을 추가하면 상태 변경으로 간주됩니다. 일반적으로 주문 제출, 자금 이체 또는 이메일 주소 업데이트와 비교할 때 이것이 무해한 국가 변경 이라고 생각 합니다.
상태 변경 및 HTTP 방법과 관련하여 RFC 2616 은 다음과 같이 말합니다.
특히, GET 및 HEAD 메소드는 검색 이외의 조치를 취하지 않아야한다는 협약이 확립되었습니다. 이 방법들은 "안전한"것으로 간주되어야합니다.
Magento는 토큰 (양식 키)을 사용하여 관리 영역과 프런트 엔드 영역 모두에 CSRF 방지 메커니즘을 구현합니다. Magento의 목표는 다른 개발자가 구축 할 플랫폼으로 모든 상태 변경 요청 을 보호 하는 것입니다. 그 이유는 구현 개발자 또는 타사 확장 프로그램이 실수로 무엇을 노출 시킬지 모릅니다. 타사 모듈에 의해 노출 된 것이 있고 플랫폼에 나쁜 PR이되는 것보다 모든 상태 변경 요청을 보호하는 것이 더 안전합니다. 모든 상태 변경 요청이 CSRF 공격으로부터 보호 되는지 실제로 알 수 없습니다 .
Magento는 항상 상태 변경 요청을 보호하기 위해 양식 키를 사용하지는 않습니다. 예를 들어 장바구니에서 삭제 ( /checkout/cart/delete/id/{ID}) 및 고객 주소 삭제 ( /customer/address/delete/id/{ID}) 요청은 모두 엔티티 ID를 전달하는 GET 요청입니다. 그런 다음 컨트롤러 (또는 모델)는 사용자가 해당 엔터티 레코드를 제거 할 수있는 권한을 갖도록합니다 (상태 수정). Magento가 RFC 2616을 따르지 않는 두 가지 경우 입니다. 공평하게, 일부 유스 케이스의 경우 실용적이지 않거나 필요하지 않을 수 있습니다.
Mage_Checkout_CartController::addAction메소드 의 양식 키 검사 가 버전 1.8에서 추가 된 것으로 보입니다 . 릴리스 노트에서 다음과 같은 내용을 마무리합니다.
웹 스토어에서 CSRF (Cross-Site Request Forgery)를 초래할 수있는 문제가 해결되었습니다.
불행히도 언어는 애매 모호하며 "있을 수있다"는 내가 앞서 언급 한 가정, 즉 안전한 상태 변경 요청 때문이라고 믿게한다. 의도하지 않은 동작을 유발하는 추가 매개 변수를 보낼 수 있습니다./checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
장바구니에 무언가를 추가하면 장바구니에 추가하는 동안 트리거되는 몇 가지 코드 (코어 또는 타사)가 있습니다 (예 : 일부 이벤트 전달).
그러한 취약점이 즉시 존재하지는 않을 것으로 보이며, 그렇게한다면 Magento가 세부 사항 / 위험을 공개하는 데 더 나은 일을하기를 바랍니다. 내가 볼 수있는 한 가지 위험은 Magento가 장바구니에 추가하는 동안 product_options판매 주문 항목 테이블 열에 요청 매개 변수를 맹목적으로 저장한다는 것입니다 (참조 info_buyRequest). 이론적으로 누군가가 이상한 쿼리 매개 변수와의 장바구니에 항목을 추가로 사용자 그룹을 속일 수 있고 그에 저장받을 것입니다 sales_flat_quote_item_option테이블과 결국 sales_flat_order_item그들이 있다면 테이블 도 변환에 해당 사용자를 얻을 수. 이것은 대부분의 경우 나에게는 거의 보이지 않습니다.
사람들이 FPC 구현 및 CSRF 토큰과 관련된 큰 문제 중 하나는 결국 캐시에 들어가는 것입니다. 캐시를 예열하는 첫 번째 클라이언트가 토큰을 생성하고, 두 번째 클라이언트가 캐시 HIT를 받으면 이제 첫 번째 사용자 토큰이있는 페이지가 제공됩니다. 양식을 제출하면 토큰이 일치하지 않습니다.
Magento Enterprise는 자리 표시자를 사용하여 캐시 된 페이지에서 양식 키를 찾거나 교체합니다. 바니시 구현은 폼 키가 사용되는 모든 곳에서 ESI를 사용합니다.
좀 더 인기있는 "ajax cart"확장 프로그램이 장바구니에 추가 요청 중에 CSRF 토큰을 확인하게되는지 궁금합니다.
장바구니에 추가 조치에 대한 CSRF 토큰보다 앞서 언급 한 한 가지 기능 요청은 이메일 또는 다른 웹 사이트 (소셜 미디어)에서 사용할 장바구니에 추가 링크를 작성하는 기능을 허용합니다. 때로는 마케팅 부서에서 사용자가 직접 장바구니에 품목을 추가하고 장바구니 또는 결제로 즉시 리디렉션하도록하려는 경우가 있습니다. CSRF 토큰이 필요한 경우 쉽게 수행 할 수 없습니다. 위험 수준에 익숙하고 자신과 타사 코드를 신뢰 하는 경우에만 권장 합니다.
웹 개발 원칙에 따르면 CSRF (Cross-Site Request Forgery) 또는 XSS (Cross-Site Scripting)는 바람직하지 않으며 항상 피해야합니다.
그게 무슨 뜻이야? CSRF의 경우 상태 저장 데이터 자체를 변경하는 URL을 가질 수 없습니다. 그렇지 않으면 침입자가 해당 URL을 클릭하거나 방문하도록 유도하여 (바꾸기) 개인의 장바구니 내용을 조작하거나 위시리스트 또는 비교에서 항목을 추가 / 제거 할 수 있습니다.
양식 키는 이러한 문제를 해결하는 방법입니다. Magento는 세션별로 해시를 생성하며 모든 데이터 변경 요청과 함께 제출해야합니다.
카트 항목 추가 / 제거가 심각한 공격 경로입니까? 아마도 대부분의 사이트에서는 그렇지 않을 것입니다. 그럼에도 불구하고 CSRF이고 CSRF는 나쁩니다. 이것이 바로 form_key현재 가치 가있는 이유 입니다 (CE 1.8 기준).