잘못된 데이터 입력 방지
https://stackoverflow.com/questions/88962
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
데이터 유효성 검사를 데이터베이스 엔진 제약 조건에 전적으로 위임하는 것이 좋은 방법입니까?
애플리케이션에서 데이터를 검증해도 다른 소프트웨어에서 잘못된 삽입(다른 팀이 다른 언어로 작성했을 수 있음)을 방지할 수는 없습니다.데이터베이스 제약 조건을 사용하면 잘못된 입력 데이터에 대해 걱정해야 하는 지점이 줄어듭니다.
데이터베이스와 애플리케이션 모두에 유효성 검사를 적용하면 유지 관리가 지루해집니다. 애플리케이션 수를 아는 사람이 코드를 업데이트해야 하므로 인적 오류가 발생할 확률이 높아지기 때문입니다.
자유 소프트웨어 프로젝트의 코드를 보면 이런 작업이 많이 수행되는 것을 볼 수 없습니다.
해결책
가능하다면 데이터베이스에 유효성 검사 규칙을 지정하고 해당 규칙이 프런트 엔드에 표시되도록 하는 프레임워크를 사용하거나 작성하는 것이 가장 좋습니다.ASP.NET Dynamic Data는 이 작업에 도움이 되며 이를 더욱 쉽게 만들어주는 상용 라이브러리도 있습니다.
이는 간단한 입력 유효성 검사(예: 숫자 또는 날짜)와 외래 키로 제한되는 관련 데이터에 대해 모두 수행할 수 있습니다.
요약하자면, 한 곳(대부분 데이터베이스)에서 규칙을 정의하고 해당 규칙을 시행할 다른 계층에 코드를 두는 것이 아이디어입니다.
다른 팁
입력 시 유효성을 검사합니다.데이터베이스에 넣기 전에 다시 유효성을 검사하십시오.그리고 잘못된 입력을 방지하기 위해 데이터베이스 제약 조건이 있습니다.그리고 이 모든 것에도 불구하고 잘못된 데이터가 여전히 데이터베이스에 들어갈 수 있으므로 사용할 때 다시 검증하십시오.
일부 웹 앱은 Javascript를 사용하여 형식 또는 그보다 더 나쁜 형식으로 모든 유효성 검사를 수행하고 사람들이 이를 우회할 방법을 찾았기 때문에 매일 해킹당하는 것 같습니다.당신은 그것을 경계해야합니다.
편집증?나?아니요, 그냥 경험했어요.
논리를 데이터베이스에 남겨두는 경우의 단점은 해당 특정 서버의 로드가 증가한다는 것입니다.웹 및 애플리케이션 서버는 외부로 확장하기가 비교적 쉽지만 데이터베이스에는 특별한 기술이 필요합니다.일반적으로 많은 계산 논리를 애플리케이션 계층에 배치하고 데이터베이스와의 상호 작용을 최대한 단순하게 유지하는 것이 좋습니다.
그렇다면 귀하의 애플리케이션은 이러한 심각한 확장성 문제에 대해 걱정할 필요가 없을 수도 있습니다.당신이있는 경우 확실한 해당 데이터베이스 서버 로드는 가까운 미래에 문제가 되지 않을 것이므로 계속해서 데이터베이스에 제약 조건을 적용하십시오.유효성 검사 논리를 중앙 위치에 유지함으로써 시스템 전체의 구성과 단순성이 향상된다는 점은 맞습니다.
입력에 SQL을 주입하는 것 외에 다른 문제도 있습니다.사용자 입력을 받아들일 때마다 최대한 방어적인 자세를 취해야 합니다.예를 들어, 사용자는 이미지에 대한 링크를 텍스트 상자에 입력할 수 있습니다. 이는 실제로 불쾌한 작업을 실행하는 PHP 스크립트입니다.
애플리케이션을 잘 디자인했다면 모든 입력을 힘들게 확인할 필요가 없습니다.예를 들어 대부분의 작업을 처리하는 Forms API와 동일한 작업을 수행하는 데이터베이스 계층을 사용할 수 있습니다.
이는 기본적인 취약점 점검을 위한 좋은 리소스입니다.
사용자와 애플리케이션에 대한 의미 있는 검증을 제공하기에는 데이터가 데이터베이스에 도착할 때까지는 너무 늦습니다.데이터베이스가 수행되는 것을 원하지 않습니다 모두 유효성 검사로 인해 작업 속도가 상당히 느려지고 데이터베이스가 논리를 명확하게 표현하지 못합니다.마찬가지로, 성장함에 따라 데이터베이스 트랜잭션을 보완하기 위해 더 많은 애플리케이션 수준 트랜잭션을 작성하게 됩니다.
쿼리가 실패할 때 어떤 일이 발생하는지에 따라 이는 잠재적으로 나쁜 습관이라고 말하고 싶습니다.예를 들어, 애플리케이션이 지능적으로 처리한 오류가 데이터베이스에서 발생할 수 있다면 괜찮을 것입니다.
반면에 앱에 유효성 검사를 추가하지 않으면 잘못된 데이터가 없을 수도 있지만 사용자는 저장되지 않는 항목을 입력했다고 생각할 수 있습니다.
다른 목표를 손상시키지 않으면서 데이터베이스 끝에서 최대한 많은 데이터 검증을 구현하십시오.예를 들어 속도가 문제인 경우 다음을 고려해 볼 수 있습니다. ~ 아니다 외래 키 등을 사용하여또한 일부 데이터 검증은 애플리케이션 측에서만 수행될 수 있습니다(예: 이메일 주소에 유효한 도메인이 있는지 확인).
데이터베이스에서 데이터 유효성 검사를 수행할 때의 또 다른 단점은 모든 경우에 동일한 방식으로 유효성을 검사하지 않는 경우가 많다는 것입니다.실제로 애플리케이션 논리(사용자 역할)에 따라 달라지는 경우가 많으며 때로는 유효성 검사를 완전히 우회하고 싶을 수도 있습니다(크론 작업 및 유지 관리 스크립트).
데이터베이스가 아닌 애플리케이션에서 유효성 검사를 수행하는 것이 잘 작동한다는 것을 알았습니다.물론 모든 상호 작용은 애플리케이션을 거쳐야 합니다.데이터를 사용하는 다른 애플리케이션이 있는 경우 해당 애플리케이션은 일종의 API(REST도 가능)를 지원해야 합니다.
정답은 하나도 없고 용도에 따라 다르다고 생각합니다.
매우 많이 사용되는 시스템이 있고 데이터베이스 성능이 병목 현상을 일으킬 가능성이 있는 경우 검증 책임을 여러 서버로 확장하기 더 쉬운 프런트 엔드로 옮기는 것이 좋습니다.
데이터베이스와 상호 작용하는 여러 애플리케이션이 있는 경우 여러 애플리케이션에 걸쳐 유효성 검사 규칙을 복제하고 유지 관리하고 싶지 않을 수 있으므로 데이터베이스가 더 나은 위치일 수 있습니다.
사용자가 레코드를 저장하려고 할 때 유효성 검사 경고만 표시하지 않는 더 매끄러운 입력 화면을 원할 수도 있고, 데이터가 입력되어 포커스를 잃은 후 필드의 유효성을 검사할 수도 있습니다.또는 사용자가 입력하는 경우에도 유효성 검사가 실패/통과하면 글꼴 색상을 변경합니다.
또한 제약 조건과 관련하여 의심스러운 데이터에 대한 경고도 있습니다.내 애플리케이션에는 데이터베이스에 엄격한 제약 조건이 있습니다(예:누군가는 생년월일 이전에 작업을 시작할 수 없지만 프런트엔드에는 정확할 수도 있지만 의심스러운 데이터에 대한 경고가 표시됩니다(예:8세 취직 시작).
