사용자 입력을 삭제하는 것이 가장 좋은 때는 언제인가요?

https://stackoverflow.com/questions/34896

09-06-2019
|

문제

사용자는 신뢰할 수 없습니다.신뢰할 수 없는 사용자의 입력을 절대 신뢰하지 마세요.나는 그것을 이해한다.그러나 입력을 삭제하기에 가장 좋은 시기는 언제인지 궁금합니다.예를 들어, 사용자 입력을 맹목적으로 저장한 다음 액세스/사용될 때마다 이를 삭제합니까, 아니면 입력을 즉시 삭제한 다음 이 "정리된" 버전을 저장합니까?어쩌면 이것 외에도 제가 아직 생각해보지 않은 다른 접근 방식이 있을 수도 있습니다.나는 첫 번째 방법을 더 선호합니다. 왜냐하면 사용자 입력에서 나온 모든 데이터는 여전히 조심스럽게 접근해야 하기 때문입니다. 여기서 "정리된" 데이터는 여전히 무의식적으로 또는 우발적으로 위험할 수 있습니다.어느 쪽이든, 사람들은 어떤 방법이 가장 좋다고 생각하며, 그 이유는 무엇입니까?

해결책

나는 가능한 한 빨리 이를 삭제하는 것을 좋아합니다. 즉, 사용자가 유효하지 않은 데이터를 입력하려고 하면 삭제가 발생한다는 의미입니다.연령에 맞는 TextBox가 있고 숫자 이외의 다른 항목을 입력하는 경우 문자에 대한 키 누르기가 통과되지 않도록 합니다.

그런 다음 데이터를 읽는 것이 무엇이든(종종 서버) 데이터를 읽을 때 더 확고한 사용자(예: 파일을 직접 편집하거나 패킷을 수정하는 등)로 인해 실수가 없는지 확인하기 위해 온전한 검사를 수행합니다. !)

편집하다:전반적으로, 조기에 정리하고 단 1초라도 데이터를 놓친 경우 언제든지 정리하십시오(예:파일 저장 -> 파일 열기)

다른 팁

불행하게도 참가자 중 자신이 말하는 내용을 명확하게 이해하는 사람은 거의 없습니다.문자 그대로.@Kibbee만이 이를 바로잡았습니다.

이번 주제는 위생처리에 관한 것입니다.하지만 사실은 모두가 그토록 이야기하고 싶어하는 광범위한 "범용 위생 처리"와 같은 것입니다. 그냥 존재하지 않습니다.

있다 엄청나게 다양한 매체, 각각 필요 그것은 고유한 데이터 형식입니다. 게다가 - 심지어 단일 특정 매체에는 해당 부분에 대해 다른 형식이 필요합니다..HTML 형식은 HTML 페이지에 포함된 자바스크립트에는 쓸모가 없습니다.또는 문자열 형식은 SQL 쿼리의 숫자에 쓸모가 없습니다.

사실, 대부분의 찬성 답변에서 제안된 것처럼 "가능한 한 빨리 위생 처리"하는 것은 단지 불가능한.데이터가 어떤 특정 매체 또는 매체 부분에 사용될지 알 수 없기 때문입니다.예를 들어, 우리는 움직이는 모든 것을 피하면서 "sql-injection"으로부터 방어할 준비를 하고 있다고 가정해 보겠습니다.그런데 앗!- 일부 필수 필드가 채워지지 않았으므로 데이터베이스 대신 양식에 데이터를 다시 입력해야 합니다...모든 슬래시가 추가되었습니다.

반면에 우리는 "사용자 입력"을 모두 부지런히 탈출했습니다 ...하지만 SQL 쿼리에서는 숫자나 식별자이므로 주위에 따옴표가 없습니다.그리고 어떤 "위생 처리"도 우리에게 도움이 되지 않았습니다.

세 번째로, 좋습니다. 우리는 끔찍하고 신뢰할 수 없으며 경멸받는 "사용자 입력"을 삭제하는 데 최선을 다했습니다...하지만 일부 내부 프로세스에서 우리는 어떤 형식도 지정하지 않고 바로 이 데이터를 사용했습니다(이미 최선을 다했기 때문입니다!).모든 영광을 누리며 2차 주입을 받았습니다.

따라서 실제 사용 관점에서 볼 때 유일한 올바른 방법은 다음과 같습니다.

"위생 처리"가 아닌 서식 지정
사용 직전
특정 매체 규칙에 따라
이 매체의 다양한 부분에 필요한 하위 규칙도 따릅니다.

나는 Radu와 마찬가지로 사용자 데이터를 삭제합니다...

regex를 사용하고 허용 가능한 문자를 모두 사용하여 허용 가능한 문자를 제어하여 JavaScript 또는 OnChange 또는 OnBlur와 같은 이벤트에 연결된 JavaScript 또는 jQuery를 제어하여 제출할 수 있기 전에 허용되지 않은 입력을 제거합니다.그러나 이것이 실제로 해당 사용자에게 알리는 효과가 있다는 사실을 알고 데이터가 서버 측면도 확인 될 것입니다.실제 보호보다 경고입니다.
둘째, 요즘에는 더 이상 이 작업을 거의 못하는데, 첫 번째 확인은 서버 측에서 완료는 양식이 제출되는 위치를 확인하는 것입니다.유효한 것으로 지정한 페이지에서만 양식 제출을 허용합니다 위치, 데이터를 읽기 전에 스크립트를 죽일 수 있습니다.부여 자체 서버를 가진 좋은 해커가 '스푸핑'할 수 있기 때문에 그 자체로는 충분하지 않습니다 도메인과 IP 주소를 모두 사용하여 스크립트에 오는 것처럼 보이도록 합니다. 유효한 양식 위치에서.
다음으로, 이런 말을 할 필요도 없지만 항상, 그리고 내 말은 언제나, 스크립트를 오염 모드로 실행하십시오.이것은 당신이 게으르지 않고 단계 4에 대해 부지런히하도록 강요합니다.
적절한 형식의 정규식을 사용하여 가능한 한 빨리 사용자 데이터를 삭제합니다. 양식의 지정된 필드에서 예상되는 데이터입니다.다음과 같은 지름길을 사용하지 마십시오. 악명 높은 '유니콘의 마법 뿔'당신의 오염 수표를 날려 버리기 위해 ...또는 모든 좋은 점을 위해 처음부터 테인트 검사를 끄는 것이 좋습니다 그것은 당신의 보안을 위해 할 것입니다.그것은 사이코패스에게 날카로운 칼을 주는 것과 같습니다. 목을 조르고, '그걸로 날 해치지 않을 거야'라고 말하더군요.

그리고 여기에 내가 이 네 번째 단계에서 대부분의 다른 사람들과 다른 점이 있습니다. 보안을 제공 할 수있는 방식으로 실제로 사용할 사용자 데이터 시스템 호출, 다른 변수에 대한 할당 또는 쓰기와 같은 위험 데이터를 저장합니다.사용자가 입력 한 데이터 만 사용하여 데이터와 비교하는 경우 나는 시스템에 직접 저장했습니다 (따라서 내 자신의 데이터가 안전하다는 것을 알고 있음). 그런 다음 사용자 데이터를 삭제하지 않아도됩니다. 이는 보안 문제로 나타납니다.예를 들어 사용자 이름 입력을 다음과 같이 사용합니다. 예를 들면 다음과 같습니다.사용자가 입력 한 사용자 이름을 사용하여 일치 항목과 비교합니다. 내 데이터베이스, 그리고 사실이면 그 후에 데이터베이스의 데이터를 사용하여 수행합니다. 다른 모든 함수는 스크립트에서 호출 할 수 있으며 안전하다는 것을 알고 있습니다. 그 후에 사용자 데이터를 다시 사용하십시오.
마지막으로, 요즘 로봇이 시도하는 모든 자동 제출을 필터링하는 것입니다. Captcha와 같은 '인간 인증' 시스템.이것은 요즘 충분히 중요합니다 사진을 사용하는 나만의 '인간 인증'스키마를 작성하는 데 시간이 걸렸습니다 그리고 '인간'이 그림에서 보는 것을 입력하기 위한 입력입니다.나는 이것을했다. Captcha 유형 시스템이 사용자를 정말 짜증나게 한다는 것을 알았습니다( 일그러진 글자를 해독하느라 눈을 가늘게 뜬 채로...보통 이상과 다시).이는 SendMail 또는 SMTP를 사용하는 스크립트에 특히 중요합니다 이메일의 경우 배고픈 스팸 봇이 즐겨 찾기입니다.

한마디로 정리하자면 아내에게 하는 것처럼 설명을 하자면...서버는 인기 있는 나이트클럽과 같으며 경비원이 많을수록 문제가 줄어들 수 있습니다 나이트 클럽에서.문 밖에 경비원 2명이 있고(클라이언트측 확인 및 사람 인증) 문 안에 경비원 1명이 있습니다(유효한 양식 제출 위치 확인 중...)'Is that really you on this ID'), 그리고 몇 명의 경비원이 더 있습니다. 문에 근접(테인트 모드를 실행하고 좋은 규칙을 사용하여 사용자 데이터).

나는 이것이 오래된 게시물이라는 것을 알고 있지만 여기를 방문한 후 그것을 읽을 수 있는 사람이 자신의 게시물이 '아니요'라는 것을 깨닫게 될 만큼 충분히 중요하다고 느꼈습니다.마법의 총알' 보안에 관해서는 사용자가 제공한 데이터를 안전하게 만들기 위해 이러한 모든 작업이 서로 결합되어 필요합니다.이 방법 중 한두 가지만 사용하는 것은 실질적으로 가치가 없습니다. 모두가 함께 팀을 이루어야 그 힘이 존재하기 때문입니다.

아니면 요약하자면, 우리 엄마가 자주 말씀하셨던 것처럼...'죄송합니다보다 더 안전".

업데이트:

요즘 제가 하고 있는 또 다른 일은 모든 데이터를 Base64로 인코딩한 다음 SQL 데이터베이스에 상주할 Base64 데이터를 암호화하는 것입니다.이런 방식으로 저장하려면 총 바이트 수의 3분의 1 정도가 더 필요하지만 보안상의 이점이 데이터의 추가 크기보다 더 크다고 생각합니다.

어떤 종류의 소독을 하고 있는지에 따라 다릅니다.

SQL 삽입을 방지하려면 데이터 자체에 아무 작업도 수행하지 마세요.준비된 명령문을 사용하면 사용자가 입력한 데이터가 엉망이 되어 논리에 부정적인 영향을 미치는 것에 대해 걱정할 필요가 없습니다.요청에서 나온 모든 것이 문자열이기 때문에 숫자가 숫자이고 날짜가 날짜인지 확인하기 위해 약간의 정리가 필요하지만 블록 키워드 등의 작업을 수행하기 위해 검사를 시도하지 마십시오.

XSS 공격으로부터 보호하려면 데이터를 저장하기 전에 수정하는 것이 더 쉬울 것입니다.그러나 다른 사람들이 언급한 것처럼 때로는 사용자가 입력한 내용을 정확하게 그대로 유지하는 것이 좋은 경우가 있습니다. 한번 변경하면 영원히 잃어버리기 때문입니다.준비된 쿼리를 사용하여 SQL 삽입에 걸리지 않도록 애플리케이션이 삭제된 HTML만 출력하도록 보장하는 확실한 방법이 없다는 것은 거의 안타까운 일입니다.

가장 중요한 것은 탈출할 때 항상 일관성을 유지하는 것입니다.실수로 이중 소독을 하는 것은 형편없는 일이며, 소독을 하지 않는 것은 위험합니다.

SQL의 경우 데이터베이스 액세스 라이브러리가 값을 자동으로 이스케이프하는 바인드 변수를 지원하는지 확인하세요.사용자 입력을 SQL 문자열에 수동으로 연결하는 사람이라면 누구나 더 잘 알 것입니다.

HTML의 경우 가능한 마지막 순간에 이스케이프하는 것을 선호합니다.사용자 입력을 파괴하면 다시 되돌릴 수 없으며, 실수를 하면 나중에 편집하고 수정할 수 있습니다.원래 입력을 파괴하면 영원히 사라집니다.

파싱을 시도하기 전에는 초기가 좋습니다.나중에 출력할 내용이나 특히 다른 구성 요소(예: 셸, SQL 등)에 전달하려는 내용은 모두 삭제해야 합니다.

하지만 너무 지나치지 마세요. 예를 들어 비밀번호는 저장하기 전에 해시됩니다(맞죠?).해시 함수는 임의의 이진 데이터를 허용할 수 있습니다.그리고 절대 비밀번호를 인쇄하지 않을 것입니다(맞죠?).그러므로 비밀번호를 분석하거나 삭제하지 마세요.

또한 신뢰할 수 있는 프로세스에서 삭제 작업을 수행하고 있는지 확인하세요. JavaScript/클라이언트 측 모든 것이 쓸모없는 보안/무결성보다 더 나쁩니다.(하지만 일찍 실패하는 것이 더 나은 사용자 경험을 제공할 수도 있습니다. 두 곳 모두에서 수행하면 됩니다.)

Perl에는 정규식으로 검사할 때까지 모든 사용자 입력을 "오염됨"으로 간주하는 오염 옵션이 있습니다.오염된 데이터는 사용하고 전달할 수 있지만 오염되지 않을 때까지 접촉하는 모든 데이터를 오염시킵니다.예를 들어 사용자 입력이 다른 문자열에 추가되면 새 문자열도 오염됩니다.기본적으로 오염된 값을 포함하는 모든 표현식은 오염된 결과를 출력합니다.

오염된 데이터는 마음대로 던져질 수 있지만(데이터가 흘러가면서 오염됨) 외부 세계에 영향을 미치는 명령에 의해 사용되자마자 Perl 스크립트는 실패합니다.따라서 오염된 데이터를 사용하여 파일을 생성하고, 쉘 명령을 구성하고, 작업 디렉토리를 변경하는 등의 작업을 수행하면 Perl은 보안 오류와 함께 실패하게 됩니다.

나는 "taint"와 같은 것을 가지고 있는 다른 언어를 알지 못하지만 그것을 사용하는 것은 매우 놀라운 일이었습니다.오염된 데이터를 즉시 제거하지 않으면 오염된 데이터가 얼마나 빨리 퍼져나가는지 놀랍습니다.사용자 데이터를 기반으로 변수를 설정하거나 파일을 여는 등 프로그래머에게 자연스럽고 일반적인 일들은 오염이 활성화되면 위험하고 위험해 보입니다.따라서 작업을 완료하는 가장 좋은 전략은 외부에서 일부 데이터를 얻는 즉시 오염을 제거하는 것입니다.

그리고 나는 이것이 다른 언어에서도 가장 좋은 방법이라고 생각합니다.버그와 보안 허점이 너무 멀리 전파되지 않도록 사용자 데이터를 즉시 검증하세요.또한 잠재적인 허점이 한 곳에 있는 경우 보안 허점이 있는지 코드를 감사하는 것이 더 쉬워야 합니다.그리고 나중에 어떤 데이터가 어떤 목적으로 사용될지 예측할 수 없습니다.

내 의견은 가능한 한 빨리 클라이언트 측과 서버 측에서 사용자 입력을 삭제하는 것입니다. 저는 이렇게 하고 있습니다.

(클라이언트 측), 사용자가 다음을 수행할 수 있도록 합니다. 필드에 특정 키만 입력합니다.
(클라이언트 측), 사용자가 onBlur를 사용하여 다음 필드로 이동하면 입력 한 입력을 테스트합니다. 정규 표현식에 대해 뭔가 좋지 않은 경우 사용자에게 알립니다.
(서버 측), 입력을 다시 테스트하고, 필드가 INTEGER여야 하는 경우 (PHP에서는 is_numeric()를 사용할 수 있음), 필드에 잘 알려진 형식이 있는 경우 정규 표현식에 대해 확인하십시오. 다른 사람들 (예 : 텍스트 주석), 그냥 그들을 피하십시오.의심스러운 것이 있으면 스크립트 실행을 중지하고 사용자가 입력한 데이터가 유효하지 않다는 알림을 사용자에게 반환합니다.

실제로 공격 가능성이 있는 것처럼 보이면 스크립트가 나에게 메일과 SMS를 보내므로 가능한 한 빨리 이를 확인하고 방지할 수 있습니다. 모든 사용자 입력을 로그인하는 로그를 확인하면 됩니다. 입력을 수락하거나 거부하기 전에 스크립트가 수행한 단계입니다.

데이터를 저장하기 전에 정리하세요.일반적으로 사전 성형을 해서는 안 됩니다. 어느 먼저 입력을 정리하지 않고 SQL 작업을 수행합니다.SQL 주입 공격을 받고 싶지는 않습니다.

저는 이런 기본적인 규칙을 따릅니다.

POST를 통해 INSERT, UPDATE, DELETE와 같은 SQL 작업 수정만 수행하세요.절대 GET하지 마세요.
모든 것을 탈출하세요.
사용자 입력이 무엇인가를 기대한다면 그것이 무엇인가를 확인하십시오.예를 들어, 번호를 요청한 다음 번호인지 확인하세요.검증을 사용하세요.
필터를 사용하세요.원하지 않는 문자를 정리합니다.

유저들은 악마다!

항상 그런 것은 아닐 수도 있지만, 내 접근 방식은 백엔드 근처에 위험한 것이 없도록 항상 즉시 위생 처리하는 것입니다.

추가 이점은 입력 시점에서 정리하면 사용자에게 피드백을 제공할 수 있다는 것입니다.

모든 사용자가 악의적이라고 가정합니다.가능한 한 빨리 모든 입력 내용을 삭제하세요.마침표.

나는 데이터를 처리하기 직전에 데이터를 삭제합니다.이름과 성 필드를 가져와서 데이터베이스에 삽입되는 세 번째 필드에 연결해야 할 수도 있습니다.어떤 종류의 처리 또는 삽입 오류도 발생하지 않도록 연결을 수행하기 전에 입력을 삭제하겠습니다.빠를수록 좋다.프런트 엔드(웹 설정에서)에서 Javascript를 사용하는 경우에도 처음부터 서버로 데이터가 이동하지 않고 발생하기 때문에 이상적입니다.

무서운 부분은 데이터베이스에서 나오는 데이터도 삭제하기를 원할 수도 있다는 것입니다.최근 급증하고 있는 ASPRox SQL 주입 공격은 해당 데이터베이스의 모든 데이터베이스 테이블을 감염시키기 때문에 치명적입니다.동일한 데이터베이스에서 여러 계정이 호스팅되는 곳에 데이터베이스가 호스팅되는 경우 다른 사람의 실수로 인해 데이터가 손상되었지만 이제는 자신의 초기 잘못이 없기 때문에 방문자에게 악성 코드를 호스팅하는 대열에 합류했습니다. .

물론 이로 인해 사전에 많은 작업이 필요하지만 데이터가 중요하다면 가치 있는 투자입니다.

즉시 청소하면 두 가지 장점이 있다는 것을 알았습니다.첫째, 이를 검증하고 사용자에게 피드백을 제공할 수 있습니다.둘째, 다른 곳에서 데이터를 소비하는 것에 대해 걱정할 필요가 없습니다.

사용자 입력은 애플리케이션의 하위 계층으로 내려지기 전에 항상 악의적인 것으로 처리되어야 합니다.항상 가능한 한 빨리 삭제된 입력을 처리하고 악의적인 의도를 확인하기 전에 어떤 이유로든 데이터베이스에 저장해서는 안 됩니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow