flash-based uploader을 구현하는 동안 Flash doesn't provide the correct cookies이라는 문제가 발생했습니다. POST 변수를 통해 PHP 세션 ID를 전달해야합니다.POST는 쿠키만큼 안전합니까?
우리는 POST PHPSESSID를 확인하면서 기능적 솔루션을 구현했습니다.
세션 ID를 쿠키로 보내는 것처럼 안전하게 게시하고 있습니까?
가능한 이유 : 둘 다 http 헤더에 있고 클라이언트가 위조 할 수 있기 때문에 가능합니다. 가능한 이유 : POST 변수를 쿠키보다 위조하기가 쉽기 때문입니다.
보안 단조와 마찬가지로 POST도 쿠키만큼 쉽습니다. 이것들은 단순히 cURL에 플래그를 설정하여 수행됩니다.
그렇게 말하면서, 당신도 좋은 해결책을 가지고 있다고 생각합니다.
활성 콘텐츠에서 세션 ID를 가져 와서 POST 할 수있는 경우 이는 세션 쿠키가 HttpOnly으로 표시되지 않았 음을 의미합니다. 호스트 쿠키 중 하나는 a good idea for defending against cross-site scripting attacks입니다.
대신 JavaScript 기반 또는 심지어는 새로 고침 기반 업 로더 모니터를 고려하십시오.이 모니터는 쿠키가 HttpOnly가 될 수있는 모든 기능과 잘 통합되어야합니다.
사이트에서 타사 콘텐츠를 허용하지 않으면 사이트 간 스크립팅 공격에 별다른 관심을 두지 않을 수 있습니다. 이 경우 POST가 정상입니다.
HTTP 요청 (컬 또는 플래시 사용)에서 위조 된 것이므로 GET을 통해 전송하는 것이 좋습니다. 중요한 점은 쿠키/게시/가져 오기 매개 변수에서 암호화되는 내용과 암호화되어 서버 측에서 확인되는 방법입니다.
POST 데이터는 HTTP 헤더가 아니지만 TCP 스트림의 일부로 전송되므로 HTTP 헤더로 읽거나 위조하기 쉽습니다. 당신이 HTTP 요청을 가로 챌 경우는 다음과 같이 보일 것입니다 :
POST /path/to/script HTTP/1.1
Host: yourdomain.com
User-Agent: Mozilla/99.9 (blahblahblah)
Cookie: __utma=whateverthisisacookievalue;phpsessid=somePHPsessionID
data=thisisthepostdata&otherdata=moredummydata&etc=blah
다른 사람이 말했듯이 그들은 모두 단지에 있기 때문에 그래서, POST 및 쿠키 (및 GET 데이터, 즉 쿼리 문자열), 모든 스푸핑하기 쉬운 동일한 HTTP 패킷의 텍스트
정말 위장하기 쉬운 것이 걱정되면 잘못된 것을 걱정하는 것입니다. 간단히 말해, 숙련 된 공격자에게는 사소한 것입니다. 당신은 다른 것을 통해 하나를 선택하여 "스크립트 꼬마 들아"를 지킬 수도 있지만, 그 사람들은 당신이 걱정할 필요가없는 사람들입니다. 자신에게 묻어야 할 질문은 "이드를 위조하는 사람에게 어떤 방비가 있습니까?" 그것은 일어날 것이다. ID가 암호화되지 않고 추측하기 쉬운 경우 문제가 발생합니다. 해킹 당할거야. 당신이 더 안전한 것을 요구하고 있기 때문에, 나는 당신이 걱정된다고 말할 것입니다.
컴파일 된 코드가 공격자 컴퓨터에 있기 때문에 응용 프로그램이 플래시이므로 javascript HTML 코드와 같이 수정할 수 있으므로 고려해야 할 사항이 있습니다. 그들은 바이너리를 살펴보고 코드의 작동 방식과 서버에서 검색해야 할 사항을 파악할 수 있습니다.
나는 쿠키와 포스트가 똑같이 안전하지 않다는 것을 반복해서 말하고 싶다.
쿠키를 사용하면 전송하기 전에 SSL을 요구할 수 있으며 HttpOnly를 지정할 수 있습니다. 즉, 쿠키가 POST보다 잠재적 인 이점을 가지고 있다고 생각 하겠지만, 이러한 보호 장치는 사용할 수 없습니다. –
content-length는 요청에서 예상되는 데이터의 양을 무한 대기 또는 버퍼 오버 플로우가 발생하지 않도록 서버에 알려주는 것이 중요합니다. –