2013-02-27 10 views
25

이 질문은 원래 코멘트 here에 질문되었습니다.filter_input()을 사용하는 경우

사용자 지정 데이터를 인쇄하기 전에 매개 변수화 된 쿼리를 사용하는 경우 htmlspecialchars()을 사용하는 경우에는 여전히 filter_input()입니까?

나에게 불필요한 것처럼 보이지만, 항상 "필터 입력, 이스케이프 출력"이라고 들었습니다. 따라서 데이터베이스 (또는 다른 형태의 스토리지)를 제외하고 입력 된 데이터를 필터링 할 필요가 있습니까?

+2

형식 정규화의 경우. 이미 쿼리 및 출력을위한 컨텍스트 - 이스케이프를 수행하는 경우 XSS 및 SQL 익스플로잇을 방지하기 위해 중복됩니다. 이메일 주소, URL 또는 일반 텍스트가 속한 실제/확인 된 이메일 주소를 가지고 있어도 좋습니다. – mario

+0

@mario "형식 정규화"가 의미하는 바를 조금 더 설명 할 수 있습니까? – Jonathan

답변

27

음, 다른 의견이있을 것입니다.

제 생각에는 당신이 항상 그것을 사용해야한다는 것입니다 (일반적으로 filter 확장 기능). 적어도 3 가지 이유가 있습니다.

  1. 위탁 입력은 항상 수행해야합니다. 함수가이 기능을 제공하기 때문에 입력을 위생 처리하는 다른 방법을 찾을 이유가 없습니다. 확장 기능이기 때문에 필터는 다른 PHP 솔루션에 비해 훨씬 빠르고 안전하며 대부분의 PHP 솔루션보다 안전합니다. 유일한 예외는 더 특수한 필터가 필요한 경우입니다. 그렇다면 FILTER_UNSAFE_RAW 필터 (# 3 참조)를 사용하여 값을 가져와야합니다.

  2. filter 확장 프로그램에는 여러 가지 유용한 기능이 있습니다. 새 니타이징 및 유효성 검사 코드를 작성하는 데 몇 시간을 절약 할 수 있습니다. 물론 모든 단일 사례를 다루는 것은 아니지만 특정 필터링/유효성 검사 코드에 더 집중할 수 있도록 충분히 있습니다.

  3. 이 기능을 사용하면 코드를 디버깅/감사 할 때 매우 유용합니다. 함수가 사용될 때 입력이 정확히 무엇인지 알 수 있습니다. 예를 들어 FILTER_SANITIZE_NUMBER_INT 필터를 사용하면 입력이 숫자가 될 것입니다 (SQL 삽입, HTML 또는 자바 스크립트 코드 없음). FILTER_UNSAFE_RAW과 같은 것을 사용하면 신중하게 다루어야하며 보안 문제를 쉽게 일으킬 수 있다는 점을 강조합니다.

+0

이 질문에 대한 좀 더 많은 의견 (답변)을 기대했지만 귀하의 답변은 매우 명확하고 많은 의미가 있습니다. 감사! – Jonathan

+0

이것은 구체적이지 않으며 예제가 없습니다. 왜 그것이 좋은가, 무엇이 잘못 될 수 있는가? 이것은 질문이었고이 대답은 적합하지 않습니다. –

23

Sverri M. Olsen이 말한 것처럼 이것에 대한 의견이 다릅니다.

나는 철학에 매우 동의한다 필터 입력, 이스케이프 출력.

사용자 제공 데이터를 인쇄하기 전에 매개 변수화 된 쿼리와 htmlspecialchars()를 사용하는 경우에도 filter_input()이 필요합니까?

짧은 대답 : IMO, 아니요. 일부 경우에 유용 할 수 있습니다.


filter_input 기능은 많은 유용한 필터를 가지고 있으며, 나는 그들 중 일부 (즉 FILTER_VALIDATE_EMAIL)를 사용합니까. validate filters유효성 입력 입력에 유용합니다. 그러나 IMO는 데이터를 변환 할 때 데이터 만 변환해야합니다.

일부 사용자는 이스케이프 입력을 권장합니다.실제로, filter_input 매뉴얼 페이지에 주어진 예제는 이것을 장려하는 것 같다.

$search_html = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_SPECIAL_CHARS); 
$search_url = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_ENCODED); 

유일한 예는 탈출을위한 것입니다. 기능의 이름 (filter_ 입력)과 결합하면 입력을 탈출하는 것이 좋습니다. 이스케이프가 필요하지만 IMO는 입력이 아닌 출력 전에 수행되어야합니다. 최소한 반환 값은 적절하게 명명 된 변수에 저장됩니다.

입력에 철저히 동의하지 않습니다. 나는 이미 너무 일찍 데이터를 변환하는 것이 문제가되는 현실 세계를 접했다.

예를 들어 Google 애널리틱스에서는 검색어 매개 변수가 제외되기 전에 인코딩 된 앰퍼샌드 (% 26)가 디코딩되도록 입력을 처리합니다. 결과적으로 내 URL에 실제로 존재하지 않는 쿼리 매개 변수에 대한 통계가 있습니다. 해결되지 않은 문제에 대해서는 my question을 참조하십시오.

Why escape-on-input is a bad idea을 읽을 수도 있습니다. 기사가 사라질 경우를 대비하여 내가 동의하는 일부 발췌 내용이 있습니다.

는 [...] 탈출-에 입력 것은가 [...] 그것이 레이어 위반 그냥 잘못이다 -이 처리 입력에 우려를 포맷 출력을 혼합합니다. 계층 적 위반은 코드를 이해하고 유지하는 것을 훨씬 어렵게 만듭니다. 왜냐하면 각 구성 요소와 계층이 자체 작업을 수행하는 대신 다른 계층을 고려해야하기 때문입니다.

당신은 기본적으로 데이터를 손상했다. 이 시스템은 [...] 이제 데이터가 올 것에 대한 누워있다.

입력에 이스케이프

만 개 이상의 출력의 문제, 그것은 것입니다 처리하지 않을 것이다 실제로 많은 출력에 대해 데이터를으로 잘못 지정하십시오.

PHP 마법 따옴표라는 기능을하는 데 사용됩니다. 그것은 [...] 모든 종류의 문제를 일으킨 입력에서 벗어나는 기능이었습니다. [...] Lerdorf에 따르면 훨씬 더 새로운 PHP 필터 확장은 "magic_quotes right done"입니다. 그러나 여기에 설명 된 거의 모든 문제로 인해 여전히 어려움을 겪고 있습니다.

는 어떻게 (이 다양한 필터를 가지고 있다는 사실 이외의) 마법의 따옴표보다 필터 확장 낫다? 필터는 마법 인용과 동일한 문제를 유발합니다.여기


은 내가 사용하는 코딩 규칙이다 : $ _POST에

  • 값, $ _GET, $ _REQUEST 등 이스케이프 안 항상 안전하지 않은 것으로 간주한다
  • 값은 데이터베이스에 기록되거나 $ _SESSION에 저장되기 전에 의 유효성을 검사해야합니다.
  • 숫자 또는 부울로 예상되는 값은 삭제되어야합니다. 데이터베이스에 기록 또는 숫자 및 부울 데이터베이스의 값과 $ _SESSION 실제로 숫자 또는 부울입니다 $ _SESSION
  • 신뢰에 저장되기 전에 2 SQL 이스케이프 모든 SQL 쿼리에 직접 사용하기 전에해야
  • 문자열 값
  • 문자열 값 HTML 출력에 사용되기 전에 HTML 이스케이프되어야 준비된 문 (비 문자열 값 2을 살균한다) 또는 사용 (문자열이 아닌 값을 살균한다 2)
  • 문자열 값해야 쿼리 문자열에 사용되기 전에 백분율로 인코딩됩니다. 문자열이 아닌 값 2)
  • 을 위해 변환 된 데이터

을 저장) 등 * _url * _html * _sql로 (용어

를 가변 명명 규칙을 사용하여 살균한다 내 여기에서 목적은 위에 사용 된 용어를 정의하는 방법입니다. 모든 가정을 확인하는 수단에 검증

  1. 값은 예상대로 정확히 (즉 $ ID_NUM을해야 함을 확인할 수 있도록하는 수단을 살균하는 값
  2. 를 갖는 등의 특정 형식을 갖는 등의 데이터 나 필수 필드에 대해 이루어지고() 몇 가지 예외가있을 수 있습니다 일반적으로 숫자에 불과)

요약

을 포함하지, 내가 권하고 싶습니다 다음 출력

    • 사용 validate filters 사용 sanitize filters
    • 입력 에 대한 것은 TIMTOWDI 기억 - 예를 들어, 내가 반드시 htmlspecialchars()를 FILTER_SANITIZE_FULL_SPECIAL_CHARS 또는 FILTER_SANITIZE_SPECIAL_CHARS 이상 (더 많은 옵션을 가지고있는) (선호 줄 바꿈을 피하는)
  • +0

    나는 이것을 읽는 데 많은 시간을 할애하고 매우 구체적인 google api에 대한 한 가지 예를 찾습니다. 대답을 주셔서 감사합니다. 그러나 질문은 "왜"였습니까? 그리고이 대답은 대답하지 않습니다. –

    관련 문제