HTTPS 쿼리 문자열은 안전합니까?

HTTPS를 사용하는 안전한 웹 기반 API를 만들고 있습니다. 그러나 사용자가 쿼리 문자열을 사용하여 암호를 포함하여 구성 할 수있게하면 이것이 안전합니까 아니면 POST를 통해 강제로 수행해야합니까?

그렇습니다. 그러나 민감한 데이터에 GET을 사용하는 것은 여러 가지 이유로 나쁜 생각 입니다.

• 대부분 HTTP 리퍼러 유출 (대상 페이지의 외부 이미지가 비밀번호를 유출 할 수 있음 [1])
• 비밀번호는 서버 로그에 저장됩니다 (분명히 나쁩니다).
• 브라우저의 히스토리 캐시

따라서 Querystring은 보안이 유지되지만 querystring을 통해 중요한 데이터를 전송하지 않는 것이 좋습니다.

[1] RFC는 브라우저가 HTTPS에서 HTTP로 리퍼러를 보내면 안된다고 명시하고 있습니다. 그러나 이것이 나쁜 타사 브라우저 툴바 또는 HTTPS 사이트의 외부 이미지 / 플래시가 누출되지 않는다는 것을 의미하지는 않습니다.

브라우저가 먼저 보안 연결을 설정 한 다음 GET 매개 변수를 포함하는 요청을 보내므로 "네트워크 패킷 감지"관점에서 GET 요청은 안전합니다. 그러나 GET url은 사용자 브라우저 기록 / 자동 완성에 저장됩니다. 예를 들어 비밀번호 데이터를 저장하기에는 적합하지 않습니다. 물론 브라우저에서 서비스에 액세스 할 수있는 더 넓은 "웹 서비스"정의를 취하는 경우에만 적용됩니다. 사용자 지정 응용 프로그램에서만 액세스하면 문제가되지 않습니다.

따라서 최소한 비밀번호 대화 상자에 게시를 사용하는 것이 좋습니다. 또한 littlegeek이 링크에서 지적한 것처럼 GET URL은 서버 로그에 기록 될 가능성이 높습니다.

예 , 검색어 문자열이 암호화됩니다.

그 이유는 쿼리 문자열이 응용 프로그램 계층 프로토콜 인 HTTP 프로토콜의 일부이고, 보안 (SSL / TLS) 부분은 전송 계층에서 오기 때문입니다. SSL 연결이 먼저 설정된 다음 쿼리 매개 변수 (HTTP 프로토콜에 속함)가 서버로 전송됩니다.

SSL 연결을 설정할 때 클라이언트는 다음 단계를 순서대로 수행합니다. example.com 이라는 사이트에 로그인하려고하고 쿼리 매개 변수를 사용하여 자격 증명을 보내 려고한다고 가정합니다 . 완전한 URL은 다음과 같습니다.

https://example.com/login?username=alice&password=12345)

1. 클라이언트 (예 : 브라우저 / 모바일 앱)는 먼저 DNS 요청을 사용하여 도메인 이름 example.com을 IP 주소 (124.21.12.31)로 확인합니다. 해당 정보를 쿼리 할 때 도메인 특정 정보 만 사용됩니다. 즉example.com 사용됩니다. 사용됩니다.
2. 이제 클라이언트는 IP 주소를 사용하여 서버 124.21.12.31에 연결을 시도하고 포트 443 (기본 HTTP 포트 80이 아닌 SSL 서비스 포트)에 연결을 시도합니다.
3. 이제 서버 example.com는 인증서를 클라이언트로 보냅니다.
4. 클라이언트는 인증서를 확인하고 세션의 공유 비밀 키 교환을 시작합니다.
5. 보안 연결을 성공적으로 설정 한 후에 만 ​​보안 연결을 통해 쿼리 매개 변수가 전송됩니다.

따라서 민감한 데이터가 노출되지 않습니다. 그러나이 방법을 사용하여 HTTPS 세션을 통해 자격 증명을 보내는 것이 가장 좋은 방법은 아닙니다. 다른 접근 방식으로 가야합니다.

예. HTTPS 세션의 전체 텍스트는 SSL로 보호됩니다. 여기에는 쿼리와 헤더가 포함됩니다. 그런 점에서 POST와 GET은 정확히 같습니다.

분석법의 보안과 관련하여 적절한 검사 없이는 실제로 말할 수있는 방법이 없습니다.

SSL은 먼저 호스트에 연결되므로 호스트 이름과 포트 번호가 일반 텍스트로 전송됩니다. 호스트가 응답하고 챌린지가 성공하면 클라이언트는 HTTP 요청을 실제 URL (예 : 세 번째 슬래시 뒤)로 암호화하여 서버로 보냅니다.

이 보안을 해제하는 방법에는 여러 가지가 있습니다.

"중간자"역할을하도록 프록시를 구성 할 수 있습니다. 기본적으로 브라우저는 실제 서버에 대한 연결 요청을 프록시에 보냅니다. 프록시가 이런 식으로 구성되면 SSL을 통해 실제 서버에 연결되지만 브라우저는 여전히 프록시와 통신합니다. 따라서 공격자가 프록시에 액세스 할 수 있으면 프록시를 통해 흐르는 모든 데이터를 일반 텍스트로 볼 수 있습니다.

귀하의 요청은 브라우저 기록에도 표시됩니다. 사용자가 사이트를 즐겨 찾기하려는 유혹을받을 수 있습니다. 일부 사용자에게는 책갈피 동기화 도구가 설치되어 있으므로 비밀번호가 deli.ci.us 또는 다른 위치에있을 수 있습니다.

마지막으로 누군가가 컴퓨터를 해킹하고 키보드 로거 또는 화면 스크레이퍼를 설치했을 수 있습니다 (많은 트로이 목마 바이러스가 있습니다). 암호는 화면에서 직접 볼 수 있기 때문에 (암호 대화 상자에서 "*"가 아닌) 또 다른 보안 허점입니다.

결론 : 보안과 관련하여 항상 구타에 의존하십시오. 당신이 알지 못하고 생각하지 않으며 목이 부러 질 수있는 것이 너무 많습니다.

모니터에서 어깨 너머로 아무도보고 있지 않는 한 가능합니다.

Slough의 응답 에서 [...] HTTP 참조 자 유출 (대상 페이지의 외부 이미지가 비밀번호를 유출 할 수 있음) 에 대한 진술에 동의하지 않습니다 .

HTTP 1.1 RFC는 다음과 같이 명시 적으로 설명합니다 .

참조 페이지가 보안 프로토콜로 전송 된 경우 클라이언트는 (비보안) HTTP 요청에 Referer 헤더 필드를 포함하지 않아야합니다.

어쨌든 서버 로그 및 브라우저 기록은 중요한 데이터를 쿼리 문자열에 넣지 않는 충분한 이유가됩니다.

그렇습니다. HTTPS 연결을 설정하는 순간부터 모든 것이 안전합니다. POST 인 쿼리 문자열 (GET)은 SSL을 통해 전송됩니다.

소금을 추가하여 MD5 해시 매개 변수로 비밀번호를 보낼 수 있습니다. 인증을 위해 서버 측에서 비교하십시오.