2
스푸핑 된 양식 제출 중단에 대한 질문이 있습니다. 어떻게하면 $_SERVER['HTTP_REFERER']을 사용하면 내 웹 사이트에서 오는 양식에만 제출할 수 있습니까? 그게 도움이 되겠습니까?! 감사!스푸핑 된 양식 제출 중지
A
답변
5
더하기 쉽게 추가 할 수 있지만 대상 공격을 중지하지 않아야합니다. HTTP_REFERER 헤더를 스푸핑 할 수는 있습니다.
클라이언트가 HTTP_REFERER을 보낼 필요가 없다는 것을 명심해야 할 것이 하나 있습니다. 따라서 헤더가 누락되면 어쨌든 제출을 허용 할 수 있습니다. 이것이 가능하지 않다면 을 확인하는 것이 도움이되지 않습니다.
"를 제외하고 컴퓨터와 인간에게 완전히 자동화 된 공공 튜링 테스트"CAPTCHA 에 대한 검색을 실행, 이것은 당신이 정말로 찾고있는 것입니다.
0
그만 하시겠습니까? 제한 없음? 혹시. 놀라운 숫자의 스푸핑 된 양식 제출으로 귀하의 웹 사이트에 실제로 피해가 발생합니까 아니면 선제 적입니까? 거기에없는 문제는 해결하지 마십시오.
+2
보안이 문제가 언제나 그곳에. 스푸핑 된 양식 제출이 문제가되는 경우 첫 번째 사건이 발생하기 전에도이를 방지해야합니다. –
3
명확하게 알려 드리겠습니다. 기술적으로는 은 불가능합니다. 스푸핑 된 양식 제출을 방지하십시오. 요약하면 다음과 같습니다.
브라우저로 처리하면 누구나 할 수 있습니다.
+2
기술적으로는 사실이지만 이전 GET없이 양식 제출을 막을 수 있습니다. 일반적인 경우에는 가능하지 않으며 따라서 XSRF (Cross Site Request Forgeries)를 방지하는 데 필요한 조치를 취하지 못한다는 결론을 사람들이 보게되는 것을 싫어합니다. –
+1
나는 당신이 정한 조건에 달려 있다고 생각합니다. 세션이 안전하고 합리적으로 짧게 인증되면 쿠키가 암호화되고 적절한 기술 (예 : 위조 방지 토큰)이 사용되며 스푸핑 된 양식을 방지하기 위해 막대를 매우 높게 설정할 수 있습니다. – tvanfosson
+0
tvanfosson/David Conrad의 의견에 추가되었습니다. 데이터베이스에서 변경해야 할 민감한 데이터, 특히 암호/전자 메일과 같은 필드에서 사용자가 암호를 입력해야하고 변수에 액세스하기 위해 $ _GET/$ _REQUEST를 사용하지 않으면 XSRF에서 도움이 될 것입니다 및 다른 쉬운 스푸핑/익스플로잇 시도. XSRF 측면에서는 계정 요청에 $ _GET/$ _REQUEST를 사용하지 않는 것이 대부분의 문제를 해결할 것이라고 생각합니다. –
0
리퍼러는 쉽게 스푸핑 될 수 있습니다.
어리석은 봇을 잡기 위해 최선의 형태를 확인하고 가능하면 서버 측 보안 문자를 사용해야합니다.
0
Referer는 스푸핑하기 쉽기 때문에 양식 제출을 스푸핑하고 싶은 공격자는 Referer 헤더를 스푸핑 할 수 있습니다. 또한 웹 브라우저가 Referer 헤더를 보내야한다고 생각하지 않기 때문에 잠재적으로 합법적 인 사용자로부터 양식 게시물을 제외시킬 수 있습니다.
0
ReCaptcha과 같은 보안 문자를 사용하십시오. 뿐만 아니라 당신은 당신의 웹 사이트를 스팸으로부터 막을뿐만 아니라 당신의 양식을 사용하는 사람들에게도 "권한을 부여"할 수 있습니다 (적어도 어느 정도는 - 당신의 양식을로드하여 보안 문자를 얻고 응답).
-1
정말 도움이되지 않습니다. 읽기 : http://shiflett.org/articles/form-spoofing
0
스푸핑 HTTP 헤더는 매우 쉽기 때문에 엄격한 보안이 필요한 항목에 사용하면 안됩니다. 일반적으로 사용되는 한 가지 방법은 양식의 숨겨진 입력에서 암호화 된 쿠키와 일치하는 암호화 된 토큰을 보내는 것입니다. 쿠키는 HTTP 전용 쿠키 여야합니다. 양식 제출시 쿠키의 값과 숨겨진 입력의 값이 일치하는지 확인하십시오. 이는 사이트에 대한 요청이 쿠키 (MIM 공격의 경우) 또는 숨겨진 입력 (스푸핑 된 양식)이 누락되어 다른 사이트에서 성공적으로 만들 수 없기 때문에 사이트 간 요청 위조를 방지하는 데 도움이됩니다. 물론, 이것은 귀하의 사이트가 그렇지 않으면 보안을 위해 토큰을 냄새 맡지 않아서 무엇을 제공해야 하는지를 확인하는 것에 달려 있습니다.
2
폼 스푸핑의 주된 문제는 클라이언트가 보내는에 대한 제어를 필요가 없다는 것입니다, 이것은 ASP.NET MVC에서 수행하는 방법에 좋은 토론입니다. 사용자는 모든 양식 매개 변수를 변경할 수 있습니다. 따라서 클라이언트가 양식 제출시 보내는 모든 내용의 유효성을 검사하고 확인해야합니다.
이렇게하면 폼에 보낼 매개 변수가 적을수록 유효성을 검사하고 확인해야하는 횟수가 줄어 듭니다. 특히 미리 설정되어 있고 사용자가 변경할 수없는 매개 변수 (즉 숨겨진 양식 필드)는 실제로 필요하지 않은 경우 양식에 포함 할 필요가 없습니다. 대신 container in the session에 저장할 수 있으며 숨겨진 필드를 통해서만이 컨테이너를 참조 할 수 있습니다. 이것이 옵션이 아니면 적어도 MAC으로 사전 설정 값을 노래하여 무결성 결함을 감지 할 수 있는지 확인하십시오.
또 다른 문제는 공격자가 반복적으로 유효한 양식 제출을 보낼 수 있도록 성공적인 양식 제출을 위해 보내야하는 양식 매개 변수가 상당히 예측 가능하다는 것입니다. 서버에서 발급 할 수 있고 양식 제출시 유효성을 확인할 수없는 예측할 수없는 매개 변수가 필요한 경우 양식 제출이 승인되었는지 확인할 수 있습니다.
한 가지 해결책은 양식 요청에서 생성 된 임의의 일회용 토큰을 사용하는 것입니다.이 토큰은 세션에 저장되고 숨겨진 입력 필드로 양식에 저장됩니다. 그런 다음 폼 제출시 토큰이 제공되었는지 여부와 세션에 저장된 토큰과 동일한 지 여부를 확인합니다. 동등한 경우 세션에서 토큰을 제거하고 양식을 처리합니다. 그렇지 않으면 양식 처리가 거부됩니다.
솔직히 양식을 먼저 요청한 다음 스푸핑 된 양식 데이터를 보낼 수 있으므로이 메커니즘은 완벽하지 않습니다. 바로 그 곳에서 Captchas 또는 자동 요청을 방지하는 다른 메커니즘을 사용할 수 있습니다.
제일 위에서 언급 한 모든 측정 값의 조합을 사용하는 것이다 :
- 가 충분히 무작위 식별자가 세션에서 폼 컨테이너를 생성하는 단계; 이 식별자를 양식 제출시 양식 컨테이너를 식별하는 양식의 숨겨진 입력 필드로 지정하십시오.
- 미리 설정된 매개 변수를 폼에서 제외 할 수 없으면 양식 컨테이너에 사전 설정된 매개 변수를 양식 대신 저장하십시오.
- 의심스럽게 반복되는 형태로 요청/양식 제출이있는 경우 MAC는
- 을 (양식 컨테이너 당 키를 사용)와, 추가로 자동 요청 또한
을 방지하기 위해 보안 문자를 사용하는 생각이 세션 기반 양식 용기도 방지 할 CSRF은 (는) 해당 식별자에 대해 예측할 수 없습니다. 제 3자를 태킹.
0
"스푸핑"의 정의가 없으면 빈 이야기가됩니다.
다양한 "스푸핑 (spoofs)"이 있습니다. 각기 다른 보호 장치가 있습니다.
대부분의 일반적인 솔루션은 보안 문자입니다.
0
토큰을 사용하는 것이 좋습니다. 널리 사용되는 MVC 아키텍처를 사용하고 있다면 스푸핑 방지가 처리되므로 걱정할 필요가 없습니다. 그러나 나 자신과 같은 커스텀 MVC 아키텍쳐를 사용한다면 토큰이 하나의 접근법이다. Database 클래스에서 모든 CRUD (CREATE, READ, UPDATE 및 DELETE) 함수에 대해 토큰을 확인하십시오. 예 : md5를 통해 토큰을 생성 할 수 있습니다.
public function save(){
if(isset($_SESSION['token']){
//proceed with saving
}else{
//kill it,
die;
}
}
양자 택일로, 당신은 쉽게 크로스 사이트 요청 위조 보호 키트를 사용하여 웹 애플리케이션을 통합 할 수 있습니다.그것을 밖으로 확인 here
'HTTP_REFERER'는 – veritas
읽기 사용자 정의 리퍼러와 요청을 준비하기 위해 쉽게 신뢰할 수 : http://stackoverflow.com/questions/233192/detecting-stealth-web-crawlers – Jacco