HTTP_REFERER를 사용하여 사이트 내부에 대한 사용자 액세스를 차단합니다.
https://stackoverflow.com/questions/3486
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
HttpServer에 대한 제어 권한은 있지만 ApplicationServer나 Java 애플리케이션에 대한 제어 권한은 없지만 해당 애플리케이션의 특정 페이지에 대한 직접 액세스를 차단해야 합니다.정확하게 말하면, 나는 사용자가 적절한 서블릿에 직접 GET/POST HTTP 요청을 보내는 양식에 대한 액세스를 자동화하는 것을 원하지 않습니다.
그래서 저는 다음의 가치에 따라 사용자를 차단하기로 결정했습니다. HTTP_REFERER.결국 사용자가 사이트 내부를 탐색하는 경우 적절한 HTTP_REFERER.글쎄, 그게 내 생각이었다.
.htaccess 파일에 다음과 같은 다시 쓰기 규칙을 구현했습니다.
RewriteEngine on
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteRule (servlet1|servlet2)/.+\?.+ - [F]
나는 사이트를 탐색하지 않고 쿼리 문자열을 사용하여 "servlet1" 또는 "servlet2" 서블릿에 직접 GET 요청을 보내는 사용자의 액세스를 금지할 것으로 예상했습니다.하지만 내 기대는 갑자기 끝났습니다. 왜냐하면 정규 표현식이 (servlet1|servlet2)/.+\?.+ 전혀 작동하지 않았습니다.
표현을 이렇게 바꿨을 때 정말 실망했어요. (servlet1|servlet2)/.+ 그리고 그것은 매우 잘 작동해서 내 사용자가 사이트를 탐색하든 안 하든 상관없이 차단되었습니다.
그래서 내 질문은 다음과 같습니다.애플리케이션을 수정할 수 있는 액세스/권한/시간이 없는 경우 특정 페이지에 직접 액세스하는 "로봇"을 허용하지 않는 작업을 어떻게 수행할 수 있습니까?
해결책
이 문제를 한 번에 해결할 수 있을지는 모르겠지만 필요에 따라 왔다갔다할 수 있습니다.
먼저, 나는 당신이 말하고 있다고 생각하는 것을 반복하고 확실히 하고 싶습니다.servlet1 및 servlet2에 대한 요청을 허용하지 않으려는 경우 요청에 적절한 리퍼러가 없고 하다 쿼리 문자열이 있나요?(servlet1|servlet2)/.+\?.+를 이해하는지 잘 모르겠습니다. servlet1과 2 아래에 파일이 필요한 것 같기 때문입니다.아마도 PATH_INFO("?" 앞)와 GET 쿼리 문자열("?" 뒤)을 결합하고 있는 것 같습니다.PATH_INFO 부분은 작동하지만 GET 쿼리 테스트는 작동하지 않는 것 같습니다.나는 script1.cgi 및 script2.cgi를 사용하여 내 서버에서 빠른 테스트를 수행했으며 다음 규칙은 귀하가 요구하는 것을 달성하는 데 효과적이었습니다.분명히 내 환경에 맞게 약간 편집되었습니다.
RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]
위의 내용은 쿼리 문자열을 사용하여 데이터를 제출하려고 시도한 script1.cgi 및 script2.cgi에 대한 모든 잘못된 참조자 요청을 포착했습니다.그러나 path_info를 사용하고 데이터를 게시하여 데이터를 제출할 수도 있습니다.나는 잘못된 리퍼러와 함께 사용되는 세 가지 방법 중 하나를 방지하기 위해 이 양식을 사용했습니다.
RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]
당신이 일하려고 했던 예에 따르면 이것이 당신이 원하는 것이라고 생각합니다.
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule (servlet1|servlet2)\b - [F]
이를 통해 적어도 목표에 더 가까워지길 바랍니다.어떻게 작동하는지 알려주세요. 귀하의 문제에 관심이 있습니다.
(그런데, 나는 리퍼러 차단이 보안이 좋지 않다는 점에 동의하지만, 릴레이션이 때로는 불완전하고 부분적인 솔루션을 강제한다는 것도 이해합니다. 이미 인정하신 것 같습니다.)
다른 팁
해결책은 없지만 사용자 에이전트는 자유롭게 리퍼러를 보내지 않거나 들어올 수 있도록 스푸핑할 수 있기 때문에 리퍼러에 의존하는 것은 결코 작동하지 않을 것이라고 확신합니다.
http 요청으로는 사용자와 악성 스크립트를 구분할 수 없습니다.하지만 어떤 사용자가 너무 짧은 시간에 너무 많은 페이지를 요청하는지 분석하고 해당 사용자의 IP 주소를 차단할 수 있습니다.
리퍼러를 사용하는 것은 확인 방법으로 매우 신뢰할 수 없습니다.다른 사람들이 언급했듯이 쉽게 스푸핑됩니다.가장 좋은 해결책은 애플리케이션을 수정하는 것입니다(가능한 경우).
CAPTCHA를 사용하거나 사용자가 마지막으로 방문한 페이지를 추적하고(세션을 스푸핑하기가 더 어려울 수 있음) 페이지 보기 기록을 추적하고 해당 페이지를 탐색한 사용자만 허용하는 일종의 쿠키 또는 세션 쿠키를 설정할 수 있습니다. 차단하려는 페이지로 이동하려면 페이지가 필요합니다.
이를 위해서는 분명히 문제의 응용 프로그램에 대한 액세스 권한이 필요하지만 가장 확실한 방법입니다(완전하지는 않지만 제 생각에는 "충분히 좋습니다").
Javascript는 화면 스크래핑을 방지(또는 적어도 지연)하는 데 유용한 또 다른 도구입니다.대부분의 자동화된 스크래핑 도구에는 Javascript 해석기가 없으므로 숨겨진 필드 설정 등의 작업을 수행할 수 있습니다.
편집하다:뭔가 라인을 따라 이 Phil Haack 기사.
화면 긁힘을 방지하려고 하는 것 같은데요?
내 솔직한 의견으로는 HTTP_REFERER의 값을 확인하여 해결하고 수정하려고 시도하는 것은 어려운 문제입니다.제출을 자동화하는 데 어려움을 겪는 사람은 '자동 장치'에서 올바른 추천자를 보낼 만큼 능숙할 것입니다.
속도 제한을 시도할 수 있지만 어느 시점에서 일종의 인간인지 확인(CAPTCHA)을 강제하도록 앱을 실제로 수정하지 않으면 이를 방지하기 어려울 것입니다.
상황을 좀 더 명확하게 하려면 다음과 같이 하세요.
예, HTTP_REFERER를 사용하는 것이 완전히 신뢰할 수 없고 다소 유치하다는 것을 알고 있지만 Excel VBA를 사용하여 자동화하는 방법을 배운 사람들은 해당 기간 내에 HTTP_REFERER를 파괴하는 방법을 알지 못할 것이라고 확신합니다. 최종 솔루션.
애플리케이션 코드를 수정할 수 있는 액세스/권한이 없습니다.정치.당신은 그것을 믿습니까?따라서 권리 보유자가 내가 요청한 내용을 변경할 때까지 기다려야 합니다.
이전 경험을 통해 요청한 변경사항이 프로덕션에 적용되기까지 2개월이 소요된다는 것을 알고 있습니다.아니요, 애자일 방법론 책을 머릿속에 던져도 아무 것도 개선되지 않았습니다.
인트라넷 앱입니다.그래서 내 명성을 훼손하려는 젊은이들이 많지 않습니다.그러나 나는 "인도에서 온 아주 멋진 글로벌 컨설팅 서비스"의 명성을 훼손하려고 할 만큼 젊지만, 이상하게도 거기에는 인도인이 단 한 명도 일하고 있지 않습니다.
지금까지 가장 좋은 답변은 "Michel de Mare"에서 나왔습니다.IP를 기반으로 사용자를 차단합니다.글쎄요, 제가 어제 그랬거든요.오늘은 VPN이나 DHCP를 사용하는 캥거루 사용자(IP 주소에서 다른 IP 주소로 점프)가 많기 때문에 좀 더 일반적인 것을 만들고 싶었습니다.
당신이 원하는 것을 달성하기 위해 안티 CSRF 토큰을 사용할 수도 있습니다.
이 기사에서는 이에 대해 더 자세히 설명합니다. 사이트 간 요청 위조
