URL에서 base64로 인코딩 된 문자열 전달

GET 매개 변수를 통해 원시 base64로 인코딩 된 문자열을 전달하는 것이 안전합니까?

아니요, base64 문자열에는 데이터의 의미를 변경할 수있는 "+", "="및 "/"문자가 포함될 수 있으므로 URL을 인코딩해야합니다. 하위 폴더처럼 보입니다.

유효한 base64 문자는 다음과 같습니다.

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=

추가적인 base64 사양이 있습니다. (자세한 내용은 여기 표를 참조하십시오 ). 그러나 기본적으로 인코딩하려면 65 문자가 필요합니다 : 26 소문자 + 26 대문자 + 10 자리 = 62.

두 개의 [ '+', '/']와 패딩 문자 '='가 더 필요합니다. 그러나 그중 어느 것도 URL 친화적이지 않으므로 다른 문자를 사용 하면 설정됩니다. 위의 차트에서 표준 문자는 [ '-', '_']이지만, 동일한 문자를 해독하고 다른 문자와 공유 할 필요가없는 한 다른 문자를 사용할 수 있습니다.

나는 당신 자신의 도우미를 작성하는 것이 좋습니다. base64_encode 에 대한 PHP 매뉴얼 페이지 의 주석에서 이와 같이 :

function base64_url_encode($input) {
 return strtr(base64_encode($input), '+/=', '._-');
}

function base64_url_decode($input) {
 return base64_decode(strtr($input, '._-', '+/='));
}

@joeshmo 또는 도우미 함수를 작성하는 대신 base64로 인코딩 된 문자열을 urlencode 할 수 있습니다. 이것은 도우미 기능과 똑같은 일을하지만 두 가지 추가 기능이 필요하지 않습니다.

$str = 'Some String';

$encoded = urlencode( base64_encode( $str ) );
$decoded = base64_decode( urldecode( $encoded ) );

소개 참고 여기에 대한 답변 중 일부가 약간 잘못되어 있기 때문에 약간의 설명을 게시하는 경향이 있습니다.

대답은 NO입니다 . 더하기 부호는 $ _GET 전역 배열 내에서 SPACE로 변환되므로 URL 쿼리 문자열 내에서 base64로 인코딩 된 매개 변수를 전달할 수 없습니다. 즉, test.php? myVar = stringwith + sign 을 보낸 경우

//test.php
print $_GET['myVar'];

결과는 다음과 같습니다.
stringwith sign

이 문제를 해결하는 쉬운 방법 urlencode()은 쿼리 문자열에 base64 문자열을 추가하여 +, = 및 / 문자를 % ## 코드로 이스케이프 처리하는 것입니다. 인스턴스에 대한 urlencode("stringwith+sign")반환stringwith%2Bsign

액션을 처리 할 때 PHP는 $ _GET 전역을 채울 때 쿼리 문자열을 자동으로 디코딩합니다. 예를 들어, test.php? myVar = stringwith % 2Bsign 을 보낸 경우

//test.php
print $_GET['myVar'];

결과는 다음과 같습니다.
stringwith+sign

당신은 할 수 없습니다 원하는 urldecode()+의이 공간으로 변환됩니다으로는 $ _GET 문자열을 반환했습니다.
즉, 동일한 test.php? myVar = stringwith % 2Bsign 을 보낸 경우

//test.php
$string = urldecode($_GET['myVar']);
print $string;

결과는 예기치 않은 것입니다.
stringwith sign

rawurldecode()입력에 안전 하지만 중복되어 불필요합니다.

예, 아니오

base64의 기본 문자 집합은 경우에 따라 URL에 사용 된 기존 규칙과 충돌 할 수 있습니다. 그러나 많은 base64 구현을 통해 문자 집합을 변경하여 URL을 더 잘 일치 시키거나 Python과 같은 URL을 제공 할 수도 있습니다 urlsafe_b64encode().

직면 할 수있는 또 다른 문제는 URL 길이 제한 또는 그와 같은 제한이 없다는 것입니다. 표준은 최대 길이를 지정하지 않기 때문에 브라우저, 서버, 라이브러리 및 HTTP 프로토콜을 사용하는 기타 소프트웨어는 자체 제한을 정의 할 수 있습니다. 이 문서를 한 번 봐 걸릴 수 있습니다 : WWW FAQ를 :의 URL의 최대 길이 무엇입니까?

그것의 base64url 인코딩은 위의 joeshmo 코드의 확장입니다.

function base64url_encode($data) {
return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
}

function base64url_decode($data) {
return base64_decode(str_pad(strtr($data, '-_', '+/'), strlen($data) % 4, '=', STR_PAD_RIGHT));
}

예를 들어 "="문자는 원시 기본 64에서 사용되며 매개 변수를 HTTP GET의 값과 구별하는 데 사용되기 때문에 이것이 안전하다고 생각하지 않습니다.

이론적으로, 클라이언트 또는 서버의 최대 URL 및 / 또는 쿼리 문자열 길이를 초과하지 않는 한 가능합니다.

실제로는 상황이 조금 까다로워 질 수 있습니다. 예를 들어, 값에 "on"이 포함되고 후행 "=="로두면 ASP.NET에서 HttpRequestValidationException을 트리거 할 수 있습니다.

base64.urlsafe_b64encode(...)파이썬에서 와 같이 URL 안전 인코딩을 위해 아래 코드는 100 % 나에게 효과적입니다.

function base64UrlSafeEncode(string $input)
{
   return str_replace(['+', '/'], ['-', '_'], base64_encode($input));
}

예, 항상 안전합니다. 물론 base64는 다음을 포함 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/= 하지만 base64로 인코딩 된 문자열은 보통 no +입니다. +공백으로 변환되어 잘못된 디코딩 문자열이 생성됩니다. /get 매개 변수 쌍에서 안전합니다. =는 항상 base64로 인코딩 된 문자열의 끝에 있으며 서버 측에서 =직접 확인할 수 있습니다.