나는 이런 식으로 뭔가 보이는 MVC 응용 프로그램의 컨트롤러에 SPA에서 '비밀번호 찾기'과정을 시작하는 데 사용되는 아약스 호출이 있습니다특정 사이트의 게시물에 대한 컨트롤러 작업을 제한하는 속성이 MVC에 있습니까?
[HttpPost]
public JsonResult ResetPassword(User acct)
{
...
}
을 나는이 컨트롤러를 제한하는 방법이 있었다 기대했다 해당 페이지의 게시물 만 내가 생각할 수있는 사용자 지정 특성을 작성할 수는 있지만, 이것이 누군가가 이미 수행 한 공통적 인 문제라고 기대하고있었습니다. 그리고 네, 스푸핑 된 리퍼러 데이터를 포함하는 위조 된 헤더가 가능하다는 사실을 깨달았지만, 보안이 강화되면 더 많은 마음을 갖게 될 것입니다. 아니면 누구나 똑같은 것을 성취 할 수있는 더 좋은 방법을 제안합니까?
도움 주셔서 감사합니다.
짧은 대답은 당신이 할 수 없다는 것입니다. 언급 한 바와 같이, 당신은 리퍼러 헤더 (HttpRequest.Referrer)를 사용을 시도 할 수 있지만,이 여러 가지 이유로 신뢰할 수 없습니다입니다 :
HttpRequest.UserHostAddress은 다소 신뢰할 수 있습니다. 그러나 다시 한번, 요청에 의존하는 IP 주소는 아니지만 다시 요청이 프록시되거나 방화벽을 통해 들어오는 경우 실제 클라이언트가 아닌 프록시 주소를 얻게 될 것입니다. IP 주소. 그것이 번거 로움 조금 비록
:
가장 신뢰할 수있는 방법이 인증서를 통해 클라이언트 인증을 구현하는 것입니다 클라이언트가 올바른을 제공해야 인증서 요청의 일부로 서버와 일치하는 인증서도 있어야합니다.
입력 해 주셔서 감사합니다! 위조 방지 토큰 제안이 좋은 해결책이되지 못하는 이유가 있습니까? – David
위조 토큰은 IP 주소로 요청을 제한하지 않고 사이트 간 요청 위조를 방지합니다. 자세한 내용은 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) 및 http://en.wikipedia.org/wiki/Cross-site_request_forgery –
을 참조하십시오. 이것에 대한 실제 사용을 조사한 후에 클라이언트 인증을 사용하기로 결정했습니다. 우리의 목적을 위해 번거 로움은 부가적인 보안의 가치가 있습니다. – David
HTTP에서 referer header을 확인할 수 있습니다. 그러면 요청이 만들어진 페이지가 나타납니다.
예, HTTP 헤더가 쉽게 스푸핑 될 수 있으므로 안전하지 않다는 점에 유의해야합니다.
난 당신이 토큰 안티 위조를 사용할 수 있습니다 생각하는 사람들이 아직도 가짜 헤더, 나는 당신이 "마음의 평화"아마 실제보다 더 망상이라고 말하고 싶지만 수 (내가 말할 점을 감안
http://kamranicus.com/blog/posts/70/protip-using-anti-forgery-token-with-aspnet-web-ap/
이것은 완벽 할 것입니다! 나는 내가 필요한 것에 이것을 비틀 수 있다고 생각한다. 내 API를 직접 호출하지 않습니다. JQuery는 (다른 것들 중에서) 요청을 내부 전용 API로 중계하는 MVC 컨트롤러를 호출한다. 그래서 저는 여전히 위조 방지 토큰을 그들이 한 것과 비슷한 방식으로 사용할 수 있다고 생각합니다. 감사! – David
좋은 방법으로). 어쨌든 여전히 더 크고 전반적인 보안 그림을 해결해야 할 것이므로 실제로 얻는 것은 무엇입니까? –