예상보다 긴 URL을 거부해야 합니까?

Question

애플리케이션을 개발 중이며 다음 형식의 URL이 있습니다. www.example.com/some_url/some_parameter/some_keyword.나는 의도적으로 이러한 URL이 가질 수 있는 최대 길이(그리고 여전히 유효한)가 있다는 것을 알고 있습니다.버퍼 오버플로/주입 공격으로부터 보호하기 위해 모든 요청에서 URL 길이의 유효성을 검사해야 합니까?나는 이것이 분명한 예라고 생각하지만 보안 전문가가 아니기 때문에 뭔가 빠졌을 수도 있습니다.

Answer 1

해당 입력을 기대하지 않는 경우 거부하십시오.

항상 입력 내용을 검증해야 하며 예상 범위를 벗어나는 내용은 모두 폐기해야 합니다.귀하의 URL이 특정 길이를 초과하지 않을 것임을 이미 알고 있다면 해당 URL이 애플리케이션에 도달하기 전에 거부하는 것이 현명해 보입니다.

Answer 2

심층 방어는 좋은 원칙입니다.그러나 잘못된 보안 조치는 나쁜 원칙입니다.차이점은 많은 세부 사항에 따라 다릅니다.

N 이상의 URL이 유효하지 않다고 정말로 확신한다면 이를 거부할 수도 있습니다.그러나 그것이 사실이고 입력 유효성 검사의 나머지 부분이 정확하다면 어쨌든 나중에 거부될 것입니다.따라서 이 모든 검사는 잠재적으로 코드의 다른 버그로 인한 피해를 완화하는 것입니다.N이 무엇인지 생각하는 것보다 이러한 버그를 피하는 방법을 생각하는 데 시간을 보내는 것이 더 나은 경우가 많습니다.

길이를 확인하는 경우에도 코드의 다른 곳에서 이 길이 제한에 의존하지 않는 것이 가장 좋습니다.이렇게 하면 서로 다른 검사가 더 긴밀하게 결합되고 사양을 변경하고 더 긴 URL을 허용해야 하는 경우 다음 버전에서 제한을 변경하기가 더 어려워집니다.예를 들어, 길이 제한이 적절한 주의 없이 URL을 스택에 올려놓는 구실이 된다면 누군가를 넘어지게 만들 수도 있습니다.

Answer 3

어떻게 그렇게 확신해? 모두 N보다 긴 URL은 유효하지 않습니까?확신할 수 있다면 온전한 확인을 위해 제한하는 것도 나쁘지 않습니다. 하지만 이로 인해 악용 클래스를 방지했다고 생각하는 바보가 되지 마십시오.

Answer 4

문제를 일으킬 수 있는 유일한 것은 현재 귀하의 URL이 N을 초과하지 않지만 영원히 그렇지 않을 것이라고 보장할 수는 없다는 것입니다.그리고 1년 후에 URL 길이가 N+y가 되도록 편집하기 위해 돌아가면 URL 거부 코드를 수정하는 것을 잊어버릴 수도 있습니다.

URL 매개변수를 사용하기 전에 항상 확인하는 것이 좋습니다.

Answer 5

Safari, Internet Explorer 및 Firefox는 모두 허용되는 최대 길이가 다릅니다.

나는 세 가지 중 가장 짧은 것에 투표합니다.

http://www.boutell.com/newfaq/misc/urllength.html

링크에서 가져왔습니다 -

"Microsoft Internet Explorer(브라우저) - 2,083자

파이어폭스(브라우저) - 65,536자 이후에는 Windows Firefox 1.5.x에서 위치 표시줄에 더 이상 URL이 표시되지 않습니다.그러나 더 긴 URL도 작동합니다.100,000자 이후에 테스트를 중단했습니다.

사파리(브라우저) - 최소 80,000자 이상이어야 합니다."

Answer 6

나는 이것이 어느 정도 안전을 제공할 수 있고 사람들이 당신에게 엄청나게 긴 URL을 보낼 경우 약간의 대역폭을 절약할 수 있다고 생각합니다. 그러나 대체로 실제 애플리케이션에서도 데이터의 유효성을 검사해야 합니다.일반적으로 여러 수준의 보안이 더 좋지만 처음에는 (약한) 보호 장치가 있기 때문에 나머지에는 문제가 없을 것이라고 생각하는 실수를 범하지 마십시오.

Answer 7

나는 아니오라고 말하고 싶습니다.그것은 단지 허위 보안일 뿐입니다.프로그램을 잘 작성하고 나쁜 내용에 대한 요청을 확인하세요.충분할 것입니다.

또한 미래에 대한 증거도 아닙니다.

Answer 8

예.너무 길고 확실하다면 가능한 한 빨리 거부하십시오.가능하다면 애플리케이션에 도달하기 전에 거부하십시오(예를 들어 IISLockdown이 이를 수행함).

하지만 문자 인코딩을 고려해야 합니다.

Answer 9

길이를 확인하는 것보다 내용을 확인하는 것이 좋다고 생각합니다.앞으로 URL 스키마를 어떻게 사용할지 알 수 없지만 언제든지 입력 내용을 정리할 수 있습니다.매우 복잡한 것을 매우 간단하게 표현하면 다음과 같습니다.사용자가 제공한 데이터를 신뢰하지 마세요.DB 쿼리에 직접 넣지 말고, eval()하지 말고, 아무것도 당연하게 여기지 마세요.

Answer 10

유효한 URL을 넘을 수 없다는 것을 알고 있는 경우 N bytes라면 큰 노력을 들이지 않고도 크로스 사이트 스크립팅 시도를 빠르게 거부할 수 있는 좋은 방법인 것 같습니다.

Answer 11

무엇인지 확인하는 것이 좋습니다. 요청에 URL 길이를 확인하는 것보다.

나중에 요구 사항이 변경될 수 있으며, 이 시점에서 URL 길이 유효성 검사를 제거하거나 변경해야 하며, 이로 인해 버그가 발생할 수 있습니다.

입증된 보안 취약점으로 판명되면 이를 구현할 수 있습니다.

Answer 12

좋아요, 그러한 N이 존재한다고 가정해 봅시다.누군가가 지적했듯이 N자보다 긴 잘못된 URL은 어쨌든 다른 입력 유효성 검사에 의해 거부됩니다.그러나 내 눈에는 이것이 완전히 새로운 생각을 열어준다.

이 상수를 사용하면 다른 유효성 검사를 확인할 수 있습니다.다른 유효성 검사에서 특정 URL이 유효하지 않은 것으로 감지할 수 없지만 URL이 N자보다 긴 경우 이 URL은 버그를 유발하므로 기록되어야 합니다. 전체 애플리케이션이 종료되어야 할 수도 있습니다. 충분히 짧은 잘못된 URL).

Answer 13

아, 답변도 많고 좋은 점도 많아서 널리 퍼져 있으므로 이 모든 것을 통합해 보겠습니다. tl;dr imo, 이것은 애플리케이션 계층 코드에 대한 우려 수준이 너무 낮습니다.

예, URL은 다음과 같을 수 있습니다. 어느 길이가 길지만 실제로는 브라우저에 제한이 있습니다.물론 이는 자신을 해당 벡터로 제한하려는 사람들의 브라우저 기반 공격으로부터만 보호하므로 활성 공격 시도를 처리할 수 있는 방법이 필요합니다.

좋습니다. 버퍼 오버플로로부터 보호할 수 있습니다.글쎄, 당신이 낮은 수준에서 일하고 그러한 문제에 대해 생각하지 않는 경우에만 가능합니다.요즘 대부분의 언어는 문자열을 잘 지원하며 문자열이 오버플로되는 것을 허용하지 않습니다.매우 낮은 수준의 시스템을 다루고 실제로 데이터를 바이트로 읽고 '문자열' 유형에 넣는 경우 이를 감지하고 처리할 수 있는 방법이 있어야 하지만 메모리를 할당하는 것은 그리 어렵지 않습니다. 한 번에 알려진 양을 전송하고, 따로 설정한 메모리 양을 추적하기만 하면 됩니다.솔직히 말해서 그 낮은 수준을 다루고 있다면 실제로 다른 것을 사용해야 합니다.

좋아요, 문자열 길이에 따라 거부하는 것은 어떨까요?이에 대한 가장 큰 단점은 잘못된 보안 감각이 발생할 가능성이 있다는 것입니다.즉, 코드의 일부 영역은 '엉성해'지고 피하려는 악용에 취약할 수 있습니다.이 '전역' 제한이 실제로 충분한지 확인하기 위해 분명히 주의해야 하지만 URI 형식을 고려하면 해당 '부분'이 최대 길이를 다시 보고하고 중앙에서 길이를 확인하도록 할 수 있습니다(둘 모두에 대해). 전체 문자열 및 그 구성 요소);적어도 이렇게 하면 한 부분에서 더 긴 문자열을 허용해야 하는 경우 변경 사항을 처리하기가 더 쉽습니다.

물론 여기에는 몇 가지 장점이 있습니다. 예를 들어 문자열 길이를 비교하고 요청을 즉시 거부할 수 있다는 점은 매우 빠릅니다.하지만 '잘 작동하는' 사이트라는 점을 잊지 마세요. 서버가 이를 거부하는 이유를 설명하는 적절한 응답을 다시 보내야 합니다.그러나 실제로는 이러한 유형의 '잘못된' URL을 처리해야 한다고 생각하십니까? 물론 다른 여러 가지 방법으로 잘못되었을 것입니다.

왠지 당신이 어떤 언어를 사용하고 있는지 말하지 않고 싶은 기분이 들었습니다.Java나 Python과 같은 고급 언어에는 '웹 관련'을 처리하기 위한 매우 좋은 라이브러리가 있습니다.Java에서는 해당 패턴에 대한 정규식 사용을 포함하여 URI에 대한 패턴을 지정할 수 있으므로 URL에 이름을 원하는 경우 다음과 같이 사용할 수 있습니다. @Path("/person/(.{0..100}") 매개변수를 100자로 제한합니다.Ruby나 Python과 같은 언어에 상응하는 언어가 없다면 그들은 자신을 멋진 '웹비' 언어로 홍보하기를 좋아합니다.

마지막으로 길이에 상관없이 많은 길이뿐만 아니라 검증해야 할 것입니다.버퍼 오버플로를 일으키는 URI 길이에 대해 걱정하는 것은 매우 낮은 수준의 일이며 매우 일반적이어야 합니다. 즉 잠재적으로 1GB URI가 있는 요청이라도 모든 요청을 처리해야 합니다.참고로 저는 '받아들이고 애플리케이션 계층에 전달'하는 것이 아니라 '처리'한다고 말했습니다. 낮은 수준에서 거부할 수도 있고 시스템 이벤트를 트리거할 수도 있습니다.